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.
Cookie Bomb or Let's Break the Internet
31–40 of 82 posts
Re: Cookie Bomb or Let's Break the Internet
#32This 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.
Re: Cookie Bomb or Let's Break the Internet
#33Probably this feature is of critical use. If so, would be grateful if someone explains it to me.
Re: Cookie Bomb or Let's Break the Internet
#34Optimizely (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
#35Earlier 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 .
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
#36Earlier 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.
Re: Cookie Bomb or Let's Break the Internet
#37Why 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.
Re: Cookie Bomb or Let's Break the Internet
#38Earlier 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.
Re: Cookie Bomb or Let's Break the Internet
#39Earlier 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.
Re: Cookie Bomb or Let's Break the Internet
#40The 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/