> That’s why cookies should be set with the __Host- prefix. You can also set the domain of a cookie to actually be a host (subdomain). Does that also prevent subdomains from clobbering root directory cookies?
PS: I realize this is close to off topic, my last comment on this. - Jim Manico > On Sep 25, 2021, at 10:24 PM, Neil Madden <[email protected]> wrote: > > > 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 >>> <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>>> 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 >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> Manage My Preferences, Unsubscribe >>>> >>> -- >>> Jim Manico >>> Manicode Security >>> https://www.manicode.com >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> > > Manage My Preferences, Unsubscribe >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
