8

Ours is a Ajax heavy application with concurrent Ajax requests. Generating unique tokens with each request or expire and creation of new tokens after a certain interval could get tricky with multiple concurrent Ajax requests.

My question comes from the suggested approach here -

Really, generating one each time the whole page is loaded should be enough if you are doing this over HTTPS, which you should be.

If we enable HTTPS, generating one CSRF token per session and using that token for all the requests in the session is enough?

Community
  • 1
johnbabu koppolu
  • 183
  • 1
  • 5
  • 1
    It may be worth generating a new token at any successful login step, but IMO changing on every request gets you nothing. Background: http://security.stackexchange.com/a/22936/6566 – bobince Jan 07 '13 at 14:50
  • 1
    One token per session adequately protects against CSRF, but it may be vulnerable to guessing by the BREACH attack. See also [With BREACH attack, is session-based CSRF token still secure?](http://security.stackexchange.com/questions/43669/with-breach-attack-is-session-based-csrf-token-still-secure) – Sjoerd Nov 24 '16 at 09:10

2 Answers2

13

To prevent CSRF you need to have something unguessable in the explicit part of the request (GET or POST). Putting it into the POST part is preferred, since it's harder to leak it, and you typically only protect requests that trigger an action, which should be POST.

A per-session random value is unguessable and should do the job. The standard anti CSRF token mechanism built into ASP.net works just like that.

HTTPS prevents leaking the token on the wire, and also prevents replay attacks. So a one-time-token doesn't seem necessary.

CodesInChaos
  • 11,854
  • 2
  • 40
  • 50
2

One CSRF token per session could provide adequate protection against CSRF, but better security can be obtained by using a different CSRF token for each form.

In the case of some other vulnerability, an attacker may steal or misuse a CSRF token. In that case, it is a good idea to limit the CSRF token as much as possible. This Ruby on Rails PR changes CSRF token to be only valid for a specific form action and method, so that stolen CSRF tokens can not be used for any other purpose. This is described a bit more in a GitHub engineering blog.

This is a defense in depth measure. In the case that some other vulnerability makes it possible to steal a CSRF token, it is a good idea to limit the validity of CSRF tokens.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102