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?

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.

13
  • Excellent, thank you, "Origin-Bound-Cookies" is what I failed to find. Great! Jul 14 at 22:50
  • You do have the ‘SECURE’ keyword limiting its use to only HTTPS (especially if combined with the __secure prefix) see developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie
    – LvB
    Jul 15 at 8: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 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 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 at 11:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.