the-web-application-hackers-handbook

492 Chapter 12 n Attacking Users: Cross-Site Scripting
Preventing XSS Attacks
Despite the various manifestations of XSS, and the different possibilities for
exploitation, preventing the vulnerability itself is in fact conceptually straightforward.
What makes it problematic in practice is the difficulty of identifying every
instance in which user-controllable data is handled in a potentially dangerous
way. Any given page of an application may process and display dozens of items
of user data. In addition to the core functionality, vulnerabilities may arise in
error messages and other locations. It is hardly surprising, therefore, that XSS
flaws are so hugely prevalent, even in the most security-critical applications.
Different types of defense are applicable to reflected and stored XSS on the one
hand, and to DOM-based XSS on the other, because of their different root causes.
Preventing Reflected and Stored XSS
The root cause of both reflected and stored XSS is that user-controllable data is
copied into application responses without adequate validation and sanitization.
Because the data is being inserted into the raw source code of an HTML page,
malicious data can interfere with that page, modifying not only its content but
also its structure — breaking out of quoted strings, opening and closing tags,
injecting scripts, and so on.
To eliminate reflected and stored XSS vulnerabilities, the first step is to identify
every instance within the application where user-controllable data is being
copied into responses. This includes data that is copied from the immediate
request and also any stored data that originated from any user at any prior time,
including via out-of-band channels. To ensure that every instance is identified,
there is no real substitute for a close review of all application source code.
Having identified all the operations that are potentially at risk of XSS and
that need to be suitably defended, you should follow a threefold approach to
prevent any actual vulnerabilities from arising:
n Validate input.
n Validate output.
n Eliminate dangerous insertion points.
One caveat to this approach arises where an application needs to let users
author content in HTML format, such as a blogging application that allows
HTML in comments. Some specific considerations relating to this situation are
discussed after general defensive techniques have been described.
Validate Input
At the point where the application receives user-supplied data that may be copied
into one of its responses at any future point, the application should perform