To start with the background, this post is what Jeff Atwood says about CSRF tokens. In this very page, he goes on to say:
An even stronger, albeit more complex, prevention method is to leverage server state -- to generate (and track, with timeout) a unique random key for every single HTML FORM you send down to the client. We use a variant of this method on Stack Overflow with great success.
But in this post itself, Jeff never remarks about when and how the tokens should be updated.
I was using a similar technique in a web-app I was working on. It works like this:
- Whenever the user will
POSTdata to my server, a csrf token is sent along.
- This CSRF token is stored in a cryptographically strong cookie in user's session.
- If the token is valid, the user's request is processed and vice-versa.
- If the request is valid, discard the old token on server side and create a new token. The response from server contains a new csrf token to be used in the next request. The old token on all the forms on a page is updated with the new one so that the next request is processed properly.
Is it wise to update the tokens after ever
POST request or should the updation be done only whenever the user makes a
GET request and keep the same token till the next GET request is made?