Rethinking Cookies: originOnly | Hacker News Reader

Rethinking Cookies: originOnly

homakov.blogspot.com

26 pointshomakov22 comments

It is an interesting rant about a real problem. Cookies provide a function for their origin web site, every other use is generally not good for the consumer. The challenge implementing something like cookies that can only be consumed by the web server that baked them. Not an easy problem to solve while still supporting proxies and firewalls and things between client and the web server.

That said, would love to hear some ideas.

I don't really see the problem with cookies. They make things easier to implement, they enable a ton of new businesses and they make things easier for the consumers.

Sorry to be pedantic, but the problems were enumerated in the article. There are multiple major security problems with cookies, and their costs are in the billions of dollars per year.

Instead of "I don't really see the problem with X" I think you really meant "I think on the whole the benefits of X outweigh its downsides". Neither the article nor the OP has suggested getting rid of cookies. They're merely trying to broach the subject of re-examining the HTTP state mechanism to see if there are better ways to solve the problem.

To suggest that something is sub-optimal is not to necessarily suggest that its net effect is negative.

Ok i wasn't talking about security problems. Just the problem in general of cookies. And so I don't think it is true that "Cookies provide a function for their origin web site, every other use is generally not good for the consumer."

Besides, some people have the illusion that changing the cookies will give them privacy. Well, there are many other ways of following them around although a little less accurate.

That "every other use is generally not good for the consumer" is a broad generalization, I think.

I don't disagree. One way to look at the question is "if we ban all other uses we cripple case X, Y, and Z" vs "if we allow other uses we allow X, Y, and Z but enable P, Q, and R type problems."

Lots of things in the world have similar tradeoffs, to use a silly example "Leave your front door unlocked" makes it easy for anyone to come in, but also makes it easy for crooks to come in, so a common solution is to lock it and give certain folks the key.

Cookies came about as a way for a web service to retain state across sessions, and then that concept got applied to lots and lots and lots of things, some good some bad. Perhaps there are two things here we should have "originHostState" and "GenericUserState". We could then see how many people allowed the latter type of cookie to be set.

yes, "not good" usually. So originOnly flag coould be nice addition

Related: Mozilla's sameDomain proposal https://bugzilla.mozilla.org/show_bug.cgi?id=795346

Some research browser architectures like Atlantis (http://research.microsoft.com/pubs/154698/Atlantis-SOSP.pdf) go the opposite extreme, where cookies are never sent unless their domain matches the initiating origin. In the case of Atlantis, the reason they have to go this route is somewhat messy: their microkernel architecture exposes a network interface to webpages, and the network interface has no way to differentiate between a request initiated by XHR or by an img/script/etc., so the network interface cannot send cookies with any cross-origin requests, or else it risks exposing private data via XHR.

I wonder if it would be useful to see something more flexible than the current standard, sameDomain, or disallowing all cross-origin cookies. When you set a cookie, maybe it would be nice to be able to specify which origins are authorized to send requests with that cookie.

i believe SameOrigin is enough for everyone. If no - you can make your own mechanizme

The same logic should be applied to the inclusion of a Referer header in a request. If a page on foo.com is pulling down a .js from code.jquery.com, there should be no Referer sent.

Perhaps a more illustrative example is that this will deny Twitter, FB, Google and other embeddable widget factories any tracking and analytics information that leaks with every request for TweetThis, LikeThat and WhatNot buttons, fonts and scripts. There is absolutely no reason for them to be seeing this information.

agreed. actually referrer is very bad thing for security. have a post on it too

It's a great idea, and I think it should be the default behavior for cookies - require users to explicitly agree whenever a cross-site cookie comes up.

How would you frame that question in terms that a user who calls IE "the internet" could understand?

In that case either automatically ignoring the cookie or displaying the equivalent of the "this certificate is invalid" warning would be workable. It's a compromise. Personally, I believe nothing of value would be lost if browsers simply enforced originOnly period (without supporting anything else).

hm.. "Do you want to expose your identity .. " dunno

I'm curious if you have ever expanded on your problem #2 claim: Google doesn't provide solutions for client-side clickjacking prevention in Chrome, because they have a competitive advantage in detecting it server-side.

Are there such protections in other browsers such as Firefox or IE? Were there proposals for Chromium that got shut down?

there is NoScript for FF. There is no noscript in chrome because of poor API. im pretty sure clearclick will not come up for a reason i told

Stupid question. Is this originOnly proposal about the problem that a document from evil.com can drive requests to victim.com (e.g. img, iframe, clickjacking form, AJAX) and that these user-unintended requests to victim.com will stupidly include the cookies set by victim.com? Or some other problem?

As far as I understand it, yes.

The basic idea is that any requests that do not originate from the domain will not send the cookies, preventing CSRF, clickjacking and the advanced CSRF discussed here yesterday (from stackoverflow: http://stackoverflow.com/q/2669690/3287)

Yes!

Assuming a single page js app: wouldn't storing a session token in localStorage, and appending as a header on every xhr request, solve some of these problems?

no, it will create only new, already solved. u cannot make localstorage httponly. if attacker steals it - session is lost..

Reply on news.ycombinator.com