Intent to Implement: "First-Party" cookies.

[Mike West]

+blink-dev@, net-dev@, and erikwright@.

Contact emails

mk...@chromium.org

Spec

https://tools.ietf.org/html/draft-west-first-party-cookies (Note that this is a pretty early draft with more than a few open questions; details will certainly change based on implementation experience)

Summary

First-party cookies allow servers to mitigate the risk of cross-site request forgery and related information leakage attacks by asserting that a particular cookie should only be sent in a "first-party" context.

Motivation

Cookies are a form of ambient authority, attached by default to requests the user agent sends on a user's behalf to a particular host. Even when an attacker doesn't know the contents of a user's cookies, she can still execute commands on the user's behalf (and with the user's authority) by asking the user agent to send HTTP requests to unwary servers.

For instance, `evil.com` can include `bank.com/admin/transfer-all-money-to-mike` in an `<img>` tag. That request will include cookies, and if the target doesn't do a good job defending itself (via CSRF tokens, for instance), it could execute commands on your behalf.

This proposal is a simple mitigation strategy that allows servers to declare certain cookies as "first-party", and that they should be attached to requests if and only if they occur in a first-party context. It doesn't solve the problem, but it is a reasonable defense in depth.

Compatibility Risk

Low. Cookies marked as "first-party" will simply behave as regular cookies in browsers that don't support the flag.

Ongoing technical constraints
None.

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

Yes.


OWP launch tracking bug

https://crbug.com/459154 

Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/4672634709082112

Requesting approval to ship?

No.

--
Mike West <mk...@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Ryan Sleevi]

On Tue, Feb 17, 2015 at 2:41 AM, 'Mike West' via net-dev
<net...@chromium.org> wrote:
> +blink-dev@, net-dev@, and erikwright@.
>
> Contact emails
> mk...@chromium.org
>
> Spec
> https://tools.ietf.org/html/draft-west-first-party-cookies (Note that this
> is a pretty early draft with more than a few open questions; details will
> certainly change based on implementation experience)

I'm fairly cool to this, if only because of the significant
complications we've encountered at the networking stack due to the
notion of first-/third-party requests and the ambiguous security
guarantees there.

For example, Chrome currently maintains two independent stacks of
socket pools in order to satisfy an ambiguous notion of
first/third-party and the implicit (but mistaken) privacy assumptions
therein. Put more concretely, can a connection that was used
previously to send a first-party cookie be re-used to satisfy a
request in which first-party cookies are omitted? Likewise, if a
connection previously only had non-first-party cookies sent on it, can
it be reused for first-party cookies?

Consider further the implications with HTTP/2's connection pooling,
which further adds complexity in determining when it's acceptable to
send such a request.

These issues are fundamentally tied to what you're trying to
accomplish by the First-Party/Third-Party separation, what
expectations Site Operators can have upon their use and
appropriateness, and what experience and controls the user have. I
don't think this draft does anything to clarify these issues at an
abstract level, and thus I'm deeply concerned with implementing
something that is difficult to reason about from a "Correctness" and
"Expected Behaviour" standpoint.

Put differently, I would hope that you first focus on the
first-party/third-party use cases and guarantees, and then revisit how
cookies interact with it. I fear implementing this proposal w/o those
bits in place is going to create long term complexity, debt, and bugs,
even if the implementation itself turns out to be 'novel'.

[Mike West]

Hey Ryan! Thanks for the feedback!

On Tue, Feb 17, 2015 at 10:38 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Tue, Feb 17, 2015 at 2:41 AM, 'Mike West' via net-dev
<net...@chromium.org> wrote:
> +blink-dev@, net-dev@, and erikwright@.
>
> Contact emails
> mk...@chromium.org
>
> Spec
> https://tools.ietf.org/html/draft-west-first-party-cookies (Note that this
> is a pretty early draft with more than a few open questions; details will
> certainly change based on implementation experience)

I'm fairly cool to this, if only because of the significant
complications we've encountered at the networking stack due to the
notion of first-/third-party requests and the ambiguous security
guarantees there.

Based on our quick discussion this morning, I hope it's fair to summarize your coolness as relating mostly to the privacy expectations the specification raises (in particular, the recommendations at https://tools.ietf.org/html/draft-west-first-party-cookies-00#section-6.1). While I'd hoped that that section would avoid raising expectations by being intentionally weak in it's description, I agree that we need to consider more than cookies to have meaningful effects on explicit linkability (to say nothing of passive fingerprinting). Socket pools, Channel ID/Token Binding, etc. all have distinct impacts there that this spec doesn't address.

That said, I think we're in agreement that there are good security implications to allowing a host to assert that cookies (which most sites use exclusively as ambient bearer tokens) should be suppressed in certain contexts. Moreover, I think we're in agreement that the first-/third-party distinction is a reasonable way to frame the discussion.

With that in mind, I'd like to do the following:

