Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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?
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-origin (which is strictly tighter than same-site) authenticated requests, rendering CSRF irrelevant. Conversely, most CSRF attacks do the sort of thing an XSS payload might do, rather than actually 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.
