Intent to Ship: 'First-Party-Only' cookies.

[Mike West]

+net-dev and security-dev via BCC.

Contact emails

mk...@chromium.org

Spec

https://tools.ietf.org/html/draft-west-first-party-cookies

Summary

'First-Party-Only' 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.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/vT98riFhhT0/3Q-lADqsh0UJ

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

Yes.

Demo link

If you have a demo page, link to it here.

Debuggability

The inspector has a cookies view behind the chrome://flags/#enable-devtools-experiments flag. I intend to add the 'First-Party-Only' attribute to that table. Otherwise, cookies are cookies, and remain visible in the network tab's header view.

Compatibility Risk

Low.

'First-Party-Only' cookies are defense-in-depth against CSRF attacks, which gracefully degrade into "normal" cookies in browsers that don't support the new attribute. That is, when presented with:

Cookie: key=value; First-Party-Only

Chrome would treat the cookie as First-Party-Only, other browsers would treat it as though the attribute wasn't there at all.

Folks at Mozilla seem excited about the change (see the conversation starting hereish: https://groups.google.com/d/msg/mozilla.dev.platform/yEqC74IgnqQ/wIVQh4W2EAkJ, and https://twitter.com/mr_goodwin/status/572755941436878849). CCing Mark Goodwin and Jonas Sicking in case they have specific feedback on the proposal, and to ensure that I'm not misrepresenting their opinions.

Moreover, this seems to be a feature that developers want. For instance, GitHub is already experimenting with the header for their `user_session` cookie: https://twitter.com/joshpeek/status/572564724350525442

As a counterpoint, folks on the IETF HTTP WG list were cooler in response, but did invite prototypes: https://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0752.html

If this experiment fails completely, we'll remove the 'First-Party-Only' attribute support from //net, and downgrade all such cookies to "normal" cookies, just as they were treated in every other browser. I don't believe there's any risk of lock-in here.

There is a single open question regarding how we should treat requests from Service Workers, as it's unclear whether those should be considered 'first' or 'third' party. For the moment, we've settled on keeping the same behavior for "first-party-only" cookies that we have for "third-party cookie blocking" in Chrome; that is, Service Workers are generally first-party, even if they're responding to requests from a third-party. It's likely that we'll want to change this at some point in the future, but I don't believe that discussion should block shipping this feature.

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

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

-mike

[Chris Bentzel]

Happy to see this go in. Also seems low risk given the fallback behavior you describe.

How do you plan to track usage?

[Mike West]

On Thu, Mar 19, 2015 at 11:35 AM, Chris Bentzel <cben...@chromium.org> wrote:

Happy to see this go in. Also seems low risk given the fallback behavior you describe.

How do you plan to track usage?

An excellent question. I hadn't considered it, but should absolutely add some metrics. Are there any counts in particular that you'd find interesting? Adding a `Cookie.Type` seems reasonable, with buckets for `HttpOnly`, `Secure`, and `First-Party-Only` (as it doesn't look like we have metrics for those properties either).

In an ideal world, we'd do that UseCounter as well so that it shows up on the public feed and is relative to page views. Not sure whether we can easily hook into that from Blink, however (at least, not without reparsing the cookie string when creating a document...).

-mike

[Chris Bentzel]

On Thu, Mar 19, 2015 at 6:45 AM Mike West <mk...@chromium.org> wrote:

On Thu, Mar 19, 2015 at 11:35 AM, Chris Bentzel <cben...@chromium.org> wrote:

Happy to see this go in. Also seems low risk given the fallback behavior you describe.

How do you plan to track usage?

An excellent question. I hadn't considered it, but should absolutely add some metrics. Are there any counts in particular that you'd find interesting? Adding a `Cookie.Type` seems reasonable, with buckets for `HttpOnly`, `Secure`, and `First-Party-Only` (as it doesn't look like we have metrics for those properties either).

Not sure! But Cookie.Type sounds pretty reasonable. Main question I have is whether it would be recorded at retrieval time before a request is sent, or at setting time (whether via Set-Cookie or via document.cookie). 

One other question: does this show up in content settings UI display?

I also assume this would automatically show up in document.cookie or in the list of headers for WebRequest extensions?

[Mike West]

On Thu, Mar 19, 2015 at 11:51 AM, Chris Bentzel <cben...@chromium.org> wrote:

Not sure! But Cookie.Type sounds pretty reasonable. Main question I have is whether it would be recorded at retrieval time before a request is sent, or at setting time (whether via Set-Cookie or via document.cookie). 

I'd record `Cookie.Type` at the same time we update `Cookie.Count`, in `CookieMonster::RecordPeriodicStats`. It's not really clear to me where we'd want to hook in for Blink. The more I think about it, the less I like the idea of trying, because it would be pretty ugly. :)

 

One other question: does this show up in content settings UI display?

It doesn't show up in the current implementation, but we do show other properties, so I should add it: https://crbug.com/468709

 

I also assume this would automatically show up in document.cookie or in the list of headers for WebRequest extensions?

If the cookies were sent to an origin, yes, they'll show up in `document.cookie`. If the cookies weren't sent, then they won't show up (just as happens now for the "Block third-party cookies" option).

The headers will show up in the WebRequest extension; it's just another property in the cookie string, there's no magic going on.

We will need to update the `chrome.cookies` API  to include the new property, though, now that you mention it: https://crbug.com/468711

-mike

[Ryan Sleevi]

As someone who was more reserves during the Intent to Implement, I think Mike has addressed my concerns - and the compat story - quite well.

I think the spec itself needs some tweaking, which I'll provide feedback separately from this I2S.

My biggest concern for compat risk now is Service Workers. I'm not entirely sure that calling them First Party is correct, but I may be missing bits. Just that if we ship with them being FP, sites may come to rely on that, and then any change to that policy may break SWs by making cookies disappear.

I'd kinda prefer if we opted for a fail close model where we treat SWs as third party until we can fully rationalize why they're FP. It does mean that sites may have to choose between FP cookies and SWs (with SWs generally being far more compelling, thus likely to win), but I feel like that may be a more consistent approach. The only risk would seem if we decide SWs are FPs, it might introduce new attack vectors on sites that relied on FP cookies + SWs being third parties...

Beyond the challenges of SWs and spec tweaking, I think this is sensible!

[Mike West]

On Thu, Mar 19, 2015 at 12:33 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

As someone who was more reserves during the Intent to Implement, I think Mike has addressed my concerns - and the compat story - quite well.

I think the spec itself needs some tweaking, which I'll provide feedback separately from this I2S.

Happy to have it, in whatever format you prefer (mailing list, GitHub issues, telepathy, whatever).

My biggest concern for compat risk now is Service Workers. I'm not entirely sure that calling them First Party is correct, but I may be missing bits. Just that if we ship with them being FP, sites may come to rely on that, and then any change to that policy may break SWs by making cookies disappear.

I agree that this is a risk. FWIW, it's already a risk with our existing "Block third-party cookies" behavior, as these features key off the same property (FirstPartyForCookies). This is good, as it ensures that we're consistent, but it's not clear that we're consistently correct. :)

I'd kinda prefer if we opted for a fail close model where we treat SWs as third party until we can fully rationalize why they're FP.

It's not entirely clear what the "correct" behavior here should be, to be honest. +annevk who raised the question with me initially. Let's move this detail discussion to https://github.com/mikewest/internetdrafts/issues/3.

Beyond the challenges of SWs and spec tweaking, I think this is sensible!

Glad to hear it, thanks!

-mike

[Mike West]

On Thu, Mar 19, 2015 at 12:53 PM, Mike West <mk...@chromium.org> wrote:

On Thu, Mar 19, 2015 at 12:33 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

My biggest concern for compat risk now is Service Workers. I'm not entirely sure that calling them First Party is correct, but I may be missing bits. Just that if we ship with them being FP, sites may come to rely on that, and then any change to that policy may break SWs by making cookies disappear.

I agree that this is a risk. FWIW, it's already a risk with our existing "Block third-party cookies" behavior, as these features key off the same property (FirstPartyForCookies). This is good, as it ensures that we're consistent, but it's not clear that we're consistently correct. :)

Just in case it wasn't clear, the risk I'm agreeing with here is that 'First-Party-Only' wouldn't differ in behavior from status quo. Service Worker treatment doesn't open any new holes above and beyond what cookies do today (and would continue to do in any browser that doesn't implement the attribute).

-mike

[David Benjamin]

Could you clarify what the SW behavior is exactly? Do you mean that all requests from a SW include First-Party-Only cookies period or that the SW is treated as a first-party context whose URL is the script's URL, independent of whether the documents attached to it are top-level or iframe?

The latter seems correct to me[*], while the former would cancel any CSRF defense you may expect to gain out of this header. You could just make your SW mount attacks on your behalf. And since a SW only ever acts on behalf of a document same-origin to it, using that URL shouldn't break anything.

[*]  It does give a third-party context access to a first-party context to do its bidding, but having another tab open within the same BrowsingContext does the same. Even registering a SW is already stateful, so I think a "block third-party cookies" setting in a SW world would have to mean rejecting SW registrations in third-party contexts, maaaybe also not attaching SWs to them? I'm not as familiar with the exact semantics of that setting, so feel free to ignore this footnote if I'm confused. Anyway, it's fairly orthogonal to this header.

[Mike West]

On Thu, Mar 19, 2015 at 3:05 PM, David Benjamin <davi...@chromium.org> wrote:

Could you clarify what the SW behavior is exactly? Do you mean that all requests from a SW include First-Party-Only cookies period or that the SW is treated as a first-party context whose URL is the script's URL, independent of whether the documents attached to it are top-level or iframe?

I believe the current behavior is the latter. Requests from a SW are first-party to the origin which served the SW. The complication is that SW can send outgoing requests in order to service an incoming request. This has the potential to "launder" third-party requests into first-party requests for the host which served the SW. Attackers could frame `example.com`, for instance, and it's SW would make first-party requests, even though it's not really loaded in a first-party context.

This does not open holes with regard to hosts distinct from the SW. That is, `example.com`'s SW will certainly not make first-party requests to `not-example.com` (until and unless `example.com`'s SW starts responding to those requests, which I vaguely recall being discussed, but can't find in the spec now).

-mike

[Philip Jägenstedt]

It looks like the only thing that needs to be sorted is whether Service Workers should be considered first-party or third-party.

Alex, do you have any opinions about this? Is it likely that Service Workers will gain capabilities in the future that would increase the scope of the problem?

Mike, do you expect any trouble if you make Service Workers third party to begin with, or is this mainly a question of consistency with third-party cookie blocking?

Philip

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

[Mike West]

On Fri, Mar 20, 2015 at 8:43 AM, Philip Jägenstedt <phi...@opera.com> wrote:

It looks like the only thing that needs to be sorted is whether Service Workers should be considered first-party or third-party.

Three things popped up in off-thread comments last night:

1. lcamtuf@ noted that I'm totally overselling the CSRF mitigation, and underselling the timing attack/XSSI mitigations. He is, of course, correct. This doesn't change much practically about the feature, but I need to take another pass at the claims I'm making in the spec.

2. lcamtuf@ also noted that I need to explicitly consider prerendering, which is a neat bypass that I hadn't considered. We might want to block prerendering origins with first-party cookies.

 

3. aaj@ noted that this has the same definitional problem as `x-frame-options: sameorigin` in that allowing `example.com` -> `evil.com` -> `example.com` ancestor chains leaves some holes open that he'd like to see closed.

Alex, do you have any opinions about this? Is it likely that Service Workers will gain capabilities in the future that would increase the scope of the problem?

The capability that would worry me would be `example.com`'s SW responding to requests _to_ `example.com` _from_ `not-example.com`.

 

Mike, do you expect any trouble if you make Service Workers third party to begin with, or is this mainly a question of consistency with third-party cookie blocking?

I think we need to examine Service Workers (as well as the ancestor chain case) a bit more closely for third-party cookie blocking in general, but I don't think there's significant risk in shipping the existing behavior and tightening it in the near future. We'll get some implementation experience, have better understanding of the threats that the feature mitigates, and can use that experience to inform other vendors' implementations.

-mike

[Peter Kasting]

On Fri, Mar 20, 2015 at 1:24 AM, Mike West <mk...@chromium.org> wrote:

2. lcamtuf@ also noted that I need to explicitly consider prerendering, which is a neat bypass that I hadn't considered. We might want to block prerendering origins with first-party cookies.

That could have serious performance impact.  Be careful if you do that.

PK 

[Mike West]

Indeed. I did say "might". :)

The feature is a pretty careful tradeoff between performance and privacy/security already. I don't intend to poke at it without consulting folks who know more about those tradeoffs from the performance side than I do.

-mike

[Jake Archibald]

I think fetch(url, {credentials: 'include'}) requests made by a ServiceWorker should be the same as those made by a SharedWorker, which I guess uses the url of the worker to determine if first-party cookies should be sent.

I guess https://fetch.spec.whatwg.org/#requestcredentials could include "except-first-party" or something, so onfetch = e => e.respondWith(fetch(e.request)) would respect that, but fetch(e.request.url, {credentials: 'include'}) wouldn't.

This reduces first-party-only effectiveness in the iframe + ServiceWorker case, if event.request isn't used directly, but I think we're into the same territory as using postMessage to get a SharedWorker to make a request.

Once a page receives a response from a SW, it still has the opportunity to reject the response. Eg, if a no-cors response is given to a request that initially required CORS. Something could be done around this, but I'm not sure it necessary. 

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

[David Benjamin]

What's the concern with prerender? Is it that the lack of user-gesture rate-limiting would bypass attempts to frustrate timing and chosen-plaintext attacks on the transport and such? I don't see a way for it to bypass the CSRF-related bits.

David

[carl....@gmail.com]

I love the idea; automatically attaching cookies to arbitrary third-party requests has always seemed like a completely insane idea from a security perspective.

What about the approach based on CSP, suggested at http://deadliestwebattacks.com/2013/08/05/blackhat-us-2013-dissecting-csrf/
?

Maybe, if a CSP-based approach is implemented in the future, that could override the first-party-only attribute with more fine-grained controls, in a similar way to how CSP directives can currently override the X-Frame-Options header?

[Adam Barth]

On Thu, Mar 19, 2015 at 2:08 AM Mike West <mk...@chromium.org> wrote:

+net-dev and security-dev via BCC.

Contact emails

mk...@chromium.org

Spec

https://tools.ietf.org/html/draft-west-first-party-cookies

Summary

'First-Party-Only' 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.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/vT98riFhhT0/3Q-lADqsh0UJ

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

Yes.

Demo link

If you have a demo page, link to it here.

Sorry to be a downer, but it seems like an attacker can bypass this defense fairly easily.

Section 7.1 of draft-west-first-party-cookies-01 says "it is possible to bypass the protection that first-party-only cookies offer against cross-site request forgery attacks by creating first-party contexts in which to execute the attack...  Note, though, that popping up a window, or doing a top-level navigation are both significantly more visible to the user than loading a subresource.  Users will at least have the opportunity to notice that something strange is going on, which hopefully reduces an attacker's ability to perform untargeted attacks."

However, it seems possible create a first-party context in which to execute the attack without doing anything the user would notice as strange.  Consider the following demo:

http://www.adambarth.com/experimental/first-party-only/

Adam

[Mike West]

On Mon, Mar 23, 2015 at 12:42 AM, Adam Barth <aba...@chromium.org> wrote:

On Thu, Mar 19, 2015 at 2:08 AM Mike West <mk...@chromium.org> wrote:

+net-dev and security-dev via BCC.

Contact emails

mk...@chromium.org

Spec

https://tools.ietf.org/html/draft-west-first-party-cookies

Summary

'First-Party-Only' 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.

Sorry to be a downer

Not at all! "Intent to Ship" is a much better time to point out defects in my thinking than sometime after shipping something that doesn't work. :)

 

but it seems like an attacker can bypass this defense fairly easily.

Yes, as you demonstrated, I was simply wrong on this point. lcamtuf@ also noted that he had a number of thoughts about sneaky first-party-context-creating mechanisms that reduce this proposal's effectiveness against CSRF attacks. Let's pretend for the moment that this proposal never mentioned "cross-site request forgery". :)

