Intent to Ship: cookie prefixes

51 views
Skip to first unread message

Emily Stark

unread,
Dec 8, 2015, 1:28:29 PM12/8/15
to blink-dev, Joel Weinberger, Mike West

+net-dev and security-dev via BCC.


Contact emails

est...@chromium.org, mk...@chromium.org


Spec

https://tools.ietf.org/html/draft-west-cookie-prefixes-05

Summary
This feature adds a set of restrictions upon the names which may be used for cookies with specific properties. These restrictions enable user agents to smuggle cookie state to the server within the confines of the existing "Cookie" request header syntax, and limits the ways in which cookies may be abused.

In a nutshell: `__Secure-*` cookies have to be set from secure origins with the `Secure` flag, and `__Host-*` cookies have to have `Path=/`, can't have `Domain`, and require `Secure`.

Motivation
Cookies are terrible. This proposal makes them slightly less terrible, by addressing the "Weak Confidentiality" and "Weak Integrity" concerns spelled out in RFC 6265. See the Intent to Implement thread for more detail.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/IU5t6eLuS2Y/Uq-7Kat9BwAJ


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Compatibility Risk

The syntax is backwards compatible with existing cookie syntax and flags. There is a risk that existing sites might already use the __Secure or __Host prefixes on their cookies and those sites would break when we ship this change. Our telemetry from Canary and Dev does not show any uses of those prefixes, though.


We can't implement this on iOS because we don't have control over either the cookie store or the network stack.


OWP launch tracking bug? https://crbug.com/541511


Link to entry on the feature dashboard: https://www.chromestatus.com/features/4952188392570880

Devdatta Akhawe

unread,
Dec 8, 2015, 2:11:21 PM12/8/15
to Emily Stark, blink-dev, Joel Weinberger, Mike West
how does this interact with document.cookie? Can a document that has
modified document.domain set __Host cookies? Can an insecure page set
__Secure cookies?

(sorry .. a quick grep didn't find anything in the intent to implement
or in the draft)
> --
> You received this message because you are subscribed to the Google Groups
> "Security-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev...@chromium.org.

Mike West

unread,
Dec 8, 2015, 2:50:10 PM12/8/15
to Devdatta Akhawe, Emily Stark, blink-dev, Joel Weinberger
On Tue, Dec 8, 2015 at 8:10 PM, Devdatta Akhawe <dev.a...@gmail.com> wrote:
how does this interact with document.cookie? Can a document that has
modified document.domain set __Host cookies? Can an insecure page set
__Secure cookies?

(sorry .. a quick grep didn't find anything in the intent to implement
or in the draft)

Prefixes have no effect on `document.cookie`, other than requiring that if you set a cookie via `document.cookie` that the flags are set as specified. If the document can set a cookie with `secure; path=/`, it can set a cookie named `__Host-whatever` via `document.cookie`.

I'd have to check the code to be 100% sure, but I'm _pretty_ sure that `document.domain` has no effect on a cookie's domain. We use the actual URL of the document (or of its origin in some weird edge cases).

-mike

Philip Jägenstedt

unread,
Dec 9, 2015, 9:15:31 AM12/9/15
to Mike West, Devdatta Akhawe, Emily Stark, blink-dev, Joel Weinberger
LGTM1

The syntax is ugly, but the spec section Why "__"? quickly removed those doubts :)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Philip Jägenstedt

unread,
Dec 9, 2015, 9:20:01 AM12/9/15
to Mike West, Devdatta Akhawe, Emily Stark, blink-dev, Joel Weinberger
Actually, scratch that, I don't understand the relationship between this and Joel's thread, can they really be considered in isolation, or should we pick one of the threads to cover it all?

Mike West

unread,
Dec 9, 2015, 9:30:37 AM12/9/15
to Philip Jägenstedt, Devdatta Akhawe, Emily Stark, blink-dev, Joel Weinberger
On Wed, Dec 9, 2015 at 3:19 PM, Philip Jägenstedt <phi...@opera.com> wrote:
Actually, scratch that, I don't understand the relationship between this and Joel's thread, can they really be considered in isolation, or should we pick one of the threads to cover it all?

I think they're separate features, but I'm happy for you to just LGTM both at the same time if that's simpler for you. :)

Prefixes place restrictions upon cookies with certain special names, no more no less. Those restrictions are defined in terms of existing behavior, and are completely backwards compatible. The feature is easily shippable in isolation, and doesn't require any changes to any other part of any other cookies' behavior. There's basically zero risk to shipping prefixes.

Joel's thread deals with a change to the existing behavior of the `secure` token. That change will affect prefixed cookies, but only insofar as it effects all cookies with that token, and both prefixes require it. It is less backwards compatible, and has some level of risk associated with it. I believe Joel intends to take it slow with that rollout, gating things on field trials to let us roll the change out incrementally, but I'll defer to him on a discussion of the details.

-mike

Philip Jägenstedt

unread,
Dec 9, 2015, 9:56:41 AM12/9/15
to Mike West, Devdatta Akhawe, Emily Stark, blink-dev, Joel Weinberger
OK, let's see if I understand this. This intent covers the prefixes "__Secure-" and "__Host-", rejecting attempts to set that cookie if the requirements for the prefix are not met.

Joel's intent, on the other hand, is ensuring that cookies with the "Secure" attribute set are entirely isolated from insecure origins? This affects all secure cookies, incidentally including those using the "__Secure-" prefix?

Philip

Mike West

unread,
Dec 9, 2015, 10:04:30 AM12/9/15
to Philip Jägenstedt, Devdatta Akhawe, Emily Stark, blink-dev, Joel Weinberger
Correct.

-mike

Philip Jägenstedt

unread,
Dec 9, 2015, 10:28:30 AM12/9/15
to Mike West, Devdatta Akhawe, Emily Stark, blink-dev, Joel Weinberger
OK, LGTM1-1+1 = LGTM1 to ship cookie prefixes!

Joel Weinberger

unread,
Dec 9, 2015, 11:05:17 AM12/9/15
to Philip Jägenstedt, Mike West, Devdatta Akhawe, Emily Stark, blink-dev

Just confirming what Mike said about the slow rollout. Based on our measurements, we think Strict Secure should be OK to rollout, but we want to just make sure there isn't any surprise breakage.

Chris Harrelson

unread,
Dec 11, 2015, 12:16:22 AM12/11/15
to Joel Weinberger, Philip Jägenstedt, Mike West, Devdatta Akhawe, Emily Stark, blink-dev
LGTM2

Dimitri Glazkov

unread,
Dec 11, 2015, 11:28:24 AM12/11/15
to Chris Harrelson, Joel Weinberger, Philip Jägenstedt, Mike West, Devdatta Akhawe, Emily Stark, blink-dev
__LGTM3
Reply all
Reply to author
Forward
0 new messages