Can a site vulnerable to XSS be used to attack a site with a CSRF vulnerability?

Question

I heard of the attacks Cross Site Scripting (XSS: An attack where an attacker injects malious client side code (For example: JavaScript) into a web application.) and Cross Site Request Forgery (CSRF: An attack where an attacker tricks an already authenticated user of a web application into sending a forge request to that vulnerable web app.) Mostly in a CSRF attack the hacker will create a site which when someone visits it or do some action a request will be sent in the background. But, what if the attacker uses a site with a XSS vulnerability and adds the request code to that site so the attacker is using someone else's site as the trigger for the forge request.

I will like to know can this happen and is there any good reason to do this?

Answer 1

Yes. But first, lets understand what each of these attacks are:

• XSS: An attack on the user; specifically through the browser and client-side.
• CSRF: An attack on the server; often used to imposter a user; specifically through lack of a CSRF token during "privileged" requests.

With that being said:

• The type of XSS attack is reflected or stored (this depends on how you want to execute the attack).
• To pull off the CSRF attack, the site must have a predictable form privilege action (ie, no CSRF tokens). For example, if it's a bank when you transfer funds or updating email, etc.

If you were using stored XSS to CSRF you'd store the payload on the site, and then when the user loads the page with your stored XSS, you'd execute your vulnerable CSRF payload.

If you were using reflected XSS to CSRF, you'd be looking to phish users into execution of your malicious code (via XSS); a link would be sent to the victim, and upon clicking the link, your reflected XSS payload would execute the CSRF payload.

Why wouldn't this be a good attack, you get to:

• Phish users.
• Potentially harvest privileged information from a victim.

Answer 2

Yes.

Lets say a banking site is at http://mybank.com and login information is verified in your cookie.

Transferring money may look like:

http://mybank.com/api/transfer?toAcc=1&fromAcc=10&amount=100

This only allows transfers with an authenticated cookie for http://mybank.com which is attached to each request.

Now lets say when someone transfers money to your account they can add a comment to the transfer. If this is not sanitized and allows script tags you can inject a page redirect.

<script>windows.location.href="http://mybank.com/api/transfer?toAcc=10&fromAcc=1&amount=100000"</script>

If you view the comment you will now be performing a transfer of money using your cookie due to XSS+CSRF and end up transferring money.

---

That's a simple example which assumes the worst and lacking basic controls.