Skip to content
CA Single Sign-On - 12.52 SP1
Documentation powered by DocOps

Help Prevent Attacks

Last update September 12, 2017

This content describes how to configure CA Single Sign-On to help prevent attacks.

Protect Web Sites Against Cross-Site Scripting

A Cross Site Scripting (CSS) attack can occur when the input text from the browser (typically, data from a post or data from query parameters on a URL) is displayed by an application without being filtered for characters that may form a valid, executable script when displayed at the browser.

An attack URL can be presented to unsuspecting users. When a user clicks on the URL, an application may return a display to the browser that includes the input characters, along with an error message about bad parameters on the query string. The display of these parameters at the browser can lead to an unwanted script being executed on the browser.

For example, when a user types news into a search engine web page, the application normally might return a blank field, or a response, such as:

Your search for news returned the following:

In response to an attack URL, the browser might receive a response, such as:

news<script>BadProgram</script>

The BadCSSChars parameter does not interpret the double quotation mark (") if it is entered as an ASCII character. To include the double quotation mark as a bad cross-site scripting character, enter the hexidecimal equivalent of the ASCII character, which is %22. For example:

BadCSSChars="%22"

Prevent Cross-Site Scripting Attacks in Web Agent FCC Pages

To prevent cross-site scripting attacks against the web agent FCC pages, use HTML encoding to ensure that your FCC variable data is rendered correctly.

HTML encoding ensures that the characters are treated as their literal value and not as HTML syntax. Encoding ensures that the damaging cross-site scripting syntax is rendered as literal text as it must appear and that the browser does not execute the code while rendering the HTML form. You can encode all the syntax that could be misused during an attack.

The fcchtmlencoding parameter instructs an agent to apply an HTML encoding algorithm to all the values inserted into the FCC variables that have the following syntax:

$$varname$$

If the characters that are traditionally blocked are necessary in the FCC data, then enable the fcchtmlencoding parameter.

  • fcchtmlencoding
    Specifies whether the HTML encoding is enabled to prevent Cross-Site Scripting attacks against web agent FCC pages. This parameter does not block any characters.
    Values: Yes and No.
    Default: No

The fcchtmlencoding parameter applies to all the variable substitutions for all the FCC forms. An agent using this parameter can serve one or more FCC forms.

To apply the HTML encoding to a specific character in an FCC file, use the following parameter:

  • fcchtmlencodingchars
    Fetches the specific character value, applies the HTML encoding, and substitutes the actual character value with the encoded value in an FCC file.
Important! To use the fcchtmlencodingchars parameter, the fcchtmlencoding parameter must be set to no.

To apply the HTML encoding to a specific variable in an FCC file, use the following function:

  • HTMLENCODE
    Fetches the specific variable values, applies the HTML encoding, and substitutes the actual variable values with the encoded values in an FCC file.

The HTMLENCODE function has the following syntax:

$$htmlencode(varname)$$
Important! To use the HTMLENCODE function, the fcchtmlencoding parameter must be set to No.

Configure the Web Agent to Check For Cross Site-Scripting

To instruct the Web Agent to check a URL for characters that may be part of an executable script, set the following ACO parameter to Yes.

CSSChecking

Enable this parameter to configure the Web Agent to scan a full URL, including the query string, for escaped and unescaped versions of the following default character set:

    • left and right angle brackets (< >)
    • single quote (')

Default: Yes 

Define Valid Target Domains

To configure agents to help protect your resources from phishing attempts that could redirect users to a hostile website, set the following configuration parameter:

ValidTargetDomain

Specifies the domains to which a credential collector is allowed to redirect users. If the domain in the URL does not match the domains set in this parameter, the redirect is denied.

Default: No.

All advanced authentication schemes, including forms credential collectors (FCCs) support this parameter.

The ValidTargetDomain parameter identifies the valid domains for the target during processing. Before the user is redirected, the agent compares the values in the redirect URL against the domains in this parameter. Without this parameter, the agent redirects the user to targets in any domain.

The ValidTargetDomain parameter can include multiple values, one for each valid domain.

For local agent configurations, specify an entry, one entry per line, for each domain, for example:

validtargetdomain=".xyzcompany.com"

validtargetdomain=".abccompany.com"

Protect J2EE Applications against Cross-Site Scripting Attacks

You can prevent an attacker from bypassing cross-site scripting protection by using noncanonical (overlong) unicode characters in a request.

Follow these steps:

  1. Set the value of the CSSChecking parameter to yes.
  2. Set the value of the following parameter to yes:
    • DisallowUTF8NonCanonical
      Prevents attackers from sending noncanonical (overlong) Unicode (utf-8) characters in requests and attempting to bypass cross-site scripting protection. When the value of this parameter is yes, the agent blocks requests for URLs containing noncanonical (overlong) Unicode characters.
      Default: Yes

Override the Default CSS Character Set

By default, the agent checks for the following default cross-site scripting character set:

  • Left and right angle brackets (>)
  • Single quote  (')

To override the default character set, use the BadCSSChars parameter.

  • BadCSSChars
    Overrides the default cross-site scripting character set with the characters of your choice. Include the entire string of characters that you want.
    Default: <,',>
    A comma separates the characters.

    Example:
     <,> 
    In this example, the agent scans only for the left and right angle brackets.

    Value: 
    Enter a set of characters. Note the following guidelines:
    • The maximum number of characters is 4096, including commas, which separate the characters.
    • Specify a range of characters by separating them with a hyphen. The syntax is: starting_character-ending_character. For example, a-z is a range of characters.
    • The BadCSSChars parameter does not interpret the double quotate marks (") when it is entered as an ASCII character. To include the double quote marks as a bad cross-site scripting character, enter the hexidecimal equivalent of the ASCII character, which is %22. For example: BadCSSChars="%22" 

If the agent detects a problem related to the character set, it returns an Access Denied message to the user, and the logs the following message in the Agent error log:

Caught Possible Cross Site Scripting Violation in URL. Exiting with HTTP 403 ACCESS FORBIDDEN.

Some applications require the use of quote marks in the query string, irrespective of the web server platform. For example, some Domino applications, such as iNotes Web Access, require the use of a single quote character.

To use applications that require quotes in the query string, remove the quote mark from the BadCssChars parameter.

Specify Bad Query Characters

To prevent certain characters the query string portion of a URL, set the following parameter:

BadQueryChars

Specifies characters that the Web Agent prohibits in the query string portion (following the '?') in a URL.

Default: Empty (any characters allowed in query strings)

Limits:

The default hexadecimal numbers apply to English characters. For other languages, remove any hexadecimal values that correspond to the characters of the language that you want to allow. Examples of such languages include (but are not limited to), Brazilian Portuguese, French, Japanese, and Chinese.

You can specify characters literally. You can also enter the URL-encoded form of that character. For example, you can enter the letter a, or you can enter the encoded equivalent of %61.

You can specify a maximum number of 4096 characters (including commas that are used for separating characters).

You can specify ranges of characters that are separated with hyphens. The syntax is: starting_character-ending_character. For example, you can enter a-z as a range of characters.

Specify any quotation marks (") with the URL-encoded equivalent of %22. Do not use ASCII.

Example: %25 blocks URL-encoded characters in queries.

Web Agents search for prohibited characters in query strings by comparing the characters in the query string of the URL with the ASCII values of the characters defined in the BadQueryChars parameter. For an example, see the following process;

  1. The BadQueryChars parameter contains the URL-encoded value for the percent symbol (%) as shown in the following example:

    %25

  2. The Web Agent receives an HTTP request that contains the following query string:

    xxx=%0d

  3. The Web Agent examines the URL in the previous example, but does not decode the URL-encoded values. For example, the Web Agent interprets the previous example (in Step 2) as the literal string %0d, and not as a carriage return.
  4. The Web Agent examines the values in the BadQueryChars parameter, and converts them to their ASCII values. For example, the %25 in Step 1 is converted to a percent symbol (%).
  5. The Web Agent compares each character in the URL against the decoded ASCII values from the BadQueryChars parameter.
  6. The Web Agent blocks the request, because the ASCII percent symbol (%) exists in both of the following places:
    • The query string of the URL.
    • The decoded (ASCII) value in the BadQueryChars parameter.

To block certain characters from query strings, set the value of the BadQueryChars parameter to include the characters you want to block.

Specify Bad URL Characters

You can list a set of character sequences that cannot be part of a URL request. These are treated by the Agent as bad URL characters. The Web Agent will refuse URL requests that contain any of the characters or strings of characters that you include in this list. The checking is done on the URL before the "?" character. The Web Agent rejects URL requests that include such characters because a malicious Web client might use such characters to evade policy rules.

When a Web Agent refuses a URL request containing a Bad URL character, the web server responds with one of the following messages:

  • Internal Server Error
  • Web Page not Found (404) Error

Check your Web Agent logs for information on how the Agent is handling requests.

You specify the characters with the following parameter:

BadUrlChars

Specifies the character sequences that cannot be used in URL requests. The Web Agent checks the characters in the URL that occur before the "?" character against the list in this parameter. If any of the specified characters are found, the Web Agent rejects the request.

You can specify the following characters:

    • a backward slash (\)
    • Two forward slashes (//)
    • Period and a forward slash (./)
    • Forward slash and a period (/.)
    • Forward slash and an asterisk (/*)
    • An asterisk and a period (*.)
    • A tilde (~)
    • %2d
    • %20
    • %00-%1f
    • %7f-%ff
    • %25

Separate multiple characters with commas. Do not use spaces.

You can use the bad URL characters in CGI parameters if the question mark (?) precedes the bad URL characters.

Default: Disabled (all characters are allowed).

Limits:

The default hexadecimal numbers apply to English characters. For other languages, remove any hexadecimal values that correspond to the characters of the language that you want to allow. Examples of such languages include (but are not limited to), Brazilian Portuguese, French, Japanese, and Chinese.

You can specify characters literally. You can also enter the URL-encoded form of that character. For example, you can enter the letter a, or you can enter the encoded equivalent of %61.

You can specify a maximum number of 4096 characters (including commas that are used for separating characters).

You can specify ranges of characters that are separated with hyphens. The syntax is: starting_character-ending_character. For example, you can enter a-z as a range of characters.

Specify any quotation marks (") with the URL-encoded equivalent of %22. Do not use ASCII.

To specify Bad URL characters, edit the value of the BadURLChars parameter to include the characters that you want to block.

Note: When configuring the Apache 2.0 Reverse Proxy Server and Outlook Web Access (OWA), be sure to turn off the BadURLChars parameter. OWA allows unrestricted characters in the email subject that might be listed in the BadURLChars parameter.

Enable Bad Form Characters

The following characters are commonly used in cross-site scripting attacks:

  • Left and right brackets (< >)
  • ampersand (&)
  • quotation marks (")

If you want to use scripting code for presenting forms to a user during an authentication challenge, enable the following parameter to configure the Web Agent to block any special characters before sending them to an HTML form:

  • BadFormChars
    Specifies the characters that the Web Agent blocks before using them as output on a form. If enabled and if the agent name part of the URL has one or more characters that are specified in this parameter, then the login page returns the following error message:

    Internal Server Error
    

    Default: Disabled (characters are not blocked)
    Examples: <, >, &, %22
    Limits:

  • You can specify the characters literally.
    • You can specify a maximum number of 4096 characters (including commas that are used for separating the characters).
    • You can specify ranges of characters that are separated with hyphens. The syntax is: starting_character-ending_character. For example, you can enter a-z as a range of characters.
    • Specify the quotes (") with the URL-encoded equivalent of %22. Do not use ASCII.

Follow these steps:

  1. Log in to the Administrative UI.
  2. Open the Agent Configuration Object in which you want to enable this parameter.
  3. Enable the BadFormChars parameter by removing the # character in front of it.
    The BadFormChars parameter is enabled with the default values.
  4. (Optional) Remove any characters that you do not want to use from the list. You can add any other character to this list. Verify that the characters are separated from one another by a comma.

Help Prevent DNS Denial Of Service Attacks

If a web server receives HTTP requests with false IP addresses, the Web Agent tries to resolve the IP addresses to fully qualified domain names. For large volumes of HTTP requests, a denial-of-service condition could affect the Web Agent and possibly the DNS servers. The following parameter controls whether the Web Agent performs DNS lookups:

DisableDNSLookup

Prevents the Web Agent from performing DNS lookups. This includes both reverse (IP to FQDN) and forward (FQDN to IP) DNS lookups.

Default: No

Follow these steps:

  1. Verify that the DisableDNSLookup parameter does not end with an s. Some earlier versions of the ACO templates and LocalConfig.conf files possibly contain this error. The correct parameter ends with a p.
  2. Set the value of the DisableDNSLookup parameter to yes.
Important! When the value of this parameter is set to yes, fully qualified domain names are required for cookie-based functions to work properly.

Protect Resources Without Extensions

To prevent unauthorized users from gaining access to resources without extensions, you can use the following parameter:

OverrideIgnoreExtFilter

Specifies a list of strings you want the Web Agent to match against all URIs. This helps you protect resources whose extensions are normally ignored by the Web Agent, or any files or applications that do not have extensions. If the URI matches one of the strings in the list, the Web Agent checks with the Policy Server to determine if the resource is protected.

It is better to specify more general strings instead of exact paths. You can also include a partial string to protect a group of resources. For example, the string /servlet/ protects the following resources:

    • /dira/app1/servlet/app
    • /dirb/servlet/app1
    • /dirc/mydir/servlet/app2

Default: No default

To protect resources without extensions, add strings for the resources (without periods) that you want to protect to the value of the OverrideIgnoreExtFilter parameter. If you are using an Agent Configuration Object, use the multi-value option to add the strings. If you are using a local configuration file, add each string on its own line.

Disable POST Preservation

If you do not need to use POST preservation, you may disable it with the following parameter:

PreservePostData

Specifies whether the Web Agent preserves POST data when redirecting requests. When the user is challenged for advanced authentication, such as forms or certificate authentication, the post data is preserved during the authentication phase.

Default: Yes

To disable POST preservation, set the value of the PreservePostData parameter to no.

Secure Applications

An unauthorized user can append a false file name that contains an extension that the Web Agent is configured to ignore to the end of a URL . The Agent then allows the unauthorized user access to the resource. To have the Web Agent deny access to such attempts, use the following parameter:

SecureApps

Prevents the Agent from authorizing URLs from an unauthorized user. If your Web Agent is configured to ignore requests for files ending with certain extensions, an attacker can attempt to access resources by creating a false URL.

For example, if you have a resource with the following URL:

/scripts/myapp

An attacker may attempt to gain access by creating a false URL like the one in the following example:

/scripts/myapp/junk.jpg

If the value of the SecureApps parameter is set to no, the request for /scripts/myapp/junk.jpg is automatically authorized if the Web Agent was set to ignore requests for .jpg files.

If the value of the SecureApps parameter is set to Yes, and a URI ends in an extension, the Web Agent determines whether the URL maps to a physical resource. For example, if the URI is /scripts/myapp/junk.jpg, the Web Agent calls the web server to map the URI to the physical resource junk.jpg. If the web server cannot resolve the resource, the agent blocks the request. Blocking the request ensures that the agent does not mistakenly grant access to /scripts/myapp using a malformed URI. 

Default: No

Ensure Agent Responses Comply with X-Frame-Options

The X-Frame-Options HTTP header determines whether a browser loads a web page that is embedded or framed in another web page using the <frame> tag. If you use the X-Frame-Options response header in your web applications, ensure that Web Agent responses, such as the login.fcc form response, comply with the X-Frame-Options response header by setting the XFrameOptions ACO parameter. Specifying a value for this parameter sets a Web Agent response with the correct X-Frame-Options header.

XFrameOption

The available values for the XFrameOptions parameter are the same as the values for the X-Frame-Options response header:

Values: DENY, SAMEORIGIN, ALLOW-FROM uri
The X-Frame-Options is described by RFC 7024

Default: None (the header is not set)

Example: XFRAMEOptions = SAMEORIGIN

Was this helpful?

Please log in to post comments.

  1. Ujwol Shrestha
    2017-09-10 08:17

    Setting DisableDNSLookup=yes, disables both reverse (IP to hostname) and forward (hostname to IP ) DNS lookups. The current description seems to indicate that it disables only reverse DNS lookup ..which is NOT correct.

    1. Gayathri Karanam
      2017-09-11 01:51

      Hi Ujwol: I have added clarification on forward and reverse lookups. The updated topic will be reflected when the doc space is republished. Thanks for your suggestion.