Why refresh CSRF token per form request?

  • In many tutorials and guides I see that a CSRF token should be refreshed per request. My question is why do I have to do this? Isn't a single CSRF token per session much easier than generating one per request and keeping track of the ones requested?

    Generating the token on a per-request basis doesn't seem to improve security beyond what a per-session token would already do. The only argument seems to be XSS protection, but this doesn't apply as when you have a XSS vulnerability the script could read out new tokens anyway.

    What are the benefits of generating new tokens per request?

  • bobince

    bobince Correct answer

    9 years ago

    For the reasons already discussed, it is not necessary to generate a new token per request. It brings almost zero security advantage, and it costs you in terms of usability: with only one token valid at once, the user will not be able to navigate the webapp normally. For example if they hit the 'back' button and submit the form with new values, the submission will fail, and likely greet them with some hostile error message. If they try to open a resource in a second tab, they'll find the session randomly breaks in one or both tabs. It is usually not worth maiming your application's usability to satisfy this pointless requirement.

    There is one place where it is worth issuing a new CSRF token, though: on principal-change inside a session. That is, primarily, at login. This is to prevent a session fixation attack leading to a CSRF attack possibility.

    For example: attacker accesses the site and generates a new session. They take the session ID and inject it into a victim's browser (eg via writing cookie from a vulnerable neighbour domain, or using another vulnerability like jsessionid URLs), and also inject the CSRF token into a form in the victim's browser. They wait for the victim to log in with that form, and then use another form post to get the victim to perform an action with the still-live CSRF token.

    To prevent this, invalidate the CSRF token and issue a new one in the places (like login) that you're already doing the same to the session ID to prevent session fixation attacks.

    Is this advice still valid now that BREACH attacks are a thing?

    BREACH attacks are supposed to be solved at a different layer (by disabling application data compression AND TLS compression), so the answer is: you shouldn't worry about the BREACH attack unless you're setting up TLS or the HTTP server

    @millerdev BREACH attack can be mitigated by applying a random mask to the csrf token on each request while keeping the actual token value unchanged. This prevents BREACH attack as the random mask makes it impossible to guess and also maintains usability because the token's secret value is still the same.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM