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?

  • 1
    Since it can be (has been) imagined, I'm sure it's "possible" even if not practical. Prevention, on the other hand, is an issue.
    – user135823
    Sep 26, 2018 at 1:54
  • This is plausible and the "benefit" is obvious, if the triggering come from a popular repository , e.g. github, google doc, an spam email message sending to the user will be missed by user and spam filter that using white-listing approach will think it is legit.
    – mootmoot
    Sep 26, 2018 at 11:45

2 Answers 2


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

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.


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

Transferring money may look like:


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.


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.

  • Can't the attacker just steal your cookies assuming they aren't HTTPOnly? Then they can impersonate you later on.
    – TheLizzard
    Dec 15, 2023 at 0:31

You must log in to answer this question.

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