CSRF token unique per user session - Why?

Question

OWASP recommends that a CSRF token should be unique per user session.

• What is the attack vector or reasoning behind that?
• How could an attacker exploit a web application that does not invalidate the CSRF token after logout (or renews it after login)?
• How severe is it if a web application does not follow that recommendation?
• Does this apply to all kinds of (anti-) CSRF protection implementations (e.g. a token submitted via a custom header), or only to specific forms of CSRF tokens?

Answer 1

The attack vector here is disclosure of the token. The defense is not so much concerned with specifically how that token is disclosed, but addresses any method in which an attacker might obtain that value. If an attacker can obtain the token, that opens the possibility they can craft a CSRF attack. Again, the specific method of attack itself isn't the concern here.

The purpose of changing the token is to limit the window of opportunity. You could have the CSRF token change once a month or have it change on every request. Changing it with every session is a good middle ground that avoids some of the complications of a token changing too fast yet still provides good limits of exposure. Ending a session is also a natural transition of state, so that also makes it a good place to change the CSRF token.

Limiting your overall exposure to CSRF can make changing the CSRF token with every session less important. Some ways to do that are:

• Passing the token as HTTP header rather than a form value.
• Properly using POST vs GET requests when updating data or initiating transactions.
• Using the SameSite cookie attribute, the Secure attribute, and the __Host- or __Secure- cookie prefixes to help protect cookies from exposing information or being overwritten.
• Using the Origin and Referer HTTP headers to verify that the request came from the expected location.
• Providing additional interactive steps such as a confirmation page or even re-authentication for the most sensitive actions.

Deciding when to renew the CSRF token depends on your overall risk and general resistance to CSRF attacks. With a good defense-in-depth strategy you might be able to compromise on on how frequently you change that token.

Answer 2

Your server doesn't need to do anything to the Synchronizer Token on logout. It only needs to generate a new token on every login.

The obvious condition for Syncrhronizer Token to work is: the attacker must not know the victim's CSRF Token. Else, the token becomes meaningless as the attacker can simply submit the token as part of the malicious request.

If you don't regenerate a token on each new session (i.e. at login), there are two ways an attacker may get hold of it:

1. CSRF Token Fixation. Related concept to session fixation. Imagine an attacker manages to inject his own session ID and CSRF token into a victim's browser, and the victim performs a login. Let's say your server mitigates session fixation by regenerating session ID but does not regenerate the CSRF Token. The attacker would already have the victim's CSRF token, despite not having his session ID, and may now carry out CSRF attacks.

2. Algorithmic Guessing. If the CSRF Token never changes for a user, it essentially becomes perpetually tied to a user. Guessing it is a matter of time (brute force), especially if the attacker figures out the algorithm and/or the parameters used. Regenerating the token on every login makes any brute-force attack window much smaller.