It's clear to me now that the bulk of this proposal's value is wrapped up in mitigating information leakage attacks that require subresource loads (XSSI, the "pixel perfect" timing attack, etc). First-party cookies might make some kinds of CSRF harder, but are not a reliable mitigation. I plan to update the draft spec accordingly to give better guidance as to what they defend against, and what they don't.

I still think they have the potential to be a valuable addition to the platform, especially given the relatively low complexity of the implementation.

-mike

[Craig Francis]

On 22 Mar 2015, at 22:47, carl....@gmail.com wrote:
> What about the approach based on CSP, suggested at http://deadliestwebattacks.com/2013/08/05/blackhat-us-2013-dissecting-csrf/

Hi Carl,

I'm not on the Chrome dev team... but I don't think CSP is the correct place to set this restriction.

So where Mike Shema (at blackhat USA 2013) is proposing a "Storage Origin Security":

https://www.youtube.com/watch?v=JUY4DQZ02o4&t=27m50s

It looks like the CSP header must always be sent along with any "Set-Cookie" header.

The CSP header then instructs the browser to go back to the cookie, and set a policy for it.

I personally view CSP as a policy for the *content* the browser is loading at the time (i.e. the resources such as images, javascript, etc).

What Mike West is proposing is to extend the "Set-Cookie" header to include this new property (first-party-only), along with the existing http-only (not JS), secure (https-only), path, etc.

