The DoS won't work on most of the specific example services mentioned in the post (Blogspot, GitHub, etc.), at least not if the user is using a modern browser, because most of the big names have such cookies blacklisted by browsers.
The mechanism is the Public Suffix List, which was originally created because there needed to be a list to keep track of which TLDs used public second-level domains and only allowed registrations in the third level. For example, while foo.example.com and bar.example.com are both owned by example.com, foo.co.uk and bar.co.uk are two different domains, since co.uk is part of the UK domain hierarchy (along with ac.uk and so on) and registrations happen at the third level. Therefore it would be undesirable if foo.co.uk could set cookies for the entire .co.uk, as in the UK ccTLD world that's equivalent to setting a cookie for all of .com.
So there's a big list (initiated by Mozilla) specifying that .com is a public suffix, .co.uk is a public suffix, etc., and wildcard cookies on public suffixes are refused. This has been adapted, as a huge hack, to big sites that have user-registerable subdomains. So now .blogspot.com is also treated as a public suffix, since anyone can "register" a foo.blogspot.com under it.
However new entries are added on a fairly ad-hoc basis, so a site that allows user subdomains that can run JS is vulnerable by default unless they explicitly get themselves added. I notice Dropbox isn't there, for one.
Hmm, looks like Chrome isn't respecting the Public suffix list for setting cookies ATM, even though the site for the list claims that it does.[0]
For an example, view [1] and [2] in Chrome, and note that cookies set by [1] are viewable by [2] even though this shouldn't be allowed given blogspot's entry in the public suffix list. Firefox doesn't exhibit this behaviour, and I'm thinking this is a recent regression in Chrome, but who knows.
> Also look at translate.googleusercontent.com, if you bomb it, Google Translate will stop working.
I haven't taken a look at it, but would it make sense to add dynamic <original>.translate.googleusercontent.com subdomains for translated sites and add the base domain to the public suffix list?
> it should be solved by browsers too & length should be limited
IMO this is only going to be solved by a revision to the spec that resolves the ambiguity. The core issue is that browsers and servers disagree as to what a "reasonable" cookie jar size is, and servers are rejecting request with "unreasonably" large cookie jars.
Until those limits are actually part of a spec that people follow, someone's going to be sending too much or allowing too little and legitimate requests will get rejected.
I don't know if you've read Michal's "The Tangled Web" or the Browser Security Handbook but they both go into it a little.[3]
>I haven't taken a look at it, but would it make sense to add dynamic <original>.translate.googleusercontent.com subdomains for translated sites and add the base domain to the public suffix list?
random hash as a sandbox.<hash>.guc.com will work.
The public suffix list has two purposes: browsers won't accept wildcard cookies (desirable) but also won't accept a wildcard certificate against that name (undesirable). It's true that nobody should have a certificate for * .com or * .co.uk, but it is reasonable for Google to have * .blogspot.com.
To remove the cross-site exposure in shared domains using the PSL, there'd need to be an extra bit expressed with every entry in the PSL. Alternately, browsers could re-try the request without any cookies.
Oh, I had no idea they started adding domains like blogspot.com--that's clever! They must have just started doing that recently. And not quite as much of a hack as you say, really, since the justification is the same as the other suffixes.
The justification is the same, but it seems much less feasible to be "complete". There are a pretty manageable number of TLDs, and they generally have published policies about what they'll publicly register, so you can plausibly collect a complete list of which suffixes are public ones. But covering stuff like blogspot.com has to be done on a case-by-case basis and will be wildly incomplete. It mitigates the problem by including some of the higher-profile sites, but it doesn't seem like it can solve it generally.
Wouldn't a relatively simple fix for this be to detect this at the front end, and serve a static page with JavaScript that clears all of their cookies and then redirects back?
If I understand this correctly, that would be after the client has sent umpteen MB or GB of cookie data to you, and you've hopefully detected what's going on and are just routing the request to /dev/null by this time. If, after that, the sending of the request hasn't caused a timeout, sure, we can send some JS to delete cookies.
Yes, now I see. Weird it stayed not fixed, Public suffix list is not implemented in Chrome.
Anyway, the list is not even close to real solution (just had long discussion with @titanius on twitter why not). So many quirks and use cases of <sub>.domain.
To take an example we all know and love, a malicious *.cloudfront.net distribution could be setting cookies against cloudfront, breaking all your fancy static asset serving from cloudfront.
Is there a mitigation other than _always_ having to use a myappname-static.com domain name?
Thinking about this at a higher level -- there are some interesting similarities to "shared hosting" resource contention, but this time with domain names on CDNs. If somebody executes a forkbomb on your shared host, you're hosed. If somebody executes a cookiebomb on your CDN provider SLD, you're hosed.
Browser vendors could prevent this with good second level domain support. Register cloudfront, akamai, etc domain names as only hosting user-created content on third level domains. Pin large examples to the browser distribution, and allow TXT records in DNS specifying this at the top level.
Web browsers could also mitigate against it by limiting the size of their requests. If too many cookies have been set, throw away the older ones until the request is small enough to likely be accepted by most web servers.
It's not a perfect fix, nor does it solve the wider issue of letting one domain set a cookie for a domain that it has no authority over, but it would stop people being blocked from a site with a bizarre 500 error. Worst case, a login/ID cookie gets flushed and the user has to log in again.
Interesting. Just this week I had to investigate the exact same issue at my job. One user (of course it was the CEO...) had accumulated so many cookies that on some pages of our website he ran into the HTTP request header limit and would only get a 500 error page.
One risk factor is using JavaScript based third party services that use cookies with your host name. In our case, it was Optimizely that was storing pretty significant amounts of data in cookies. Not really sure how to tackle this issue.
We had the same issue with Optimizely cookies. They serialize the experiment data as a json blob, which grows with more experiments, and store it in a cookie. What a pain to debug as it wasn't consistent for every user.
Forgot to mention that we're using Akamai, and it's actually Akamai's servers that are hitting the limit. We'll see if we'll be able to convince them to bump up the limit. I have a hunch that there might be some resistance because of performance implications (I'm not an operations guy, my knowledge of how web servers work internally is limited). On the other hand, it seemed to intermittently work, so there may be some servers in their farm that are configured differently. Or it could have been due to fluctuations in the header length because of different query string lengths and cookie changes.
Pretty clever. This appears to be in the same vein as that trick where you could use popups to spawn more popups, and by the time the user realized what was going on their computer was completely unresponsive. (fixed with popup blocking in any browser in the last decade.)
Implementing limits on the number of cookies would seem to be the natural solution to the problem in the OP, although I doubt this problem is "worth" solving in practice since most people seem to be using cookies to do what they were meant to do.
> This appears to be in the same vein as that trick where you could use popups to spawn more popups, and by the time the user realized what was going on their computer was completely unresponsive. (fixed with popup blocking in any browser in the last decade.)
I recently visited a site that did something similar but was still effective. It opened up mailto: URI's in a loop and since I had Thunderbird set up to handle the links, it practically killed my X session.
Interesting. Quick test result: looks like flipping network.protocol-handler.external.mailto in the firefox config to false prevents this (of course, in the process, prevents action on mailto links).
I suppose I can see an argument for popping something up before firing the schema handler when something sets location.href to a mailto: URL, but that seems like the sort of thing where you'd really want to wait for evidence that it's a problem for anyone before you implement it; it both annoys the user and complicates your code, neither of which is desirable in the absence of real provocation.
not amount, but total Length of the Cookie header. Otherwise number of cookies will be ~5.
Yes I recall filldisk.com, but that one doesn't seem harmful to user (he knows where it comes from & exploit is quite slow).
Cookie bomb can "bomb" some exact path, so the trick has many uses. E.g. you can "block" /dont_like_this_post on blogspot entirely, while the rest of Blogger will work.
There's a similar self-denial of service you can run into when you're injecting javascript and cookies into third-party pages.
Optimizely (YC W10) had this problem when they were setting cookies on a single domain across all of their customer sites. If you happened to be the kind of user that visited websites that had a high chance of using Optimizely, you quickly accumulated enough cookie to make their fronting proxy reject your request for their JS.
One common use is to pass session data between subsections of a site. For example, the user logs into www.example.com, and is still logged in when they head over to store.example.com.
That could be also implemented in my proposed fix by example.com setting the auth cookies. They will continue to be readable by store.example.com.
Sure, it will require a change on the server side, which is a pain. But I can't think of a practical scenario which will be impossible to implement with the proposed fix.
- "If you're able to execute your own JS on SUB1.example.com it can cookie-bomb not only your SUB1 but the entire *.example.com network, including example.com"
So you've got to be able to execute JS in a subdomain to plant a cookie bomb that will affect the entire domain.
It's really interesting. The problem is that i don't see any fix for it. The only way would be to update the browsers, or maybe use a plugin to block such attacks.
Or serve the untrusted content from a sub-subdomain, e.g. "foo.bar.CDN_HOST.com", so that you could only bomb bar.CND_HOST.com and not the entire domain
That would be nice, but it would have a lot of ramifications. Before setting the cookie, the browser would need to know if it's allowed, so presumably it would have to load some file. Perhaps this could be done in a manner similar to CORS requests
Seems the way to do this would be to create accounts on all the services you want to bomb and set up JavaScript redirects so that hitting one will set the cookies and redirect to the next host. Have it be in a loop so that any entry into the redirect loop is possible. By definition, once you hit the first host in the chain again, your request will be denied.
The question is how to get people to visit a site that loads one of those URLs...
Possible detection method (server side)?
If the request is too long due to cookie length, then look at the last URL the client IP hit. That should be the URL creating the long cookies. Remove the offending URL / resource.
That won't work, and could be easily abused by crafting your own requests to blame any arbitrary URL of your choosing.
Plus, servers drop huge requests because they are most likely malformed or DOS attempts. Attempting to do extra work (like tracking down previous visits by the client) will only make matters worse for the server.
This was happening on my Gmail account a few weeks ago. It was a little disconcerting. I never figured out what was wrong but it seemed to fix itself after I deleted cookies a few times.
> Is there an equivalent to status.github.com for github.io?
If you want to check the status of your own GH Pages hosted site, you can go to your repository for the page, then go to "Settings > Health" and you can see a basic status for Server Status, Usage, and Repository Integrity.
The mechanism is the Public Suffix List, which was originally created because there needed to be a list to keep track of which TLDs used public second-level domains and only allowed registrations in the third level. For example, while foo.example.com and bar.example.com are both owned by example.com, foo.co.uk and bar.co.uk are two different domains, since co.uk is part of the UK domain hierarchy (along with ac.uk and so on) and registrations happen at the third level. Therefore it would be undesirable if foo.co.uk could set cookies for the entire .co.uk, as in the UK ccTLD world that's equivalent to setting a cookie for all of .com.
So there's a big list (initiated by Mozilla) specifying that .com is a public suffix, .co.uk is a public suffix, etc., and wildcard cookies on public suffixes are refused. This has been adapted, as a huge hack, to big sites that have user-registerable subdomains. So now .blogspot.com is also treated as a public suffix, since anyone can "register" a foo.blogspot.com under it.
However new entries are added on a fairly ad-hoc basis, so a site that allows user subdomains that can run JS is vulnerable by default unless they explicitly get themselves added. I notice Dropbox isn't there, for one.
The list: http://publicsuffix.org/