How BadURLChars, BadQueryChars and BadFormChars settings work.
search cancel

How BadURLChars, BadQueryChars and BadFormChars settings work.

book

Article ID: 52507

calendar_today

Updated On:

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On

Issue/Introduction

Description:

It is also important to understand that BadCSSChars ACO setting overwrites all the configuration settings in BadURLChars, BadQueryChars. So, use it as your overriding configuration setting.

BadForms on the other hand lets you allow these chars in the Form so it works the other way around.

 

Environment

Release:
Component: SMAPC

Resolution

Solution:

BadURLChars

In the Agent's configuration 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. By default, the Web Agent rejects URL requests that include these 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

These default characters block URLs that might allow a malicious Web client to evade SiteMinder rules.

For the BadURLChars parameter:

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

  • You can also specify ranges of characters separated by a hyphen. The syntax is: <starting_character>-< ending_character>

  • For example, you can enter a-z as a range of characters.

  • If you want to specify quotes (") for the BadQueryChars, or BadCSSChars, you cannot enter this character in ASCII form-use the hexadecimal equivalent, which is %22. For example, BadFormChars="<,>,&,%22"

BadQueryChars

If you do not wish to allow escaped characters in query data, you can block the percent character (%) by using the BadQueryChars parameter. This parameter is configured in the same manner and works exactly the same as BadURLChars, except that it checks characters following the '?' character, or "hook," in a URL. For example, you might set BadQueryChars to a value of %25.

Note: The quotation mark (") must be entered as %22, the hexadecimal equivalent of the ASCII character.

By default, this setting does not function unless values are specified.

When BadQueryChars is enabled, the web agent will perform a character by character comparison of the defined sequence.

Therefore;

"abc" would only stop the sequence "abc" and not "afbh" for example.

There is a difference when the URL contains a ASCII sequence "%0d" versus the ASCII 10 (unprintable newline) character. For the first one you need to have %250d and for the second one you need %0d.

Apache in Reverse Proxy Mode

When an agent is deployed, and in the Agent Configuration Object (ACO), %25 or %2520 is in the BadURLChars list, the Webagent will not give any problems when the URL contains %20 as long as the request is not reverse proxyed. If it is reverse proxyed, then "HTTP 500 Server error 00-0002" is displayed. Both of these scenarios is as per design.

If the URL contains encoded characters such as %25, %20, %23 then the web server decodes these encoded characters as %, space and #. This decoded string is then checked for valid characters as per Bad URL chars list.

As part of fix 52884 (delivered in 6QMR4-CR04), it was required that in case of proxy request, these characters (%25, %20, %23 etc.) should not be decoded. So the code changes were done to get parsed URL (i.e. decoded) in case of non proxied request and unparsed URL (i.e. not-decoded) in case of proxied request.

In case it is required that URL should contain %20 and request should be proxied, then "%25" "%2520" should not be present in the Bad URL chars list.