the-web-application-hackers-handbook

Chapter 12 n Attacking Users: Cross-Site Scripting 475
In some situations, the opposite technique can be useful. Converting an attack that
uses the GET method into one that uses the POST method may enable you to bypass
certain filters. Many applications perform some generic application-wide filtering
of requests for known attack strings. If an application expects to receive requests
using the GET method, it may perform this filtering on the URL query string only. By
converting a request to use the POST method, you may be able to bypass this filter.
Exploiting XSS Via Cookies
Some applications contain reflected XSS vulnerabilities for which the entry point
for the attack is within a request cookie. In this situation, you may be able to
use various techniques to exploit the vulnerability:
n As with modifying the request method, the application may allow you to
use a URL or body parameter with the same name as the cookie to trigger
the vulnerability.
n If the application contains any functionality that allows the cookie’s value
to be set directly (for example, a preferences page that sets cookies based
on submitted parameter values), you may be able to devise a cross-site
request forgery attack that sets the required cookie in the victim’s browser.
Exploiting the vulnerability would then require the victim to be induced
into making two requests: to set the required cookie containing an XSS
payload, and to request the functionality where the cookie’s value is
processed in an unsafe way.
n Historically, various vulnerabilities have existed in browser extension
technologies, such as Flash, that have enabled cross-domain requests to be
issued with arbitrary HTTP headers. Currently at least one such vulnerability
is widely known but not yet patched. You could leverage one of
these vulnerabilities in browser plug-ins to make cross-domain requests
containing an arbitrary cookie header designed to trigger the vulnerability.
n If none of the preceding methods is successful, you can leverage any other
reflected XSS bug on the same (or a related) domain to set a persistent
cookie with the required value, thereby delivering a permanent compromise
of the victim user.
Exploiting XSS in the Referer Header
Some applications contain reflected XSS vulnerabilities that can only be triggered
via the Referer header. These are typically fairly easy to exploit using a
web server controlled by the attacker. The victim is induced to request a URL
on the attacker’s server that contains a suitable XSS payload for the vulnerable
application. The attacker’s server returns a response that causes a request to the
vulnerable URL, and the attacker’s payload is included in the Referer header
that is sent with this request.