homakov, you have a fun job.
Cookie Bomb or Let's Break the Internet
71–80 of 82 posts
Re: Cookie Bomb or Let's Break the Internet
#72Earlier quoted context omitted.
That 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.
Your idea would likely break any site on the internet that uses authentication and subdomins, isn't it clear why this isn't being considered?
Or sites could opt-in to this with a header?
EDIT: homakov says the same thing down thread.
Re: Cookie Bomb or Let's Break the Internet
#73The 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…
The public suffix list has two purposes: browsers won't accept wildcard cookies (desirable) but also won't accept a wildcard certificate against that name (undesirable). It's true that nobody should have a certificate for * .com or * .co.uk, but it is reasonable for Google to have * .blogspot.com.
To remove the cross-site exposure in shared domains using the PSL, there'd need to be an extra bit expressed with every entry in the PSL. Alternately, browsers could re-try the request without any cookies.
Re: Cookie Bomb or Let's Break the Internet
#74Earlier quoted context omitted.
That 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.
Your idea would likely break any site on the internet that uses authentication and subdomins, isn't it clear why this isn't being considered?
Yes, it is backwards incompatible. Perhaps it could be enforced in HTTP 2?
Re: Cookie Bomb or Let's Break the Internet
#75The 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…
Works in Chrome. Actual "bombing" works in FF too, but doesn't affect top-level domain. That's semi-solution. How is it going to help mysite.cdn.com/file1 to bomb mysite.cdn.com/other-files... Also look at translate.googleusercontent.com, if you bomb it, Google Translate will stop working. I think public suffix is great and useful idea but it should be solved by browsers too & length should be limited
> Works in Chrome.
Hmm, looks like Chrome isn't respecting the Public suffix list for setting cookies ATM, even though the site for the list claims that it does.[0]
For an example, view [1] and [2] in Chrome, and note that cookies set by [1] are viewable by [2] even though this shouldn't be allowed given blogspot's entry in the public suffix list. Firefox doesn't exhibit this behaviour, and I'm thinking this is a recent regression in Chrome, but who knows.
> Also look at translate.googleusercontent.com, if you bomb it, Google Translate will stop working.
I haven't taken a look at it, but would it make sense to add dynamic .translate.googleusercontent.com subdomains for translated sites and add the base domain to the public suffix list?
> it should be solved by browsers too & length should be limited
IMO this is only going to be solved by a revision to the spec that resolves the ambiguity. The core issue is that browsers and servers disagree as to what a "reasonable" cookie jar size is, and servers are rejecting request with "unreasonably" large cookie jars.
Until those limits are actually part of a spec that people follow, someone's going to be sending too much or allowing too little and legitimate requests will get rejected.
I don't know if you've read Michal's "The Tangled Web" or the Browser Security Handbook but they both go into it a little.[3]
[0]: http://publicsuffix.org/learn/ (under Chromium)
[1]: http://cookietestblog1.blogspot.com/2014/01/cookie-test.html
[2]: http://cookietestblog2.blogspot.com/2014/01/cookie-test.html
[3]: http://code.google.com/p/browsersec/wiki/Part2#Same-origin_p... (under cookie jar size)
Re: Cookie Bomb or Let's Break the Internet
#76[deleted]
Re: Cookie Bomb or Let's Break the Internet
#77This 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.
The attack was also discussed in details here: http://mixedbit.org/blog/2013/04/11/dos_attack_on_cdn_users....
Re: Cookie Bomb or Let's Break the Internet
#78Earlier quoted context omitted.
Works in Chrome. Actual "bombing" works in FF too, but doesn't affect top-level domain. That's semi-solution. How is it going to help mysite.cdn.com/file1 to bomb mysite.cdn.com/other-files... Also look at translate.googleusercontent.com, if you bomb it, Google Translate will stop working. I think public suffix is great and useful idea but it should be solved by browsers too & length should be limited
> Works in Chrome. Hmm, looks like Chrome isn't respecting the Public suffix list for setting cookies ATM, even though the site for the list claims that it does.[0] For an example, view [1] and [2] in Chrome, and note that cookies set by [1] are viewable by [2] even though this shouldn't be allowed given blogspot's entry in the public suffix list. Firefox doesn't exhibit this behaviour, and I'm thinking this is a rec…
>I haven't taken a look at it, but would it make sense to add dynamic .translate.googleusercontent.com subdomains for translated sites and add the base domain to the public suffix list?
random hash as a sandbox..guc.com will work.
Re: Cookie Bomb or Let's Break the Internet
#79The 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…
Couldn't a solution be something stored in DNS, that tells browsers not to let subdomains' JS do this?
So if I own example.com I could set something in my DNS that would prevent subdomain.example.com from setting cookies on example.com.
Re: Cookie Bomb or Let's Break the Internet
#80Earlier 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]