The software fails to adequately filter user-controlled input
for alternate script syntax.
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Demonstrative Examples
Example 1
In the following example, an XSS sanitization routine checks for the
lower-case "script" string but fails to account for alternate strings
("SCRIPT", for example).
(Bad Code)
Java
public String sanitize(String input, String mask) {
Resolve all filtered input to absolute or canonical representations
before processing.
Carefully check each input parameter against a rigorous positive
specification (white list) defining the specific characters and format
allowed. All input should be sanitized, not just parameters that the
user is supposed to specify, but all data in the request, including tag
attributes, hidden fields, cookies, headers, the URL itself, and so
forth. A common mistake that leads to continuing XSS vulnerabilities is
to validate only fields that are expected to be redisplayed by the site.
We often encounter data from the request that is reflected by the
application server or the application that the development team did not
anticipate. Also, a field that is not currently reflected may be used by
a future developer. Therefore, validating ALL parts of the HTTP request
is recommended.
This involves "HTML Entity Encoding" all non-alphanumeric characters
from data that was received from the user and is now being written to
the request.
With Struts, you should write all data from form beans with the bean's
filter attribute set to true.
Additionally, to help mitigate XSS attacks against the user's session
cookie, set the session cookie to be HttpOnly. In browsers that support
the HttpOnly feature (such as Internet Explorer), this attribute
prevents the user's session cookie from being accessed by client-side
scripts, including scripts inserted due to a XSS attack.