Right, cookie prefixes is one approach - but still has a little way to go on browser share [1].
In my book (have I mentioned my book? :-)), I show a variant of the double-submit cookie pattern in which the anti-CSRF token is a SHA-256 hash of the session cookie [2], which prevents the cookie being overridden. We should probably just defer to the security considerations in rfc6265-bis [3], which already discusses some limitations of SameSite and recommends it be used as a defence-in-depth alongside traditional defences. [1]: https://caniuse.com/?search=cookie%20prefix [2]: https://livebook.manning.com/book/api-security-in-action/chapter-4/181 [3]: https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-08.html#name-samesite-cookies — Neil > On 26 Sep 2021, at 07:30, Philippe De Ryck > <phili...@pragmaticwebsecurity.com> wrote: > > That’s why cookies should be set with the __Host- prefix. > > In a carefully-designed API, CORS will function as a CSRF defense, even when > the attacker is controlling a subdomain or sibling domain. > > Overall, I think the first part of 6.1 makes sense, but I don’t think the > document should try to draw out such an architecture in 1 or 2 paragraphs at > the end of that section. > > Philippe > > — > Pragmatic Web Security > Security for developers > https://pragmaticwebsecurity.com > >> On 26 Sep 2021, at 00:15, Jim Manico <j...@manicode.com> wrote: >> >> Hi Neil! =) >> >> I get your point! >> I would suggest this text be written as something along the lines of: >> >> "Additionally, the SameSite cookie attribute can be used to >> prevent CSRF attacks but the application and API should also >> be written to use anti-CSRF tokens for stateful session-based >> applications >> or use of the double-cookie submit pattern for stateless >> applications.”' >> >> PS: If an adversary controls a subdomain can't they clobber and over-write >> root level cookies anyhow? I do not think CSRF defense will defeat an >> adversarial subdomains ability to over-write a cookie and circumvent >> double-cookie-submit. >> >>> On 9/25/21 8:10 AM, Neil Madden wrote: >>> Technically yes, CSRF refers to cross-site attacks. However, there is a >>> class of attacks that are cross-*origin* but not cross-site and which are >>> otherwise identical to CSRF. SameSite doesn’t protect against these attacks >>> but other traditional CSRF defences *do*. For example, synchronizer tokens >>> in hidden form fields or even just requiring a custom header on requests >>> both provide some protection against such attacks, as they both use >>> mechanisms that are subject to the same origin policy rather than >>> same-site. >>> >>> — Neil >>> >>>>> On 25 Sep 2021, at 18:20, Jim Manico <j...@manicode.com> wrote: >>>>> >>>> If someone has taken over a subdomain in the ways described, that is not >>>> cross site request forgery since the attack is occurring from within your >>>> site. It’s more likely XSS that allows for cookie clobbering or similar, >>>> or just malicious code injected by the malicious controller of your >>>> subdomain. This is not strictly CSRF nor are these problems protected from >>>> any other standard form of CSRF defense. >>>> >>>> CSRF is Cross Site attack where the attack is hosted on a different >>>> domain. >>>> >>>> -- >>>> Jim Manico >>>> >>>>>> On Sep 25, 2021, at 1:07 AM, Dominick Baier <dba...@leastprivilege.com> >>>>>> wrote: >>>>>> >>>>> >>>>> In 6.1 it says >>>>> >>>>> "Additionally, the SameSite cookie attribute can be used to >>>>> prevent CSRF attacks, or alternatively, the application and API >>>>> could >>>>> be written to use anti-CSRF tokens.” >>>>> >>>>> “Prevent” is a bit strong. >>>>> >>>>> SameSite only restricts cookies sent across site boundaries Iit does not >>>>> prevent CSRF attacks from within a site boundary. Scenarios could be a >>>>> compromised sub-domain, like sub-domain takeover or just some vulnerable >>>>> application co-located on the same site. >>>>> >>>>> thanks >>>>> ——— >>>>> Dominick Baier >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> Manage My Preferences, Unsubscribe >>> >> -- >> Jim Manico >> Manicode Security >> https://www.manicode.com >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe <https://preferences.forgerock.com/>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
