Potential changes to cookies in Chrome.

66 views
Skip to first unread message

Mike West

unread,
Nov 27, 2015, 5:33:19 AM11/27/15
to security-dev, Emily Stark, Joel Weinberger
Hello, security-dev@! (And _secretly_ hello to net-dev@, blink-dev@, dev-se...@lists.mozilla.org, and public-w...@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 from 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 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 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, 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 when we issue an intent to ship, and from developers at large.

WDYT, folks?

-mike
Reply all
Reply to author
Forward
0 new messages