5 ms·

Cross-Site Request Forgery

156 points by tatersolid 1y ago

nchmy 1y ago
i just discovered the Sec-Fetch stuff recently, due to Go 1.25's changelog. Very excited to start using it in some applications where tokens are currently used - what a hassle to deal with those.
- jerf 1y ago
  Cookies have been truly horrible. I check in on them every couple of years, because I don't do a lot of front-end but when I do it's often security-sensitive, and every single time I check in on them there's some new entry in "SameSite; NoSeriouslySecureHarder; WhoopsTheLastStandardWasNotGoodEnough=BeActuallySecure; AwwShitDidWeGetItRightLastTime=false" parade of attributes you need to send to get actually secure cookies. No shade on the people implementing this stuff, I understand the backwards compatibility concerns, but I mean, keeping up with this stuff is harder than it should be. And thanks to backwards compatibility most of it still defaults open, though browsers have pecked at that as they can.
  - pstuart 1y ago
    Fortunately the stability and consistency of JS frameworks make light work of that pain!
  - unethical_ban 1y ago
    Your examples made me chuckle. I was thinking "God I hope frameworks deal with all this stuff".
MajesticHobo2 1y ago
Not sure I agree with this part: > Allow all GET, HEAD, or OPTIONS requests. > These are safe methods, and are assumed not to change state at various layers of the stack already. Plenty of apps violate this assumption and do allow GET requests to alter state.
- chrisfosterelli 1y ago
  IMO apps that do this have a bug, and possibly a security one. This causes issues with prefetching, bot traffic, caching, CSRF, and just plain violates HTTP standards.
  - pstuart 1y ago
    Agreed. Those methods should be treated as idempotent.
    - almog 1y ago
      > Those methods should be treated as idempotent Idempotency still implies it can change state on the initial call, which to me feels wrong in the context of GET/HEAD/OPTIONS.
      - Mavvie 1y ago
        Indeed, the correct term here is nullipotent.
  - pinoy420 1y ago
    Not really. If I have a service where I need one click to perform an action and store data. It has to be a GET. You can’t post from a url… purist dogma for the sake of purist dogma
    - FireInsight 1y ago
      One click to perform an action and store data? Have you heard of HTML forms with method="post"?
      - whatabtemaillnk 1y ago
        [dead]
- simonw 1y ago
akersten 1y ago
I'm not really grokking the explanation in the article of why the SameSite cookie attribute doesn't fix CSRF. I thought that was the whole design intent of SameSite=Secure on an HTTPS cookie, was to fix CSRF. Can someone boil it down? The article seemingly says "these cookies won't be sent with an unsafe request. But that doesn't fix it!" And doesn't elaborate?
- MajesticHobo2 1y ago
  The problem boils down to the lack of equivalence between a site and an origin. The article explains how https://app.example.com https://app.example.com and https://marketing.example.com https://marketing.example.com may sit at very different trust levels, but are considered the same site by the browser. You don't want https://marketing.example.com https://marketing.example.com to be able to make requests to https://app.example.com https://app.example.com with your authentication cookies, but SameSite wouldn't prevent that.
  - deleted 1y ago
    [deleted]
  - edoceo 1y ago
    This doesn't match my experience. What am I doing different? Example I set SameSite=Strict on www.edoceo.com and then visiting app.edoceo.com the cookie is not there? They are different sites, different origins. And the cookie is set to the domain (ie: host, ie: www.edoceo.com)
    - FiloSottile 1y ago
      For CSRF (and for SameSite), you are not looking at what cookies are sent to attacker.example.com, but what cookies are sent to target.example.com if a request is originated from attacker.example.com (or from attacker.com).
- deleted 1y ago
  [deleted]
- 1y ago
dizlexic 1y ago
[flagged]
- deleted 1y ago
  [deleted]
