Re: [OAUTH-WG] Web apps BCP feedback

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 <philippe@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 <jim@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 <jim@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 <dbaier@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/>