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

[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?

[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.