Re:Ask HN: What kinds of cookies are “required” for a websit...
by mgliwka on Thursday April 08, 2021 @04:36AM
(#26736441)
To implement the synchronizer token pattern you usually store the randomly generated CSRF token in the session to validate it on the subsequent request, even if you generate a new one for each form.
You could also handle this stateless without the session using encryption or HMAC, but then you need to manage secret keys and not screw up.
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
Re:Ask HN: What kinds of cookies are “required” for a websit...
by mgliwka on Thursday April 08, 2021 @04:20AM
(#26736337)
I think parent was referring to the session cookie. The linked article mentions putting the generated token into the server side user session and then to validate it on the next request. You might need a session cookie for that.
Re:Ask HN: What kinds of cookies are “required” for a websit...
by onion2k on Thursday April 08, 2021 @04:25AM
(#26736375)
Session cookies persist for the length of the session. That's still too long for a CSRF token. You should be generating a new one in every request that needs a token in the response.
It correctly suggests putting CSRF tokens in either hidden fields or custom request headers. If you're putting the token in to a cookie then you're persisting it for some length of time beyond the existence of the page, in which case you've broken your CSRF token mechanism because they're not supposed to persist across multiple requests. You should generate a new token for every request.