3 ms·
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
by 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 agoSorry, 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 agoThat 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 agoOnce 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