3 ms·

All the voting down but not a single comment as to why. The "Sec-Fetch-Site" primarily protects the browser against Javascript hijacking, but does little to not

All the voting down but not a single comment as to why. The "Sec-Fetch-Site" primarily protects the browser against Javascript hijacking, but does little to nothing to protect the server. This is probably apocryphal, but Willie Sutton was asked why he kept robbing banks, he quipped "that's where the money is". Sure browser hacking occurs, but it's a means to an end because the server is where the juicy stuff is. So headers that can't be accessed by Javascript are way down the food chain and only provide lesser defence in depth if you have proper CSRF tokens (which you should have anyway to protect the far more valuable server resources which are the primary target).

nchmy 1y ago
I must be missing something. What does JavaScript have to do with this? My understanding is that csrf is about people getting tricked into clicking a link that makes, for example, a post request to another site/origin that makes an undesired mutation to their account. If the site/origin has some sort of Auth (eg session cookie), it'll get sent along with the request. If the Auth cookie doesn't exist (user isn't logged in/isn't a user) the request will fail as well.
- tankenmate 1y ago
  There's server security and there's client security. From what I've seen in these comments people are focused on the client security and are either a) ignoring server security, or b) don't understand server security. But the server security is the primary security, because it's the one with the resources (in the money analogy it's the bank). So yes, we do want to secure the client, but if the attacker has enough control of your computer to get your cookies then it's already game over. Like I said you can have time bounded CSRF tokens (be they cookies or whatever else, URL encoded, etc who cares) to prevent replay attacks. But at the end of the day if an attacker can get your cookies in real time you're done for, it's game over already. If they want to do a man in the middle attack (i.e. click on a fake "proxy" URL) then having the "secure" flag should be enough. If the server checks the cookie against the client's IP address, time, HMAC, other auth attributes, will then prevent the attack. If they attacker takes control of your end device, you've already lost.
  - nchmy 1y ago
    Sorry, but you seem to be lost. I, the article and most comments here quite explicitly talked about server security via Auth and csrf protections. None of this has anything to do with browser security, such as stealing csrf tokens (which tend to be stored as hidden fields on elements in the html, not cookies). MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.
    - tankenmate 1y ago
      "MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.", you're just posting misinformation, you are flat out wrong. "It is important to note that Fetch Metadata headers should be implemented as an additional layer defense in depth concept. This attribute should not replace a [sic] CSRF tokens (or equivalent framework protections)." -- OWASP; https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
      - minitech 1y ago
        That quote is probably referring to the limitations listed later on the page (https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#limitations-and-gotchas https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...). I think if you understood that this was the caveat, you wouldn’t use the phrasing “flat out wrong” or have brought up all the irrelevant stuff about client/server security earlier in the thread. You have some kind of deeper misunderstanding, but it’s not clear where.
        deleted 1y ago
        [deleted]
      - nchmy 1y ago
        Once again, you have no idea what you're talking about. Moreover, you lack critical thinking skills - the Sec-Fetch-Site section in that doc is senseless and will now be modified to say that Sec-Fetch-Site is sufficient on its own. https://github.com/OWASP/CheatSheetSeries/issues/1803 https://github.com/OWASP/CheatSheetSeries/issues/1803

nchmy 1y ago

I must be missing something. What does JavaScript have to do with this? My understanding is that csrf is about people getting tricked into clicking a link that makes, for example, a post request to another site/origin that makes an undesired mutation to their account. If the site/origin has some sort of Auth (eg session cookie), it'll get sent along with the request. If the Auth cookie doesn't exist (user isn't logged in/isn't a user) the request will fail as well.

tankenmate 1y ago
There's server security and there's client security. From what I've seen in these comments people are focused on the client security and are either a) ignoring server security, or b) don't understand server security. But the server security is the primary security, because it's the one with the resources (in the money analogy it's the bank). So yes, we do want to secure the client, but if the attacker has enough control of your computer to get your cookies then it's already game over. Like I said you can have time bounded CSRF tokens (be they cookies or whatever else, URL encoded, etc who cares) to prevent replay attacks. But at the end of the day if an attacker can get your cookies in real time you're done for, it's game over already. If they want to do a man in the middle attack (i.e. click on a fake "proxy" URL) then having the "secure" flag should be enough. If the server checks the cookie against the client's IP address, time, HMAC, other auth attributes, will then prevent the attack. If they attacker takes control of your end device, you've already lost.
- nchmy 1y ago
  Sorry, but you seem to be lost. I, the article and most comments here quite explicitly talked about server security via Auth and csrf protections. None of this has anything to do with browser security, such as stealing csrf tokens (which tend to be stored as hidden fields on elements in the html, not cookies). MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.
  - tankenmate 1y ago
    "MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.", you're just posting misinformation, you are flat out wrong. "It is important to note that Fetch Metadata headers should be implemented as an additional layer defense in depth concept. This attribute should not replace a [sic] CSRF tokens (or equivalent framework protections)." -- OWASP; https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
    - minitech 1y ago
      That quote is probably referring to the limitations listed later on the page (https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#limitations-and-gotchas https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...). I think if you understood that this was the caveat, you wouldn’t use the phrasing “flat out wrong” or have brought up all the irrelevant stuff about client/server security earlier in the thread. You have some kind of deeper misunderstanding, but it’s not clear where.
      - deleted 1y ago
        [deleted]
    - nchmy 1y ago
      Once again, you have no idea what you're talking about. Moreover, you lack critical thinking skills - the Sec-Fetch-Site section in that doc is senseless and will now be modified to say that Sec-Fetch-Site is sufficient on its own. https://github.com/OWASP/CheatSheetSeries/issues/1803 https://github.com/OWASP/CheatSheetSeries/issues/1803