Why are the default characters in BadURLChars?
search cancel

Why are the default characters in BadURLChars?


Article ID: 50747


Updated On:


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



Why are the default characters in BadURLChars and what is the security risk involved if they are removed?


Please know that these defaults are only guidelines, and that your application teams should always do their own risk assessment of characters and then you can add to, or subtract from our defaults as they see fit.

Why are .. ./ /. // /* *. ~ \ in badurlchars?

In earlier versions of webservers, the webserver acted much like a web based windows explorer, and there were many ways to access content that would not match a SiteMinder realm configuration.

For instance, you could access in a browser:

In SiteMinder your realm resource filter is:

So SiteMinder would not match on this URI and would consider it unprotected.

But the webserver would interpret the ./ as "this directory", and it would give you:

The same goes for ~ and // and \ The ~ could be used as windows shorthand to represent a directory which again would not match a SiteMinder realm filter. The // could be used to start at the document root, or sometimes drive root of the webserver.

Most or all of these directory manipulations have been prevented at the webserver level now, but we still leave them in as SiteMinder defaults just in case.

Why are non-printable characters (%00-%1f and %7f-%ff) and %25 (which is the encoded % sign) in badurlchars?

This is a general safety net to prevent ASCII character tricks like non-canonical UTF8 sequences, like those:


Component: SMAPC