the-web-application-hackers-handbook

472 Chapter 12 n Attacking Users: Cross-Site Scripting
Suppose that each field has length restrictions, such that no feasible attack
string can be inserted into any of them. Nevertheless, you can still deliver a
working exploit by using the following URL to span a script across the three
locations you control:
https://myapp.com/account.php?page_id=”>/*&seed=*/alert(document
.cookie);/*&mode=*/
When the parameter values from this URL are embedded into the page, the
result is the following:
/*”>
The resulting HTML is valid and is equivalent to only the portions in bold.
The chunks of source code in between have effectively become JavaScript comments
(surrounded by the /* and */ markers), so the browser ignores them.
Hence, your script is executed just as if it had been inserted whole at one location
within the page.
TIP The technique of spanning an attack payload across multiple fields can
sometimes be used to beat other types of defensive filters. It is fairly common
to find different data validation and sanitization being implemented on different
fields within a single page of an application. In the previous example, suppose
that the page_id and mode parameters are subject to a maximum length
of 12 characters. Because these fields are so short, the application’s developers
did not bother to implement any XSS filters. The seed parameter, on the other
hand, is unrestricted in length, so rigorous filters were implemented to prevent
the injection of the characters “ < or >. In this scenario, despite the developers’
efforts, it is still possible to insert an arbitrarily long script into the seed parameter
without employing any of the blocked characters, because the JavaScript
context can be created by data injected into the surrounding fields.
A third technique for beating length limits, which can be highly effective
in some situations, is to “convert” a reflected XSS flaw into a DOM-based
vulnerability. For example, in the original reflected XSS vulnerability, if the
application places a length restriction on the message parameter that is copied
into the returned page, you can inject the following 45-byte script, which
evaluates the fragment string in the current URL:
eval(location.hash.slice(1))
By injecting this script into the parameter that is vulnerable to reflected XSS,
you can effectively induce a DOM-based XSS vulnerability in the resulting page