1. Continue implementing first-party cookies on a per-request basis, as there seem to be clear security benefits to doing so, and it seems to be reasonably straightforward to do so without adding substantial complexity to //net (https://codereview.chromium.org/876973003 is an unreviewed first pass, if you'd like to evaluate that bold assertion :) ).

2. Narrow the focus of the spec to the security implications, to avoid privacy implications that UAs can't easily enforce.

3. Separately explore the privacy guarantees that we'd like to be able make at a network level when taking first-/third-partyness into account.

Does that seem like a reasonable approach to you?

-mike

[Anne van Kesteren]

On Tue, Feb 17, 2015 at 10:38 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

> For example, Chrome currently maintains two independent stacks of
> socket pools in order to satisfy an ambiguous notion of
> first/third-party and the implicit (but mistaken) privacy assumptions
> therein. Put more concretely, can a connection that was used
> previously to send a first-party cookie be re-used to satisfy a
> request in which first-party cookies are omitted? Likewise, if a
> connection previously only had non-first-party cookies sent on it, can
> it be reused for first-party cookies?

I think it's fine to pool them together with other requests that
potentially contain cookies (whatever flavor). First-party cookies is
about the site not getting cookies for certain requests so the site
isn't vulnerable to XSRF. It's not about scoping requests in a certain
way and I don't really see why it needs to be.

(If the site ties authority to TLS session identifiers and such they
may have a problem, but as you note cookies are not going to solve
that.)


--
https://annevankesteren.nl/

[Ryan Sleevi]

On Wed, Feb 18, 2015 at 12:54 AM, Mike West <mk...@chromium.org> wrote:
> Hey Ryan! Thanks for the feedback!

> With that in mind, I'd like to do the following:
>
> 1. Continue implementing first-party cookies on a per-request basis, as
> there seem to be clear security benefits to doing so, and it seems to be
> reasonably straightforward to do so without adding substantial complexity to
> //net (https://codereview.chromium.org/876973003 is an unreviewed first
> pass, if you'd like to evaluate that bold assertion :) ).
>
> 2. Narrow the focus of the spec to the security implications, to avoid
> privacy implications that UAs can't easily enforce.
>
> 3. Separately explore the privacy guarantees that we'd like to be able make
> at a network level when taking first-/third-partyness into account.
>
> Does that seem like a reasonable approach to you?
>
> -mike

Sounds good. The spec raised concerns that you were trying to address
privacy concerns, but from our chat and from this thread, I think it's
clear(er) that this is only about reducing ambient authority.

From the net stack, I don't think this will be too much of a problem.

If/when it comes to ripping this code out (e.g. if this work proves
less fruitful), how do you plan to handle the cookies that were marked
as First Party?

Either they can be deleted - removing any risk of accidental increase
in scoping, but at the cost of causing unknown issues - or they can be
silently degraded back to 'traditional' - mirroring the behaviour of
other UAs. I just want to make sure our exit strategy is clear for any
sites that choose to adopt these during the implementation flag, so
that they know what the risks are. But I don't think that should block
implementation.

[Philip Jägenstedt]

No LGTM needed, but this sounds like a worthwhile experiment to me!

Ryan's question about exit strategy is a good one, although I don't know what the answer ought to be :)

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike West]

On Mon, Feb 23, 2015 at 3:03 PM, Philip Jägenstedt <phi...@opera.com> wrote:

No LGTM needed, but this sounds like a worthwhile experiment to me!

Ryan's question about exit strategy is a good one, although I don't know what the answer ought to be :)

I think Ryan's suggestion that we simply revert the cookies to non-first-party-only status is reasonable. That is, of course, how they will be treated in every browser that doesn't support the flag.

-mike

[Philip Jägenstedt]

The hypothetical that comes to mind is a site that (using browser sniffing) only uses cookies if your new spec is supported, and thus counts on these never being sent in a third-party context.

Philip 

[Mike West]

Sure. My hope would be that any site using this feature would rely on it only as defense-in-depth, as there are certainly ways to create first-party contexts which would send cookies (that the spec points out). This isn't going to _prevent_ attack. It can only mitigate the most problematic attack vectors.

-mike

[Ryan Sleevi]

On Mon, Feb 23, 2015 at 7:27 AM, Mike West <mk...@chromium.org> wrote:
> Sure. My hope would be that any site using this feature would rely on it
> only as defense-in-depth, as there are certainly ways to create first-party
> contexts which would send cookies (that the spec points out). This isn't
> going to _prevent_ attack. It can only mitigate the most problematic attack
> vectors.
>
> -mike

Sites will rely on whatever we tell them, either explicitly or
implicitly through omission.

I think it's entirely reasonable to drop them to 'traditional' cookies
if and when support is removed, as long as we're perfectly clear to
sites that this is what will happen if we decide to remove support :)

[craig....@gmail.com]

On Tuesday, 17 February 2015 10:43:21 UTC, Mike West wrote:

Spec