So everything is in one place, and we don't have a content policy also creating a cookie/storage policy.

Craig

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

[craig....@gmail.com]

On Monday, 23 March 2015 05:19:43 UTC, Mike West wrote:

Let's pretend for the moment that this proposal never mentioned "cross-site request forgery"

Just thinking out loud... and potentially introducing a breaking change, it might be possible to fix this (I think).

At the moment it does protect against resource requests from the malicious website, e.g.

- Images

- Script tags

- IFrames

- XMLHttpRequest / Fetch API

- CSP report-uri (to make a POST request)

- Prerender

The problem is when you create a first party context, e.g.

- Links

- Forms

- Redirects (JS/Meta/Header)

- Window.open()

Would it be possible to extent the restriction of first party cookies, so that they are also not sent when the request was initialised from a third party?

And that includes the malicious website linking to the target website, going via a redirect, then going to the target URL to perform the action.

This might break a few things... e.g. a separate support website links to a /admin/change-password/ page, logged in users won't be seen as logged in, so the website should redirect them to the login page.

But I don't think that is a major problem... and it *might* improve the effectiveness of protecting against more (most?) types of CSRF attacks.

Craig

[Chris Harrelson]

The API owners met today and discussed this Intent. We concluded that there doesn't seem to be enough consensus about the proposal to move forward right now, though it seems like it could succeed with more discussion among the security standards community to work out the corner cases.

