draft-west-first-party-cookies-05.txt   draft-west-first-party-cookies-06.txt 
HTTPbis M. West HTTPbis M. West
Internet-Draft Google, Inc Internet-Draft Google, Inc
Updates: 6265 (if approved) M. Goodwin Updates: 6265 (if approved) M. Goodwin
Intended status: Standards Track Mozilla Intended status: Standards Track Mozilla
Expires: July 23, 2016 January 20, 2016 Expires: July 28, 2016 January 25, 2016
Same-site Cookies Same-site Cookies
draft-west-first-party-cookies-05 draft-west-first-party-cookies-06
Abstract Abstract
This document updates RFC6265 by defining a "SameSite" attribute This document updates RFC6265 by defining a "SameSite" attribute
which allows servers to assert that a cookie ought not to be sent which allows servers to assert that a cookie ought not to be sent
along with cross-site requests. This assertion allows user agents to along with cross-site requests. This assertion allows user agents to
mitigate the risk of cross-origin information leakage, and provides mitigate the risk of cross-origin information leakage, and provides
some protection against cross-site request forgery attacks. some protection against cross-site request forgery attacks.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 23, 2016. This Internet-Draft will expire on July 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and notation . . . . . . . . . . . . . . . . . . 4 2. Terminology and notation . . . . . . . . . . . . . . . . . . 4
2.1. "Same-site" and "cross-site" Requests . . . . . . . . . . 5 2.1. "Same-site" and "cross-site" Requests . . . . . . . . . . 4
2.1.1. Document-based requests . . . . . . . . . . . . . . . 5 2.1.1. Document-based requests . . . . . . . . . . . . . . . 5
2.1.2. Worker-based requests . . . . . . . . . . . . . . . . 6 2.1.2. Worker-based requests . . . . . . . . . . . . . . . . 6
3. Server Requirements . . . . . . . . . . . . . . . . . . . . . 8 3. Server Requirements . . . . . . . . . . . . . . . . . . . . . 7
3.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Semantics of the "SameSite" Attribute (Non-Normative) . . 8 3.2. Semantics of the "SameSite" Attribute (Non-Normative) . . 8
4. User Agent Requirements . . . . . . . . . . . . . . . . . . . 8 4. User Agent Requirements . . . . . . . . . . . . . . . . . . . 8
4.1. The "SameSite" attribute . . . . . . . . . . . . . . . . 8 4.1. The "SameSite" attribute . . . . . . . . . . . . . . . . 8
4.1.1. "Strict" and "Lax" enforcement . . . . . . . . . . . 8
4.2. Monkey-patching the Storage Model . . . . . . . . . . . . 9 4.2. Monkey-patching the Storage Model . . . . . . . . . . . . 9
4.3. Monkey-patching the "Cookie" header . . . . . . . . . . . 9 4.3. Monkey-patching the "Cookie" header . . . . . . . . . . . 10
5. Authoring Considerations . . . . . . . . . . . . . . . . . . 10 5. Authoring Considerations . . . . . . . . . . . . . . . . . . 10
5.1. Mashups and Widgets . . . . . . . . . . . . . . . . . . . 10 5.1. Defense in depth . . . . . . . . . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 5.2. Top-level Navigations . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Mashups and Widgets . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Section 8.2 of [RFC6265] eloquently notes that cookies are a form of Section 8.2 of [RFC6265] eloquently notes that cookies are a form of
ambient authority, attached by default to requests the user agent ambient authority, attached by default to requests the user agent
sends on a user's behalf. Even when an attacker doesn't know the sends on a user's behalf. Even when an attacker doesn't know the
contents of a user's cookies, she can still execute commands on 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 user's behalf (and with the user's authority) by asking the user
agent to send HTTP requests to unwary servers. agent to send HTTP requests to unwary servers.
skipping to change at page 3, line 36 skipping to change at page 3, line 38
mitigated by treating these navigational requests as "cross- mitigated by treating these navigational requests as "cross-
site". site".
4. Same-site cookies have some marginal value for policy or 4. Same-site cookies have some marginal value for policy or
regulatory purposes, as cookies which are not delivered with regulatory purposes, as cookies which are not delivered with
cross-site requests cannot be directly used for tracking cross-site requests cannot be directly used for tracking
purposes. It may be valuable for an origin to assert that its purposes. It may be valuable for an origin to assert that its
cookies should not be sent along with cross-site requests in cookies should not be sent along with cross-site requests in
order to limit its exposure to non-technical risk. order to limit its exposure to non-technical risk.
1.2. Limitations 1.2. Examples
Same-site cookies provide reasonable defense in depth against CSRF
attacks that rely on unsafe HTTP methods (like "POST"). They do not
offer a robust defense against CSRF as a general category of attack:
1. Attackers can still pop up new windows or trigger top-level
navigations in order to create a "same-site" request (as
described in section 2.1), which is only a speedbump along the
road to exploitation.
2. Features like "<link rel='prerender'>" [prerendering] can be
exploited to create "same-site" requests without the risk of user
detection.
In addition to the usual server-side defenses (CSRF tokens, ensuring
that "safe" HTTP methods are idempotent, etc), client-side techniques
such as those described in [app-isolation] may prove effective
against CSRF, and are certainly worth exploring in combination with
"SameSite" cookies. These cookies on their own, however, are not a
barrier to CSRF attacks as a general category.
1.3. Examples
Same-site cookies are set via the "SameSite" attribute in the "Set- Same-site cookies are set via the "SameSite" attribute in the "Set-
Cookie" header field. That is, given a server's response to a user Cookie" header field. That is, given a server's response to a user
agent which contains the following header field: agent which contains the following header field:
Set-Cookie: SID=31d4d96e407aad42; SameSite Set-Cookie: SID=31d4d96e407aad42; SameSite
Subsequent requests from that user agent can be expected to contain Subsequent requests from that user agent can be expected to contain
the following header field if and only if both the requested resource the following header field if and only if both the requested resource
and the resource in the top-level browsing context match the cookie. and the resource in the top-level browsing context match the cookie.
skipping to change at page 8, line 18 skipping to change at page 7, line 48
This section describes extensions to [RFC6265] necessary to implement This section describes extensions to [RFC6265] necessary to implement
the server-side requirements of the "SameSite" attribute. the server-side requirements of the "SameSite" attribute.
3.1. Grammar 3.1. Grammar
Add "SameSite" to the list of accepted attributes in the "Set-Cookie" Add "SameSite" to the list of accepted attributes in the "Set-Cookie"
header field's value by replacing the "cookie-av" token definition in header field's value by replacing the "cookie-av" token definition in
Section 4.1.1 of [RFC6265] with the following ABNF grammar: Section 4.1.1 of [RFC6265] with the following ABNF grammar:
cookie-av = expires-av / max-age-av / domain-av / cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av / path-av / secure-av / httponly-av /
samesite-av / extension-av samesite-av / extension-av
samesite-av = "SameSite" samesite-av = "SameSite" / "SameSite=" samesite-value
samesite-value = "Strict" / "Lax"
3.2. Semantics of the "SameSite" Attribute (Non-Normative) 3.2. Semantics of the "SameSite" Attribute (Non-Normative)
The "SameSite" attribute limits the scope of the cookie such that it The "SameSite" attribute limits the scope of the cookie such that it
will only be attached to requests if those requests are "same-site", will only be attached to requests if those requests are "same-site",
as defined by the algorithm in Section 2.1. For example, requests as defined by the algorithm in Section 2.1. For example, requests
for "https://example.com/sekrit-image" will attach same-site cookies for "https://example.com/sekrit-image" will attach same-site cookies
if and only if initiated from a context whose "site for cookies" is if and only if initiated from a context whose "site for cookies" is
"example.com". "example.com".
If the "SameSite" attribute has no value, if the value is "Strict",
or if the value is invalid, the cookie will only be sent along with
"same-site" requests. If the value is "Lax", the cookie will be sent
with "same-site" requests, and with "cross-site" top-level
navigations, as described in Section 4.1.1.
The changes to the "Cookie" header field suggested in Section 4.3 The changes to the "Cookie" header field suggested in Section 4.3
provide additional detail. provide additional detail.
4. User Agent Requirements 4. User Agent Requirements
This section describes extensions to [RFC6265] necessary in order to This section describes extensions to [RFC6265] necessary in order to
implement the client-side requirements of the "SameSite" attribute. implement the client-side requirements of the "SameSite" attribute.
4.1. The "SameSite" attribute 4.1. The "SameSite" attribute
The following attribute definition should be considered part of the The following attribute definition should be considered part of the
the "Set-Cookie" algorithm as described in Section 5.2 of [RFC6265]: the "Set-Cookie" algorithm as described in Section 5.2 of [RFC6265]:
If the attribute-name case-insensitively matches the string If the "attribute-name" case-insensitively matches the string
"SameSite", the user agent MUST append an attribute to the "cookie- "SameSite", the user agent MUST process the "cookie-av" as follows:
attribute-list" with an "attribute-name" of "SameSite" and an empty
"attribute-value". 1. Let "enforcement" be "Strict".
2. If "cookie-av"'s "attribute-value" is a case-insensitive match
for either "Strict" or "Lax", set "enforcement" to "cookie-av"'s
"attribute-value".
3. Append an attribute to the "cookie-attribute-list" with an
"attribute-name" of "SameSite" and an "attribute-value" of
"enforcement".
4.1.1. "Strict" and "Lax" enforcement
By default, same-site cookies will not be sent along with top-level
navigations. As discussed in Section 5.2, this might or might not be
compatible with existing session management systems. In the
interests of providing a drop-in mechanism that mitigates the risk of
CSRF attacks, developers may set the "SameSite" attribute in a "Lax"
enforcement mode that carves out an exception which sends same-site
cookies along with cross-site requests if and only if they are top-
level navigations which use a "safe" (in the [RFC7231] sense) HTTP
method.
Lax enforcement provides reasonable defense in depth against CSRF
attacks that rely on unsafe HTTP methods (like "POST"), but do not
offer a robust defense against CSRF as a general category of attack:
1. Attackers can still pop up new windows or trigger top-level
navigations in order to create a "same-site" request (as
described in section 2.1), which is only a speedbump along the
road to exploitation.
2. Features like "<link rel='prerender'>" [prerendering] can be
exploited to create "same-site" requests without the risk of user
detection.
When possible, developers should use a session management mechanism
such as that described in Section 5.2 to mitigate the risk of CSRF
more completely.
4.2. Monkey-patching the Storage Model 4.2. Monkey-patching the Storage Model
Note: There's got to be a better way to specify this. Until I figure Note: There's got to be a better way to specify this. Until I figure
out what that is, monkey-patching! out what that is, monkey-patching!
Alter Section 5.3 of [RFC6265] as follows: Alter Section 5.3 of [RFC6265] as follows:
1. Add "samesite-flag" to the list of fields stored for each cookie. 1. Add "samesite-flag" to the list of fields stored for each cookie.
This field's value is one of "None", "Strict", or "Lax".
2. Before step 11 of the current algorithm, add the following: 2. Before step 11 of the current algorithm, add the following:
1. If the "cookie-attribute-list" contains an attribute with an 1. If the "cookie-attribute-list" contains an attribute with an
"attribute-name" of "SameSite", set the cookie's "samesite- "attribute-name" of "SameSite", set the cookie's "samesite-
flag" to true. Otherwise, set the cookie's "samesite-flag" flag" to "attribute-value" ("Strict" or "Lax"). Otherwise,
to false. set the cookie's "samesite-flag" to "None".
2. If the cookie's "samesite-flag" is set to true, and the 2. If the cookie's "samesite-flag" is not "None", and the
request which generated the cookie's client's "site for request which generated the cookie's client's "site for
cookies" is not an exact match for "request-uri"'s host's cookies" is not an exact match for "request-uri"'s host's
registrable domain, then abort these steps and ignore the registrable domain, then abort these steps and ignore the
newly created cookie entirely. newly created cookie entirely.
4.3. Monkey-patching the "Cookie" header 4.3. Monkey-patching the "Cookie" header
Note: There's got to be a better way to specify this. Until I figure Note: There's got to be a better way to specify this. Until I figure
out what that is, monkey-patching! out what that is, monkey-patching!
Alter Section 5.4 of [RFC6265] as follows: Alter Section 5.4 of [RFC6265] as follows:
1. Add the following requirement to the list in step 1: 1. Add the following requirement to the list in step 1:
* If the cookie's "samesite-flag" is true, and the HTTP request * If the cookie's "samesite-flag" is not "None", and the HTTP
is cross-site (as defined in Section 2.1 then exclude the request is cross-site (as defined in Section 2.1 then exclude
cookie unless all of the following statements hold: the cookie unless all of the following statements hold:
1. The HTTP request's method is "safe". 1. "samesite-flag" is "Lax"
2. The HTTP request's target browsing context is a top-level 2. The HTTP request's method is "safe".
3. The HTTP request's target browsing context is a top-level
browsing context. browsing context.
Note that the modifications suggested here concern themselves only Note that the modifications suggested here concern themselves only
with the "site for cookies" of the request's client, and the with the "site for cookies" of the request's client, and the
registrable domain of the resource being requested. The cookie's registrable domain of the resource being requested. The cookie's
"domain", "path", and "secure" attributes do not come into play for "domain", "path", and "secure" attributes do not come into play for
these comparisons. these comparisons.
5. Authoring Considerations 5. Authoring Considerations
5.1. Mashups and Widgets 5.1. Defense in depth
"SameSite" cookies offer a robust defense against CSRF attack when
deployed in strict mode, and when supported by the client. It is,
however, prudent to ensure that this designation is not the extent of
a site's defense against CSRF, as same-site navigations and
submissions can certainly be executed in conjunction with other
attack vectors such as cross-site scripting.
Developers are strongly encouraged to deploy the usual server-side
defenses (CSRF tokens, ensuring that "safe" HTTP methods are
idempotent, etc) to mitigate the risk more fully.
Additionally, client-side techniques such as those described in
[app-isolation] may also prove effective against CSRF, and are
certainly worth exploring in combination with "SameSite" cookies.
5.2. Top-level Navigations
Setting the "SameSite" attribute in "strict" mode provides robust
defense in depth against CSRF attacks, but has the potential to
confuse users unless sites' developers carefully ensure that their
session management systems deal reasonably well with top-level
navigations.
Consider the scenario in which a user reads their email at MegaCorp
Inc's webmail provider "https://example.com/". They might expect
that clicking on an emailed link to "https://projects.com/secret/
project" would show them the secret project that they're authorized
to see, but if "projects.com" has marked their session cookies as
"SameSite", then this cross-site navigation won't send them along
with the request. "projects.com" will render a 404 error to avoid
leaking secret information, and the user will be quite confused.
Developers can avoid this confusion by adopting a session management
system that relies on not one, but two cookies: one conceptualy
granting "read" access, another granting "write" access. The latter
could be marked as "SameSite", and its absence would provide a
reauthentication step before executing any non-idempotent action.
The former could drop the "SameSite" attribute entirely, or choose
the "Lax" version of enforcement, in order to allow users access to
data via top-level navigation.
5.3. Mashups and Widgets
The "SameSite" attribute is inappropriate for some important use- The "SameSite" attribute is inappropriate for some important use-
cases. In particular, note that content intended for embedding in a cases. In particular, note that content intended for embedding in a
cross-site contexts (social networking widgets or commenting cross-site contexts (social networking widgets or commenting
services, for instance) will not have access to such cookies. Cross- services, for instance) will not have access to such cookies. Cross-
site cookies may be required in order to provide seamless site cookies may be required in order to provide seamless
functionality that relies on a user's state. functionality that relies on a user's state.
Likewise, some forms of Single-Sign-On might require authentication Likewise, some forms of Single-Sign-On might require authentication
in a cross-site context; these mechanisms will not function as in a cross-site context; these mechanisms will not function as
 End of changes. 20 change blocks. 
56 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/