the-web-application-hackers-handbook

Chapter 12 n Attacking Users: Cross-Site Scripting 481
to span an XSS payload across several “different” request parameters with
the same name, bypassing the blacklist with each separate value, all of
which the server recombines.
TRY IT!
Currently the following XSS exploit succeeds in bypassing the IE XSS filter:
http://mdsec.net/error/5/Error.ashx?message= alert(‘xss’)
Third, the way in which the filter sanitizes script code in application responses
can actually be leveraged to deliver attacks that otherwise would be impossible. The
core reason for this is that the filter operates passively, looking only for correlations
between script-like inputs and script-like outputs. It cannot interactively probe
the application to confirm whether a given piece of input actually causes a given
piece of output. As a result, an attacker can actually leverage the filter to selectively
neutralize the application’s own script code that appears within responses. If the
attacker includes part of an existing script within the value of a request parameter,
the IE XSS filter sees that the same script code appears in the request and
the response and modifies the script in the response to prevent it from executing.
Some situations have been identified where neutralizing an existing script
changes the syntactic context of a subsequent part of the response that contains
a reflection of user input. This change in context may mean that the application’s
own filtering of the reflected input is no longer sufficient. Therefore, the reflection
can be used to deliver an XSS attack in a way that was impossible without
the changes made by the IE XSS filter. However, the situations in which this
has arisen generally have involved edge cases with unusual features or have
revealed defects in earlier versions of the IE XSS filter that have since been fixed.
More significantly, an attacker’s ability to selectively neutralize an application’s
own script code could be leveraged to deliver entirely different attacks by interfering
with an application’s security-relevant control mechanisms. One generic example
of this relates to the removal of defensive framebusting code (see Chapter 13), but
numerous other examples may arise in connection with application-specific code
that performs key defensive security tasks on the client side.
Finding and Exploiting Stored XSS Vulnerabilities
The process of identifying stored XSS vulnerabilities overlaps substantially
with that described for reflected XSS. It includes submitting a unique string in
every entry point within the application. However, you must keep in mind some
important differences to maximize the number of vulnerabilities identified.