TLD Confusion
-
I am reading about same site cookies from https://web.dev/samesite-cookies-explained/
It says
If the user is on www.web.dev and requests an image from static.web.dev then that is a same-site request.
The public suffix list defines this, so it's not just top-level domains like .com but also includes services like github.io. That enables your-project.github.io and my-project.github.io to count as separate sites.
If the user is on your-project.github.io and requests an image from my-project.github.io that's a cross-site request.
I am super confused. The former case is considered same-site cos both have the same domain(web.dev). The second is considered cross site but they still have the same domain(github.io). Why is it considered cross-site? What am I missing here? Is the example wrong?
-
@stillwater The documentation linked says that ".github.io" is defined as a suffix string, just like ".com" is defined as a suffix string.
A.X.Z and B.X.Z will be "same site" for any Z on the public suffix list. So A.X.com and B.X.com, or A.X.github.io and B.X.github.io, both work.
-
@Unperverted-Vixen In that case, how does the browser know a.github.io and b.github.io are different sites but a.x.com and b.x.com are same sites? That's the bit that does not make sense to me.
-
@stillwater basically there’s a list that says “.com is a suffix and .github.io is a suffix” and this list is maintained by Mozilla.
-
@stillwater said in TLD Confusion:
@Unperverted-Vixen In that case, how does the browser know a.github.io and b.github.io are different sites but a.x.com and b.x.com are same sites? That's the bit that does not make sense to me.
The public suffix list is what the browser uses to determine the effective “top level domains” from the perspective of same site cookies.
The first level after a suffix is a site (a.github.io or b.com). Any level after that is a subdomain of the same site.
-
How often is this list updated?
I'm not sure of a better way to do it, but if I understand it correctly, this has the wrong failure mode. I.e. if there's a suffix that should be on that list but isn't yet (or rather, your browser isn't updated yet), then your browser fails in a way that doesn't just break the site but instead creates a silent cross site vulnerability.
-
@topspin said in TLD Confusion:
How often is this list updated?
Whenever there's a PR accepted. Literally.
GitHub - publicsuffix/list: The Public Suffix List
The Public Suffix List. Contribute to publicsuffix/list development by creating an account on GitHub.
I'm not sure of a better way to do it
How often do you synch? No idea, but once a week will usually be sufficient. At that point, an attack needs to note a problem on a site that's gained something popular very soon after it was opened up. The time for someone to register a change to the suffix list is probably shorter than the time it takes to get noticed as having content worthy of attack.
-
@topspin The other site would need to be under the same domain. But yeah, I would have assume cookies to explicitly set the applicable domains and whether sub-domains thereof are allowed, too.
-
@acrow said in TLD Confusion:
@topspin The other site would need to be under the same domain.
Yes, that's what I meant.
Say your browser doesn't have "github.io" in its list. The right failure mode would be "stuff that should work doesn't, update" but not "stuff works which should actually be forbidden to work". Which is a vulnerability if "a.github.io" can access stuff from "b.github.io" because your suffix list is too old.
-
Why is such a list maintained by The Most Holy Rosicrucian Order of the Internets even a thing in the first place?
Couldn't the first-party Host advertise its own allowed suffixes?
-
@topspin said in TLD Confusion:
Which is a vulnerability if "a.github.io" can access stuff from "b.github.io" because your suffix list is too old.
Now remember that both a.github.io and b.github.io can send/read cookies on github.io itself without this list... this has been in the spec since forever.
-
@Applied-Mediocrity Apparently that's too hard to do.
-
I wouldn't say it's "too hard", just "too limiting".
The big problem is that the domain list would be fixed when the cookie is set. So if you ever need to add a new subdomain to your application (say, you want to move all images onto a CDN), suddenly you need to invalidate every single session so that they can get new cookies with the new subdomain in the allow list.
-
My original question has been answered but this is still a very weird behaviour!
-
@Unperverted-Vixen said in TLD Confusion:
I wouldn't say it's "too hard", just "too limiting".
The big problem is that the domain list would be fixed when the cookie is set. So if you ever need to add a new subdomain to your application (say, you want to move all images onto a CDN), suddenly you need to invalidate every single session so that they can get new cookies with the new subdomain in the allow list.
If you're sure you won't be handing out subdomains to individual and potentially malicious customers, you could make your cookies valid for all potential subdomains to begin with. If the CDN needs to see your cookies at all, which it usually¹ doesn't, so that would make the CDN requests even faster.
¹ Not like I had a great overview but at least in most instances I've seen they weren't used.
-
@LaoC Yeah, a CDN probably doesn't need cookies. It was just the simplest example for adding a new subdomain to a live app that I could think of, without going full-on "build a new microservice" that I thought would distract from the case.
-
@Unperverted-Vixen you’d be surprised at the shenanigans that occur if you shove a CDN in front of a WordPress and then have to deal with all the nonsense of sending cookies for all that analytics horseshit.
The marketing people get so very upset about the cookies not arriving at their precious CRM integrations (which are all WP plugins that have no understanding whatsoever of CDNs, because of course they don’t)
