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?

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
13
  • Excellent, thank you, "Origin-Bound-Cookies" is what I failed to find. Great!
    – Borek Bernard
    Jul 14, 2021 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, 2021 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, 2021 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, 2021 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, 2021 at 11:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .