1
votes

This article suggests that we should be changing our CSRF tokens on every request to prevent a BREACH attack. i.e., if we use gzip/brotli and per-session CSRF tokens, and SSL, our tokens are vulnerable with only 1000 requests.

Supposing that's true, how would one go about regenerating a CSRF token on every request without breaking back/forward and multiple tabs?

The obvious solution is to store an array of valid CSRF tokens in our session instead of just the most recent one, perhaps limiting it to 100 or so.

But what if we used a JWT or something instead? We could store just the user ID in there, then validate that the token isn't expired and it belongs to the current user, and we wouldn't need to store it on the server at all. The only problem is that we couldn't revoke the CSRF-JWT when the user logs out, which would necessitate a short expiry, but we wouldn't want it too short or it'd expire before the user has a chance to submit the form.

What's the best way to approach this problem?

1

1 Answers

1
votes

You can use a JWT and send it as a Bearer token in the header and store it in local storage. Do NOT send it in a cookie. Send it on every request and check the validity of it on every request. You can give the user a refresh token that you can revoke when they log out. The refresh token will generate access JWTs that expire after a very short period for each call.

You can use the JWT for access control and all your authorization needs.