0

I am currently developing a web page and came across the OWASP Cheat sheet about double submit cookies. I am now thinking that's a good idea but I didn't get why you are not storing the CSRF token into a session variable of the logged in user and display it on a page in a hidden field. If you submit a form now the server compares the session variable and the form field. If they match you are good to go.

What are the drawbacks of this idea? Why should you place the token into a own cookie which could be stolen? Aren't you minimizing your attacking surface if you store it server side?

  • 2
    Isn't the linked page already answering all your questions? – ecdsa Feb 20 at 12:02
0

What you linked is not "the OWASP Cheat sheet about double submit cookies", it is a more generic OWASP cheat cheet on cross-site request forgery prevention.

The CSRF control you propose is also the first suggested in the OWASP cheat sheet and it is called "synchronizer token pattern". The CSRF control on which you express doubts is only proposed by OWASP as an alternative "if maintaining the state for CSRF token at server side is problematic".

  • 1
    So you mean there are actually no drawbacks and i missunderstod the paper a bit? – CD Rohling Feb 20 at 13:29
  • 1
    @CDRohling yes you seem to have skipped a couple of paragraphs – Enos D'Andrea Feb 20 at 13:34
1

why you are not storing the CSRF token into a session variable of the logged in user and display it on a page in a hidden field

This is a proper and commonly used solution to prevent CSRF. Store a random token in the session and compare it on every post. This is described on the linked page, starting with:

The synchronizer token pattern requires the generation of random "challenge" tokens that are associated with the user's current session.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.