5 ms·

CSRF is about preventing other websites from making requests to your page using the credentials (including cookies) stored in the browser. Cookies can't prevent

by hmry 1y ago

CSRF is about preventing other websites from making requests to your page using the credentials (including cookies) stored in the browser. Cookies can't prevent CSRF, in fact they are the problem to be solved.

tankenmate 1y ago
Somewhere auth needs to be done, somewhere, somehow, and some when. And this is done with cookies (be it CSRF, auth token, JWT, etc). There has to be some form of mechanism for a client to prove that a) it is the client it claims it is, and therefore b) it has the permission to request what it needs from the server. And, the server shouldn't trust the client "trust me bro" style. So, at the end of the day it doesn't matter whether it is a "rose by another name", i.e. it doesn't matter whether you call it a CSRF token, auth token, JWT, or whatever, it still needs to satisfy the following; a) the communication is secure (preferably encryption), b) the server can recognise the token when it sees it (headers (of which cookies are one type), etc), c) the server doesn't need to trust the client (it's easiest if the server creates the token, but it could also be a trusted OOB protocol like TOTP), and d) it identifies a given role (again it's easiest if it identifies a unique client (like a user or similar)). So a name is just a name, but there needs to be a cookie or a cryptographically secure protocol to ensure that an untrusted client is who it says it is. Cookies are typically easier than crypto secure protocols. Frankly it doesn't really matter what you call it, what matters is that it works and is secure.
- 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
- hmry 1y ago
  I don't understand what you are getting at. CSRF is not another name for auth. You always need auth, CSRF is a separate problem. When the browser sends a request to your server, it includes all the cookies for your domain. Even if that request is coming from a <form> or <img> tag on a different website you don't control. A malicious website could create a form element that sends a request to yourdomain.com/api/delete-my-account and the browser would send along the auth cookie for yourdomain.com. A cookie only proves that the browser is authorized to act on behalf of the user, not that the request came from your website. That's why you need some non-cookie way to prove the request came from your origin. That's what Sec-Fetch-Site is.
- RagingCactus 1y ago
  I work as a pentester. CSRF is not a problem of the user proving their identity, but instead a problem of the browser as a confused deputy. CSRF makes it so the browser proves the identity of the user to the application server without the user's consent. You do need a rigid authentication and authorization scheme just as you described. However, this is completely orthogonal to CSRF issues. Some authentication schemes (such as bearer tokens in the authorization header) are not susceptible to CSRF, some are (such as cookies). The reason for that is just how they are implemented in browsers. I don't mean to be rude, but I urge you to follow the recommendation of the other commenters and read up on what CSRF is and why it is not the same issue as authentication in general. Clearly knowledgeable people not knowing about the intricacies of (web) security is actually an issue that comes up a lot in my pentesting when I try to explain issues to customers or their developers. While they often know a lot about programming or technology, they frequently don't know enough about (web) security to conceptualize the attack vector, even after we explain it. Web security is a little special because of lots of little details in browser behavior. You truly need to engage your suspension of disbelief sometimes and just accept how things are to navigate that space. And on top of that, things tend to change a lot over the years.
  - seethishat 1y ago
    It's very complicated and ever evolving. It takes dedicated web app pentesters like you to keep up with it... back in the day, we were all 'generalists'... we knew a little bit about everything, but those days are gone. It's too much and too complicated now to do that.
  - tankenmate 1y ago
    Of course CSRF is a form of authorisation; "should I trust this request? is the client authorised to make this request? i.e. can the client prove that it should be trusted for this request?", it may not be "logging in" in the classic sense of "this user needs to be logged into our user system before i'll accept a form submit request", but it is still a "can i trust this request in order to process it?" model. You can wrap it up in whatever names and/or mechanism you want, it's still a trust issue (web or not, form or not, cookie or not, hidden field or not, header or not). Servers should not blindly trust clients (and that includes headers passed by a browser claiming they came from such and such a server / page / etc); clients must prove they are trustworthy. And if you're smart your system should be set up such that the costs to attack the system are more expensive than compliance. And yes, I have worked both red team and blue team.

