41–50 of 116 posts
Earlier quoted context omitted.
The entire web security model assumes we can trust browsers to implement web security policies!
I appreciate that, but in the case of TLS or CSRF tokens the server is not blindly trusting the browser in the way Sec-Fetch-Site makes it.
Earlier quoted context omitted.
This is "not allowing cross site at all" so, technically it's not "request forgery" protection. Yes, this is very semantic, but, CSRF is a vulnerability introduced by enabling CS and CORS. So, technically, same-site cookies are not "protection" against CSRF.
I don't understand your distinction at all. I may not quite grok your meaning here, but CORS is usually discussed in the context of allowing cross-origin AJAX calls. But cross origin form posts are and have always been permitted, and are the main route by which CSRF vulnerabilities arise. Nothing on the client or server needs to be enabled to allow these form posts. Furthermore, the approach detailed in the article s…
I'm surprised there's no mention of the SameSite cookie attribute, I'd consider that to be the modern CSRF protection and it's easy, just a cookie flag: https://scotthelme.co.uk/csrf-is-dead/ But I didn't know about the Sec-Fetch-Site header, good to know.
I’m confused, how does this prevent a CSRF attack? SameSite or not is inconsequential to the check a backend does for a CSRF token in the POST.
Earlier quoted context omitted.
I appreciate that, but in the case of TLS or CSRF tokens the server is not blindly trusting the browser in the way Sec-Fetch-Site makes it.
Sure it is. The same-origin rule that holds the whole web security model together is entirely a property of browser behavior.
Earlier quoted context omitted.
I’m confused, how does this prevent a CSRF attack? SameSite or not is inconsequential to the check a backend does for a CSRF token in the POST.
No? The whole point of SameSite=(!none) is to prevent requests from unexpectedly carrying cookies, which is how CSRF attacks work.
I’m not being rude, what does it mean to unexpectedly carry cookies? That’s not what I understand the risk of CSRF is.
My understanding is that we want to ensure a POST came from our website and we do so with a double signed HMAC token that is present in the form AND the cookie, which is also tied to the session.
What on earth is unexpectedly carrying cookies?
Earlier quoted context omitted.
I’m confused, how does this prevent a CSRF attack? SameSite or not is inconsequential to the check a backend does for a CSRF token in the POST.
The only reason CSRF is even possible is because the browser sends (or, well, used to send) cookies for a particular request even if that request initiated from a different site. If the browser never did that (and most people would argue that's a design flaw from the get go) CSRF attacks wouldn't even be possible. The SameSite attribute makes it so that cookies will only be sent if the request that originated them is…
I'm surprised there's no mention of the SameSite cookie attribute, I'd consider that to be the modern CSRF protection and it's easy, just a cookie flag: https://scotthelme.co.uk/csrf-is-dead/ But I didn't know about the Sec-Fetch-Site header, good to know.
This is "not allowing cross site at all" so, technically it's not "request forgery" protection. Yes, this is very semantic, but, CSRF is a vulnerability introduced by enabling CS and CORS. So, technically, same-site cookies are not "protection" against CSRF.
Earlier quoted context omitted.
The OWASP CSRF prevention cheat sheet page does mention SameSite cookies, but they consider it defense in depth: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re... .
Because of clientside Javascript CSRF, which is not a common condition.
Earlier quoted context omitted.
Yep SameSite lax, and just make sure you never perform any actions using Get requests, which you shouldn’t anyway.
Unsubscribe often need to be GET, or at least start as GET
Am I missing something? The suggested protection helps with XSS flavors of CSRF but not crafted payloads that come from scripts which have freedom to fake all headers. At that point you also need an oauth/jwt type cookie passed over a private channel (TLS) to trust the input. Which is true for any sane web app, but still…
As I understand it, the moment you’re dealing with custom scripts, you’ve left the realm of a csrf attack. They’re dependent upon session tokens in cookies