CA SiteMinder® agents can help prevent attacks using the parameters described in the following procedures:
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"
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.
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 variable in an FCC file, use the following function:
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.
To instruct the Web Agent to check a URL for characters that may be part of an executable script, set the CSSChecking parameter to yes. By enabling this parameter, the Web Agent scans a full URL, including the query string, for escaped and unescaped versions of the following default character set:
You can prevent an attacker from bypassing cross-site scripting protection by using noncanonical (overlong) unicode characters in a request.
Follow these steps:
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: No
By default, the agent checks for the following default cross-site scripting character set:
To override this default character set, specify a BadCSSChars agent parameter that defines a character set of your choice.
If specified, overrides the default cross-site scripting character set with the characters of your choice. Include the entire string of characters that you want.
Default: (<,',>)
Example: <,> (In which case, the agent scans only for the left and right angle brackets)
Limits:
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 the quote characters in the query string, irrespective of the web server platform. For example, some Domino applications, such as iNotes Web Access, require the use of single quotes.
To use applications that require quotes in the query string, remove quotation marks from the BadCssChars parameter.
To prevent certain characters the query string portion of a URL, set the following parameter:
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:
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;
%25
xxx=%0d
To block certain characters from query strings, set the value of the BadQueryChars parameter to include the characters you want to block.
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 CA SiteMinder® rules.
When a Web Agent refuses a URL request containing a Bad URL character, the web server responds with one of the following messages:
Check your Web Agent logs for information on how the Agent is handling requests.
You specify the characters with the following parameter:
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:
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:
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.
The following characters are commonly used in cross-site scripting attacks:
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:
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:
Follow these steps:
The BadFormChars parameter is enabled with the default values.
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:
Prevents the Web Agent from performing DNS lookups.
Follow these steps:
Important! When the value of this parameter is set to yes, fully qualified domain names are required for cookie-based functions to work properly.
To prevent unauthorized users from gaining access to resources without extensions, you can use the following parameter:
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:
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.
If you do not need to use POST preservation, you may disable it with the following parameter:
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.
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:
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 may 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 would be 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, the Web Agent attempts to discover if the resource is legitimate or if the URL is false.
Default: No
To secure applications, set the value of the SecureApps parameter to yes.
If you use the X-Frame-Options response header in your web applications, you can ensure that any customized responses from your agent return this header properly. The setting in the X-frame options header determines if the browser renders a page with content between a <frame> or an <iframe> tag.
You can determine whether the custom responses from your agent comply with X-frame-options with the following parameter:
Specifies whether custom responses comply with the x-frame-options response headers. Setting this parameter sets any custom responses with the correct x-frame-options header.
Default: None
Example: SAMEORIGIN
To ensure that your custom responses comply with x-frame options, set the value of the XFrameOptions parameter to yes.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|