In Safari, cookies are blocked in all third-party requests regardless of their SameSite status and regardless of the HTTP method. If you're referring to whether SameSite=lax by default fixes CSRF or not, you'd have to ask the browser people who have chosen that path.
-
-
Replying to @johnwilander
If http://evil.com embeds <form action="https://site.com/x " method="POST"> and the browser has first-party cookies on http://site.com , are those cookies sent along with the POST request in Safari?
2 replies 1 retweet 1 like -
Replying to @mikispag @johnwilander
In other words, does Safari have an equivalent of `SameSite=Strict` by default?
1 reply 0 retweets 0 likes -
Replying to @mikispag
Does the user stay on http://evil.com in your example?
1 reply 0 retweets 0 likes -
Replying to @johnwilander
In a textbook XSRF attack, the victim visits http://evil.com , which has a <form method=POST action=https://bank.com/withdraw?amount=1337&to=attacker …>. Pretty sure Safari sends http://bank.com 's cookies along with the POST request to http://bank.com .
1 reply 0 retweets 0 likes -
Replying to @mikispag
Are you talking about a top frame navigation away from http://evil.com to http://bank.com or a subresource request to http://bank.com while still on http://evil.com as top frame website?
1 reply 0 retweets 0 likes -
Replying to @johnwilander
I am talking about an automatically submitting <form method=POST action=https://bank.com/withdraw > in the markup of http://evil.com , owned by an attacker, as in the simplest XSRF possible.
1 reply 0 retweets 0 likes -
Replying to @mikispag @johnwilander
But yes, the form[method=POST] would trigger a navigation away from http://evil.com , unless you add _target to form, but that doesn't change the fact that cookies are sent along with the request, right?
1 reply 0 retweets 1 like -
Replying to @mikispag
Navigating the top frame cross-site is not classic CSRF. If evil.example navigates the top frame to other.example, the applicable cookies will be sent. But if evil.example makes subresource requests to other.example, including form posts, those will not carry cookies.
3 replies 0 retweets 0 likes -
Replying to @johnwilander @mikispag
Attackers simply choose the method that works - and it seems app owners still need to rely on xsrf tokens, even only in Safari.
2 replies 0 retweets 2 likes
Hmm, It seems like the claim "solves cross-site request forgeries" is dangerously misleading. I get what you were trying to say John, but nobody can safely remove XSRF mitigations, so why even mention it..? It will just cause confusion, no?
-
-
As mentioned in a sub thread, I've changed that bullet point to say "Disables cross-site request forgery attacks against websites through third-party requests."
1 reply 0 retweets 1 like -
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?
1 reply 0 retweets 2 likes - 13 more replies
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.