Live data from Hacker News

Cookie Bomb or Let's Break the Internet

homakov.blogspot.com

41–50 of 82 posts

Re: Cookie Bomb or Let's Break the Internet

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

Simple proof of concept: 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 :)

Re: Cookie Bomb or Let's Break the Internet

#42
post #22
post #14

Earlier quoted context omitted.

That 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

Content-Security-Policy: can-set-cookies: no! BTW if JS is of we can use

Well OK then.

Re: Cookie Bomb or Let's Break the Internet

#43
Seems 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...

Re: Cookie Bomb or Let's Break the Internet

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

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.

Re: Cookie Bomb or Let's Break the Internet

#45

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…

Oh, 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.

Re: Cookie Bomb or Let's Break the Internet

#46

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…

Combined with simple XSS(or any other problem, modern websites are full of such bugs) this DoS will work.

Re: Cookie Bomb or Let's Break the Internet

#47

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…

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

Re: Cookie Bomb or Let's Break the Internet

#48
post #44

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Cookie Bomb or Let's Break the Internet

#49

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…

Oh, 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.

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

Re: Cookie Bomb or Let's Break the Internet

#50
post #36

Earlier quoted context omitted.

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?

I think by "interactive prompt" he means "user interaction".
Post reply on HN