HTTPbis M. West Internet-Draft Google, Inc Updates: 6265 (if approved) October 22, 2014 Intended status: Standards Track Expires: April 25, 2015 Origin Cookies draft-west-origin-cookies-00 Abstract This document updates RFC6265, defining the "origin" attribute for cookies and the "Origin-Cookie" header field, which together allow servers to choose to harmonize the security policy of their cookies with the same-origin policy which governs other available client-side storage mechanisms. Status of This Memo 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 April 25, 2015. Copyright Notice Copyright (c) 2014 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 West Expires April 25, 2015 [Page 1]
Internet-Draft Origin-Cookies October 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and notation . . . . . . . . . . . . . . . . . . 3 3. User Agent Requirements . . . . . . . . . . . . . . . . . . . 4 3.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. The "Origin" attribute . . . . . . . . . . . . . . . . . 4 3.3. Monkey-patching the Storage Model . . . . . . . . . . . . 4 3.4. Monkey-patching the "Cookie" header . . . . . . . . . . . 5 3.5. The "Origin-Cookie" header field . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4.1. "HttpOnly" . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Paths are ignored . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1. Origin-Cookie . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Cookies, as defined by [RFC6265], diverge from the web's general security policy in a number of ways which may be surprising to implementers and authors who haven't carefully read that document's discussion of "domain matching", and "path matching", or who ignored the admonitions regarding "Weak Confidentiality" and "Weak Integrity". This document updates [RFC6265], describing a mechanism by which servers can opt-in to harmonizing cookies' security policy with the same-origin policy, as described in [RFC6454]. User agents that support these "origin cookies" will ignore a "Set-Cookie" header's value's "Path", "Domain", and "Secure" attributes if an "Origin" attribute is present, instead tying the cookie to the origin that set it. These "origin cookies" will be returned in a new "Origin-Cookie" header field (see Section 3.5 for detail), separating them from non- origin cookies in a way a server can easily distinguish. Harmonizing with the same-origin policy mitigates the confidentiality and integrity risks noted above by ensuring that origin cookies are West Expires April 25, 2015 [Page 2]
Internet-Draft Origin-Cookies October 2014 not influenced by malicious code running on a server's subdomain or a non-standard port or scheme. Note that the mechanism outlined here is backwards compatible with the existing cookie syntax. Servers may serve origin cookies to all user agents; those that do not support the "Origin" attribute will simply store a non-origin cookie, just as they do today. 1.1. Examples Origin cookies are set via the "Origin" 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; Origin Subsequent requests from that user agent can be expected to contain the following header field: Origin-Cookie: SID=31d4d96e407aad42 Non-origin cookies are returned in the "Cookie" header field as usual. If both non-origin and origin cookies are present for an origin, then both a "Cookie" and "Origin-Cookie" header field will be present. That is, given a server's response to a user agent which contains the following header fields: Set-Cookie: SID=31d4d96e407aad42; Origin Set-Cookie: lang=en-US; Path=/; Domain=example.com Subsequent requests from that user agent can be expected to contain the following header fields: Cookie: lang=en-US Origin-Cookie: SID=31d4d96e407aad42 2. Terminology and notation 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]. West Expires April 25, 2015 [Page 3]
Internet-Draft Origin-Cookies October 2014 3. User Agent Requirements This section describes extensions to [RFC6265] necessary in order to implement the client-side requirements of the "Origin" attribute and "Origin-Cookie" header field. 3.1. Grammar Replace the "cookie-av" token definition in [RFC6265] with the following ABNF grammar: cookie-av = expires-av / max-age-av / domain-av / path-av / secure-av / httponly-av / origin-av / extension-av origin-av = "Origin" 3.2. The "Origin" 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 "Origin", the user agent MUST append an attribute to the cookie-attribute-list with an attribute-name of "Origin" and an empty attribute-value. 3.3. Monkey-patching the Storage Model 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: 1. Add "origin" and "origin-flag" to the list of fields stored about each cookie. 2. Before step 11 of the current algorithm, add the following: 1. If the "cookie-attribute-list" contains an attribute with an "attribute-name" of "Origin": 1. Set the cookie's "domain" attribute to the empty string. 2. Set the cookie's "http-only-flag" to true. 3. Set the cookie's "host-only-flag" to true. 4. Set the cookie's "origin" to the origin of "request-uri", as defined by Section 4 of [RFC6454]. West Expires April 25, 2015 [Page 4]
Internet-Draft Origin-Cookies October 2014 5. Set the cookie's "origin-flag" to true. 6. Set the cookie's "path" attribute to the empty string. 7. Set the cookie's "secure-only-flag" to false. Otherwise: set the cookie's "origin-flag" to false, and its "origin" to "null". 2. If the newly created cookie's "origin-flag" is set to true, and the cookie store contains a cookie with the same"name", "origin", and "origin-flag" as the newly created cookie: 1. Let "old-cookie" be the existing cookie with the same "name", "origin", and "origin-flag" as the newly created cookie. 2. Update the "creation-time" of the newly created cookie to match the "creation-time" of "old-cookie". 3. Remove "old-cookie" from the cookie store. 3. Change the priority order for excess cookie removal to the following: 1. Expired cookies. 2. Cookies whose "origin-flag" is false that share a "domain" field with more than a predetermined number of other cookies. 3. Cookies whose "origin-flag" is true that share a "domain" field with more than a predetermined number of other cookies. 4. Cookies whose "origin-flag" is false. 5. All cookies. 3.4. Monkey-patching the "Cookie" header 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: 1. Add the following requirement to the list in step 1: * The cookie's "origin-flag" is false. West Expires April 25, 2015 [Page 5]
Internet-Draft Origin-Cookies October 2014 3.5. The "Origin-Cookie" header field The user agent includes stored cookies whose "origin-flag" is set in the "Origin-Cookie" request header. When the user agent generates an HTTP request, it MUST NOT attach more than one "Origin-Cookie" header field. A user agent MAY omit the "Origin-Cookie" header in its entirety. For example, the user agent may wish to block sending cookies during "third-party" requests. If the user agent does attach an "Origin-Cookie" header field to an HTTP request, the user agent MUST send the "cookie-string" as defined below as the value of the header field. The user agent MUST use an algorithm equivalent to the following algorithm to compute the "cookie-string" from a cookie store and a "request-uri": 1. Let "cookie-list" be the set of cookies from the cookie store that meets all the following requirements: * The cookie's "origin-flag" is true. * The cookie's "origin" matches the origin of "request-uri". [RFC6454] * The "cookie-string" is not being generated for a "non-HTTP" API (as defined by the user agent). 2. The user agent SHOULD sort the "cookie-list" in the following order: * Cookies with earlier "creation-time"s are listed before cookies with later "creation-time"s. 3. Update the "last-access-time" of each cookie in the "cookie-list" to the current date and time. 4. Serialize the "cookie-list" into a "cookie-string" by processing each cookie in the "cookie-list" in order: 1. Output the cookie's "name", the %x3D ("=") character, and the cookie's "value". 2. If there is an unprocessed cookie in the "cookie-list", output the characters %x3B and %x20 ("; "). West Expires April 25, 2015 [Page 6]
Internet-Draft Origin-Cookies October 2014 4. Security Considerations The security considerations listed in Section 8 of [RFC6265] apply equally to origin cookies, with the exceptions of Sections 8.6 ("Weak Confidentiality") and Sections 8.7 ("Weak Isolation"), both of which are substantially improved if the "Origin" attribute is set. Further: 4.1. "HttpOnly" Note that origin cookies are only accessible via HTTP. "Non-HTTP" APIs like HTML's "document.cookie" cannot read these cookies' values. 4.2. Paths are ignored Origin cookies will break the (flawed) "Path"-based isolation strategy which some servers may be attempting to implement. If a server has used the "Path" attribute to limit cookies to specific areas of a site (say "/admin"), then they may be surprised by origin cookies' pathless behavior. That said, paths offer little to no protection against malicious code. The origin is the only security boundry enforced rigorously by user agents; it is therefore the only security boundry that server operators ought to rely on for isolation. 5. IANA Considerations The permanent message header field registry (see [RFC3864]) shall be updated with the following registration: 5.1. Origin-Cookie o Header field name: Origin-Cookie o Applicable protocol: http o Status: standard o Author/Change controller: IETF o Specification document: This specification (see Section 3.5) 6. Acknowledgements The origin cookie concept documented here is heavily indebted to and based upon Adam Barth's [draft-abarth-cake-01] document, as well as West Expires April 25, 2015 [Page 7]
Internet-Draft Origin-Cookies October 2014 Andrew Bortz, Adam Barth, and Alexei Czeskis' paper [origin-cookies-w2sp]. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011. [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011. 7.2. Informative References [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [draft-abarth-cake-01] Barth, A., "Origin Cookies", September 2011, <https://tools.ietf.org/html/draft-abarth-cake-01>. [origin-cookies-w2sp] Bortz,, A., Barth, A., and A. Czeskis, "Origin Cookies: Session Integrity for Web Applications", 2011, <http://w2spconf.com/2011/papers/session-integrity.pdf>. Appendix A. Open Issues o Should origin cookies be settable via "document.cookie"? Does that weaken the guarantees in any way we care about? Author's Address West Expires April 25, 2015 [Page 8]
Internet-Draft Origin-Cookies October 2014 Mike West Google, Inc Email: mkwst@google.com URI: https://mikewest.org/ West Expires April 25, 2015 [Page 9]