91–100 of 116 posts
Earlier quoted context omitted.
SameSite doesn’t protect against same-site cross-origin requests, so you are staking your app’s security on the security of the marketing blog.
What do you mean with same-site cross-origin requests?
Earlier quoted context omitted.
What do you mean with same-site cross-origin requests?
See the same-site section of https://words.filippo.io/csrf/
It's a pretty cool attack chain, if there's an XSS on marketing.example.com it can be used to execute a CSRF on app.example.com! It could also be used with dangling subdomain takeover or if there's open subdomain registration.
Earlier quoted context omitted.
See the same-site section of https://words.filippo.io/csrf/
Oh, thanks. I learned something new. Never knew that different subdomains are considered the same "site", but MDN confirms this[0]. This shows just how complex these matters are imo, it's not surprising people make mistakes in configuring CSRF protection. It's a pretty cool attack chain, if there's an XSS on marketing.example.com it can be used to execute a CSRF on app.example.com! It could also be used with dangling…
Right now the problem is what the author already mentions - the use of Sec-Fetch-Site (FYI, HTTP headers are case insensitive :) - is considered defense in depth in OWASP right now, not a primary protection. Unfortunately OWASP rules the world. Not because it's the best way to protect your apps, but because the corporate overloads in infosec teams need to check the box with "Complies with OWASP Top 10"
The OWASP Top 10 is a list of vulnerabilities, not a checklist of things you have to actually "do".
Unfortunately, the customer purchasing your product doesn’t know this and (naturally) trusts their own internal experts over you. Especially given all their other suppliers are more than happy to state they’re certified!
Earlier quoted context omitted.
See the same-site section of https://words.filippo.io/csrf/
Oh, thanks. I learned something new. Never knew that different subdomains are considered the same "site", but MDN confirms this[0]. This shows just how complex these matters are imo, it's not surprising people make mistakes in configuring CSRF protection. It's a pretty cool attack chain, if there's an XSS on marketing.example.com it can be used to execute a CSRF on app.example.com! It could also be used with dangling…
rails does this in 8.2
I just went looking for docs and it seems that 8.2 is not out yet
Earlier quoted context omitted.
The OWASP Top 10 is a list of vulnerabilities, not a checklist of things you have to actually "do".
While you’re correct, corporate security teams demand suppliers “comply with OWASP,” despite this being a nonsensical statement to anyone who’d read the website. Unfortunately, the customer purchasing your product doesn’t know this and (naturally) trusts their own internal experts over you. Especially given all their other suppliers are more than happy to state they’re certified!
Earlier quoted context omitted.
Cs and cors have nothing to do with csrf... Though, yes, neither does same-site
I don't know why I said same-site cookies have nothing to do with csrf. They can be helpful as defense in depth, but not primary defense.
I feel like people are just parroting the OWASP "they're just defense in depth!" line without understanding what the actual underlying vulnerabilities are, namely:
1. If you're performing a sensitive operation on a GET, you're in trouble. But I think that is a bigger problem and you shouldn't do that.
2. If a user is on a particularly old browser, but these days SameSite support has been out on all major browsers for nearly a decade so I think that point is moot.
The problem I have with the "it's just defense in depth" line is people don't really understand how it protects against any underlying vulnerabilities. In that case, CSRF tokens add complexity without actually making you any safer.
I'd be happy to learn why my thinking is incorrect, i.e. where there's a vulnerability lurking that I'm not thinking of if you use SameSite Lax and only perform state changes on mutable methods.