[_delirium]

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.

The list: http://publicsuffix.org/

[homakov]

Works in Chrome. Actual "bombing" works in FF too, but doesn't affect top-level domain.

That's semi-solution. How is it going to help mysite.cdn.com/file1 to bomb mysite.cdn.com/other-files...

Also look at translate.googleusercontent.com, if you bomb it, Google Translate will stop working.

I think public suffix is great and useful idea but it should be solved by browsers too & length should be limited

[anglebracket]

> Works in Chrome.

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]

[0]: http://publicsuffix.org/learn/ (under Chromium)

[1]: http://cookietestblog1.blogspot.com/2014/01/cookie-test.html

[2]: http://cookietestblog2.blogspot.com/2014/01/cookie-test.html

[3]: http://code.google.com/p/browsersec/wiki/Part2#Same-origin_p... (under cookie jar size)

[homakov]

>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.

[brians]

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.

[pixelcort]

Couldn't a solution be something stored in DNS, that tells browsers not to let subdomains' JS do this?

So if I own example.com I could set something in my DNS that would prevent subdomain.example.com from setting cookies on example.com.

[mratzloff]

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.

[_delirium]

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.

[gfosco]

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?

[kbenson]

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.

[hnha]

nice! HN should use this list for the domain display.

[ghostdiver]

Combined with simple XSS(or any other problem, modern websites are full of such bugs) this DoS will work.