Live data from Hacker News

Cookie Bomb or Let's Break the Internet

homakov.blogspot.com

31–40 of 82 posts

Re: Cookie Bomb or Let's Break the Internet

#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 significant amounts of data in cookies. Not really sure how to tackle this issue.

Re: Cookie Bomb or Let's Break the Internet

#32
post #25

This is something Zalewski has written about: 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.

Another vote for The Tangled Web. It's a great read.

Re: Cookie Bomb or Let's Break the Internet

#34
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.

Re: Cookie Bomb or Let's Break the Internet

#35
post #30
post #26

Earlier quoted context omitted.

I read that post before, maybe I missed, but where he says about DoS possibilities of cookie tossing?

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

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.

Re: Cookie Bomb or Let's Break the Internet

#36
post #12

Earlier quoted context omitted.

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

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

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

Re: Cookie Bomb or Let's Break the Internet

#37
post #33

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.

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.

Re: Cookie Bomb or Let's Break the Internet

#38
post #35
post #30

Earlier quoted context omitted.

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

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.

Re: Cookie Bomb or Let's Break the Internet

#39
post #35
post #30

Earlier quoted context omitted.

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

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.

[deleted]

Re: Cookie Bomb or Let's Break the Internet

#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 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/

Post reply on HN