3 ms·

I don't think this is accurate. As your parent comment said, Csrf defenses (tokens, origin/Sec-Fetch-Site) serve a different purpose from Auth token/jwt. The la

by nchmy 1y ago

I don't think this is accurate. As your parent comment said, Csrf defenses (tokens, origin/Sec-Fetch-Site) serve a different purpose from Auth token/jwt. The latter says that your browser is logged in as a user. The former says "the request actually came from a genuine action on your page, rather than pwned.com disguising a link to site.com/delete-account. You're conflating the two types of Auth/Defense.

tankenmate 1y ago
You're misunderstanding my point, the Sec-Fetch-Site is not a replacement for CSRF tokens (be they cookies (classic CSRF tokens, auth tokens, JWTs; all of these can be made to work for the client to prove to the server that they are allow to submit a form (and came from the "right" form), some obviously easier than others), a header (such as X-CSRF-Token - Ruby on Rails, Laravel, Django; X-XSRF-Token - AngularJS; CSRF-Token - Express.js (csurf middleware); X-CSRFToken - Django), a TOTP code, etc), but the Sec-Fetch-Site header is a defence in depth mechanism, not a replacement for CSRF (however that is achieved, classic cookie mechanism or other).
- deleted 1y ago
  [deleted]
- minitech 1y ago
  That’s not correct, or is at least seriously misleading. `Sec-Fetch-Site` is a replacement for CSRF tokens. The sole purpose of CSRF tokens is to prevent CSRF, and enforcing that all unsafe[1]-method requests have a `Sec-Fetch-Site: same-origin` header serves exactly the same purpose – in other words, adding a CSRF token to this policy doesn’t achieve anything. The most relevant difference for most apps is that `Sec-Fetch-Site` isn’t sent by older browsers. Now, I would actually prefer to make this claim about the `Origin` header, since the spec for `Sec-Fetch-Site`[2] says that “in order to support forward-compatibility with as-yet-unknown request types, servers SHOULD ignore this header if it contains an invalid value.” But given that Go 1.25 is deploying a `Sec-Fetch-Site` check[3] as mentioned in the article and that places are recommending it as defence in depth, the `same-origin` value will probably never change in a way that’s backwards-incompatible with this kind of use. [1] in the HTTP spec sense [2] https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-si... [3] https://cs.opensource.google/go/go/+/master:src/net/http/csrf.go;l=145;drc=aa83aee7de1d69b207ab9669bb2b7dcdcbdf9383 https://cs.opensource.google/go/go/+/master:src/net/http/csr...
- nchmy 1y ago
  False. OWASP will now be modifying it's doc on the topic to say that Sec-Fetch-Site is sufficient on its own, rather than defense in depth. You really have no idea what you're talking about. https://github.com/OWASP/CheatSheetSeries/issues/1803 https://github.com/OWASP/CheatSheetSeries/issues/1803

by nchmy 1y ago

tankenmate 1y ago

You're misunderstanding my point, the Sec-Fetch-Site is not a replacement for CSRF tokens (be they cookies (classic CSRF tokens, auth tokens, JWTs; all of these can be made to work for the client to prove to the server that they are allow to submit a form (and came from the "right" form), some obviously easier than others), a header (such as X-CSRF-Token - Ruby on Rails, Laravel, Django; X-XSRF-Token - AngularJS; CSRF-Token - Express.js (csurf middleware); X-CSRFToken - Django), a TOTP code, etc), but the Sec-Fetch-Site header is a defence in depth mechanism, not a replacement for CSRF (however that is achieved, classic cookie mechanism or other).

deleted 1y ago
[deleted]
minitech 1y ago
That’s not correct, or is at least seriously misleading. `Sec-Fetch-Site` is a replacement for CSRF tokens. The sole purpose of CSRF tokens is to prevent CSRF, and enforcing that all unsafe[1]-method requests have a `Sec-Fetch-Site: same-origin` header serves exactly the same purpose – in other words, adding a CSRF token to this policy doesn’t achieve anything. The most relevant difference for most apps is that `Sec-Fetch-Site` isn’t sent by older browsers. Now, I would actually prefer to make this claim about the `Origin` header, since the spec for `Sec-Fetch-Site`[2] says that “in order to support forward-compatibility with as-yet-unknown request types, servers SHOULD ignore this header if it contains an invalid value.” But given that Go 1.25 is deploying a `Sec-Fetch-Site` check[3] as mentioned in the article and that places are recommending it as defence in depth, the `same-origin` value will probably never change in a way that’s backwards-incompatible with this kind of use. [1] in the HTTP spec sense [2] https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-si... [3] https://cs.opensource.google/go/go/+/master:src/net/http/csrf.go;l=145;drc=aa83aee7de1d69b207ab9669bb2b7dcdcbdf9383 https://cs.opensource.google/go/go/+/master:src/net/http/csr...
nchmy 1y ago
False. OWASP will now be modifying it's doc on the topic to say that Sec-Fetch-Site is sufficient on its own, rather than defense in depth. You really have no idea what you're talking about. https://github.com/OWASP/CheatSheetSeries/issues/1803 https://github.com/OWASP/CheatSheetSeries/issues/1803