W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2015

Potential changes to cookies in Chrome.

From: Mike West <mkwst@chromium.org>
Date: Fri, 27 Nov 2015 11:32:51 +0100
Message-ID: <CAKXHy=eaj9AmyjWr06g5xjm_hGH1xyrXLOCagbtL=E2-EjsesQ@mail.gmail.com>
To: security-dev <security-dev@chromium.org>
Cc: Emily Stark <estark@chromium.org>, Joel Weinberger <jww@chromium.org>
Hello, security-dev@! (And _secretly_ hello to net-dev@, blink-dev@,
dev-security@lists.mozilla.org, and public-webappsec@w3.org, who I've BCC'd)

Cookies are a bit of a rough edge on the web's security model. They don't
respect the same origin policy, and the disconnect between their
persistence model and that of the rest of the platform causes no end of
teeth-gnashing and hair-pulling among developers and auditors alike. We're
planning a few changes to bring things into something more closely
resembling alignment:

1.  `secure` ought to mean "secure": Though it's well-known that cookies
cross back and forth over protocol boundaries, recent research
Zheng, et al. has highlighted the fact that this behavior remains
surprising to developers, and also that there's little practical recourse
without changes in the browser.

We intend to make it more difficult for non-secure origins to influence the
state of secure origins by preventing non-secure origins from writing
cookies with a 'secure' flag and overwriting cookies whose 'secure' flag is
set. We're also planning to tweak the eviction rules to ensure that a
host's non-secure cookies are removed before its secure cookies. These
changes are spelled out in more technical detail in an Internet Draft
<https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone> we've
submitted to the IETF for consideration.

The metrics we've gathered show impact to about 0.02% of `Set-Cookie`
operations. Those numbers exclude deletions. Mozilla's metrics
show similar impact (and include deletions). We don't have metrics

2.  "secureness" should be verifiable from the server-side: We've
implemented Eric Lawrence's clever Cookie Prefixes proposal
as a lightweight mechanism which gives servers the ability to assert
certain properties about cookies they set and receive.

In short, cookies whose names begin with `$Secure-` may only be set from
secure origins, and must have the `secure` flag. Cookies whose names begin
with `$Host-` have the same restrictions, and must additionally have a path
of `/` and no `domain` attribute. This brings them as close to the
same-origin policy as we can get with existing attributes. These changes
are likewise spelled out in more technical detail in the Internet Draft
<https://tools.ietf.org/html/draft-west-cookie-prefixes> we've submitted.

3. Ambient authority should have an opt-out: We're looking at ways to deal
with the CSRF risks that cookies' ambient authority present. We have a
mostly-complete implementation of First-Party-Only cookies
<https://tools.ietf.org/html/draft-west-first-party-cookies>, which gives
servers the ability to assert that a particular cookie ought only be sent
in a "first-party" context by appending a `first-party-only` flag to the
`Set-Cookie` operation. The hope is that this will make certain kinds of
attacks significantly more difficult by preventing `third-party.com` from
making authenticated requests against `first-party.com`'s endpoints. Again,
details are in the Internet Draft


All of these new behaviors are currently implemented behind
chrome://flags/#enable-experimental-web-platform-features in Chrome Canary.
We welcome your experimentation and feedback. These are currently targeting
Chrome 49 (which would hit stable in the March/April timeframe), but that's
somewhat dependent on the feedback we get, both from Blink's owners
<http://www.chromium.org/blink#TOC-Web-Platform-Changes:-Process> when we
issue an intent to ship, and from developers at large.

WDYT, folks?

Received on Friday, 27 November 2015 10:33:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:52 UTC