

Rethinking Cookies: originOnly - homakov
http://homakov.blogspot.com/2013/02/rethinking-cookies-originonly.html

======
ChuckMcM
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.

~~~
jjoergensen
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.

~~~
KMag
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.

~~~
jjoergensen
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.

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

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

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

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

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

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

~~~
Udo
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).

------
sirclueless
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?

~~~
homakov
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

------
pekk
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?

~~~
MindTwister
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>)

~~~
homakov
Yes!

------
sandstrom
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?

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

