Saturday, January 18, 2014

Cookie Bomb or let's break the Internet.

TL;DR I can craft a page "polluting" CDNs, blogging platforms and other major networks with my cookies. Your browser will keep sending those cookies and servers will reject the requests, because Cookie header will be very long. The entire Internet will look down to you.

I have no idea if it's a known trick, but I believe it should be fixed. Severity: depends. I checked only with Chrome.

We all know a cookie can only contain 4k of data.

How many cookies can I creates? Many!

What cookies is browser going to send with every request? All of them!

How do servers usually react if the request is too long? They don't respond, like this:

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.

Just set lots of 4k long cookies with Domain=.example.com so they will be sent with every request to *.example.com.
All requests will be ignored, because servers never process such long requests (the "Cookie" header will be like half a megabyte).

Victim is sad and crying. No more blogspot. No more github.io. Such sad user. Not wow.

It will last until the user realizes he needs to delete his cookies. Not all human beings are that smart though.

Proofs of Concept

Tip for hackers: you can "block" some exact path by specifying ;path=/some_path in the cookie bombs attributes. Your personal censorship!

Tip for browsers: limit amount of cookies on .example.com or send only sane number of them, but i'm not sure it's a pragmatic way.Tip for admins: instead of sub1.example.com use sandbox.sub1.example.com, which will limit impact of the cookie bomb to .sub1.example.com zone.Tip for users: if you was cookie-bombed remove "bombs" here:

@Denis: this is not an attack on the server, but on the user's web browser. If you can lure a user to your username.github.io website you can set cookies on their browser that will render *.github.io unusable until they clear their cookies.

If you're willing to cookiebomb your own browser, try the github.io proof of concept linked above (safest way to do it is to start a private session). In my testing it breaks Chrome and IE, but not Firefox.

Custom Styling through CSS is possible on WordPress.com (which I assume the author is refering to), but due to the security risks associated with running custom Javascript, no user-JS is ever run on a *.wordpress.com or *.wp.com domain name. Sites with an Enterprise domain can run JS, but it's sandboxed to their domain only through special mapping and only outputting JS when it's safe (for us) to.

Is there anyway we can write nginx module to ignore the cookie, or at least write a basic response to neutralize the cookie by setting Set-Cookie: minimized_cookie_size, hence subsequent browser requests won't continue bombing the planet. User will just treat it as temporary hiccup and probably blame the ISP for that ;-)

Regarding cloud front, it seems the only way to mitigate the issue is to use your own custom asset.yourdomain.com subdomain. But you will bump into SSL issue. Some browsers (e.g. Chrome and IE) won't allow https host to serve non https assets. And cloudfont charge a fortune to install your own SSL (http://aws.amazon.com/cloudfront/custom-ssl-domains/)