

Cookie Bomb or Let's Break the Internet - paulmillr
http://homakov.blogspot.com/2014/01/cookie-bomb-or-lets-break-internet.html

======
_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/](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/](http://publicsuffix.org/learn/) (under
Chromium)

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

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

[3]: [http://code.google.com/p/browsersec/wiki/Part2#Same-
origin_p...](http://code.google.com/p/browsersec/wiki/Part2#Same-
origin_policy_for_cookies) (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.

------
tptacek
This is something Zalewski has written about:
[http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-
not-...](http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-
design.html) \--- if this kind of thing is interesting to you, his latest
book, _The Tangled Web_, is excellent.

~~~
nly
That page, and the linked browsersec pages on Google Code, are terrifying.
Time to burn it all down and start from scratch.

I was particularly stunned to learn HTTP Cookie headers can clobber 'secure'
cookies set over HTTPS. Eye-popping.

~~~
wglb
And to increase your terror, check out
[http://lcamtuf.coredump.cx/postxss/](http://lcamtuf.coredump.cx/postxss/)

------
rcsorensen
The impact on CDN providers is kinda scary.

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.

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

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

~~~
tokenizerrr
Bump up the limit in the web server config ;)

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

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

Also, Fill my Disk: [http://www.filldisk.com/](http://www.filldisk.com/)
(local storage bomb)

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.

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

~~~
JoshTriplett
It shouldn't be possible to launch mailto links without an interactive prompt;
if it is, please file a bug on the browser.

~~~
aaronem
I've never seen a prompt to open a mailto: link. Where is it specified there
should be one?

~~~
mobweb
I think by "interactive prompt" he means "user interaction".

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

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

------
hrjet
Why isn't the obvious fix discussed: Change browsers to not let subdomains set
cookies for parent domains.

Probably this feature is of critical use. If so, would be grateful if someone
explains it to me.

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

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

~~~
gfodor
Your idea would likely break any site on the internet that uses authentication
and subdomins, isn't it clear why this isn't being considered?

~~~
zaroth
Or sites could opt-in to this with a header?

EDIT: homakov says the same thing down thread.

------
asmithmd1
How do you set a cookie on a domain you do not control? Won't the browser only
send cookies to a server on the domain you are trying to browse to?

EDIT: found it - not any, arbitrary site can be DOS

"Who can be cookie-bombed? Blogging/hosting/website/homepage platforms:
Wordpress, Blogspot, Tumblr, Heroku, etc."

~~~
tcgv
\- "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.

------
jokoon
I didn't like the web protocols

Now I like them even less.

------
ph4
Terry Davis scares me.

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

~~~
jffry
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

~~~
mavhc
You'd think a higher level domain should be able to specify whether a
subdomain can set cookies for it or not.

~~~
jffry
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

~~~
homakov
Content-Security-Policy: can-set-cookies: no!

BTW if JS is of we can use <meta http-equiv Set Cookie>

~~~
twic
It might be better to allow:

Content-Security-Policy: can-set-cookies-for-parent-domain: no!

There's no harm in letting haxx0r.blogspot.com set cookies for
haxx0r.blogspot.com. It's only cookies for blogspot.com that should be
restricted.

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

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

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

~~~
jchung
Hmmm. Yes,I see the potential for abuse. Why do you say it would not work
though?

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

------
aaren
Is this the reason I can't access any *.github.io right now?

Is there an equivalent to status.github.com for github.io?

~~~
bernardom
Have... you tried clearing your cookies? :-)

~~~
aaren
! I should actually read the content of articles. That's enough internet for
today.

------
tshadwell
Surely if you were able to do this, you would use it for cookie tossing rather
than this simple mischief?

~~~
homakov
Cookie tossing are not always helpful. If session is properly tied with csrf
token there's not much you can do with it.

------
enterx
pointsIterator++;

Works on Iceweasel 17.0.10.

------
anandvc
homakov, you have a fun job.

