Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cookie Bomb or Let's Break the Internet

homakov.blogspot.com

Post reply on HN
Print view View original

51–60 of 82 posts

Re: Cookie Bomb or Let's Break the Internet

#51

Post by SaneMethod »

etcet wrote: post #12
rubbingalcohol wrote: post #2

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/ (local storage bomb) Implementing limits on the number of cookies would seem to be the natural solutio…

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

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

Re: Cookie Bomb or Let's Break the Internet

#53

Post by jchung »

joosters wrote: post #21
jchung wrote: post #10

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.

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.

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

Re: Cookie Bomb or Let's Break the Internet

#54

Post by tptacek »

wglb wrote: post #38
homakov wrote: post #35

Earlier quoted context omitted.

Yes, 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 .domain. > it'll be fun to watch you uh. hmm, ok.

No pressure there.

You too! You helped us plan the damn thing!

Re: Cookie Bomb or Let's Break the Internet

#57

Post by tokenizerrr »

smartician wrote: post #31

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…

Bump up the limit in the web server config ;)

Re: Cookie Bomb or Let's Break the Internet

#58

Post by Nagyman »

smartician wrote: post #31

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…

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

Re: Cookie Bomb or Let's Break the Internet

#59

Post by smartician »

tokenizerrr wrote: post #57
smartician wrote: post #31

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…

Bump up the limit in the web server config ;)

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.

Re: Cookie Bomb or Let's Break the Internet

#60

Post by hnha »

_delirium wrote: post #40

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 regis…

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