8 ms·
Cookie Bomb or Let's Break the Internet
- rubbingalcohol 13y agoPretty 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.
- homakov 13y agonot 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.
- troels 13y agoThe extra level of subdomain as proposed by Homakov, seems like a much more worthwhile fix.
- etcet 13y ago> 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 13y agoIt shouldn't be possible to launch mailto links without an interactive prompt; if it is, please file a bug on the browser.
- aaronem 13y agoI've never seen a prompt to open a mailto: link. Where is it specified there should be one?
- mobweb 13y agoI think by "interactive prompt" he means "user interaction".
- aaronem 13y agoI 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.
- etcet 13y agoSimple proof of concept: http://jsfiddle.net/rVxkv/ http://jsfiddle.net/rVxkv/ This opens 2 Thunderbird windows in Firefox 26 but only one in Chromium 31.0.1650.63. edit: I totally agree it shouldn't be possible :)
- SaneMethod 13y agoInteresting. 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). There's an open bug in regards to this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=566893 https://bugzilla.mozilla.org/show_bug.cgi?id=566893
- ph4 13y agoTerry Davis scares me.
- lynxaegon 13y agoIt'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 13y agoOr 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 13y agoYou'd think a higher level domain should be able to specify whether a subdomain can set cookies for it or not.
- jffry 13y agoThat 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 13y agoContent-Security-Policy: can-set-cookies: no! BTW if JS is of we can use <meta http-equiv Set Cookie>
- asmithmd1 13y agoHow 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."
- jmillikin 13y agoThis is for domains that serve user-provided Javascript, such a blog hosts and GitHub.
- tcgv 13y ago- "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.
- cfinke 13y agoWho can be cookie-bombed? Blogging/hosting/website/homepage platforms: Wordpress, Blogspot, Tumblr, Heroku, etc. WordPress.com would not be vulnerable since users cannot upload or execute arbitrary JavaScript.
- jchung 13y agoPossible 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 13y agoThat 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 13y agoHmmm. Yes,I see the potential for abuse. Why do you say it would not work though?
- deleted 13y ago[deleted]
- tshadwell 13y agoSurely if you were able to do this, you would use it for cookie tossing rather than this simple mischief?
- homakov 13y agoCookie tossing are not always helpful. If session is properly tied with csrf token there's not much you can do with it.
- aaren 13y agoIs this the reason I can't access any *.github.io right now? Is there an equivalent to status.github.com for github.io?
- bernardom 13y agoHave... you tried clearing your cookies? :-)
- aaren 13y ago! I should actually read the content of articles. That's enough internet for today.
- rsanheim 13y agogithub.io works for me right now.
- jglovier 13y ago> 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.
- nixgeek 13y agoI don't see that. Did you just out a staff only feature? ;)
- tptacek 13y agoThis is something Zalewski has written about: http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-... --- if this kind of thing is interesting to you, his latest book, _The Tangled Web_, is excellent.
- homakov 13y agoI read that post before, maybe I missed, but where he says about DoS possibilities of cookie tossing?
- tptacek 13y agoSearch for "Does this matter from a security perspective". Also: take a crack at the CTF we set up. I think (a) you'll do well at it and (b) it'll be fun to watch you. http://microcorruption.com http://microcorruption.com.
- homakov 13y agoYes, 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. > it'll be fun to watch you uh. hmm, ok.
- rcsorensen 13y agoThe 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 13y agoWeb 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 13y agoInteresting. 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 13y agoBump up the limit in the web server config ;)
- smartician 13y agoForgot 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.
- Nagyman 13y agoWe 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.
- hrjet 13y agoWhy 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 13y agoOne 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 13y agoThat 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.
- deleted 13y ago[deleted]
- gfodor 13y agoYour idea would likely break any site on the internet that uses authentication and subdomins, isn't it clear why this isn't being considered?
- rcsorensen 13y agoThere'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.
- _delirium 13y agoThe 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/
- mratzloff 13y agoOh, 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 13y agoThe 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.
- mratzloff 13y agoSeems 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...
- tlrobinson 13y agoThis 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.
- jokoon 13y agoI didn't like the web protocols Now I like them even less.
- enterx 13y agopointsIterator++; Works on Iceweasel 17.0.10.
- anandvc 13y agohomakov, you have a fun job.
- deleted 13y ago[deleted]