In other words, does Safari have an equivalent of `SameSite=Strict` by default?
-
-
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?
1 reply 0 retweets 2 likes -
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?
-
-
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 - 11 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.