I'm currently struggling with the implementation of CSRF in a web application. The application is (more or less) stateless. There is however a session that is kept in a (HttpOnly) cookie. As we use this cookie we are subject to CSRF. But as the session is the only state the application has, I'm wondering how I could do the CSRF protection.

My current approach is to hash the session information and use this as CSRF token. Thus I can recreate the token for validation based on the session and (almost) no session information is available to the JS code. But I kind of dislike the idea that there is a connection from session to CSRF token as CSRF tokens should be random.

I found this post on doing CSRF in a stateless application that focuses on generating the CSRF token in the JS code and sending it as cookie and header. This approach seems to be very reasonable. But client-side generation of the CSRF token seems to be rather uncommon and most guides only mention server-side generated tokens.

Thus I'm wondering if there are any drawbacks with the approach of generating the CSRF token on the client-side?

  • 2
    This is the "double submit cookie" CSRF protection pattern. You can read about it here: cheatsheetseries.owasp.org/cheatsheets/… It probably has a few more weaknesses than your typical CSRF protection method, but your options are definitely more limited in a stateless environment. – Conor Mancone Aug 7 at 9:40
  • @ConorMancone would you consider this approach to be better than HMAC the session? I don't really get how I could use an encrypted cookie or HMAC with client generated tokens as the client would need the secret as well... – dpr Aug 7 at 9:49
  • HMAC the session? Can you clarify what process you have in mind? – Conor Mancone Aug 7 at 11:03
  • Generate a hash of the session's ID. As described here as well. – dpr Aug 7 at 11:06
  • Oh, okay. I follow. I'll see if I have time for a more detailed answer later. In general though hashing the session won't add anything over simply including the session cookie in the header/body (unless you are trying to minimize encoding issues). What you propose is still, fundamentally, the double submit cookie pattern – Conor Mancone Aug 7 at 11:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.