deleted 1y ago
[deleted]
AgentME 1y ago
It's very nice to have an up-to-date writeup like this. I've gotten some odd looks for telling people that classic CSRF tokens are unnecessary work since the Origin header became widely supported, and I'm glad to have a page like this to refer people to.
- nchmy 1y ago
  A few more links that I collected recently on the topic https://github.com/golang/go/issues/73626 https://github.com/golang/go/issues/73626 https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF#defenses_against_csrf https://developer.mozilla.org/en-US/docs/Web/Security/Attack... https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... https://web.dev/articles/fetch-metadata https://web.dev/articles/fetch-metadata https://appliedgo.net/spotlight/csrf-dont-mess-with-my-site/ https://appliedgo.net/spotlight/csrf-dont-mess-with-my-site/ And some older ones that focused on Origin header rather than sec-fetch-* https://www.sjoerdlangkemper.nl/2019/02/27/prevent-csrf-with-the-origin-http-request-header/ https://www.sjoerdlangkemper.nl/2019/02/27/prevent-csrf-with... https://www.brandur.org/fragments/origin https://www.brandur.org/fragments/origin https://srungta.github.io/blog/start-right/ui-nonce https://srungta.github.io/blog/start-right/ui-nonce
fabian2k 1y ago
So am I understanding it right that you don't need any CSRF tokens anymore to fully protect against CSRF attacks? And if Go is implementing this specific protection, are other ecosystems doing this as well? My specific interest would be .NET/C#, but I am wondering in general how widespread this specific solution is at the moment.
- caleblloyd 1y ago
  I don’t quite understand the part of the article that deems that you can skip all the checks under the assumption that this is an older browser, and that there is no CSRF vulnerability. The algorithm seems sane for modern browsers. But you could probably find an outdated browser - older Android device WebView would be common -where the whole thing breaks down. So I think tokens can be a thing of the past for modern browsers. I like the middleware, I hope it does show up in ASP.NET proper soon. My guess is they’ll keep tokens middleware around alongside it for some time once it does though, and the decision on which to use will come down to whether or not you want to make sure older browsers are secure.
cryptonector 1y ago
> Essentially all applications that use cookies for authentication need to protect against CSRF. Not just cookies!! Any HTTP authentication. Kerberos, NTLM, OAuth.
todotask2 1y ago
> Same site vs same site vs same origin I'm lost here.
coxard 1y ago
[dead]

156 points by tatersolid 1y ago

i just discovered the Sec-Fetch stuff recently, due to Go 1.25's changelog. Very excited to start using it in some applications where tokens are currently used - what a hassle to deal with those.

jerf 1y ago
Cookies have been truly horrible. I check in on them every couple of years, because I don't do a lot of front-end but when I do it's often security-sensitive, and every single time I check in on them there's some new entry in "SameSite; NoSeriouslySecureHarder; WhoopsTheLastStandardWasNotGoodEnough=BeActuallySecure; AwwShitDidWeGetItRightLastTime=false" parade of attributes you need to send to get actually secure cookies. No shade on the people implementing this stuff, I understand the backwards compatibility concerns, but I mean, keeping up with this stuff is harder than it should be. And thanks to backwards compatibility most of it still defaults open, though browsers have pecked at that as they can.
- pstuart 1y ago
  Fortunately the stability and consistency of JS frameworks make light work of that pain!
- unethical_ban 1y ago
  Your examples made me chuckle. I was thinking "God I hope frameworks deal with all this stuff".

MajesticHobo2 1y ago

Not sure I agree with this part: > Allow all GET, HEAD, or OPTIONS requests. > These are safe methods, and are assumed not to change state at various layers of the stack already. Plenty of apps violate this assumption and do allow GET requests to alter state.

chrisfosterelli 1y ago
IMO apps that do this have a bug, and possibly a security one. This causes issues with prefetching, bot traffic, caching, CSRF, and just plain violates HTTP standards.
- pstuart 1y ago
  Agreed. Those methods should be treated as idempotent.
  - almog 1y ago
    > Those methods should be treated as idempotent Idempotency still implies it can change state on the initial call, which to me feels wrong in the context of GET/HEAD/OPTIONS.
    - Mavvie 1y ago
      Indeed, the correct term here is nullipotent.
