Subject: [OAUTH-WG] Web apps BCP feedback

From: Dominick Baier <[email-masked]>
Date: Sat, 25 Sep 2021 04:07:25 -0700

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

---

From: Jim Manico <[email-masked]>
Date: Sat, 25 Sep 2021 07:19:54 -1000

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-masked]> wrote:
> 
> 
> In 6.1 it says
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Neil Madden <[email-masked]>
Date: Sat, 25 Sep 2021 19:10:58 +0100

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-masked]> wrote:
> 

-- 
Manage My Preferences <https://preferences.forgerock.com/>, Unsubscribe 
<https://preferences.forgerock.com/>

---

From: Jim Manico <[email-masked]>
Date: Sat, 25 Sep 2021 12:15:38 -1000

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
>
>>  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.
>>
>>> 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
> Manage My Preferences <https://preferences.forgerock.com/>, 
> Unsubscribe <https://preferences.forgerock.com/>
>
-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Philippe De Ryck <[email-masked]>
Date: Sun, 26 Sep 2021 08:30:17 +0200

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-masked]> wrote:
> 
> Hi Neil! =)
> 
> I get your point! 
>  	   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 25 Sep 2021, at 18:20, Jim Manico <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>>> On Sep 25, 2021, at 1:07 AM, Dominick Baier <[email-masked]> <mailto:[email-masked]> wrote:
>>>> 
>>>> 
>>>> In 6.1 it says
>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> [email-masked] <mailto:[email-masked]>
>>> 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-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Neil Madden <[email-masked]>
Date: Sun, 26 Sep 2021 09:24:25 +0100

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-masked]> wrote:
> 
>>> Manage My Preferences, Unsubscribe
>>> 
>> -- 
>> Jim Manico
>> Manicode Security
>> https://www.manicode.com

---

From: Jim Manico <[email-masked]>
Date: Sun, 26 Sep 2021 00:28:43 -1000

> 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-masked]> wrote:
> 
>

---

From: Neil Madden <[email-masked]>
Date: Sun, 26 Sep 2021 13:17:28 +0100

> On 26 Sep 2021, at 11:28, Jim Manico <[email-masked]> wrote:
> 
> 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

No, sadly not. You can set a cookie with domain set to payments.example.com but then I can hijack foo.example.com and set my own cookie with domain=example.com and the server will be none the wiser. 

Cheers,

Neil

---

From: Thomas Broyer <[email-masked]>
Date: Sun, 26 Sep 2021 15:11:04 +0200

> Right, cookie prefixes is one approach - but still has a little way to go

Fwiw, a big part of that "missing" browser share is Safari on iOS (14.25%
of global share), and I just tested on devices through BrowserStack on
https://googlechrome.github.io/samples/cookie-prefixes/ and it *does*
support cookie prefixes (tested with v14 and v13).

>
> 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, just mentioning that there should be CSRF mitigations in place should
be enough IMO.
Also maybe mention that securing the API is then actually outside the scope
of the BCP (whose role in this case is only to recommend *not* using OAuth)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>