https://tools.ietf.org/html/draft-west-first-party-cookies (Note that this is a pretty early draft with more than a few open questions; details will certainly change based on implementation experience)

First... yes please, I think this is a really good idea :-)

But, just so it's mentioned... can we check the naming convention along with HttpOnly (no hyphens) and Max-Age (which isn't supported in <= IE8). 

The draft currently says the attribute should be "First-Party-Only", for example:

Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly; First-Party-Only;

http://tools.ietf.org/html/rfc6265

But for some additional comparisons:

Keep-Alive: timeout=5...
X-Content-Type-Options: nosniff

Strict-Transport-Security: max-age=31536000; includeSubDomains

Cache-Control: no-store, no-cache...
Connection: keep-alive...
Pragma: no-cache...
Content-Security-Policy: default-src 'none'...
Public-Key-Pins: pin-sha256=...

Also... out of interest Mike, did you copy the SID from rfc6265 for your draft? It seems odd that they are both 31d4d96e407aad42 :-)

Craig

[Mike West]

On Thu, Mar 19, 2015 at 11:11 AM, <craig....@gmail.com> wrote:

On Tuesday, 17 February 2015 10:43:21 UTC, Mike West wrote:

Spec

https://tools.ietf.org/html/draft-west-first-party-cookies (Note that this is a pretty early draft with more than a few open questions; details will certainly change based on implementation experience)

First... yes please, I think this is a really good idea :-)

Glad to hear it!

 

But, just so it's mentioned... can we check the naming convention along with HttpOnly (no hyphens) and Max-Age (which isn't supported in <= IE8). 

Within cookies, we have `Set-Cookie` and `max-age` arguing for the hyphen, and `httponly` arguing against. 2:1, so I went with the hyphen. I agree, however, that it's not at all clear what The Right Way To Spell Things In Headers(tm) actually is. We're all over the map, really.

I picked one and ran with it. If there are strong anti-hyphen feelings, I'm happy to change the spelling. This isn't something I have strong feelings about (except insofar as I've already implemented the hypenated property, and it would be a little annoying to change it).

The draft currently says the attribute should be "First-Party-Only", for example:

Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly; First-Party-Only;

http://tools.ietf.org/html/rfc6265

But for some additional comparisons:

Keep-Alive: timeout=5...
X-Content-Type-Options: nosniff

Strict-Transport-Security: max-age=31536000; includeSubDomains

Cache-Control: no-store, no-cache...
Connection: keep-alive...
Pragma: no-cache...
Content-Security-Policy: default-src 'none'...
Public-Key-Pins: pin-sha256=...

Also... out of interest Mike, did you copy the SID from rfc6265 for your draft? It seems odd that they are both 31d4d96e407aad42 :-)

I did. :)

-mike

[Craig Francis]

On 19 Mar 2015, at 10:26, Mike West <mk...@chromium.org> wrote:

I picked one and ran with it. If there are strong anti-hyphen feelings, I'm happy to change the spelling. This isn't something I have strong feelings about (except insofar as I've already implemented the hypenated property, and it would be a little annoying to change it).

I'm not sure I would change the name either.

Maybe it could be "first-only", so it's abbreviated in the same sort of way (as I know some people like to shave every byte they can from their HTTP requests).

But certainly don't make any changes without someone with a strong opinion either way... I'm just happy to hear about the feature potentially existing, it would certainly help with a defence in depth approach to CSRF :-)

Craig

[James Hartig]

"<iframe>"s do not create new first-party contexts; their requests MUST be considered in the context of the origin of the URL the user actually sees in the user agent's address bar.

So if evil.com loaded bank.com in an iFrame, it wouldn't get any cookies marked as First-Party-Only. Let's say the user logs into bank.com inside that iframe on evil.com, what would happen? Would any cookies that bank.com tried to set via logging in (i.e. to store session info) just not be set because the origin is still evil.com? I assume this would break how StumbleUpon does their iFrame'd stuff and not allow people to log into sites that used First-Party-Only cookies for storing session information, correct?

James

[Mike West]

On Mon, Mar 23, 2015 at 8:33 PM, James Hartig <faste...@gmail.com> wrote:

"<iframe>"s do not create new first-party contexts; their requests MUST be considered in the context of the origin of the URL the user actually sees in the user agent's address bar.

So if evil.com loaded bank.com in an iFrame, it wouldn't get any cookies marked as First-Party-Only. Let's say the user logs into bank.com inside that iframe on evil.com, what would happen? Would any cookies that bank.com tried to set via logging in (i.e. to store session info) just not be set because the origin is still evil.com? I assume this would break how StumbleUpon does their iFrame'd stuff and not allow people to log into sites that used First-Party-Only cookies for storing session information, correct?

Right. 'First-Party-Only' cookies can't be set in a third-party context. That's step 2.2 of https://tools.ietf.org/html/draft-west-first-party-cookies-01#section-4.2.

-mike