I have recently heard that XSS + CSRF = stored XSS. I didn't think too much about it at the time, but now it's bugging me, because it doesn't make too much sense.

I would say that it can stand true, if the XSS was "self-stored XSS" for which CSRF is used to get rid of the "self" part.

Other than that, I don't see any other potential way for the aforementioned equation to be true. Is there another case that I miss?

  • You are right about the self-stored XSS. I guess it could also be useful if you don't want to associate the stored XSS with your own account, to avoid getting cought. But I find it hard to see that the "equation" would hold true in general. If there is a reflected XSS vulnerability, it doesn't become stored just because there is also a CSRF vulnerability. – Anders Dec 11 '19 at 21:08

A site that has a stored XSS that can only be inflicted on a user's own account - a "self-XSS" - but that is also vulnerable to CSRF on the stored XSS injection point should be considered to have two problems: it is vulnerable to CSRF, and it is vulnerable to XSS. Closing the CSRF vector would mitigate that particular XSS risk, but both should be fixed.

"Stored XSS" doesn't require CSRF, however, Most of what gets termed Stored XSS is created by one user on a service to attack another user on the same service (so, same-site, not cross-site), and while victims could be directed to the infected page using a URL from outside the site (including cross-site links, iframes, etc.) they could also land on the infected page without the attacker sending them there at all.

For example, consider a social media worm. Somebody finds a way to inject script on a pubic social media post they create. The script looks up the friends of everybody who lands on the page and messages/tags all of them "hey, check this out". It also promotes the post itself with a "like" or "favorite" or whatever (it could also have some actually-harmful payload, beyond just spamming all your friends, of course). Thus, it could infect a huge number of users on the site - spreading through everybody's social graphs, plus infecting users who view this suddenly explosively-trending post - without ever having any cross-site element.

Getting back to CSRF + XSS, for the most part it's not really a meaningful combination. XSS (of any sort) allows making same-site authenticated requests, rendering CSRF irrelevant. Conversely, most CSRF attacks are to do the sort of thing an XSS payload would do, rather to inject an XSS payload (if there's a way to do that, you can usually just launch an XSS attack without needing to CSRF anybody). I suppose one could claim that most reflected XSS attacks are technically some form of CSRF - if you're attacking somebody by sending them to https://example.com/search?q=<XSS _payload>, you're arguably executing a CSRF against the search endpoint. However, searches are (usually) not state-changing, and thus are not considered a CSRF risk and don't require CSRF protection. The vulnerability in that scenario isn't that the search endpoint lacks CSRF protection, it's that the search query is reflected into the response without adequate encoding.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.