- pinoy420 1y ago
  Not really. If I have a service where I need one click to perform an action and store data. It has to be a GET. You can’t post from a url… purist dogma for the sake of purist dogma
  - FireInsight 1y ago
    One click to perform an action and store data? Have you heard of HTML forms with method="post"?
    - whatabtemaillnk 1y ago
      [dead]
simonw 1y ago

akersten 1y ago

I'm not really grokking the explanation in the article of why the SameSite cookie attribute doesn't fix CSRF. I thought that was the whole design intent of SameSite=Secure on an HTTPS cookie, was to fix CSRF. Can someone boil it down? The article seemingly says "these cookies won't be sent with an unsafe request. But that doesn't fix it!" And doesn't elaborate?

MajesticHobo2 1y ago
The problem boils down to the lack of equivalence between a site and an origin. The article explains how https://app.example.com https://app.example.com and https://marketing.example.com https://marketing.example.com may sit at very different trust levels, but are considered the same site by the browser. You don't want https://marketing.example.com https://marketing.example.com to be able to make requests to https://app.example.com https://app.example.com with your authentication cookies, but SameSite wouldn't prevent that.
- deleted 1y ago
  [deleted]
- edoceo 1y ago
  This doesn't match my experience. What am I doing different? Example I set SameSite=Strict on www.edoceo.com and then visiting app.edoceo.com the cookie is not there? They are different sites, different origins. And the cookie is set to the domain (ie: host, ie: www.edoceo.com)
  - FiloSottile 1y ago
    For CSRF (and for SameSite), you are not looking at what cookies are sent to attacker.example.com, but what cookies are sent to target.example.com if a request is originated from attacker.example.com (or from attacker.com).
deleted 1y ago
[deleted]
1y ago

dizlexic 1y ago

[flagged]

deleted 1y ago
[deleted]

deleted 1y ago

[deleted]

AgentME 1y ago

It's very nice to have an up-to-date writeup like this. I've gotten some odd looks for telling people that classic CSRF tokens are unnecessary work since the Origin header became widely supported, and I'm glad to have a page like this to refer people to.

nchmy 1y ago
A few more links that I collected recently on the topic https://github.com/golang/go/issues/73626 https://github.com/golang/go/issues/73626 https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF#defenses_against_csrf https://developer.mozilla.org/en-US/docs/Web/Security/Attack... https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... https://web.dev/articles/fetch-metadata https://web.dev/articles/fetch-metadata https://appliedgo.net/spotlight/csrf-dont-mess-with-my-site/ https://appliedgo.net/spotlight/csrf-dont-mess-with-my-site/ And some older ones that focused on Origin header rather than sec-fetch-* https://www.sjoerdlangkemper.nl/2019/02/27/prevent-csrf-with-the-origin-http-request-header/ https://www.sjoerdlangkemper.nl/2019/02/27/prevent-csrf-with... https://www.brandur.org/fragments/origin https://www.brandur.org/fragments/origin https://srungta.github.io/blog/start-right/ui-nonce https://srungta.github.io/blog/start-right/ui-nonce

fabian2k 1y ago

So am I understanding it right that you don't need any CSRF tokens anymore to fully protect against CSRF attacks? And if Go is implementing this specific protection, are other ecosystems doing this as well? My specific interest would be .NET/C#, but I am wondering in general how widespread this specific solution is at the moment.

caleblloyd 1y ago
I don’t quite understand the part of the article that deems that you can skip all the checks under the assumption that this is an older browser, and that there is no CSRF vulnerability. The algorithm seems sane for modern browsers. But you could probably find an outdated browser - older Android device WebView would be common -where the whole thing breaks down. So I think tokens can be a thing of the past for modern browsers. I like the middleware, I hope it does show up in ASP.NET proper soon. My guess is they’ll keep tokens middleware around alongside it for some time once it does though, and the decision on which to use will come down to whether or not you want to make sure older browsers are secure.

cryptonector 1y ago

> Essentially all applications that use cookies for authentication need to protect against CSRF. Not just cookies!! Any HTTP authentication. Kerberos, NTLM, OAuth.

todotask2 1y ago

> Same site vs same site vs same origin I'm lost here.

coxard 1y ago

[dead]