OK, XSRF mitigations are always still required though, because any sub-resource request can be changed so that it performs a top-level navigation, and it would still be exploitable, right? So I guess my question is, don't you think it might be confusing to readers?
-
-
I don't think so. This is how https://web.dev/samesite-cookies-explained/ … formulates it:
1 reply 0 retweets 0 likes -
Replying to @johnwilander @taviso and
"While the SameSite attribute is widely supported, it has unfortunately not been widely adopted by developers. The open default of sending cookies everywhere means all use cases work but leaves the user vulnerable to CSRF and unintentional information leakage."
2 replies 0 retweets 0 likes -
And you're saying that site is correct, there are cases where this makes a CSRF unexploitable? You might be right, but for my own education, do you have an example? My intuition is that you can always just add a navigation.
1 reply 0 retweets 0 likes -
We've made clear that we mean the third-party case in the blog post. And frankly, shouldn't we celebrate what was achieved today? I mean in terms of safety and privacy on the web. It's a huge step forward.
2 replies 0 retweets 2 likes -
Ahh.. you're not saying they're not exploitable anymore, you're saying that if a CSRF requires a navigation, then it's not a CSRF??? OK, well, I wasn't expecting that answer. I'm just trying to understand if it is safer, my intuition says it's a no-op.
1 reply 0 retweets 0 likes -
If it's a no-op, you or a coworker should change this document: https://www.chromestatus.com/feature/5088147346030592 …
1 reply 0 retweets 1 like -
Sure, that does seems like it could use some clarification too!
1 reply 0 retweets 1 like -
Replying to @taviso @johnwilander and
I asked Mike about that document, they're saying that they can make form POSTs unauthenticated, that will make some CSRFs unexploitable, so that document does seem accurate. With Safari, the attack just requires modification, and it will always still be exploitable... right?
1 reply 0 retweets 0 likes -
The default will protect against navigational requests?
1 reply 0 retweets 0 likes
Yes, my understanding is SameSite=Lax will make top-level form POSTs to a third party unauthenticated, which does seem like it will have some modest security benefit.
-
-
Replying to @taviso @johnwilander and
The behavior recommended in https://tools.ietf.org/html/draft-west-cookie-incrementalism-01 … that Chrome's working on shipping is to treat cookies as `SameSite=Lax` by default. Those cookies not be included on top-level navigations using non-"safe" HTTP methods (e.g. POST). See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05#section-8.8.2 … for detail.
1 reply 0 retweets 4 likes -
So a regular GET navigation will carry them but not a POST. Got it.
1 reply 0 retweets 2 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.