The Great SameSite Confusion
jub0bs.com
jub0bs.com
I think the term cross-origin could - and should - be avoided altogether. In the end of the day a request is either
* same-origin (which implies same-site)
* same-site (cross-origin or not, doesn't matter)
* cross-site (implying cross-origin, again doesn't matter)
That's all there is to it, and sufficiently describes the situation. cross-origin on the other hand is rather ambiguous when used alone.
The addition of Public Suffix in this mix slightly confuses things, but I can see why it's necessary for services that give out subdomains. This is actually my first time hearing of it (or to be precise, knowing of it as a concept), and yet it seems to have been around since 2007!
[...] for domains such as .co.jp or .github.io, just using the TLD of .jp or .io is not granular enough to identify the "site". And there is no way to algorithmically determine the level of registrable domains for a particular TLD. That's why a list of "effective TLDs"(eTLDs) was created.
If foo.github.io and bar.github.io were considered same-site, one subdomain could mount cross-origin same-site attacks against the other. I'm guessing that's why companies that have multiple tenants on the same domain (github.io, in this case) ask that the domain be added to the public-suffix list: for isolation purposes. Other examples of public suffixes are azurewebsites.net (Azure App Services) and repl.co (Repl.it).
If I were redesigning whatever I felt like without backwards-compatibility concerns, things like TLS certificate authentication, HTTP Strict Transport Security and public suffix matters would certainly all be done through DNS.
Not sure if anyone has ever seriously suggested shifting the PSL into DNS, but it seems a pretty reasonable goal to me. Certainly a few other things of this general style (that is, things you need to know before making the HTTPS connection) have been shifting into DNS, and a public suffix list is a better candidate than most because it’s a comparatively restricted set of people that will be using it, so they can cope with setting DNS records (that is, you’re not pushing everyone into implementing it, which would be completely doomed to failure).
Another thing: even if your browser is using DoH 100% of the time, that's not good enough. Other things can use the public suffix list, such as a commandline go program that makes http requests[1]. If that program isn't using DoH then it's now vulnerable. Most programs use the DNS resolution capabilities provided by your operating system. I don't think any operating systems by default use DoH.
[1] https://golang.org/pkg/net/http/cookiejar/#PublicSuffixList
If I want a cookie to be only sent in requests from a page on https://mywebsite.com to https://mywebsite.com/internal/..., but not from any other origins, should I use Lax or Strict?
If I use HttpOnly cookies and Access-Control-Allow-Credentials=false on https://mywebsite.com/internal/..., does that make SameSite irrelevant? Would there be a security risk even if SameSite=None? Is the only security risk related to <img>?
Neither setting will do what you want since the flag acts on Sites and not Origins. That is, even in SameSite=Strict mode, requests from subdomain.mywebsite.com will send cookies to mywebsite.com/internal, because they're the same Site.
> If I use HttpOnly cookies and Access-Control-Allow-Credentials=false on https://mywebsite.com/internal/..., does that make SameSite irrelevant? Would there be a security risk even if SameSite=None? Is the only security risk related to <img>?
HttpOnly is irrelevant for same-/cross- site/origin discussions - it just means that javascript can't read your cookie. Similarly CORS can only weaken the same origin policy - best to not send it at all. If you want to protect yourself against CSRF attacks on /internal then your best bet is still using standard protections like a double submit cookie or checking the origin/referrer headers. OWASP has a great cheat sheet on it:
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
This seems to be about as harsh as reasonable without breaking CSRF protection:
network.http.sendRefererHeader=1
network.http.referer.trimmingPolicy=2
network.http.referer.XOriginPolicy=2
Strict. If you use lax the cookies would be sent when clicking on a link cross origin.
Most people however do want cookies to be sent on cross origin link navigation.
[Edit: someone else pointed out that you would still get cookies from requests sent from subdomains, and indeed that is what the article is about. For lots of people that is probably not a big deal]
> If I use HttpOnly cookies and Access-Control-Allow-Credentials=false on https://mywebsite.com/internal/..., does that make SameSite irrelevant? Would there be a security risk even if SameSite=None? Is the only security risk related to <img>?
If samesite=none, (and you didnt implement csrf tokens) you could still send cookies from other sites via forms. So you can pull off old style csrf (like how you would exploit a csrf in the 90s before ajax was even a thing).
Also i think (but not 100% sure) that cookies would still be sent for ajax requests not requiring a preflight or for script inclusions.
Which is to say, I like the dark theme the way it is too. Rock on.
Yes terminology is important and its important to realize that there are differences, but honestly it doesnt seem that important a distinction for broad overview articles to make.
Otoh being able to set cookies cross origin within same site (except those starting with __host-) seems like a much poorer understood thing and one more likely to lead to vulns.
If I got that wrong, it's because I didn't finish reading the post. I quit around "what do we mean by 'origin'?" because it was clear there was a lot more background to go and not clear I would learn anything practical.
By the way, one of the takeaways in the post is that even SameSite=Strict is powerless against (cross-origin) same-site attacks. I would certainly recommend using Strict wherever possible and practical, but Strict shouldn't be misconstrued as a drop-in replacement for anti-CSRF tokens.
When I encounteted the problem, I wrote this practical post to resolve the problem via browser configurations: https://timdaub.github.io/2020/12/03/samesite/
--disable-web-security --user-data-dir=tmp
Of course you have to remember not to use this browser for browsing during and after development, which is easier said than done.
Have you split the universes? Is there now an alternate reality of some kind? To read that second cookie, do you always have to arrive from the first site?