the-web-application-hackers-handbook

476 Chapter 12 n Attacking Users: Cross-Site Scripting
In some situations, the XSS vulnerability is triggered only if the Referer header
contains a URL on the same domain as the vulnerable application. Here, you
may be able to leverage any on-site redirector functions within the application
to deliver your attack. To do this, you need to construct a URL to the redirector
function that both contains a valid XSS exploit and causes a redirection to the
vulnerable URL. The success of this attack depends on the redirection method
the function uses and on whether current browsers update the Referer header
when following redirections of that type.
Exploiting XSS in Nonstandard Request and Response Content
Today’s complex applications increasingly employ Ajax requests that do not
contain traditional request parameters. Instead, requests often contain data in
formats such as XML and JSON, or employing various serialization schemes.
Correspondingly, the responses to these requests frequently contain data in the
same or another format, rather than HTML.
The server-side functionality involved in these requests and responses often
exhibits XSS-like behavior. Request payloads that normally would indicate the
presence of a vulnerability are returned unmodified by the application.
In this situation, it is still possible that the behavior can be exploited to deliver
an XSS attack. To do so, you need to meet two distinct challenges:
n You need to find a means of causing a victim user to make the necessary
request cross-domain.
n You need to find a way of manipulating the response so that it executes
your script when consumed by the browser.
Neither of these challenges is trivial. First, the requests in question typically
are made from JavaScript using XMLHttpRequest (see Chapter 3). By default,
this cannot be used to make cross-domain requests. Although XMLHttpRequest
is being modified in HTML5 to allow sites to specify other domains that may
interact with them, if you find a target that allows third-party interaction, there
are probably simpler ways for you to compromise it (see Chapter 13).
Second, in any attack, the response returned by the application would be consumed
directly by the victim’s browser, not by the custom script that processes
it in its original context. The response will contain data in whatever non-HTML
format is being used, usually with the corresponding Content-Type header. In
this situation, the browser processes the response in the normal way for this
data type (if recognized), and normal methods for introducing script code via
HTML may be irrelevant.
Although nontrivial, in some situations both of these challenges can be
met, allowing the XSS-like behavior to be exploited to deliver a working
attack. We will examine how this can be done using the XML data format
as an example.