[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

HTTPbis                                                          M. West
Internet-Draft                                               Google, Inc
Updates: 6265 (if approved)                               April 20, 2015
Intended status: Standards Track
Expires: October 22, 2015


                             Origin Cookies
                      draft-west-origin-cookies-01

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 October 22, 2015.

Copyright Notice

   Copyright (c) 2015 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 October 22, 2015                [Page 1]


Internet-Draft               Origin-Cookies                   April 2015


   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  . . . . . . . . . . . . . . . . . .   4
   3.  Server Requirements . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Grammar . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Semantics of the "Origin" Attribute (Non-Normative) . . .   4
     3.3.  The <spanx style="verb">Origin-Cookie</spanx> header  . .   5
       3.3.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.2.  Semantics . . . . . . . . . . . . . . . . . . . . . .   5
   4.  User Agent Requirements . . . . . . . . . . . . . . . . . . .   5
     4.1.  The "Origin" attribute  . . . . . . . . . . . . . . . . .   5
     4.2.  Monkey-patching the Storage Model . . . . . . . . . . . .   5
     4.3.  Monkey-patching the "Cookie" header . . . . . . . . . . .   7
     4.4.  The "Origin-Cookie" header field  . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     5.1.  Paths are ignored . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Downgrade attacks . . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Origin-Cookie . . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

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 4.4 for detail), separating them from non-
   origin cookies in a way a server can easily distinguish.



West                    Expires October 22, 2015                [Page 2]


Internet-Draft               Origin-Cookies                   April 2015


   Harmonizing with the same-origin policy mitigates the confidentiality
   and integrity risks noted above by ensuring that origin cookies are
   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; Secure; HttpOnly; 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;

   Subsequent requests from that user agent can be expected to contain
   the following header fields:

   Cookie: lang=en-US
   Origin-Cookie: SID=31d4d96e407aad42

   User agents that support origin cookies are required to advertise
   their support for such by sending an "Origin-Cookie" header whenever
   a "Cookie" header is sent.  That is, given the following server
   response:

   Set-Cookie: lang=en-US; Secure; HttpOnly

   Subsequent requests from a user agent that supports origin cookies
   can be expected to contain the following header fields:




West                    Expires October 22, 2015                [Page 3]


Internet-Draft               Origin-Cookies                   April 2015


   Cookie: lang=en-US
   Origin-Cookie:

   Note that the "Origin-Cookie" field is empty.

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

3.  Server Requirements

   This section describes extensions to [RFC6265] necessary to implement
   the server-side requirements of the "Origin" attribute.

3.1.  Grammar

   Add "Origin" 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 /
               origin-av / extension-av
   origin-av = "origin"

3.2.  Semantics of the "Origin" Attribute (Non-Normative)

   The "Origin" attribute limits the scope of the cookie such that it
   will only be attached to requests if those request match the origin
   which set the cookie.  For example, requests for
   "https://example.com/" will attach origin cookies if and only if
   those cookies were set by "https://example.com/".

   The changes to the "Cookie" header field suggested in Section 4.3
   provide additional detail.







West                    Expires October 22, 2015                [Page 4]


Internet-Draft               Origin-Cookies                   April 2015


3.3.  The <spanx style="verb">Origin-Cookie</spanx> header

3.3.1.  Syntax

   The user agent sends stored origin cookies to the origin server in
   the "Origin-Cookie" header.  If the server conforms to the
   requirements in Section 3 (and the user agent conforms to the
   requirements in Section 4), the user agent will send an "Origin-
   Cookie" header which conforms to the following grammar:

   origin-cookie-header = "Origin-Cookie:" OWS [ cookie-string ] OWS

3.3.2.  Semantics

   The semantics of the "cookie-string" are the same as those of the
   same token in the "Cookie" header.

   Note, however, that the "Origin-Cookie" header MAY be empty, and MUST
   be sent with every request, even if no origin cookies are present in
   the cookie store.  This allows conformant servers to detect a user
   agent's support for origin cookies, and therefore to make a secure
   decision about whether or not to fallback to searching through the
   "Cookie" header for specific cookies.  See Section 5.2 for details.

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

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

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



West                    Expires October 22, 2015                [Page 5]


Internet-Draft               Origin-Cookies                   April 2015


   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 "host-only-flag" to true.

           3.  Set the cookie's "origin" to the origin of "request-uri",
               as defined by Section 4 of [RFC6454].

           4.  Set the cookie's "origin-flag" to true.

           5.  Set the cookie's "path" attribute to the empty string.

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



West                    Expires October 22, 2015                [Page 6]


Internet-Draft               Origin-Cookies                   April 2015


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

4.4.  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, however, a "Cookie" header is sent, a
   user agent MUST send an "Origin-Cookie" header.

   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]

   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.




West                    Expires October 22, 2015                [Page 7]


Internet-Draft               Origin-Cookies                   April 2015


   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 ("; ").

5.  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:

5.1.  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.2.  Downgrade attacks

   If a server chooses to scan both the "Origin-Cookie" and "Cookie"
   headers in order to provide backwards compatibility with user agents
   that don't support origin cookies, it ought to be done carefully.
   Careless fallback strategies can provide a window of opportunity for
   an attacker to inject cookies with the same name as origin cookies
   from a subdomain, bypassing origin cookies' main advantage.

   o  If the "Origin-Cookie" header is present, servers SHOULD NOT check
      the "Cookie" header for cookies which it set as origin cookies.

   o  If a user agent is known to support origin cookies, servers SHOULD
      check only the "Origin-Cookie" header for origin cookies, and
      SHOULD NOT fallback to the "Cookie" header if the "Origin-Cookie"
      header is not present, or if a particular cookie is not found
      there.




West                    Expires October 22, 2015                [Page 8]


Internet-Draft               Origin-Cookies                   April 2015


6.  IANA Considerations

   The permanent message header field registry (see [RFC3864]) shall be
   updated with the following registration:

6.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 4.4)

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





West                    Expires October 22, 2015                [Page 9]


Internet-Draft               Origin-Cookies                   April 2015


   [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.  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
   Andrew Bortz, Adam Barth, and Alexei Czeskis' paper
   [origin-cookies-w2sp].

Author's Address

   Mike West
   Google, Inc

   Email: mkwst@google.com
   URI:   https://mikewest.org/
































West                    Expires October 22, 2015               [Page 10]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/