by hmry 1y ago

tankenmate 1y ago

Somewhere auth needs to be done, somewhere, somehow, and some when. And this is done with cookies (be it CSRF, auth token, JWT, etc). There has to be some form of mechanism for a client to prove that a) it is the client it claims it is, and therefore b) it has the permission to request what it needs from the server. And, the server shouldn't trust the client "trust me bro" style. So, at the end of the day it doesn't matter whether it is a "rose by another name", i.e. it doesn't matter whether you call it a CSRF token, auth token, JWT, or whatever, it still needs to satisfy the following; a) the communication is secure (preferably encryption), b) the server can recognise the token when it sees it (headers (of which cookies are one type), etc), c) the server doesn't need to trust the client (it's easiest if the server creates the token, but it could also be a trusted OOB protocol like TOTP), and d) it identifies a given role (again it's easiest if it identifies a unique client (like a user or similar)). So a name is just a name, but there needs to be a cookie or a cryptographically secure protocol to ensure that an untrusted client is who it says it is. Cookies are typically easier than crypto secure protocols. Frankly it doesn't really matter what you call it, what matters is that it works and is secure.

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
hmry 1y ago
I don't understand what you are getting at. CSRF is not another name for auth. You always need auth, CSRF is a separate problem. When the browser sends a request to your server, it includes all the cookies for your domain. Even if that request is coming from a <form> or <img> tag on a different website you don't control. A malicious website could create a form element that sends a request to yourdomain.com/api/delete-my-account and the browser would send along the auth cookie for yourdomain.com. A cookie only proves that the browser is authorized to act on behalf of the user, not that the request came from your website. That's why you need some non-cookie way to prove the request came from your origin. That's what Sec-Fetch-Site is.
RagingCactus 1y ago
I work as a pentester. CSRF is not a problem of the user proving their identity, but instead a problem of the browser as a confused deputy. CSRF makes it so the browser proves the identity of the user to the application server without the user's consent. You do need a rigid authentication and authorization scheme just as you described. However, this is completely orthogonal to CSRF issues. Some authentication schemes (such as bearer tokens in the authorization header) are not susceptible to CSRF, some are (such as cookies). The reason for that is just how they are implemented in browsers. I don't mean to be rude, but I urge you to follow the recommendation of the other commenters and read up on what CSRF is and why it is not the same issue as authentication in general. Clearly knowledgeable people not knowing about the intricacies of (web) security is actually an issue that comes up a lot in my pentesting when I try to explain issues to customers or their developers. While they often know a lot about programming or technology, they frequently don't know enough about (web) security to conceptualize the attack vector, even after we explain it. Web security is a little special because of lots of little details in browser behavior. You truly need to engage your suspension of disbelief sometimes and just accept how things are to navigate that space. And on top of that, things tend to change a lot over the years.
- seethishat 1y ago
  It's very complicated and ever evolving. It takes dedicated web app pentesters like you to keep up with it... back in the day, we were all 'generalists'... we knew a little bit about everything, but those days are gone. It's too much and too complicated now to do that.
- tankenmate 1y ago
  Of course CSRF is a form of authorisation; "should I trust this request? is the client authorised to make this request? i.e. can the client prove that it should be trusted for this request?", it may not be "logging in" in the classic sense of "this user needs to be logged into our user system before i'll accept a form submit request", but it is still a "can i trust this request in order to process it?" model. You can wrap it up in whatever names and/or mechanism you want, it's still a trust issue (web or not, form or not, cookie or not, hidden field or not, header or not). Servers should not blindly trust clients (and that includes headers passed by a browser claiming they came from such and such a server / page / etc); clients must prove they are trustworthy. And if you're smart your system should be set up such that the costs to attack the system are more expensive than compliance. And yes, I have worked both red team and blue team.