Help Prevent Attacks

This content describes how to configure  to help prevent attacks.
sm1252sp1
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.
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)$$
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. For example, include '\' to avoid Java script attacks.
    Default:
    <,',>
    A comma separates the characters.
    Example:
    <,>,\
    In this example, Agent scans only for the left and right angle brackets along with the backslash.
    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.
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.
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:
sm1252sp1
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