4 ms·

An example that springs to mind is a CSRF token [1]. One might use a session cookie so that the server can have a CSRF token on any forms. In this way we still

An example that springs to mind is a CSRF token [1]. One might use a session cookie so that the server can have a CSRF token on any forms. In this way we still require a session to be present even if the user doesn't have to login. 1: https://portswigger.net/web-security/csrf/tokens https://portswigger.net/web-security/csrf/tokens

onion2k 6y ago
The page you linked to literally says "CSRF tokens should not be transmitted within cookies." 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.
- mgliwka 6y ago
  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.
  - onion2k 6y ago
    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.
- mgliwka 6y ago
  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_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

onion2k 6y ago

The page you linked to literally says "CSRF tokens should not be transmitted within cookies." 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.

mgliwka 6y ago
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.
- onion2k 6y ago
  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.
mgliwka 6y ago
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_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...