I am testing a web application. CSRF is applied and sent in cookies and header but not in the form as hidden input. The csrf token does not change for every request but it change during the session. How often should the csrf token change ? Should it change per session or per request ? should the client or the server set the csrf token ? what is the best strategy to apply csrf protection? double submit cookie ? Triple Submit Cookie ? or any other new strategy ?
1 Answers
I'm just going to attempt to answer your questions one by one here.
How often should the CSRF token change?
You can change your CSRF token once per session. Changing it once per request offers no real security advantage and if anything, only serves as an easy way to waste resources and limit usability. For example, a user will not be able to hit the "back" button because they will have an outdated CSRF token, or if they try to resubmit a form with new values (such as after a validation error) it may not send.
Should it change per session or per request?
As discussed, it should change per session. The only time that a user should be given a new token per request is at login. This is to prevent a session fixation attack leading to a CSRF attack possibility.
For example: An attacker accesses the site and generates a new session. They take the session ID and inject it into a victim's browser (eg via writing cookie from a vulnerable neighbour domain, or using another vulnerability like jsessionid URLs), and also inject the CSRF token into a form in the victim's browser. They wait for the victim to log in with that form, and then use another form post to get the victim to perform an action with the still-live CSRF token.
To prevent this, invalidate the CSRF token and issue a new one in the places (like login) that you're already doing the same to the session ID to prevent session fixation attacks.
Should the client or the server set the CSRF token?
The server - always on the server! You want to generate the token from a trusted source, as per OWASP guidelines. This ensures that you know exactly where the token is generated and limits attack surface since an attacker cannot control what happens on the server.
What is the best strategy to apply CSRF protection?
I think CSRF is a very in-depth topic and can't really be summed up in just a few words. This is where a little research and reading can go a long way. I would recommend you take a look at the OWASP CSRF Prevention Cheat Sheet.

- 1,365
- 12
- 24
-
Using double submit, the token can be generated on the client in modern browsers (with `Crypto.getRandomValues()`). Double submit (especially with client-side token generation) has a slightly higher risk, but that can still be acceptable for many applications, and may be much easier in some cases. – Gabor Lengyel Dec 07 '18 at 17:34
-
Thanks Horkrine for the detailed answer, one point left, is that the csrf token in my application is not submitted as a hidden input in the form, it is sent as a cookie as a header, is that considered a risk ? btw, the application is using ssl and HSTS policy – Tom Dec 10 '18 at 08:22
-
As i can read in the owasp recommendations, that csrf tokens should sent as a hidden element in the form, i saw that also in many java csrf protection implementation.. . – Tom Dec 10 '18 at 09:17
-
Hi Tom. I have always placed my CSRF tokens as hidden elements within the form - I've never put them in a cookie / header so I cannot provide a confident answer. However, I have found [this answer](https://stackoverflow.com/questions/20504846/why-is-it-common-to-put-csrf-prevention-tokens-in-cookies) which may be of use to you – Horkrine Dec 10 '18 at 09:26
-
thanks Horkrine, from the link you sent, i do not see a security difference between sending the csrf token in the request body ( as hidden form field) or as cookie or as a header, . .. so why does owasp recommends sending it as a hidden form field ? maybe because the cookie and the header parameters are easier to be accessed than the message body when using ssl ? – Tom Dec 10 '18 at 11:15