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:


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.

  • 3
    that's like worrying about an enemy machine gunner having a pocket knife... – dandavis Jan 11 '18 at 9:23
  • @dandavis ' concise comment seems to agree with the one answer to the StackOverflow question ( stackoverflow.com/a/36980059/805141 ), as well as the first answer I received to this question ( security.stackexchange.com/a/177311/92720 ). Since the second answer I received ( security.stackexchange.com/a/177325/92720 ) expresses that the attacker can take certain actions only after compromising the CSRF token, the comment might be somewhat at odds with that answer. Regardless, use of HttpOnly auth cookies + anti-CSRF protection might provide hardening via defence in depth. – Daniel Jan 15 '18 at 0:29

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).

| improve this answer | |
  • I've been doing a days long research about auth security. Started out with saving user token in LocalStorage, read that it was bad everywhere, now using double-cookie-submit, but if XSS is "game over" anyway, why no use LocalStorage for tokens, after all? (considering it's MUCH simpler) – zerohedge Oct 12 '19 at 21:50

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.

| improve this answer | |
  • 1
    "If your CSRF tpken is compromised...": If there is XSS, isn't it always compromised? I know of no way to secure it against XSS. – Anders Jan 11 '18 at 10:09
  • But lets assume I can't read it. I can still load whatever form I want in an hidden iframe, fill in whatever data I want, and hit submit, all using JS. So actually reading the CSRF token is not stricly necessary. – Anders Jan 11 '18 at 10:11
  • @Anders Yes, it's always compromised (I did point that out in my answer, twice). I took this as a theoretical, "what-if" type question. And here, compromise of the token is what enables write access to the server, which you otherwise wouldn't have. It's true that you don't technically have to read it, but I think in the context of this question that could be considered "compromised" as well. – tim Jan 11 '18 at 10:21
  • Sorry, first comment was a bit stupid... ha ha. – Anders Jan 11 '18 at 10:27
  • @Anders No, problem; my answer is probably not as clear as it should be. What I basically wanted to get across was CSRF=write access to server, XSS=read/write to client + read to server + CSRF (ie write to server). – tim Jan 11 '18 at 10:33

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.