draft-ietf-httpstate-cookie-03.txt   draft-ietf-httpstate-cookie-04.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2109 (if approved) February 12, 2010 Obsoletes: 2109 (if approved) February 23, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: August 16, 2010 Expires: August 27, 2010
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-03 draft-ietf-httpstate-cookie-04
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie headers. These This document defines the HTTP Cookie and Set-Cookie headers. These
headers can be used by HTTP servers to store state on HTTP user headers can be used by HTTP servers to store state on HTTP user
agents, letting the servers maintain a stateful session over the agents, letting the servers maintain a stateful session over the
mostly stateless HTTP protocol. The cookie protocol has many mostly stateless HTTP protocol. The cookie protocol has many
historical infelicities and should be avoided for new applications of historical infelicities and should be avoided for new applications of
HTTP. HTTP.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2010. This Internet-Draft will expire on August 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General Nonsense . . . . . . . . . . . . . . . . . . . . . . . 5 2. General Nonsense . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 5 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. A Well-Behaved Profile . . . . . . . . . . . . . . . . . . . . 7 4. A Well-Behaved Profile . . . . . . . . . . . . . . . . . . . . 9
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 8 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 10
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 12
5. The Cookie Protocol . . . . . . . . . . . . . . . . . . . . . 11 5. The Cookie Protocol . . . . . . . . . . . . . . . . . . . . . 14
5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.2. Domains . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.2. Domains . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 14 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 17
5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 16 5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 19
5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 16 5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 19
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 17 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 20
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 17 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 20
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 18 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 21
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 18 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 21
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 21
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 21 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 24
6. Implementation Considerations . . . . . . . . . . . . . . . . 23 6. Implementation Considerations . . . . . . . . . . . . . . . . 26
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Application Programmer Interfaces . . . . . . . . . . . . 23 6.2. Application Programmer Interfaces . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. General Recommendations . . . . . . . . . . . . . . . . . 24 7.1. General Recommendations . . . . . . . . . . . . . . . . . 27
7.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 24 7.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 27
7.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 27
7.4. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 25 7.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 28
7.5. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 25 7.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 28
7.6. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 26 7.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 29
8. Normative References . . . . . . . . . . . . . . . . . . . . . 27 7.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header. Using This document defines the HTTP Cookie and Set-Cookie header. Using
the Set-Cookie header, an HTTP server can store name/value pairs and the Set-Cookie header, an HTTP server can store name/value pairs and
associated metadata (called cookies) at the user agent. When the associated metadata (called cookies) at the user agent. When the
user agent makes subsequent requests to the server, the user agent user agent makes subsequent requests to the server, the user agent
uses the metadata to determine whether to return the name/value pairs uses the metadata to determine whether to return the name/value pairs
in the Cookie header. in the Cookie header.
skipping to change at page 5, line 33 skipping to change at page 5, line 33
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), HTAB (horizontal tab), VCHAR (any sequence of data), SP (space), HTAB (horizontal tab), VCHAR (any
visible [USASCII] character), and WSP (whitespace). visible [USASCII] character), and WSP (whitespace).
2.3. Terminology 2.3. Terminology
The terms user agent, client, server, proxy, and origin server have The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification. the same meaning as in the HTTP/1.1 specification ([RFC2616]).
The terms request-host and request-URI refer to the values the user The terms request-host and request-URI refer to the values the user
agent would send to the server as, respectively, the host (but not agent would send to the server as, respectively, the host (but not
port) and abs_path portions of the absoluteURI (http_URL) of the HTTP port) and abs_path portions of the absoluteURI (http_URL) of the HTTP
Request-Line. Request-Line.
3. Overview 3. Overview
We outline here a way for an origin server to send state information We outline here a way for an origin server to send state information
to a user agent, and for the user agent to return the state to a user agent, and for the user agent to return the state
skipping to change at page 6, line 37 skipping to change at page 6, line 37
Servers MAY return a Set-Cookie response header with any response. Servers MAY return a Set-Cookie response header with any response.
User agents SHOULD send a Cookie request header, subject to other User agents SHOULD send a Cookie request header, subject to other
rules detailed below, with every request. rules detailed below, with every request.
An origin server MAY include multiple Set-Cookie header fields in a An origin server MAY include multiple Set-Cookie header fields in a
single response. Note that an intervening gateway MUST NOT fold single response. Note that an intervening gateway MUST NOT fold
multiple Set-Cookie header fields into a single header field. multiple Set-Cookie header fields into a single header field.
3.1. Examples 3.1. Examples
[TODO: Put some examples here. Using the cookie protocol, a server can send the user agent a short
string in an HTTP response that the user agent will return in future
HTTP requests. For example, the server can send the user agent a
"session identifier" named SID with the value 31d4d96e407aad42. The
user agent then returns the session identifier in subsequent
requests.
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
The server can alter the default scope of the cookie using the Path
and Domain attributes. For example, the server can instruct the user
agent to return the cookie to every path and every subdomain of
example.com.
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=.example.com
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
The server can store multiple cookies in the user agent. For
example, the server can store a session identifier as well as the
user's preferred language by returning two Set-Cookie response
headers. Notice that the server uses the Secure and HttpOnly
attributes to provide additional security protections for the more-
sensitive session identifier.
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure, HttpOnly
Set-Cookie: lang=en-US; Path=/; Domain=.example.com
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42; lang=en-US
If the server wishes the user agent to persist the cookie over
multiple sessions, the server can specify a expiration date in the
Expires attribute. Note that the user agent might might delete the
cookie before the expiration date if the user agent's cookie store
exceeds its quota or if the user manually deletes the server's
cookie.
== Server -> User Agent ==
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
== User Agent -> Server ==
Cookie: lang=en-US
Finally, to remove a cookie, the server returns a Set-Cookie header
with an expiration date in the past. The server will be successful
in removing the cookie only if the Path and the Domain attribute in
the Set-Cookie header match the values used when the cookie was
created.
== Server -> User Agent ==
Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT
== User Agent -> Server ==
(No Cookie header)
4. A Well-Behaved Profile 4. A Well-Behaved Profile
This section describes the syntax and semantics of a well-behaved This section describes the syntax and semantics of a well-behaved
profile of the protocol. Servers SHOULD use the profile described in profile of the protocol. Servers SHOULD use the profile described in
this section, both to maximize interoperability with existing user this section, both to maximize interoperability with existing user
agents and because a future version of the cookie protocol could agents and because a future version of the cookie protocol could
remove support for some of the most esoteric aspects of the protocol. remove support for some of the most esoteric aspects of the protocol.
User agents, however, MUST implement the full protocol to ensure User agents, however, MUST implement the full protocol to ensure
interoperability with servers making use of the full protocol. interoperability with servers making use of the full protocol.
skipping to change at page 10, line 6 skipping to change at page 12, line 6
many user agents does not isolate different paths within an origin. many user agents does not isolate different paths within an origin.
For example, /foo/bar.html can read cookies with a Path attribute of For example, /foo/bar.html can read cookies with a Path attribute of
"/baz" because they are within the "same origin". "/baz" because they are within the "same origin".
4.1.2.4. Secure 4.1.2.4. Secure
The Secure attribute limits the scope of the cookie to "secure" The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent). When a channels (where "secure" is defined by the user agent). When a
cookie has the Secure attribute, the user agent will include the cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over a cookie in an HTTP request only if the request is transmitted over a
secure channel (typically TLS [RFC5234]). secure channel (typically TLS [RFC5246]).
Although seemingly useful for protecting cookies from active network Although seemingly useful for protecting cookies from active network
attackers, the Secure attribute protects only the cookie's attackers, the Secure attribute protects only the cookie's
confidentiality. An active network attacker can overwrite Secure confidentiality. An active network attacker can overwrite Secure
cookies from an insecure channel, disrupting the integrity of the cookies from an insecure channel, disrupting the integrity of the
cookies. cookies.
4.1.2.5. HttpOnly 4.1.2.5. HttpOnly
The HttpOnly attribute limits the scope of the cookie to HTTP The HttpOnly attribute limits the scope of the cookie to HTTP
skipping to change at page 11, line 5 skipping to change at page 13, line 5
Notice that the cookie attributes are not returned. In particular, Notice that the cookie attributes are not returned. In particular,
the server cannot determine from the Cookie header alone when a the server cannot determine from the Cookie header alone when a
cookie will expire, for which domains the cookie is valid, for which cookie will expire, for which domains the cookie is valid, for which
paths the cookie is valid, or whether the cookie was set with the paths the cookie is valid, or whether the cookie was set with the
Secure or HttpOnly attributes. Secure or HttpOnly attributes.
The semantics of individual cookies in the Cookie header is not The semantics of individual cookies in the Cookie header is not
defined by this document. Servers are expected to imbue these defined by this document. Servers are expected to imbue these
cookies with server-specific semantics. cookies with server-specific semantics.
Although cookies are serialized linearly in the Cookie header,
servers SHOULD NOT rely upon the serialization order. In particular,
if the Cookie header contains two cookies with the same name, servers
SHOULD NOT rely upon the order in which these cookies appear in the
header.
5. The Cookie Protocol 5. The Cookie Protocol
For historical reasons, the full cookie protocol contains a number of For historical reasons, the full cookie protocol contains a number of
exotic quirks. This section is intended to specify the cookie exotic quirks. This section is intended to specify the cookie
protocol in enough detail to enable a user agent that implements the protocol in enough detail to enable a user agent that implements the
protocol precisely as specified to interoperate with existing protocol precisely as specified to interoperate with existing
servers. servers.
Conformance requirements phrased as algorithms or specific steps may Conformance requirements phrased as algorithms or specific steps may
be implemented in any manner, so long as the end result is be implemented in any manner, so long as the end result is
skipping to change at page 18, line 22 skipping to change at page 21, line 22
5.2.5. The Secure Attribute 5.2.5. The Secure Attribute
If the attribute-name case-insensitively matches the string "Secure", If the attribute-name case-insensitively matches the string "Secure",
the user agent MUST append an attribute to the cookie-attribute-list the user agent MUST append an attribute to the cookie-attribute-list
with an attribute-name of Secure and an empty attribute-value. with an attribute-name of Secure and an empty attribute-value.
5.2.6. The HttpOnly Attribute 5.2.6. The HttpOnly Attribute
If the attribute-name case-insensitively matches the string If the attribute-name case-insensitively matches the string
"HttpOnly", the user agent MUST append an attribute to the cookie- "HttpOnly", the user agent MUST append an attribute to the cookie-
attribute-list with an attribute-name of Secure and an empty attribute-list with an attribute-name of HttpOnly and an empty
attribute-value. attribute-value.
5.3. Storage Model 5.3. Storage Model
When the user agent receives a cookie, the user agent SHOULD record When the user agent receives a cookie, the user agent SHOULD record
the cookie in its cookie store as follows. the cookie in its cookie store as follows.
A user agent MAY ignore a received cookie in its entirety if the user A user agent MAY ignore a received cookie in its entirety if the user
agent is configured to block receiving cookies. For example, the agent is configured to block receiving cookies. For example, the
user agent might wish to block receiving cookies from "third-party" user agent might wish to block receiving cookies from "third-party"
skipping to change at page 24, line 14 skipping to change at page 27, line 14
7. Security Considerations 7. Security Considerations
7.1. General Recommendations 7.1. General Recommendations
The cookie protocol is NOT RECOMMENDED for new applications. The cookie protocol is NOT RECOMMENDED for new applications.
For applications that do use the cookie protocol, servers SHOULD NOT For applications that do use the cookie protocol, servers SHOULD NOT
rely upon cookies for security. rely upon cookies for security.
For servers that do use cookies for security, servers SHOULD use a
redundant form of authentication, such as HTTP authentication or TLS
client certificates.
7.2. Ambient Authority 7.2. Ambient Authority
A server that uses cookies to authenticate users can suffer security A server that uses cookies to authenticate users can suffer security
vulnerabilities because some user agents let remote parties issue vulnerabilities because some user agents let remote parties issue
HTTP requests from the user agent (e.g., via HTTP redirects and HTML HTTP requests from the user agent (e.g., via HTTP redirects and HTML
forms). When issuing those requests, user agent attaches cookies forms). When issuing those requests, user agent attaches cookies
even if the entity does not know the contents of the cookies, even if the entity does not know the contents of the cookies,
possibly letting the remote entity exercise authority at an unwary possibly letting the remote entity exercise authority at an unwary
server. User agents can mitigate this issue to some degree by server.
providing APIs for suppressing the Cookie header on outgoing
requests.
Although this security concern goes by a number of names (e.g., Although this security concern goes by a number of names (e.g.,
cross-site scripting and cross-site request forgery), the issue stems cross-site request forgery, confused deputy), the issue stems from
from cookies being a form of ambient authority. Cookies encourage cookies being a form of ambient authority. Cookies encourage server
server operators to separate designation (in the form of URLs) from operators to separate designation (in the form of URLs) from
authorization (in the form of cookies). Disentangling designation authorization (in the form of cookies). Consequently, the user agent
and authorization can cause the server and its clients to become might supply the authorization for a resource designated by the
confused deputies and undertake undesirable actions. attacker, possibly causing the server or its clients to undertake
actions designated by the attacker as though they were authorized by
the user.
Instead of using cookies for authorization, server operators might Instead of using cookies for authorization, server operators might
wish to consider entangling designation and authorization by treating wish to consider entangling designation and authorization by treating
URLs as object-capabilities. Instead of storing secrets in cookies, URLs as capabilities. Instead of storing secrets in cookies, this
this approach stores secrets in URLs, requiring the remote entity to approach stores secrets in URLs, requiring the remote entity to
supply the secret itself. ALthough this approach is not a panacea, supply the secret itself. Although this approach is not a panacea,
judicious use of these principles can lead to more robust security. judicious use of these principles can lead to more robust security.
7.3. Clear Text 7.3. Clear Text
Unless sent over a secure channel (such as TLS), the information in Unless sent over a secure channel (such as TLS), the information in
the Set-Cookie and Cookie headers is transmitted in the clear. the Set-Cookie and Cookie headers is transmitted in the clear.
1. All sensitive information conveyed in these headers is exposed to 1. All sensitive information conveyed in these headers is exposed to
an eavesdropper. an eavesdropper.
2. A malicious intermediary could alter the headers as they travel 2. A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results. in either direction, with unpredictable results.
3. A malicious client could alter the Cookie header before 3. A malicious client could alter the Cookie header before
transmission, with unpredictable results. transmission, with unpredictable results.
Servers SHOULD encrypt and sign their cookies when transmitting them Servers SHOULD encrypt and sign the contents of cookies when
to the user agent (even when sending the cookies over a secure transmitting them to the user agent (even when sending the cookies
channel). However, encrypting and signing cookies does not prevent over a secure channel). However, encrypting and signing cookie
an attacker from transplanting a cookie from one user agent to contents does not prevent an attacker from transplanting a cookie
another. from one user agent to another or from replaying the cookie at a
later time.
In addition to encrypting and signing the contents of every cookie, In addition to encrypting and signing the contents of every cookie,
servers that require a higher level of security SHOULD use the cookie servers that require a higher level of security SHOULD use the cookie
protocol only over a secure channel. protocol only over a secure channel. When using the cookie protocol
over a secure channel, servers SHOULD set the Secure attribute in
every cookie. If a server does not set the Secure attribute, the
protection provided by the secure channel will be largely moot.
7.4. Weak Confidentiality 7.4. Session Identifiers
Instead of storing session information directly in a cookie (where it
might be exposed to or replayed by an attacker), servers commonly
store a nonce (or "session identifier") in a cookie. When the server
receives an HTTP request with a nonce, the server can look up state
information associated with the cookie using the nonce as a key.
Using session identifier cookies limits the damage an attacker can
cause if the attacker learns the contents of a cookie because the
nonce is useful only for interacting with the server (unlike non-
nonce cookie content, which might itself be sensitive). Furthermore,
using a single nonce prevents an attacker from "splicing" together
cookie content from two interactions with the server, which could
cause the server to behave unexpectedly.
Using session identifiers is not without risk. For example, the
server SHOULD take care to avoid "session fixation" vulnerabilities.
A session fixation attack proceeds in three steps. First, the
attacker transplants a session identifier from his or her user agent
to the victim's user agent. Second, the victim uses that session
identifier to interact with the server, possibly imbuing the session
identifier with the user's credentials or confidential information.
Third, the attacker uses the session identifier to interact with
server directly, possibly obtaining the user's authority or
confidential information.
7.5. Weak Confidentiality
Cookies do not provide isolation by port. If a cookie is readable by Cookies do not provide isolation by port. If a cookie is readable by
a service running on one port, the cookie is also readable by a a service running on one port, the cookie is also readable by a
service running on another port of the same server. If a cookie is service running on another port of the same server. If a cookie is
writable by a service on one port, the cookie is also writable by a writable by a service on one port, the cookie is also writable by a
service running on another port of the same server. For this reason, service running on another port of the same server. For this reason,
servers SHOULD NOT both run mutually distrusting services on servers SHOULD NOT both run mutually distrusting services on
different ports of the same host and use cookies to store security- different ports of the same host and use cookies to store security-
sensitive information. sensitive information.
Cookies do not provide isolation by scheme. Although most commonly Cookies do not provide isolation by scheme. Although most commonly
used with the http and https schemes, the cookies for a given host used with the http and https schemes, the cookies for a given host
are also available to other schemes, such as ftp and gopher. This might also available to other schemes, such as ftp and gopher.
lack of isolation is most easily seen when a user agent retrieves a Although this lack of isolation by scheme is most apparent in via
URI with a gopher scheme via HTTP, but the lack of isolation by non-HTTP APIs that permit access to cookies (e.g., HTML's
scheme is also apparent via non-HTTP APIs that permit access to document.cookie API), the lack of isolation by scheme is actually
cookies, such as HTML's document.cookie API. present in the cookie protocol itself (e.g., consider retrieving a
URI with the gopher scheme via HTTP).
7.5. Weak Integrity Cookies do not always provide isolation by path. Although the
network-level protocol does not send cookie stored for one path to
another, some user agents expose cookies via non-HTTP APIs, such as
HTML's document.cookie API. Because some of these user agents (e.g.,
web browsers) do not isolate resources received from different paths,
a resource retrieved from one path might be able to access cookies
stored for another path.
7.6. Weak Integrity
Cookies do not provide integrity guarantees for sibling domains (and Cookies do not provide integrity guarantees for sibling domains (and
their subdomains). For example, consider foo.example.com and their subdomains). For example, consider foo.example.com and
bar.example.com. The foo.example.com server can set a cookie with a bar.example.com. The foo.example.com server can set a cookie with a
Domain attribute of ".example.com", and the user agent will include Domain attribute of ".example.com" (possibly overwriting an existing
that cookie in HTTP requests to bar.example.com. In the worst case, ".example.com" cookie set by bar.example.com), and the user agent
bar.example.com will be unable to distinguish this cookie from a will include that cookie in HTTP requests to bar.example.com. In the
cookie it set itself. The foo.example.com server might be able to worst case, bar.example.com will be unable to distinguish this cookie
leverage this ability to mount an attack against bar.example.com. from a cookie it set itself. The foo.example.com server might be
able to leverage this ability to mount an attack against
bar.example.com.
Similarly, an active network attacker can inject cookies into the Even though the cookie protocol supports the Path attribute, the Path
Cookie header sent to https://example.com/ by impersonating a attribute does not provide any integrity protection because the user
response from http://example.com/ and injecting a Set-Cookie header. agent with accept an arbitrary Path attribute in a Set-Cookie header.
The HTTPS server at example.com will be unable to distinguish these For example, an HTTP response to a request for
cookies from cookies that it set itself in an HTTPS response. An http://example.com/foo/bar can set a cookie with a Path attribute of
active network attacker might be able to leverage this ability to "/qux". Consequently, servers SHOULD NOT both run mutually
mount an attack against example.com even if example.com uses HTTPS distrusting services on different paths of the same host and use
cookies store security sensitive information.
An active network attacker can also inject cookies into the Cookie
header sent to https://example.com/ by impersonating a response from
http://example.com/ and injecting a Set-Cookie header. The HTTPS
server at example.com will be unable to distinguish these cookies
from cookies that it set itself in an HTTPS response. An active
network attacker might be able to leverage this ability to mount an
attack against example.com even if example.com uses HTTPS
exclusively. exclusively.
Servers can partially mitigate these attacks by encrypting and Servers can partially mitigate these attacks by encrypting and
signing their cookies. However, using cryptography does not mitigate signing the contents of their cookies. However, using cryptography
the issue completely because an attacker can replay a cookie he or does not mitigate the issue completely because an attacker can replay
she received from the authentic example.com server in the user's a cookie he or she received from the authentic example.com server in
session, with unpredictable results. the user's session, with unpredictable results.
7.6. Reliance on DNS Finally, an attacker might be able to force the user agent to delete
cookies by storing large number of cookies. Once the user agent
reaches its storage limit, the user agent will be forced to evict
some cookies. Servers SHOULD NOT rely upon user agents retaining
cookies.
7.7. Reliance on DNS
The cookie protocol relies upon the Domain Name System (DNS) for The cookie protocol relies upon the Domain Name System (DNS) for
security. If the DNS is partially or fully compromised, the cookie security. If the DNS is partially or fully compromised, the cookie
protocol might fail to provide the security properties required by protocol might fail to provide the security properties required by
applications. applications.
8. Normative References 8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
8.2. Informative References
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This document borrows heavily from RFC 2109. [TODO: Figure out the This document borrows heavily from RFC 2109 [RFC2109]. [TODO: Figure
proper way to credit the authors of RFC 2109.] out the proper way to credit the authors of RFC 2109.]
Author's Address Author's Address
Adam Barth Adam Barth
University of California, Berkeley University of California, Berkeley
Email: abarth@eecs.berkeley.edu Email: abarth@eecs.berkeley.edu
URI: http://www.adambarth.com/ URI: http://www.adambarth.com/
 End of changes. 26 change blocks. 
91 lines changed or deleted 221 lines changed or added

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