2

I have read Incrementally Better Cookies, a couple of web.dev articles and tried to google for "same-origin cookies" but could not find anything so I wonder if this is being worked on.

SameSite=Strict & Lax are a very good protection against CSRF but hacked subdomains remain a way to attack – for example, hacked.example.com can forge credentialed requests to example.com easily.

I would imagine that restricting cookies further, from same-site to same-origin, would be a logical next step. What is being worked on is schemeful same-site (distinguishing http:// vs. https:// when considering what is same-site) but why not use the concept of origin?

Borek Bernard
  • 345
  • 1
  • 4
  • 11

1 Answers1

2

Yes it would definitely make sense and there is a proposition about this (Origin Bound cookies).

SameSite=Strict & Lax are a very good protection against CSRF but hacked subdomains remain a way to attack – for example, hacked.example.com can forge credentialed requests to example.com easily.

Fot this, you can actually use the __Host- cookie prefix. On browsers with support for cookie prefixes, it is not possible to set them across domains: this way your are sure that the cookie actually comes from example.com and not hacked.example.com.

However, there is currently no way to bind a cookie to a (domain, port) pair. As I'm discussing on a bug entry, this is especially problematic for localhost-bound non-HTTPS web server: another local user can exfiltrate your cookies by spawning a local server on another port and tricking you into browser to this web server.

ysdx
  • 851
  • 6
  • 14
  • Excellent, thank you, "Origin-Bound-Cookies" is what I failed to find. Great! – Borek Bernard Jul 14 '21 at 22:50
  • You do have the ‘SECURE’ keyword limiting its use to only HTTPS (especially if combined with the __secure prefix) see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie – LvB Jul 15 '21 at 08:54
  • @LvB, not sure what you bean by this. __Host is strictly more "strict" than __Secure has it implies the same things are __Strict. Concerning the exfiltration of localhost-bound cookies, using HTTPS is indeed an option (but usually those services are usually not using HTTPS). – ysdx Jul 15 '21 at 10:41
  • __HOST does not say anything about the connection type, __SECURE does… but who one to pick is a implementatie detail. (But having a __SECUREmy.example.com for my.example.com would vind said cookie to the domain (and it’s leafs) and to the protocol (HTTPS). The main caveat is the localhost exception. Finally I have heard no valid reason to not run TLS… (as of yet, in any case). – LvB Jul 15 '21 at 10:59
  • @LvB, the prefix is actually to the cookie **name**, not the domain name (eg. Set-Cookie: __Host-SID=12345; Secure; Path=/) – ysdx Jul 15 '21 at 11:07
  • @LvB, see https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cookie-prefixes-00, “If a cookie's name begins with "__Host-", the **cookie MUST be: Set with a "Secure" attribute** […]” – ysdx Jul 15 '21 at 11:08
  • @ysdx you are correct… I missed that.. sorry. (I only know it for the __SECURE prefix… Thank you for pointing it out to me. – LvB Jul 15 '21 at 11:10
  • @LvB, by the way, "secure" cookies actually work on http://127.0.0.1:* (and at least for Firefox "localhost", etc.) as it is considered a secure context, https://www.w3.org/TR/secure-contexts/#localhost https://github.com/w3c/webappsec-secure-contexts/issues/43 – ysdx Jul 15 '21 at 11:21
  • @ysdx From the MDN site " Secure Cookie is only sent to the server when a request is made with the https: scheme (except on localhost), and therefore is more resistent to man-in-the-middle attacks." So if this is true, its not conform there own Documentation. – LvB Jul 15 '21 at 12:41
  • @ysdx After reading the explainers [here](https://github.com/sbingler/Origin-Bound-Cookies#does-this-proposal-obsolete-schemeful-same-site) and [here](https://github.com/sbingler/schemeful-same-site#how-do-schemeful-same-site-and-scheme-bound-cookies-differ), I think that even the combination of Schemeful Same-Site and Origin-Bound Cookies don't prevent subdomain CSRF attacks – a hypothetical "Originful Same-Site" would (or the `__Host-` prefix as you said). So to renew the question, would it make sense to propose "Originful Same-Site"? Is there such proposal? – Borek Bernard Jul 20 '21 at 10:27
  • Origin-bound is designed to be more strict and supersede schemefule cookies AFAIU. The opt-out mechanism for origin-bound cookies would be toggled by passing a Domain argument. This parameter is forbidden in __Host- prefixed cookies. Thus, these cookies would be completely origin-bound under this proposal. Would you expect something else? – ysdx Jul 20 '21 at 18:25
  • Origin-bound cookies are complementary to schemeful cookies as explained [here](https://github.com/sbingler/Origin-Bound-Cookies#does-this-proposal-obsolete-schemeful-same-site). Surprisingly to me, even the combination of both of them isn't enough to protect from subdomain attacks and the (relatively unknown) `__Host-` prefix needs to be used. – Borek Bernard Jul 21 '21 at 14:20
  • Also relevant, but never implemented by browsers: https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html – jub0bs Aug 10 '21 at 19:03