61–70 of 82 posts
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.
I was particularly stunned to learn HTTP Cookie headers can clobber 'secure' cookies set over HTTPS. Eye-popping.
Is this the reason I can't access any *.github.io right now? Is there an equivalent to status.github.com for github.io?
If you want to check the status of your own GH Pages hosted site, you can go to your repository for the page, then go to "Settings > Health" and you can see a basic status for Server Status, Usage, and Repository Integrity.
How do you set a cookie on a domain you do not control? Won't the browser only send cookies to a server on the domain you are trying to browse to? EDIT: found it - not any, arbitrary site can be DOS "Who can be cookie-bombed? Blogging/hosting/website/homepage platforms: Wordpress, Blogspot, Tumblr, Heroku, etc."
WordPress.com would not be vulnerable since users cannot upload or execute arbitrary JavaScript.
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.
Works on Iceweasel 17.0.10.
Is this the reason I can't access any *.github.io right now? Is there an equivalent to status.github.com for github.io?
> Is there an equivalent to status.github.com for github.io? If you want to check the status of your own GH Pages hosted site, you can go to your repository for the page, then go to "Settings > Health" and you can see a basic status for Server Status, Usage, and Repository Integrity.
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.
That page, and the linked browsersec pages on Google Code, are terrifying. Time to burn it all down and start from scratch. I was particularly stunned to learn HTTP Cookie headers can clobber 'secure' cookies set over HTTPS. Eye-popping.
The impact on CDN providers is kinda scary. To take an example we all know and love, a malicious *.cloudfront.net distribution could be setting cookies against cloudfront, breaking all your fancy static asset serving from cloudfront. Is there a mitigation other than _always_ having to use a myappname-static.com domain name? Thinking about this at a higher level -- there are some interesting similarities to "shared ho…
It's not a perfect fix, nor does it solve the wider issue of letting one domain set a cookie for a domain that it has no authority over, but it would stop people being blocked from a site with a bizarre 500 error. Worst case, a login/ID cookie gets flushed and the user has to log in again.
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…
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…
Wouldn't a relatively simple fix for this be to detect this at the front end, and serve a static page with JavaScript that clears all of their cookies and then redirects back?