Explanation of BadFormChars ACO

Products

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

Issue/Introduction

The current documentation has this definition of BadFormChars:

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.

How exactly does this differ from older versions and how does it work in practice?

Environment

Release:
Component: SMPLC

Resolution

One of the issues researching this topic was the conflicting information and data depending on the age of the KB or document they looked at. Over the years, as CSS/XSS checking has advanced, the product design around the various ACOs, CSSChecking, BadCSSChars, BadFormChars, etc has evolved as well.

Originally, BadFormChars did not block characters, it encoded them as literal HTML characters. And it was limited to a specific set of 4 characters.

BadFormsChars="<,>,&,""

< was encoded as <
> was encoded as >
& was encoded as &
" was encoded as "

It was not designed or intended to scan the actual FCC source code or filter the POST data. It was meant to apply during a GET request when FCC directives like $$variable$$ are used. It will also apply to the FCC hidden variables which become POST data during the POST request.

Please note that SiteMinder does not provide any support for filtering POST data. This is the responsibility of the application that is receiving the data.

Here is what was changed and how it works in the newer releases:
- BadFormChars now accepts any character in the ACO so that it is on par with the other CSS/XSS ACOs rather than being limited to a specific set.
- BadFormChars now requires a " to URL-encoded in the ACO value as %22.
- BadFormChars now blocks, rather than encodes, any character listed in the ACO.

The application of the ACO remains the same in that it applies to GET requests, does not scan the FCC source code or POST data. And for additional clarification, none of the ACOs like BadCSSChars, BadURLChars, BadQueryChars, or BadFormChars will filter or block the POST data.