I've just read an article about CSRF and it mentions 3 attack vectors; XSS, Manipulated Links and a local exploid.

Whereas the last two methods seem to be possible (for me), I'm quite unsure, how XSS will play a role here.

Based on my understanding that I'd like to exploit a website through a victim, I see no option how I can use XSS here. I could only understand how to do it if I'm the one that does the XSS, but in this case I wouldn't need a victim, would it?

The only option I can think about is a spoofed URL with the Payload as Parameter, but that would be vector 2 already.

Edit: Now I think I have a clue; the attacker would create a persistent XSS that is triggered, when a (any) victim visits the legitimate site.

Is this idea correct?

3 Answers 3


Actually if there is XSS, CSRF tokens don't offer any protection. The moment you can inject JavaScript, you could easily also fetch the token protecting the form.

  • Unless the CSRF token is protecting the form field that is vulnerable to XSS ;) Commented Nov 3, 2016 at 9:13

The way CSRF usually works is that you somehow fool the victim to click a link (or otherwise request a page) that does some action on the target site. This could e.g. be done by having a site called evil.com that autosubmitting a hidden form to bank.com/transfer.php with JS every time an innocent surfer stumbles onto it. That is CSRF without XSS.

So where does the XSS come into the picture? If there is an XSS vulnerability on bank.com the attacker could do the same thing from bank.com, that is submit a request to transfer money every time the victim visits the banks homepage. That is much more powerfull since customers of Bank is much more likely to visit bank.com while logged in there than they are to visit evil.com.

It gets even better when you take into account that the XSS vulnerability can be used to read the CSRF-token if there is one, and thereby bypass that defence.

Now I am not sure I would call this second examle CSRF anymore, since the request isn't cross site anymore. But I guess that this is what XSS assisted CSRF refers to.


You just need a request (GET, POST) traveling through victim's session to do a successful CSRF attack, in this way, you could use HTML tags which request resources from the server, for example, img tag, then if there is a XSS vulnerability in the web application, you could inject something like this:

<img src="http://mywebbank/transfer?account=12345678&quantity=1000000" />

This is a simple sample about CSRF with XSS. Now if the web application use token to validate a legitimate request, you need a way to get that token; the most web applications add a token in a HTML form, something like this:

<input type="hidden" id="token" name="token" value="3343583489" />

You could inject a XSS in the same page where the token field is located, this XSS will get that token and will create a HTML element which will generate a HTTP request with each parameter required (including the token), for instance:

var ifr = document.createElement("IFRAME");

In this way, you can do a CSRF attack through a XSS and bypass the protection based on token; this is only a way to do it, but you could do it in a different way, you just need to be creative.

I hope this information helps you.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .