The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

Defeating Anti-XSRF Defenses via XSS

It is often said that anti-XSRF defenses can be defeated if the application contains

any XSS vulnerabilities. But this is only partly true. The thought behind this the-

ory is correct — that because XSS payloads execute on-site, they can perform

two-way interaction with the application, and so can retrieve tokens from the

application’s responses and submit them in subsequent requests. However, if a

page that is itself protected by anti-XSRF defenses also contains a reflected XSS

flaw, then this flaw cannot be used to break the defenses. Don’t forget that the ini-

tial request in a reflected XSS attack is itself cross-site. The attacker crafts a URL

or 

POST

request containing malicious input that gets copied into the applica-

tion’s response. But if the vulnerable page implements anti-XSRF defenses, then

the attacker’s crafted request must already contain the required token in order to

succeed. If it does not, the request will be rejected and the code path containing

the reflected XSS flaw will not execute. The issue here is not about whether

injected JavaScript can read any tokens contained in the application’s response

(of course it can), but rather about getting the JavaScript into a response con-

taining those tokens in the first place.

In general, there are two situations in which XSS vulnerabilities can be

exploited to defeat anti-XSRF defenses:

■■

If there are any stored XSS flaws within the defended functionality,

these can always be exploited to defeat the defenses. JavaScript injected

via the stored attack can directly read the tokens contained within the

same response that the script appears in.

■■

If the application employs anti-XSRF defenses for only part of its

authenticated functionality, and a reflected XSS flaw exists in a function

that is not defended against XSRF, then that flaw can be exploited to