What happens if my anti-CSRF token is compromised by an XSS attack?

Question

The interesting Stack Overflow question "Do cookies protect tokens against XSS attacks?" was closed as too broad, but as mentioned in a comment on it, there is a tangible question of "What happens if my anti-CSRF token is compromised by an XSS attack?"; it seems to me that answers to this question may provide information that will help people form opinions on the questions posed on Stack Overflow. Thus I'm posing said tangible question.

Let's assume that we're using the Double Submit Cookies method (unless there's a better method I'm unaware of) and we're storing JWTs (e.g., authentication tokens) in HttpOnly, Secure cookies.

The following Security Stack Exchange pages are relevant:

• Can CSRF protection work even if an XSS vulnerability exists?
• localStorage vs. HTTP-Only Cookies + XSRF: Is either better when it comes to XSS?
• Is JWT in cookies with any CSRF solution just as vulnerable to XSS as JWT in localStorage?
• Double Submit Cookies vulnerabilities
• Why are cookies considered more secure against XSS?
• Why does Double Submit Cookies require a separate cookie?
• Does setting httponly prevent stealing a session using XSS?
• Is there a strong protection against CSRF executed from the sames server via stored XSS?

UPDATE:

I've been reading more about anti-CSRF methods and came across this OWASP page comparing the Double Submit Cookies method to the alternative Synchronizer Design Pattern and the Encrypted Token Pattern, and stating that in terms of strength of defence they can be ordered as:

1. Synchronizer (i.e.,CSRF) Tokens
2. Double Cookie Defense
3. Encrypted Token Pattern

(OWASP also states that 1. requires session state whereas 2. and 3. require no server-side state. There's a discussion on whether the Encrypted Token Pattern's actually stateless in the comments on the article entitled Leveraging the Encrypted Token Pattern. Said article also describes shortfalls of 1. and 2. that 3. solves, apparently without introducing new security concerns or architectural problems. As such, I don't know why OWASP listed it as third in terms of strength of defence. Perhaps due to the amount of testing that it's undergone at this point in time, since both it and Double Submit Cookies are relatively new; perhaps due to the discussion on statelessness/statefulness and replay attack protection in the article's comments? It'd be nice if there was an explanation of that ordering.)

Anyway... If anyone wants to respond to this question under the alternative assumption that either the Synchronizer Token Pattern or the Encrypted Token Pattern's being used instead, that would be neat.

Answer 1

If somebody has an XSS in your site, they can do anything they want on that origin -- submit any form, perform any operation, etc. Javascript can modify the DOM in arbitrary ways, submit forms, modify the user's view, etc.

Consequently, stealing the CSRF token is the least of your worries -- the XSS allows anything on the same origin that a CSRF would allow. The only time you might worry about this is if you share the same CSRF token across multiple origins (which would be a poor practice to begin with).

Answer 2

With XSS, you have read and write access to the DOM - among other - of the attacked user. You could for example read out sensitive data or perform phishing attacks.

But if you couldn't read the anti-CSRF token (which you of course can) - and you can't read the session token -, you couldn't perform write actions to the server in the name of the attacked user. You could still perform read actions to the server, so you could get sensitive data that isn't already currently displayed to the user, but you couldn't perform actions that change things.

But when your anti-CSRF token is compromised, an attacker could perform any action that isn't further protected by challenge-response mechanisms (this is often the case when for example changing the password or email address, which commonly requires the entering of the current password).

So I disagree with people who would say that it is nothing to worry about. Compromising the anti-CSRF token enables an attacker to do much more damage, as it upgrades read-only access to the server to read-write access in the name of the attacked user; it's only insofar irrelevant as you can't prevent the compromise of the token once you have an XSS vulnerability.

Answer 3

An XSS attack, while it is ongoing, strictly dominates CSRF; anything an attacker could do with CSRF, they can do with XSS (and much more besides).

However, there is a question: what happens after the XSS attack ends (e.g. because the victim closed their browser)? There are several possibilities.

1. If the attacker stole the session/access token and refresh token then the attacker can continue to control the victim's session until the session is ended by the server (e.g. hits a hard lifetime limit or the server revokes the session/refresh token). This scenario doesn't require that the user's device ever go online, much less interact with the attacker, again. This is the worst-case scenario, and is why session/access/refresh tokens are often stored in HttpOnly cookies.
2. If the attacker stole the CSRF token but not any other then the attacker can continue to make CSRF attacks against the victim (once they open their browser to an attacker-controlled page again, if they closed that; they don't need to have a tab open to the target site though), until such time as the attacker's session ends or their CSRF token changes. In effect, the attacker can bypass the site's CSRF protection for anybody who the attacker has hit with XSS until such time as the victim logs out, their session expires (without, or until, refreshing), or the CSRF token changes for any reason (e.g. maybe it changes every time the session refreshes). The attacker still needs to be in a position to carry out such a CSRF attack, though, and - assuming the CSRF tokens are per-session as they should be - the attacker will only be able to use this against however many users the attacker got XSS on.
3. If the attacker did not steal the CSRF token or session/refresh token, or the tokens were invalidated (e.g. because the user logged out rather than just closing the tab) then the attacker can't do anything at all.

As you can see, there is a small amount of additional risk from XSS if the attacker retains an ability to do CSRF even after the XSS ends but doesn't retain access to the session. However, in practice, that's a really minor risk. It only becomes relevant if:

• the session (or at least the validity overlap of the stolen CSRF token and some session) lasts after the victim ends the XSS,
• the attacker needs access longer than the duration of their XSS to complete their attack,
• the attacker can complete (or at least make meaningful progress on) their attack using only CSRF, without seeing the responses, and
• the attacker remains in a position to carry out CSRF attacks (but not the XSS attack, which probably means the victim closed a tab to the vulnerable site but not to the malicious one).

As you can see, that's a pretty narrow set of constraints, and only apply to victims of the attacker's XSS (which is hopefully very few of your users). Furthermore, while the attacker may have gained information about the victim's account during the XSS and use that info to guide their CSRF attacks, the further damage that the attacker can do is nonetheless limited to CSRF, which is often less harmful than XSS.