the-web-application-hackers-handbook

Chapter 12 n Attacking Users: Cross-Site Scripting 495
output validation are subject to bypasses. By employing both techniques, the
application gains some additional assurance that an attacker will be defeated
even if one of its two filters is found to be defective. Of the two defenses, the
output validation is the most important and is mandatory. Performing strict
input validation should be viewed as a secondary failover.
Of course, when devising the input and output validation logic itself, great
care should be taken to avoid any vulnerabilities that lead to bypasses. In particular,
filtering and encoding should be carried out after any relevant canonicalization,
and the data should not be further canonicalized afterwards. The
application should also ensure that the presence of any NULL bytes does not
interfere with its validation.
Eliminate Dangerous Insertion Points
There are some locations within the application page where it is just too inherently
dangerous to insert user-supplied input, and developers should look for
an alternative means of implementing the desired functionality.
Inserting user-controllable data directly into existing script code should be
avoided wherever possible. This applies to code within tags, and also
code within event handlers. When applications attempt to do this safely, it is
frequently possible to bypass their defensive filters. And once an attacker has
taken control of the context of the data he controls, he typically needs to perform
minimal work to inject arbitrary script commands and therefore perform
malicious actions.
Where a tag attribute may take a URL as its value, applications should generally
avoid embedding user input, because various techniques may be used to
introduce script code, including the use of scripting pseudo-protocols.
A further pitfall to avoid is situations where an attacker can manipulate the
character set of the application’s response, either by injecting into a relevant
directive or because the application uses a request parameter to specify the
preferred character set. In this situation, input and output filters that are well
designed in other respects may fail because the attacker’s input is encoded
in an unusual form that the filters do not recognize as potentially malicious.
Wherever possible, the application should explicitly specify an encoding type
in its response headers, disallow any means of modifying this, and ensure that
its XSS filters are compatible with it. For example:
Content-Type: text/html; charset=ISO-8859-1
Allowing Limited HTML
Some applications need to let users submit data in HTML format that will be
inserted into application responses. For example, a blogging application may