13

I will generate a CSRF token and include it in a hidden form field. When receiving the request, I will check the form value against the value either stored in the user's session or in a cookie.

Is it still considered acceptable from a security perspective to store this token in the cookie instead of the session?

curiousguy
  • 5,038
  • 3
  • 25
  • 27
Jarrod Everett
  • 527
  • 2
  • 6
  • 11

3 Answers3

11

Storing token in a cookie is not a solution to the CSRF problem. The CSRF vulnerability arises from the fact, that browser automatically sends cookies along with the request. As a result application considers that request as coming from valid (and authenticated) user. The only thing that attacker needs is the exact request that should be send. Introducing random Anti-CSRF token (request specific or session specific) causes it impossible (or just very difficult) to prepare valid request (in general case attacker doesn't know the valid value for anti-csrf token) and such a request will be dropped by server.

If you put your token in a cookie, it will be send to the server automatically, just as session cookie, so you don't get any additional protection from that.

EDIT: I might misunderstood your question. You may be talking about so called double submitted cookies pattern where the same value is sent in hidden field and cookie.

Yes, this approach is acceptable when storing the CSRF token in session is problematic, you can read more about this here: Double Submit Cookies .

Community
  • 1
pgolen
  • 539
  • 2
  • 5
  • Strange that this was downvoted, it is the correct answer. Except for the last sentence, which I assume is a typo - double-submitted cookies **is not** a good solution. – AviD Aug 24 '12 at 13:28
  • See e.g. http://security.stackexchange.com/q/2078/33 – AviD Aug 24 '12 at 13:32
  • 3
    According to OWASP CSRF Prevention Cheat Sheet this approach is effective in mitigating the risk of CSRF, but it may increase the risk of session hijack. You can avoid this by using separate cookies for session and anti-csrf protection. Sometimes session is not important - i.e. public vote pools where CSRF may be used to alter vote results. – pgolen Aug 27 '12 at 13:37
  • true, it creates risk in other areas, which is why it's not acceptable. Having separate cookies helps, but it still has problems, and is not a good solution (but comments are not the place for that :) ). That said, most frameworks today have a solution builtin, so I would be against rolling your own anyway... – AviD Aug 27 '12 at 14:20
  • @AviD, I have a little bit different point of view. Don't get me wrong, I agree that storing anti-csrf token in session is better solution, but using double submit cookies may be good enough in some situations and is not a vulnerability by itself. And one more thing - different frameworks uses different strategy for anti-csrf token (i.e. one-time token vs. session tokens, passing token as form element vs. passing it as a additional header) so it is another topic for discussion :) – pgolen Aug 27 '12 at 18:08
  • I dont think it *is* a vulnerability by necessity, but it is *likely* that there will be one. Thus my push for framework or packaged solution. But too long the comments... – AviD Aug 27 '12 at 19:13
4

Whilst I can't think of any direct attacks on such a system, I would argue that it's not a very good idea to put such tokens on the client side. You're opening yourself up to potential leaks. Storing them in the session makes them impossible to retrieve.

Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • 3
    CSRF is usually caused by authentication cookies. Putting another cookie in there as "protection" cannot really help much. – AviD Aug 24 '12 at 13:35
  • Can you outline a scenario in which a cookie-stored token is exploitable where a session-stored token would not be? We currently use cookie-stored tokens (secure httponly session-timeout), and if it is a problem I would like to look into fixing it. – csauve Jul 10 '13 at 13:50
  • @csauve It's *always* exploitable. The cookie will be sent with the request, and will do absolutely nothing. See pgolen's answer below. – Polynomial Jul 10 '13 at 14:00
  • @Polynomial: I think you have either misunderstood the question, or the nature of a the methodology the OP is referring to. The cookie is checked against a form value, which a third party website cannot know. See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookies – csauve Jul 10 '13 at 17:08
0

Storing it as a cookie only makes it trivial to implement replay attacks.

If it's stored in the session, then although there is a small window where replaying the same token will effect a CSRF, the window of opportunity is massively reduced - particularly if you add in some session validation (tracking user agent changes - but beware that Chrome will upgrade itself transparently mid-session - or using the organisation name from the client ip address)

symcbean
  • 18,418
  • 40
  • 74
  • 1
    I am a bit confused. Why would the window of opportunity differ between a cookie or session value, assuming the csrf token is updated at the same frequency in either case? – Jarrod Everett Aug 23 '12 at 15:14
  • 1
    Once the token is used, it should be invalidated for further use and a new token should be given. There's no window for replay attacks. – Polynomial Aug 23 '12 at 15:43
  • How would you invalidate a token on use *without* storing a copy of it serverside? – symcbean Aug 24 '12 at 08:47
  • Replay attacks are a totally different class of problems. You can use the token for both purposes, but don't confuse the two. You are essentially also using the token as a nonce. – csauve Jul 10 '13 at 17:15