Thanks,

Chris

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

[Mike West]

Hrm. +jochen, cbentzel as there was apparently some miscommunication about who was approving this feature. I landed it on their go-ahead, but I'm happy to revert given your concerns.

Could you be a bit more specific about what you'd like to see addressed before shipping a first pass?

-mike

[Mike West]

https://codereview.chromium.org/1032063002 was the CL.

-mike

[Chris Harrelson]

I thought it was going through the Blink intent process? I guess this particular case is a gray area since it doesn't really touch Blink code.

Re what should be addressed: my impression is that there is not full consensus on some details of the spec, in particular relating to Service Workers, and corner cases relating to caveats around CSRF that you referenced/alluded to a few emails back. It sounded to me from that that it would be worth going into more details on those question in the spec, then coming back with answers that can be re-reviewed by experts in the subject area.

Chris

[Mike West]

On Tue, Mar 31, 2015 at 8:24 PM, Chris Harrelson <chri...@chromium.org> wrote:

I thought it was going through the Blink intent process? I guess this particular case is a gray area since it doesn't really touch Blink code.

Re what should be addressed: my impression is that there is not full consensus on some details of the spec, in particular relating to Service Workers, and corner cases relating to caveats around CSRF that you referenced/alluded to a few emails back. It sounded to me from that that it would be worth going into more details on those question in the spec, then coming back with answers that can be re-reviewed by experts in the subject area.

Reverted in https://codereview.chromium.org/1043403003/. Will try again in M44.

-mike