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]> >>> <mailto:[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]> >>>> <mailto:[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] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe >> <https://preferences.forgerock.com/> > -- > Jim Manico > Manicode Security > https://www.manicode.com > <https://www.manicode.com/>_______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
