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.
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.
var base_domain = document.domain.substr(document.domain.indexOf('.'));Just set lots of 4k long cookies with Domain=.example.com so they will be sent with every request to *.example.com.
var pollution = Array(4000).join('a');
if(confirm('Should I Cookie Bomb '+base_domain+'?')){
for(var i=1;i<99;i++){
document.cookie='bomb'+i+'='+pollution+';Domain='+base_domain;
}
}
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.
Who can be cookie-bombed?
- Blogging/hosting/website/homepage platforms: Wordpress, Blogspot, Tumblr, Heroku, etc. Anything having <username>.example.com with your JS.
You don't need government to ban blog platforms anymore - use cookie bomb. (Joke) - Subdomains serving your HTMLs, even if they're created for user input you can cookie-bomb entire network and "poison" other subdomains with it: Dropbox, Github.io
- Content Delivery Networks. Ouch! You can poison *.CDN_HOST.com and break scripts/CSS on all websites using this CDN.
- System sandbox domains like GoogleUserContent.com. When I poison it - Google Translate, GMail attachments, Blogspot images - entire Google ecosystem goes crazy.
- Use it along with other attacks (XSS, Header injection, HTTP:// cookie forcing)
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 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:
God says "Do a better job training your Markov chain walker!"
ReplyDeleteTerry we are coming for you
DeleteYou're terrible :)
DeleteI remember something like that from here http://sirdarckcat.blogspot.mx/2009/04/how-to-use-google-analytics-to-dos.html
ReplyDeleteAhahah, ingeniously simple.
ReplyDeleteNice post!
ReplyDeleteEgor, I've read your article and think that the problem was solved already by most servers.
ReplyDeletehttp://stackoverflow.com/questions/686217/maximum-on-http-header-values
@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.
ReplyDeleteIf 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.
"Blogging/hosting/website/homepage platforms: Wordpress, Blogspot, Tumblr, Heroku, etc."
ReplyDeleteWordPress.com is not vulnerable because users cannot upload or execute arbitrary JS.
really? No custom styles?
DeleteCustom 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.
Deleteweird, i will check. i know tumblr, blogspot and all others support it
Deletediaspora too does support custom js
DeleteHehhe. Cool just for prevensive reasons not for attack :). Thanks.
ReplyDeleteMy god, the age old (and often useless) advice of clearing one's cookies may actually be relevant again someday soon.
ReplyDeleteI see listing allowed domains as a part of CSP directive.
ReplyDeleteseems like Safari is fine.
ReplyDeleteIs 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 ;-)
ReplyDeleteRegarding 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/)
ReplyDelete"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."
ReplyDeleteI think this is not effective. Browsers use publicsuffix to get effective TLD for cookies. So sandbox.sub1.example.com can still set a cookie for .example.com.
No, it isn't true.
Deletei am not sure. It would be jumping through 2 subdomain zones, and must not be allowed by RFC
Delete