How to block UNICODE in XSS attacks via BadCssChars ACO Parameter
Article ID: 263587
Updated On:
Products
Issue/Introduction
Potential vulnerability as the result of embedding a XSS attack within a Unicode payload.
EXAMPLE:
Unicode Encoded Payload:
http://myserver.example.com/siteminderagent/forms/smpwservices.fcc?USERNAME=\u003cimg\u0020src\u003dx\u0020onerror\u003d\u0022confirm(window.origin)\u0022\u003e&SMAUTHREASON=7
Decoded Payload:
http://myserver.example.com/siteminderagent/forms/smpwservices.fcc?USERNAME=<img src=x onerror="confirm(window.origin)">&SMAUTHREASON=7
Environment
PRODUCT: Siteminder
COMPONENT: Web Agent; Access Gateway
VERSION: r12.8.x
OPERATING SYSTEM: ANY
Cause
While ASCII and Unicode are both popular character encoding standards, only US-ASCII is supported as a Uniform Resource Locator (URL) as per HTTP RFC 1738 Section 2.2 "URL Character Encoding Issues"
==========================
RFC 1738 Uniform Resource Locators (URL)
2.2. URL Character Encoding Issues
URLs are sequences of characters, i.e., letters, digits, and special characters. A URLs may be represented in a variety of ways: e.g., ink on paper, or a sequence of octets in a coded character set. The interpretation of a URL depends only on the identity of the characters used.
In most URL schemes, the sequences of characters in different parts of a URL are used to represent sequences of octets used in Internet protocols. For example, in the ftp scheme, the host name, directory name and file names are such sequences of octets, represented by parts of the URL. Within those parts, an octet may be represented by the character which has that octet as its code within the US-ASCII [20] coded character set.
In addition, octets may be encoded by a character triplet consisting of the character "%" followed by the two hexadecimal digits (from "0123456789ABCDEF") which forming the hexadecimal value of the octet. (The characters "abcdef" may also be used in hexadecimal encodings.)
Octets must be encoded if they have no corresponding graphic character within the US-ASCII coded character set, if the use of the corresponding character is unsafe, or if the corresponding character is reserved for some other interpretation within the particular URL scheme.
No corresponding graphic US-ASCII:
URLs are written only with the graphic printable characters of the US-ASCII coded character set. The octets 80-FF hexadecimal are not used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent control characters; these must be encoded.
=============================
Resolution
When the Policy Store is initially implemented, there are two options for importing the 'Default' policy store objects/templates. You can import either 'smpolicy.xml' or 'smpolicy-secure.xml'. The 'smpolicy-secure.xml' is significantly more restrictive.
========================
[smpolicy.xml]
CSSChecking=yes
#BadCssChars=
#BadFormChars= <,>,&,%22
#BadQueryChars=
BadUrlChars=//,./,/.,/*,*.,~,\,%00-%1f,%7f
========================
[smpolicy-secure.xml]
CSSChecking=yes
#BadFormChars=<,>,&,%22
BadCssChars=<,>,',;,),(,&,+,%00
BadQueryChars=<,>,',;,),(,&,+,%00
BadUrlChars=//,./,/.,/*,*.,~,\,%00-%1f,<,>,',;,),(,&,+,%7f
========================
Configure the web agent's ACO as follows:
CSSChecking = true
BadCssChars=<,>,',;,),(,%00,%22,%27,\
BadUrlChars=//,./,/.,/*,*.,~,\,%00-%1f,%7f
Alternative: BadQueryChars can be used instead of 'BadCssChars' since BadQueryChars applies to the characters to the right of the query string resource identifier.
The 'forward slash' (/) is the reserved character in the http rfc to denote the virtual directory. In the use case, it's a back-slash (\) denoting the Unicode value. By default the back slash is included in the 'BadUrlChars' ACO parameter, however the BadUrlChars applies to only the characters to the LEFT of the query string resource identifier (?).
By adding the back slash character to the 'BadCssChars' it will apply to the entire URL. BadQueryChars applies to the characters to the right of the query string resource identifier.
Additional Information
Feedback
