> Source: [Origin Cookies Proposal][1] from Web 2.0 Security and Privacy Conference
.
> **6. Session Integrity in Future Browsers** Neither of the previous solutions, nor others considered using existing browser technologies,
> provide sufficient security while remaining deployable for existing
> sites. Therefore, we propose an extension to cookies called origin
> cookies. Origin cookies allow existing web applications to secure
> themselves against the described attacks, with very little complexity
> of implementation on the part of either the web application or the
> browser, with transparent backwards compatibility for browsers that do
> not yet implement origin cookies, including legacy browsers that may
> never support them, and imposing no burden on existing web sites that
> have not enabled origin cookies. This is not a trivial problem to
> solve, as evidenced by existing proposals that fail to meet one or
> more of the above desired properties. For example, sending the origin
> of every cookie on each request is one common idea. This is much more
> complicated than necessary, and imposes a much larger burden on web
> sites, including ones that don’t even know how to effectively use this
> information.
>
> **6.1. Origin Cookies** The real problem with using cookies for session management is lack of integrity, specifically due to the
> ability of other origins to clear and overwrite cookies. While we
> cannot disable this functionality from cookies without breaking many
> existing sites, we can introduce new cookie-like functionality that
> does not allow such cross-site modification.
>
> **Design.** Origin cookies are cookies that are only sent and only modifiable by requests to and responses from an exact origin. They are
> set in HTTP responses in the same way as existing cookies (using the
> Set-Cookie header), but with a new attribute named ‘Origin’. In order
> to enable web applications to distinguish origin cookies from normal
> cookies, origin cookies will be sent in an HTTP request in a new
> header ‘OriginCookie’, while normal cookies will continue to be sent
> in the existing header ‘Cookie’.
HTTP/1.1 200 OK
...
Set-Cookie: foo=bar; Origin
...
Fig. 2. An HTTP response setting an origin cookie.
GET / HTTP/1.1
Host:
[To see links please register here]
...
Origin-Cookie: foo=bar
...
Fig. 3. An HTTP request to a URI for which an origin
cookie has been set.
> For example, if in response to a GET request for
>
[To see links please register here]
, a response as in Figure 2 is received, then
> an origin cookie would be set with the key ‘foo’ and the value ‘bar’
> for the origin
[To see links please register here]
, and would be sent on subsequent
> requests to that origin. A subsequent GET request for
>
[To see links please register here]
would look like Figure 3. Requests made to any
> other origin, even
[To see links please register here]
and
[To see links please register here]
> would be made exactly as if the origin cookie for
>
[To see links please register here]
was never set. The Origin attribute extending
> the semantics of Set-Cookie itself is subtle and implies several
> semantic changes to other settable attributes of cookies. If the
> Origin attribute is set, the Domain attribute is no longer
> appropriate, and therefore should be ignored. Similarly, the Secure
> attribute is no longer appropriate, since it is implied by the scheme
> of the origin for the cookie: if the scheme is https, the the origin
> cookie effectively has the attribute – since it will only be sent over
> a secure channel – and if the scheme is anything else, the cookie does
> not have the attribute. Because the same-origin policy considers
> different paths to be part of the same origin, the Path attribute of
> cookies provides no security and should also be ignored. The semantics
> of other attributes, such as `HttpOnly`, `Max-Age`, `Expires`, etc. remain
> unchanged for origin cookies. Normal cookies are uniquely identified by
> their key, the value of the Domain attribute, and the value of the
> Path attribute: this means that setting a cookie with a key, Domain,
> and Path that is already set does not add a new cookie, but instead
> replaces that existing cookie. Origin cookies should occupy a separate
> namespace, and be uniquely identified by their key and the full origin
> that set it. This prevents sites from accidentally or maliciously
> deleting origin cookies, in addition to the other protections against
> reading and modifying, and makes server-side use of origin cookies
> significantly easier.
>
> **Security.** Because origin cookies are isolated between origins, the additional powers of the related-domain attacker and active network
> attacker in overwriting cookies are no longer effective, since they
> were specifically exploiting the lack of origin isolation with existing
> cookies, whether the ‘confusion’ was due to the scheme or domain of
> the origin. Absent these additional powers, the related-domain
> attacker and active network attacker are equivalent to the web
> attacker, who cannot break the security of existing session management
> based on the combination of cookies and secret tokens.
>
>
> **Implementation.** Integrating origin cookies into existing browsers will not involve significant modifications. As a proof of concept, we
> implemented origin cookies in Chrome. The patch totals only 573 lines
[1]: