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?
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:
- Synchronizer (i.e.,CSRF) Tokens
- Double Cookie Defense
- 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.