search

sbingler / schemeful-same-site

Explainer for Schemeful Same-Site
15 stars 3 forks source link

"Originful Same-Site"? #6

Open borekb opened 3 years ago

borekb commented 3 years ago

Hi, I've encountered this repo via a question on security.stackexchange.com Would “same-origin cookies” make sense? and thought that I'd ask here as well.

As far as I understand, with the help of excellent explainers 1 and 2, even a combination of Schemeful Same-Site && Origin-Bound Cookies wouldn't prevent an attack from a hacked subdomain, right? A hypothetical "Originful Same-Site" would do that but I couldn't find any discussion in that direction – maybe I missed it or maybe it's a bad idea?! Any insight would be greatly appreciated.

davidben commented 3 years ago

There are a few things an origin might be worried about with a compromised subdomain:

  1. Can the subdomain read cookies set by my origin? (Confidentiality)
  2. Can the subdomain write cookies and trick my origin into thinking they were set? (Integrity)
  3. Can the subdomain initiate a cookied request to my origin and trick me into performing some action. (CSRF)

And, yes, you're right that cookies do not generally handle compromised subdomains very well. The boundary for cookies has largely been an eTLD+1. This deviates significantly from the rest of the web platform, which uses an origin granularity. (Cookies, alas, predate same-origin by a bit, so there is a lot of legacy.)

(1) and (2) are concerned with the request's destination. For (1), it is sufficient to make a domain-bound cookie. That is, omit the Domain attribute. (And remember to set the Secure attribute!) Origin-bound cookies strengthen this by fixing the mess around the scheme (needing the Secure attribute is error-prone), and tweaking things to align better with same-origin around ports.

However, that doesn't help with (2), because the subdomain can always set its own cookie with the Domain attribute, and the origin can't tell. For that, the fix is cookie prefixes. You should prefix your cookie name with __Host- and not accept the unprefixed version. It's not very clean, but any other solution would break compatibility with all the existing sites that use the Domain attribute.

Finally, there are CSRF attacks, which is (3) and one of the uses of the SameSite attribute. Here, we're concerned with the initiator of the request. While we could make a SameOriginInitiator attribute, it might be more flexible (less need for lots of cookies) instead for the server to make the decision based on where the browser says the request came from. The Sec-Fetch-Site header will tell you whether a request had a same-origin initiator. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site There's also the Origin header, though it isn't always sent right now: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

borekb commented 3 years ago

Great info, thanks.

So regarding (2), which is a session fixation attack, this cannot be prevented by browsers because the Domain attribute needs to keep working for a lot of apps. Using the __Host- cookie prefix is the only prevention mechanism, and it will probably always be like that, right?

Regarding (3), this is where I keep wondering whether browsers couldn't prevent CSRF attacks from subdomains, even without any new attributes. But maybe the following is an important useful scenario that would break?

A website running on https://example.com makes requests to https://api.example.com. The user can log in, which is an HTML form on https://example.com that does a POST request to https://api.example.com/login and api.example.com responds with Set-Cookie: SID=...; SameSite=Strict. The user can then invoke actions like transferring money, which is an XHR request from https://example.com to https://api.example.com and the SID cookie needs to be sent for this to work. So if browsers stopped sending cookies for requests across subdomains, this scenario would break.

Is this the reason why it's not really possible to expand the definition of site to basically be the same as origin? Or are there other / more important reasons?

(And thanks for the recommendation to look into the Sec-Fetch-Site, that certainly sounds like a good "manual" solution.)