HTTPbis | M. West |
Internet-Draft | Google, Inc |
Updates: 6265 (if approved) | M. Goodwin |
Intended status: Standards Track | Mozilla |
Expires: July 23, 2016 | January 20, 2016 |
Same-site Cookies
draft-west-first-party-cookies-05
This document updates RFC6265 by defining a SameSite attribute which allows servers to assert that a cookie ought not to be sent along with cross-site requests. This assertion allows user agents to mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 23, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Section 8.2 of [RFC6265] eloquently notes that cookies are a form of ambient authority, attached by default to requests the user agent 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 user’s behalf (and with the user’s authority) by asking the user agent to send HTTP requests to unwary servers.
Here, we update [RFC6265] with a simple mitigation strategy that allows servers to declare certain cookies as “same-site”, meaning they should not be attached to “cross-site” requests (as defined in section 2.1).
Note that the mechanism outlined here is backwards compatible with the existing cookie syntax. Servers may serve these cookies to all user agents; those that do not support the SameSite attribute will simply store a cookie which is attached to all relevant requests, just as they do today.
These cookies are intended to provide a solid layer of defense-in-depth against attacks which require embedding an authenticated request into an attacker-controlled context:
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:
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.
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 agent which contains the following header field:
Set-Cookie: SID=31d4d96e407aad42; SameSite
Subsequent requests from that user agent can be expected to contain the following header field if and only if both the requested resource and the resource in the top-level browsing context match the cookie.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap collation defined in [RFC4790].
The terms “active document”, “ancestor browsing context”, “browsing context”, “document”, “WorkerGlobalScope”, “sandboxed origin browsing context flag”, “parent browsing context”, “the worker’s Documents”, “nested browsing context”, and “top-level browsing context” are defined in [HTML].
“Service Workers” are defined in the Service Workers specification [SERVICE-WORKERS].
The term “origin”, the mechanism of deriving an origin from a URI, and the “the same” matching algorithm for origins are defined in [RFC6454].
“Safe” HTTP methods include GET, HEAD, OPTIONS, and TRACE, as defined in Section 4.2.1 of [RFC7231].
The term “public suffix” is defined in a note in Section 5.3 of [RFC6265] as “a domain that is controlled by a public registry”. For example, example.com’s public suffix is com. User agents SHOULD use an up-to-date public suffix list, such as the one maintained by Mozilla at [PSL].
An origin’s “registrable domain” is the origin’s host’s public suffix plus the label to its left. That is, https://www.example.com’s registrable domain is example.com. This concept is defined more rigorously in [PSL].
The term “request”, as well as a request’s “client”, “current url”, “method”, and “target browsing context”, are defined in [FETCH].
A request is “same-site” if it’s target’s URI’s origin’s registrable domain is an exact match for the request’s initiator’s “site for cookies”, and “cross-site” otherwise. To be more precise, for a given request (“request”), the following algorithm returns same-site or cross-site:
The URI displayed in a user agent’s address bar is the only security context directly exposed to users, and therefore the only signal users can reasonably rely upon to determine whether or not they trust a particular website. The registrable domain of that URI’s origin represents the context in which a user most likely believes themselves to be interacting. We’ll label this domain the “top-level site”.
For a document displayed in a top-level browsing context, we can stop here: the document’s “site for cookies” is the top-level site.
For documents which are displayed in nested browsing contexts, we need to audit the origins of each of a document’s ancestor browsing contexts’ active documents in order to account for the “multiple-nested scenarios” described in Section 4 of [RFC7034]. These document’s “site for cookies” is the top-level site if and only if the document and each of its ancestor documents’ origins have the same registrable domain as the top-level site. Otherwise its “site for cookies” is the empty string.
Given a Document (document), the following algorithm returns its “site for cookies” (either a registrable domain, or the empty string):
Worker-driven requests aren’t as clear-cut as document-driven requests, as there isn’t a clear link between a top-level browsing context and a worker. This is especially true for Service Workers [SERVICE-WORKERS], which may execute code in the background, without any document visible at all.
Note: The descriptions below assume that workers must be same-origin with the documents that instantiate them. If this invariant changes, we’ll need to take the worker’s script’s URI into account when determining their status.
Dedicated workers are simple, as each dedicated worker is bound to one and only one document. Requests generated from a dedicated worker (via importScripts, XMLHttpRequest, fetch(), etc) define their “site for cookies” as that document’s “site for cookies”.
Shared workers may be bound to multiple documents at once. As it is quite possible for those documents to have distinct “site for cookie” values, the worker’s “site for cookies” will be the empty string in cases where the values diverge, and the shared value in cases where the values agree.
Given a WorkerGlobalScope (worker), the following algorithm returns its “site for cookies” (either a registrable domain, or the empty string):
Service Workers are more complicated, as they act as a completely separate execution context with only tangential relationship to the Document which registered them.
Requests which simply pass through a service worker will be handled as described above: the request’s client will be the Document or Worker which initiated the request, and its “site for cookies” will be those defined in Section 2.1.1 and Section 2.1.2.1
Requests which are initiated by the Service Worker itself (via a direct call to fetch(), for instance), on the other hand, will have a client which is a ServiceWorkerGlobalScope. Its “site for cookies” will be the registrable domain of the Service Worker’s URI.
Given a ServiceWorkerGlobalScope (worker), the following algorithm returns its “site for cookies” (either a registrable domain, or the empty string):
This section describes extensions to [RFC6265] necessary to implement the server-side requirements of the SameSite attribute.
Add SameSite to the list of accepted attributes in the Set-Cookie header field’s value by replacing the cookie-av token definition in Section 4.1.1 of [RFC6265] with the following ABNF grammar:
cookie-av = expires-av / max-age-av / domain-av / path-av / secure-av / httponly-av / samesite-av / extension-av samesite-av = "SameSite"
The “SameSite” attribute limits the scope of the cookie such that it will only be attached to requests if those requests are “same-site”, as defined by the algorithm in Section 2.1. For example, requests for https://example.com/sekrit-image will attach same-site cookies if and only if initiated from a context whose “site for cookies” is “example.com”.
The changes to the Cookie header field suggested in Section 4.3 provide additional detail.
This section describes extensions to [RFC6265] necessary in order to implement the client-side requirements of the SameSite attribute.
The following attribute definition should be considered part of the the Set-Cookie algorithm as described in Section 5.2 of [RFC6265]:
If the attribute-name case-insensitively matches the string “SameSite”, the user agent MUST append an attribute to the cookie-attribute-list with an attribute-name of “SameSite” and an empty attribute-value.
Note: There’s got to be a better way to specify this. Until I figure out what that is, monkey-patching!
Alter Section 5.3 of [RFC6265] as follows:
Note: There’s got to be a better way to specify this. Until I figure out what that is, monkey-patching!
Alter Section 5.4 of [RFC6265] as follows:
Note that the modifications suggested here concern themselves only with the “site for cookies” of the request’s client, and the registrable domain of the resource being requested. The cookie’s domain, path, and secure attributes do not come into play for these comparisons.
The SameSite attribute is inappropriate for some important use-cases. In particular, note that content intended for embedding in a cross-site contexts (social networking widgets or commenting services, for instance) will not have access to such cookies. Cross-site cookies may be required in order to provide seamless functionality that relies on a user’s state.
Likewise, some forms of Single-Sign-On might require authentication in a cross-site context; these mechanisms will not function as intended with same-site cookies.
Same-site cookies in and of themselves don’t do anything to address the general privacy concerns outlined in Section 7.1 of [RFC6265]. The attribute is set by the server, and serves to mitigate the risk of certain kinds of attacks that the server is worried about. The user is not involved in this decision. Moreover, a number of side-channels exist which could allow a server to link distinct requests even in the absence of cookies. Connection and/or socket pooling, Token Binding, and Channel ID all offer explicit methods of identification that servers could take advantage of.
[RFC7034] | Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-Options", RFC 7034, DOI 10.17487/RFC7034, October 2013. |
[app-isolation] | Chen, E., Bau, J., Reis, C., Barth, A. and C. Jackson, "App Isolation - Get the Security of Multiple Browsers with Just One", n.d.. |
[pixel-perfect] | Stone, P., "Pixel Perfect Timing Attacks with HTML5", n.d.. |
[prerendering] | Bentzel, C., "Chrome Prerendering", n.d.. |
[samedomain-cookies] | Goodwin, M. and J. Walker, "SameDomain Cookie Flag", 2011. |
The same-site cookie concept documented here is indebited to Mark Goodwin’s and Joe Walker’s [samedomain-cookies]. Michal Zalewski, Artur Janc, and Ryan Sleevi provided particularly valuable feedback on this document.