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.