idnits 2.17.1 draft-ietf-httpstate-cookie-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC2109, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 18, 2010) is 5116 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'USASCII' is mentioned on line 174, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2109 (Obsoleted by RFC 2965) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpstate A. Barth 3 Internet-Draft U.C. Berkeley 4 Obsoletes: 2109 (if approved) April 18, 2010 5 Intended status: Standards Track 6 Expires: October 20, 2010 8 HTTP State Management Mechanism 9 draft-ietf-httpstate-cookie-07 11 Abstract 13 This document defines the HTTP Cookie and Set-Cookie headers. These 14 headers can be used by HTTP servers to store state (called cookies) 15 at HTTP user agents, letting the servers maintain a stateful session 16 over the mostly stateless HTTP protocol. Although cookies have many 17 historical infelicities that degrade their security and privacy, the 18 Cookie and Set-Cookie headers are widely used on the Internet. 20 Editorial Note (To be removed by RFC Editor) 22 If you have suggestions for improving this document, please send 23 email to http-state@ietf.org. Suggestions with test cases are 24 especially appreciated. https://tools.ietf.org/wg/httpstate/ 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on October 20, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2. General Nonsense . . . . . . . . . . . . . . . . . . . . . . . 6 80 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 6 81 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 82 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 83 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 10 86 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 10 87 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 88 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11 89 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 14 92 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 15 93 5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 15 94 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 15 95 5.1.2. Domains . . . . . . . . . . . . . . . . . . . . . . . 17 96 5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 17 97 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 18 98 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 20 99 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 20 100 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 21 101 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 21 102 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 22 103 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 22 104 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 22 105 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 25 106 6. Implementation Considerations . . . . . . . . . . . . . . . . 28 107 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 6.2. Application Programmer Interfaces . . . . . . . . . . . . 28 109 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 29 110 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 29 111 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 29 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 113 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 31 114 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 31 115 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 32 116 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 32 117 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 33 118 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 33 119 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 34 120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 121 9.1. Normative References . . . . . . . . . . . . . . . . . . . 35 122 9.2. Informative References . . . . . . . . . . . . . . . . . . 35 123 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36 124 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 126 1. Introduction 128 This document defines the HTTP Cookie and Set-Cookie headers. Using 129 the Set-Cookie header, an HTTP server can store name/value pairs and 130 associated metadata (called cookies) at the user agent. When the 131 user agent makes subsequent requests to the server, the user agent 132 uses the metadata to determine whether to return the name/value pairs 133 in the Cookie header. 135 Although simple on its surface, cookies have a number of 136 complexities. For example, the server indicates a scope for each 137 cookie when sending them to the user agent. The scope indicates the 138 maximum amount of time the user agent should retain the cookie, to 139 which servers the user agent should return the cookie, and for which 140 protocols the cookie is applicable. 142 For historical reasons, cookies contain a number of security and 143 privacy infelicities. For example, a server can indicate that a 144 given cookie is intended for "secure" connections, but the Secure 145 attribute provides only confidentiality (not integrity) from active 146 network attackers. Similarly, cookies for a given host are shared 147 across all the ports on that host, even though the usual "same-origin 148 policy" used by web browsers isolates content retrieved from 149 different ports. 151 2. General Nonsense 153 2.1. Conformance Criteria 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 156 "RECOMMENDED", "MAY", and "OPTIONAL" in document are to be 157 interpreted as described in [RFC2119]. 159 Requirements phrased in the imperative as part of algorithms (such as 160 "strip any leading space characters" or "return false and abort these 161 steps") are to be interpreted with the meaning of the key word 162 ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. 164 2.2. Syntax Notation 166 This specification uses the Augmented Backus-Naur Form (ABNF) 167 notation of [RFC5234]. 169 The following core rules are included by reference, as defined in 170 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 171 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 172 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 173 sequence of data), SP (space), HTAB (horizontal tab), VCHAR (any 174 visible [USASCII] character), and WSP (whitespace). 176 The OWS (optional whitespace) rule is used where zero or more linear 177 whitespace characters may appear. OWS SHOULD either not be produced 178 or be produced as a single SP character. Multiple OWS characters 179 that occur within field-content SHOULD be replaced with a single SP 180 before interpreting the field value or forwarding the message 181 downstream. 183 2.3. Terminology 185 The terms user agent, client, server, proxy, and origin server have 186 the same meaning as in the HTTP/1.1 specification ([RFC2616]). 188 The terms request-host and request-URI refer to the values the user 189 agent would send to the server as, respectively, the host (but not 190 port) and abs_path portions of the absoluteURI (http_URL) of the HTTP 191 Request-Line. 193 3. Overview 195 We outline here a way for an origin server to send state information 196 to a user agent and for the user agent to return the state 197 information to the origin server. 199 To store state, the origin server includes a Set-Cookie header in an 200 HTTP response. In subsequent requests, the user agent returns a 201 Cookie request header to the origin server. The Cookie header 202 contains a number of cookies the user agent received in previous Set- 203 Cookie headers. The origin server is free to ignore the Cookie 204 header or use its contents for an application-defined purpose. The 205 origin server MAY send the user agent a Set-Cookie response header 206 with the same or different information, or it MAY send no Set-Cookie 207 header at all. 209 Servers MAY return a Set-Cookie response header with any response. 210 User agents SHOULD send a Cookie request header, subject to other 211 rules detailed below, with every request. 213 An origin server MAY include multiple Set-Cookie header fields in a 214 single response. Note that an intervening gateway MUST NOT fold 215 multiple Set-Cookie header fields into a single header field. 217 If a server sends multiple responses containing Set-Cookie headers 218 concurrently to the user agent (e.g., when communicating with the 219 user agent over multiple sockets), these responses create a "race 220 condition" that can lead to unpredictable behavior. 222 3.1. Examples 224 Using the Set-Cookie header, a server can send the user agent a short 225 string in an HTTP response that the user agent will return in future 226 HTTP requests. For example, the server can send the user agent a 227 "session identifier" named SID with the value 31d4d96e407aad42. The 228 user agent then returns the session identifier in subsequent 229 requests. 231 == Server -> User Agent == 232 Set-Cookie: SID=31d4d96e407aad42 234 == User Agent -> Server == 235 Cookie: SID=31d4d96e407aad42 237 The server can alter the default scope of the cookie using the Path 238 and Domain attributes. For example, the server can instruct the user 239 agent to return the cookie to every path and every subdomain of 240 example.com. 242 == Server -> User Agent == 243 Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=.example.com 245 == User Agent -> Server == 246 Cookie: SID=31d4d96e407aad42 248 The server can store multiple cookies at the user agent. For 249 example, the server can store a session identifier as well as the 250 user's preferred language by returning two Set-Cookie header fields. 251 Notice that the server uses the Secure and HttpOnly attributes to 252 provide additional security protections for the more-sensitive 253 session identifier. 255 == Server -> User Agent == 256 Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly 257 Set-Cookie: lang=en-US; Path=/; Domain=.example.com 259 == User Agent -> Server == 260 Cookie: SID=31d4d96e407aad42; lang=en-US 262 If the server wishes the user agent to persist the cookie over 263 multiple sessions, the server can specify a expiration date in the 264 Expires attribute. Note that the user agent might delete the cookie 265 before the expiration date if the user agent's cookie store exceeds 266 its quota or if the user manually deletes the server's cookie. 268 == Server -> User Agent == 269 Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT 271 == User Agent -> Server == 272 Cookie: lang=en-US 274 Finally, to remove a cookie, the server returns a Set-Cookie header 275 with an expiration date in the past. The server will be successful 276 in removing the cookie only if the Path and the Domain attribute in 277 the Set-Cookie header match the values used when the cookie was 278 created. 280 == Server -> User Agent == 281 Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT 283 == User Agent -> Server == 284 (No Cookie header) 286 4. Server Requirements 288 This section describes the syntax and semantics of a well-behaved 289 profile of the Cookie and Set-Cookie headers. Servers SHOULD use the 290 profile described in this section, both to maximize interoperability 291 with existing user agents and because a future version of the Cookie 292 or Set-Cookie headers could remove support for some of the most 293 esoteric semantics. User agents, however, MUST implement the full 294 semantics to ensure interoperability with servers making use of the 295 full semantics. 297 4.1. Set-Cookie 299 The Set-Cookie header is used to send cookies from the server to the 300 user agent. 302 4.1.1. Syntax 304 Informally, the Set-Cookie response header comprises the token Set- 305 Cookie:, followed by a cookie. Each cookie begins with a name-value- 306 pair, followed by zero or more attribute-value pairs. Servers SHOULD 307 NOT send Set-Cookie headers that fail to conform to the following 308 grammar: 310 set-cookie-header = "Set-Cookie:" OWS set-cookie-string OWS 311 set-cookie-string = cookie-pair *( ";" cookie-av ) 312 cookie-pair = cookie-name "=" cookie-value 313 cookie-name = token 314 cookie-value = token 315 token = 317 cookie-av = expires-av / max-age-av / domain-av / 318 path-av / secure-av / httponly-av 319 expires-av = "Expires" "=" sane-cookie-date 320 sane-cookie-date = 321 max-age-av = "Max-Age" "=" 1*DIGIT 322 domain-av = "Domain" "=" domain-value 323 domain-value = token 324 path-av = "Path" "=" path-value 325 path-value = 326 secure-av = "Secure" 327 httponly-av = "HttpOnly" 329 Servers SHOULD NOT include two attributes with the same name. 331 Servers SHOULD NOT include two Set-Cookie header fields in the same 332 response with the same cookie-name. 334 The cookie-value is opaque to the user agent and MAY be anything the 335 origin server chooses to send. "Opaque" implies that the content is 336 of interest and relevance only to the origin server. The content is, 337 in fact, readable by anyone who examines the Set-Cookie header. 339 To maximize compatibility with user agents, servers that wish to 340 store non-ASCII data in a cookie-value SHOULD encode that data using 341 a printable ASCII encoding, such as base64. 343 NOTE: Some user agents represent dates using 32-bit integers. Some 344 of these user agents might contain bugs that cause them process dates 345 after the year 2038 incorrectly. Servers wishing to interoperate 346 with these user agents might wish to use dates before 2038. 348 NOTE: The syntax above allows whitespace around the U+003D ("=") 349 characters. Servers wishing to interoperate with some legacy user 350 agents might wish to omit this whitespace. 352 4.1.2. Semantics (Non-Normative) 354 This section describes a simplified semantics of the Set-Cookie 355 header. These semantics are detailed enough to be useful for 356 understanding the most common uses of cookies. The full semantics 357 are described in Section 5. 359 When the user agent receives a Set-Cookie header, the user agent 360 stores the cookie in its cookie store. Subsequently, when the user 361 agent makes an HTTP request, the user agent consults its cookie store 362 and includes the applicable, non-expired cookies in the Cookie 363 header. 365 If the user agent receives a new cookie with the same cookie-name, 366 domain-value, and path-value as a cookie that already exists in its 367 cookie store, the existing cookie is evicted from the cookie store 368 and replaced with the new cookie. Notice that servers can delete 369 cookies by sending the user agent a new cookie with an Expires 370 attribute with a value in the past. 372 Unless the cookie's attributes indicate otherwise, the cookie is 373 returned only to the origin server, and it expires at the end of the 374 current session (as defined by the user agent). User agents ignore 375 unrecognized cookie attributes. 377 4.1.2.1. The Expires Attribute 379 The Expires attribute indicates the maximum lifetime of the cookie, 380 represented as the date and time at which the cookie expires. The 381 user agent is not required to retain the cookie until the specified 382 date has passed. In fact, user agents often evict cookies from the 383 cookie store due to memory pressure or privacy concerns. 385 4.1.2.2. The Max-Age Attribute 387 The Max-Age attribute indicates the maximum lifetime of the cookie, 388 represented as the number of seconds until the cookie expires. The 389 user agent is not required to retain the cookie until the specified 390 date has passed. In fact, user agents often evict cookies from the 391 cookie store due to memory pressure or privacy concerns. 393 WARNING: Not all user agents support the Max-Age attribute. User 394 agents that do not support the Max-Age attribute will retain the 395 cookie for the current session only. 397 If a cookie has both the Max-Age and the Expires attribute, the Max- 398 Age attribute has precedence and controls the expiration date of the 399 cookie. 401 4.1.2.3. The Domain Attribute 403 The Domain attribute specifies those hosts to which the cookie will 404 be sent. For example, if the Domain attribute contains the value 405 "example.com", the user agent will include the cookie in the Cookie 406 header when making HTTP requests to example.com, www.example.com, and 407 www.corp.example.com. (Note that a leading U+002E ("."), if present, 408 is ignored.) If the server omits the Domain attribute, the user 409 agent will return the cookie only to the origin server. 411 WARNING: Some legacy user agents treat an absent Domain attribute 412 as if the Domain attribute were present and contained the current 413 host name. For example, if example.com returns a Set-Cookie 414 header without a Domain attribute, these user agents will 415 erroneously send the cookie to www.example.com. 417 The user agent will reject cookies (refuse to store them in the 418 cookie store) unless the Domain attribute specifies a scope for the 419 cookie that would include the origin server. For example, the user 420 agent will accept a Domain attribute of "example.com" or of 421 "foo.example.com" from foo.example.com, but the user agent will not 422 accept a Domain attribute of "bar.example.com" or of 423 "baz.foo.example.com". 425 NOTE: For security reasons, some user agents are configured to reject 426 Domain attributes that correspond to "public suffixes." For example, 427 some user agents will reject Domain attributes of "com" or "co.uk". 429 4.1.2.4. The Path Attribute 431 The Path attribute limits the scope of the cookie to a set of paths. 432 When a cookie has a Path attribute, the user agent will include the 433 cookie in an HTTP request only if the path portion of the Request-URI 434 matches (or is a subdirectory of) the cookie's Path attribute, where 435 the U+002F ("/") character is interpreted as a directory separator. 436 If the server omits the Path attribute, the user agent will use the 437 directory of the Request-URI's path component as the default value. 439 Although seemingly useful for isolating cookies between different 440 paths within a given domain, the Path attribute cannot be relied upon 441 for security for two reasons: 443 1. User agents do not prevent one path from overwriting the cookies 444 for another path. For example, if a response to a request for 445 /foo/bar.html attempts to set a cookie with a Path attribute of 446 "/baz" the user agent will store that cookie in the cookie store. 448 2. The "same-origin" policy implemented by many user agents does not 449 isolate different paths within an origin. For example, /foo/ 450 bar.html can read cookies with a Path attribute of "/baz" because 451 they are within the "same origin". 453 4.1.2.5. The Secure Attribute 455 The Secure attribute limits the scope of the cookie to "secure" 456 channels (where "secure" is defined by the user agent). When a 457 cookie has the Secure attribute, the user agent will include the 458 cookie in an HTTP request only if the request is transmitted over a 459 secure channel (typically TLS [RFC5246]). 461 Although seemingly useful for protecting cookies from active network 462 attackers, the Secure attribute protects only the cookie's 463 confidentiality. An active network attacker can overwrite Secure 464 cookies from an insecure channel, disrupting its integrity. 466 4.1.2.6. The HttpOnly Attribute 468 The HttpOnly attribute limits the scope of the cookie to HTTP 469 requests. In particular, the attribute instructs the user agent to 470 omit the cookie when providing access to its cookie store via "non- 471 HTTP" APIs (as defined by the user agent). 473 4.2. Cookie 475 4.2.1. Syntax 477 The user agent returns stored cookies to the origin server in the 478 Cookie header. If the server conforms to the requirements in this 479 section, the requirements in the next section will cause the user 480 agent to return a Cookie header that conforms to the following 481 grammar: 483 cookie-header = "Cookie:" OWS cookie-string OWS 484 cookie-string = cookie-pair *( ";" cookie-pair ) 486 4.2.2. Semantics 488 Each cookie-pair represents a cookie stored by the user agent. The 489 cookie-name and the cookie-value are returned from the corresponding 490 parts of the Set-Cookie header. 492 Notice that the cookie attributes are not returned. In particular, 493 the server cannot determine from the Cookie header alone when a 494 cookie will expire, for which domains the cookie is valid, for which 495 paths the cookie is valid, or whether the cookie was set with the 496 Secure or HttpOnly attributes. 498 The semantics of individual cookies in the Cookie header is not 499 defined by this document. Servers are expected to imbue these 500 cookies with application-specific semantics. 502 Although cookies are serialized linearly in the Cookie header, 503 servers SHOULD NOT rely upon the serialization order. In particular, 504 if the Cookie header contains two cookies with the same name, servers 505 SHOULD NOT rely upon the order in which these cookies appear in the 506 header. 508 5. User Agent Requirements 510 For historical reasons, the full semantics of cookies contains a 511 number of exotic quirks. This section is intended to specify the 512 Cookie and Set-Cookie headers in sufficient detail to allow a user 513 agent implementing these requirements precisely to interoperate with 514 existing servers. 516 Conformance requirements phrased as algorithms or specific steps MAY 517 be implemented in any manner, so long as the end result is 518 equivalent. In particular, the algorithms defined in this 519 specification are intended to be easy to understand and are not 520 intended to be performant. 522 5.1. Algorithms 524 This section defines a number of algorithms used by user agents to 525 process the Cookie and Set-Cookie headers. 527 5.1.1. Dates 529 The user agent MUST use the following algorithm to *parse a cookie- 530 date*: 532 1. Using the grammar below, divide the cookie-date into date-tokens. 534 cookie-date = *delimiter date-token-list *delimiter 535 date-token-list = date-token *( 1*delimiter date-token ) 536 delimiter = %x09 / %x20 / %x21 / %x22 / %x23 / %x24 / 537 %x25 / %x26 / %x27 / %x28 / %x29 / %x2A / 538 %x2B / %x2C / %x2D / %x2E / %x2F / %x3B / 539 %x3C / %x3D / %x3E / %x3F / %x40 / %x5B / 540 %x5C / %x5D / %x5E / %x5F / %x60 / %x7B / 541 %x7C / %x7D / %x7E 542 date-token = day-of-month / month / year / time / mystery 543 day-of-month = 2DIGIT / DIGIT 544 month = "jan" [ mystery ] / "feb" [ mystery ] / 545 "mar" [ mystery ] / "apr" [ mystery ] / 546 "may" [ mystery ] / "jun" [ mystery ] / 547 "jul" [ mystery ] / "aug" [ mystery ] / 548 "sep" [ mystery ] / "oct" [ mystery ] / 549 "nov" [ mystery ] / "dec" [ mystery ] 550 year = 5DIGIT / 4DIGIT / 3DIGIT / 2DIGIT / DIGIT 551 time = time-field ":" time-field ":" time-field 552 time-field = 2DIGIT / DIGIT 553 mystery = 554 2. Process each date-token sequentially in the order the date-tokens 555 appear in the cookie-date: 557 1. If the found-day-of-month flag is not set and the date-token 558 matches the day-of-month production, set the found-day-of- 559 month flag and set the day-of-month-value to the number 560 denoted by the date-token. Skip the remaining sub-steps and 561 continue to the next date-token. 563 2. If the found-month flag is not set and the date-token matches 564 the month production, set the found-month flag and set the 565 month-value to the month denoted by the date-token. Skip the 566 remaining sub-steps and continue to the next date-token. 568 3. If the found-year flag is not set and the date-token matches 569 the year production, set the found-year flag and set the 570 year-value to the number denoted by the date-token. Skip the 571 remaining sub-steps and continue to the next date-token. 573 4. If the found-time flag is not set and the token matches the 574 time production, set the found-time flag and set the hour- 575 value, minute-value, and second-value to the numbers denoted 576 by the digits in the date-token, respectively. Skip the 577 remaining sub-steps and continue to the next date-token. 579 3. Abort these steps and *fail to parse* if 581 * at least one of the found-day-of-month, found-month, found- 582 year, or found-time flags is not set, 584 * the day-of-month-value is less than 1 or greater than 31, 586 * the year-value is less than 1601 or greater than 30827, 588 * the hour-value is greater than 23, 590 * the minute-value is greater than 59, or 592 * the second-value is greater than 59. 594 4. If the year-value is greater than 68 and less than 100, increment 595 the year-value by 1900. 597 5. If the year-value is greater than or equal to 0 and less than 69, 598 increment the year-value by 2000. 600 6. Let the parsed-cookie-date be the date whose day-of-month, month, 601 year, hour, minute, and second (in GMT) are the day-of-month- 602 value, the month-value, the year-value, the hour-value, the 603 minute-value, and the second-value, respectively. 605 7. Return the parsed-cookie-date as the result of this algorithm. 607 5.1.2. Domains 609 A *canonicalized* host-name is the host-name converted to lower case 610 and expressed in punycode [RFC3492]. 612 A request-host *domain-matches* a cookie-domain if at least one of 613 the following conditions hold: 615 o The cookie-domain and the canonicalized request-host are 616 identical. 618 o All of the following conditions hold: 620 * The cookie-domain is a suffix of the canonicalized request- 621 host. 623 * The last character of the canonicalized request-host that is 624 not included in the cookie-domain is a U+002E (".") character. 626 * The request-host is a host name (i.e., not an IP address). 628 5.1.3. Paths 630 The user agent MUST use the following algorithm to compute the 631 *default-path* of a cookie: 633 1. Let uri-path be the path portion of the Request-URI. 635 2. If the first character of the uri-path is not a U+002F ("/") 636 character, output U+002F ("/") and skip the remaining steps. 638 3. If the uri-path contains only a single U+002F ("/") character, 639 output U+002F ("/") and skip the remaining steps. 641 4. Output the characters of the uri-path from the first character up 642 to, but not including, the right-most U+002F ("/"). 644 A request-path *path-matches* a cookie-path if at least one of the 645 following conditions hold: 647 o The cookie-path and the request-path are identical. 649 o The cookie-path is a prefix of the request-path and the last 650 character of the cookie-path is U+002F ("/"). 652 o The cookie-path is a prefix of the request-path and the first 653 character of the request-path that is not included in the cookie- 654 path is a U+002F ("/") character. 656 5.2. The Set-Cookie Header 658 When a user agent receives a Set-Cookie header in an HTTP response, 659 the user agent *receives a set-cookie-string* consisting of the value 660 of the header. 662 A user agent MUST use the following algorithm to parse set-cookie- 663 strings: 665 1. If the set-cookie-string is empty or consists entirely of WSP 666 characters, ignore the set-cookie-string entirely. 668 2. If the set-cookie-string contains a U+003B (";") character: 670 The name-value-pair string consists of the characters up to, 671 but not including, the first U+003B (";"), and the unparsed- 672 attributes consist of the remainder of the set-cookie-string 673 (including the U+003B (";") in question). 675 Otherwise: 677 The name-value-pair string consists of all the characters 678 contained in the set-cookie-string, and the unparsed- 679 attributes is the empty string. 681 3. If the name-value-pair string lacks a U+003D ("=") character, 682 ignore the set-cookie-string entirely. 684 4. If the first character of the name-value-pair string is U+003D 685 ("="), ignore the set-cookie-string entirely. 687 5. The (necessarily non-empty) name string consists of the 688 characters up to, but not including, the first U+003D ("=") 689 character, and the (possibly empty) value string consists of the 690 characters after the first U+003D ("=") character. 692 6. Remove any leading or trailing WSP characters from the name 693 string and the value string. 695 7. The cookie-name is the name string, and the cookie-value is the 696 value string. 698 The user agent MUST use the following algorithm to parse the 699 unparsed-attributes: 701 1. If the unparsed-attributes string is empty, skip the rest of 702 these steps. 704 2. Consume the first character of the unparsed-attributes (which 705 will be a U+003B (";") character). 707 3. If the remaining unparsed-attributes contains a U+003B (";") 708 character: 710 Consume the characters of the unparsed-attributes up to, but 711 not including, the first U+003B (";") character. 713 Otherwise: 715 Consume the remainder of the unparsed-attributes. 717 Let the cookie-av string be the characters consumed in this step. 719 4. If the cookie-av string contains a U+003D ("=") character: 721 The (possibly empty) attribute-name string consists of the 722 characters up to, but not including, the first U+003D ("=") 723 character, and the (possibly empty) attribute-value string 724 consists of the characters after the first U+003D ("=") 725 character. 727 Otherwise: 729 The attribute-name string consists of the entire cookie-av 730 string, and the attribute-value string is empty. 732 5. Remove any leading or trailing WSP characters from the attribute- 733 name string and the attribute-value string. 735 6. Process the attribute-name and attribute-value according to the 736 requirements in the following subsections. 738 7. Return to Step 1. 740 When the user agent finishes parsing the set-cookie-string, the user 741 agent *receives a cookie* from the Request-URI with name cookie-name, 742 value cookie-value, and attributes cookie-attribute-list. 744 5.2.1. The Expires Attribute 746 If the attribute-name case-insensitively matches the string 747 "Expires", the user agent MUST process the cookie-av as follows. 749 Let the parsed-cookie-date be the result of parsing the attribute- 750 value as cookie-date. 752 If the attribute-value failed to parse as a cookie date, ignore the 753 cookie-av. 755 If the user agent received the set-cookie-string from an HTTP 756 response that contains a Date header field and the contents of the 757 last Date header field successfully parse as a cookie-date: 759 Let server-date be the date obtained by parsing the contents of 760 the last Date header field as a cookie-date. 762 Let delta-seconds be the number of seconds between the server-date 763 and the parsed-cookie-date (i.e., parsed-cookie-date - server- 764 date). 766 Let the expiry-time be the current date and time plus delta- 767 seconds seconds. 769 Otherwise: 771 Let the expiry-time be the parsed-cookie-date. 773 If the expiry-time is later than the last date the user agent can 774 represent, the user agent MAY replace the expiry-time with the last 775 representable date. 777 If the expiry-time is earlier than the first date the user agent can 778 represent, the user agent MAY replace the expiry-time with the first 779 representable date. 781 Append an attribute to the cookie-attribute-list with an attribute- 782 name of Expires and an attribute-value of expiry-time. 784 5.2.2. The Max-Age Attribute 786 If the attribute-name case-insensitively matches the string "Max- 787 Age", the user agent MUST process the cookie-av as follows. 789 If the first character of the attribute-value is not a DIGIT or a "-" 790 character, ignore the cookie-av. 792 If the remainder of attribute-value contains a non-DIGIT character, 793 ignore the cookie-av. 795 Let delta-seconds be the attribute-value converted to an integer. 797 If delta-seconds is less than or equal to zero (0), let expiry-time 798 be the earliest representable date and time. Otherwise, let the 799 expiry-time be the current date and time plus delta-seconds seconds. 801 Append an attribute to the cookie-attribute-list with an attribute- 802 name of Max-Age and an attribute-value of expiry-time. 804 5.2.3. The Domain Attribute 806 If the attribute-name case-insensitively matches the string "Domain", 807 the user agent MUST process the cookie-av as follows. 809 If the attribute-value is empty, the behavior is undefined. However, 810 user agent SHOULD ignore the cookie-av entirely. 812 If the first character of the attribute-value string is U+002E ("."): 814 Let cookie-domain be the attribute-value without the leading 815 U+002E (".") character. 817 Otherwise: 819 Let cookie-domain be the entire attribute-value. 821 Convert the cookie-domain to lower case. 823 Append an attribute to the cookie-attribute-list with an attribute- 824 name of Domain and an attribute-value of cookie-domain. 826 5.2.4. The Path Attribute 828 If the attribute-name case-insensitively matches the string "Path", 829 the user agent MUST process the cookie-av as follows. 831 If the attribute-value is empty or if the first character of the 832 attribute-value is not U+002F ("/"): 834 Let cookie-path be the default-path. 836 Otherwise: 838 Let cookie-path be the attribute-value. 840 Append an attribute to the cookie-attribute-list with an attribute- 841 name of Path and an attribute-value of cookie-path. 843 5.2.5. The Secure Attribute 845 If the attribute-name case-insensitively matches the string "Secure", 846 the user agent MUST append an attribute to the cookie-attribute-list 847 with an attribute-name of Secure and an empty attribute-value. 849 5.2.6. The HttpOnly Attribute 851 If the attribute-name case-insensitively matches the string 852 "HttpOnly", the user agent MUST append an attribute to the cookie- 853 attribute-list with an attribute-name of HttpOnly and an empty 854 attribute-value. 856 5.3. Storage Model 858 The user agent stores the following fields about each cookie: name, 859 value, expiry-time, domain, path, creation-time, last-access-time, 860 persistent-flag, host-only-flag, secure-only-flag, and http-only- 861 flag. 863 When the user agent *receives a cookie* from a Request-URI with name 864 cookie-name, value cookie-value, and attributes cookie-attribute- 865 list, the user agent MUST process the cookie as follows: 867 1. A user agent MAY ignore a received cookie in its entirety. For 868 example, the user agent might wish to block receiving cookies 869 from "third-party" responses. 871 2. Create a new cookie with name cookie-name, value cookie-value. 872 Set the creation-time and the last-access-time to the current 873 date and time. 875 3. If the cookie-attribute-list contains an attribute with an 876 attribute-name of "Max-Age": 878 Set the cookie's persistent-flag to true. 880 Set the cookie's expiry-time to attribute-value of the last 881 attribute in the cookie-attribute-list with an attribute-name 882 of "Max-Age". 884 Otherwise, if the cookie-attribute-list contains an attribute 885 with an attribute-name of "Expires" (and does not contain an 886 attribute with an attribute-name of "Max-Age"): 888 Set the cookie's persistent-flag to true. 890 Set the cookie's expiry-time to attribute-value of the last 891 attribute in the cookie-attribute-list with an attribute-name 892 of "Expires". 894 Otherwise: 896 Set the cookie's persistent-flag to false. 898 Set the cookie's expiry-time to the latest representable 899 date. 901 4. If the cookie-attribute-list contains an attribute with an 902 attribute-name of "Domain": 904 Let the domain-attribute be the attribute-value of the last 905 attribute in the cookie-attribute-list with an attribute-name 906 of "Domain". 908 Otherwise: 910 Let the domain-attribute be the empty string. 912 5. If the user agent is configured to use a "public suffix" list 913 and the domain-attribute is a public suffix: 915 If the domain-attribute is identical to the canonicalized 916 Request-URI's host: 918 Let the domain-attribute be the empty string. 920 Otherwise: 922 Ignore the cookie entirely and abort these steps 924 NOTE: A "public suffix" is a domain that is controlled by a 925 public registry, such as "com", "co.uk", and "pvt.k12.wy.us". 926 This step is essential for preventing attacker.com from 927 disrupting the integrity of example.com by setting a cookie 928 with a Domain attribute of "com". Unfortunately, the set of 929 public suffixes (also known as "registry controlled domains") 930 changes over time. If feasible, user agents SHOULD use an 931 up-to-date public suffix list, such as the one maintained by 932 the Mozilla project at http://publicsuffix.org/. 934 6. If the domain-attribute is non-empty: 936 If the Request-URI's host does not domain-match the domain- 937 attribute, ignore the cookie entirely and abort these steps. 939 Set the cookie's host-only-flag to false. 941 Set the cookie's domain to the domain-attribute. 943 Otherwise: 945 Set the cookie's host-only-flag to true. 947 Set the cookie's domain to the canonicalized host of the 948 Request-URI. 950 7. If the cookie-attribute-list contains an attribute with an 951 attribute-name of "Path", set the cookie's path to attribute- 952 value of the last attribute in the cookie-attribute-list with an 953 attribute-name of "Path". Otherwise, set cookie's path to the 954 default-path of the Request-URI. 956 8. If the cookie-attribute-list contains an attribute with an 957 attribute-name of "Secure", set the cookie's secure-only-flag to 958 true. Otherwise, set cookie's secure-only-flag to false. 960 9. If the cookie-attribute-list contains an attribute with an 961 attribute-name of "HttpOnly", set the cookie's http-only-flag to 962 true. Otherwise, set cookie's http-only-flag to false. 964 10. If the cookie's name and value are both empty, abort these steps 965 and ignore the cookie entirely. 967 11. If the cookie was received from a non-HTTP API and the cookie's 968 http-only-flag is set, abort these steps and ignore the cookie 969 entirely. 971 12. If the cookie store contains a cookie with the same name, 972 domain, and path as the newly created cookie: 974 1. Let old-cookie be the existing cookie with the same name, 975 domain, and path as the newly created cookie. (Notice that 976 this algorithm maintains the invariant that there is at most 977 one such cookie.) 979 2. If the newly created cookie was received from an non-HTTP 980 API and the old-cookie's host-only-flag is set, abort these 981 steps and ignore the newly created cookie entirely. 983 3. Update the creation-time of the newly created cookie to 984 match the creation-time of the old-cookie. 986 4. Remove the old-cookie from the cookie store. 988 13. Insert the newly created cookie into the cookie store. 990 The user agent MUST evict a cookie from the cookie store if, at any 991 time, a cookie exists in the cookie store with an expiry date in the 992 past. 994 The user agent MAY evict a cookie from the cookie store if the number 995 of cookies sharing a domain field exceeds some predetermined upper 996 bound (such as 50 cookies). 998 The user agent MAY evict a cookie from the cookie store if the cookie 999 store exceeds some predetermined upper bound (such as 3000 cookies). 1001 When the user agent evicts a cookie from the cookie store, the user 1002 agent MUST evict cookies in the following priority order: 1004 1. Cookies with an expiry date in the past. 1006 2. Cookies that share a domain field with more than a predetermined 1007 number of other cookies. 1009 3. All cookies. 1011 If two cookies have the same removal priority, the user agent MUST 1012 evict the cookie with the least recent last-access date first. 1014 When "the current session is over" (as defined by the user agent), 1015 the user agent MUST remove from the cookie store all cookies with the 1016 persistent-flag set to false. 1018 5.4. The Cookie Header 1020 When the user agent generates an HTTP request, the user agent SHOULD 1021 attach exactly one HTTP header named Cookie if the cookie-string 1022 (defined below) for the Request-URI is non-empty. 1024 A user agent MAY omit the Cookie header in its entirety. For 1025 example, the user agent might wish to block sending cookies during 1026 "third-party" requests. 1028 The user agent MUST use the following algorithm to compute the 1029 cookie-string from a cookie store and a Request-URI: 1031 1. Let cookie-list be the set of cookies from the cookie store that 1032 meet all of the following requirements: 1034 * Let request-host be the Request-URI's host. Either: 1036 The cookie's host-only-flag is true and the canonicalized 1037 request-host is identical to the cookie's domain. 1039 Or: 1041 The cookie's host-only-flag is false and the request-host 1042 domain-matches cookie's domain. 1044 * The Request-URI's path patch-matches cookie's path. 1046 * If the cookie's secure-only-flag is true, then the Request- 1047 URI's scheme must denote a "secure" protocol (as defined by 1048 the user agent). 1050 NOTE: The notion of a "secure" protocol is not defined by 1051 this document. Typically, user agents consider a protocol 1052 secure if the protocol makes use of transport-layer 1053 security, such as TLS. For example, most user agents 1054 consider "https" to be a scheme that denotes a secure 1055 protocol. 1057 * If the cookie's http-only-flag is true, then exclude the 1058 cookie unless the cookie-string is being generated for an 1059 "HTTP" API (as defined by the user agent). 1061 2. The user agent SHOULD sort the cookie-list in the following 1062 order: 1064 * Cookies with longer paths are listed before cookies with 1065 shorter paths. 1067 * Among cookies that have equal length path fields, cookies with 1068 earlier creation-times are listed before cookies with later 1069 creation-times. 1071 NOTE: Not all user agents sort the cookie-list in this order, but 1072 this order reflects common practice when this document was 1073 written. The specific ordering might not be optimal in every 1074 metric, but using the consensus ordering is a relatively low cost 1075 way to improve interoperability between user agents. 1077 3. Update the last-access-time of each cookie in the cookie-list to 1078 the current date and time. 1080 4. Serialize the cookie-list into a cookie-string by processing each 1081 cookie in the cookie-list in order: 1083 1. Output the cookie's name, the U+003D ("=") character, and the 1084 cookie's value. 1086 2. If there is an unprocessed cookie in the cookie-list, output 1087 the characters U+003B and U+0020 ("; "). 1089 NOTE: Despite its name, the cookie-string is actually a sequence of 1090 octets, not a sequence of characters. To convert the cookie-string 1091 into a sequence of characters (e.g., for presentation to the user), 1092 the user agent SHOULD use the UTF-8 character encoding [RFC3629]. 1094 6. Implementation Considerations 1096 6.1. Limits 1098 Practical user agent implementations have limits on the number and 1099 size of cookies that they can store. General-use user agents SHOULD 1100 provide each of the following minimum capabilities: 1102 o At least 4096 bytes per cookie (as measured by the sum of the 1103 length of the cookie's name, value, and attributes). 1105 o At least 50 cookies per domain. 1107 o At least 3000 cookies total. 1109 Servers SHOULD use as few and as small cookies as possible to avoid 1110 reaching these implementation limits and to avoid network latency due 1111 to the Cookie header being included in every request. 1113 Servers should gracefully degrade if the user agent fails to return 1114 one or more cookies in the Cookie header because the user agent might 1115 evict any cookie at any time on orders from the user. 1117 6.2. Application Programmer Interfaces 1119 One reason the Cookie and Set-Cookie headers uses such esoteric 1120 syntax is because many platforms (both in servers and user agents) 1121 provide a string-based application programmer interface (API) to 1122 cookies, requiring application-layer programmers to generate and 1123 parse the syntax used by the Cookie and Set-Cookie headers. 1125 Instead of providing string-based APIs to cookies, platforms would be 1126 well-served by providing more semantic APIs. It is beyond the scope 1127 of this document to recommend specific API designs, but there are 1128 clear benefits to accepting a abstract "Date" object instead of a 1129 serialized date string. 1131 7. Privacy Considerations 1133 Cookies are often criticized for letting servers track users. For 1134 example, a number of "web analytics" companies use cookies to 1135 recognize when a user returns to a web site or visits another web 1136 site. Although cookies are not the only mechanism servers can use to 1137 track users across HTTP requests, cookies facilitate tracking because 1138 they are persistent across user agent sessions and can be shared 1139 between domains. 1141 7.1. Third-Party Cookies 1143 Particularly worrisome are so-called "third-party" cookies. In 1144 rendering an HTML document, a user agent often requests resources 1145 from other servers (such as advertising networks). These third-party 1146 servers can use cookies to track the user even if the user never 1147 visits the server directly. 1149 Some user agents restrict how third-party cookies behave. For 1150 example, some user agents refuse to send the Cookie header in third- 1151 party requests. Other user agents refuse to process the Set-Cookie 1152 header in responses to third-party requests. User agents vary widely 1153 in their third-party cookie policies. This document grants user 1154 agents wide latitude to experiment with third-party cookie policies 1155 that balance the privacy and compatibility needs of their users. 1156 However, this document does not endorse any particular third-party 1157 cookie policy. 1159 Third-party cookie blocking policies are often ineffective at 1160 achieving their privacy goals if servers attempt to work around their 1161 restrictions to track users. In particular, two collaborating 1162 servers can often track users without using cookies at all. 1164 7.2. User Controls 1166 User agents SHOULD provide users with a mechanism for managing the 1167 cookies stored in the cookie store. For example, a user agent might 1168 let users delete all cookies received during a specified time period 1169 or all the cookies related to a particular domain. In addition, many 1170 user agent include a user interface element that lets users examine 1171 the cookies stored in their cookie store. 1173 User agents SHOULD provide users with a mechanism for disabling 1174 cookies. When cookies are disabled, the user agent MUST NOT include 1175 a Cookie header in outbound HTTP requests and the user agent MUST NOT 1176 process Set-Cookie headers in inbound HTTP responses. 1178 Some user agents provide users the option of preventing persistent 1179 storage of cookies across sessions. When configured thusly, user 1180 agents MUST treat all received cookies as if the persistent-flag were 1181 set to false. 1183 Some user agents provide users with the ability to approve individual 1184 writes to the cookie store. In many common usage scenarios, these 1185 controls generate a large number of prompts. However, some privacy- 1186 conscious users find these controls useful nonetheless. 1188 8. Security Considerations 1190 8.1. Overview 1192 Cookies have a number of security and privacy pitfalls. 1194 In particular, cookies encourage developers to rely on ambient 1195 authority for authentication, often becoming vulnerable to attacks 1196 such as cross-site request forgery. Also, when storing session 1197 identifiers in cookies, developers often create session fixation 1198 vulnerabilities. 1200 Transport-layer encryption, such as that employed in HTTPS, is 1201 insufficient to prevent a network attacker from obtaining or altering 1202 a victim's cookies because the cookie protocol itself has various 1203 vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", 1204 below). In addition, by default, cookies do not provide 1205 confidentiality or integrity from network attackers, even when used 1206 in conjunction with HTTPS. 1208 8.2. Ambient Authority 1210 A server that uses cookies to authenticate users can suffer security 1211 vulnerabilities because some user agents let remote parties issue 1212 HTTP requests from the user agent (e.g., via HTTP redirects or HTML 1213 forms). When issuing those requests, user agents attach cookies even 1214 if the remote party does not know the contents of the cookies, 1215 potentially letting the remote party exercise authority at an unwary 1216 server. 1218 Although this security concern goes by a number of names (e.g., 1219 cross-site request forgery, confused deputy), the issue stems from 1220 cookies being a form of ambient authority. Cookies encourage server 1221 operators to separate designation (in the form of URLs) from 1222 authorization (in the form of cookies). Consequently, the user agent 1223 might supply the authorization for a resource designated by the 1224 attacker, possibly causing the server or its clients to undertake 1225 actions designated by the attacker as though they were authorized by 1226 the user. 1228 Instead of using cookies for authorization, server operators might 1229 wish to consider entangling designation and authorization by treating 1230 URLs as capabilities. Instead of storing secrets in cookies, this 1231 approach stores secrets in URLs, requiring the remote entity to 1232 supply the secret itself. Although this approach is not a panacea, 1233 judicious use of these principles can lead to more robust security. 1235 8.3. Clear Text 1237 Unless sent over a secure channel (such as TLS), the information in 1238 the Cookie and Set-Cookie headers is transmitted in the clear. 1240 1. All sensitive information conveyed in these headers is exposed to 1241 an eavesdropper. 1243 2. A malicious intermediary could alter the headers as they travel 1244 in either direction, with unpredictable results. 1246 3. A malicious client could alter the Cookie header before 1247 transmission, with unpredictable results. 1249 Servers SHOULD encrypt and sign the contents of cookies when 1250 transmitting them to the user agent (even when sending the cookies 1251 over a secure channel). However, encrypting and signing cookie 1252 contents does not prevent an attacker from transplanting a cookie 1253 from one user agent to another or from replaying the cookie at a 1254 later time. 1256 In addition to encrypting and signing the contents of every cookie, 1257 servers that require a higher level of security SHOULD use the Cookie 1258 and Set-Cookie headers only over a secure channel. When using 1259 cookies over a secure channel, servers SHOULD set the Secure 1260 attribute for every cookie. If a server does not set the Secure 1261 attribute, the protection provided by the secure channel will be 1262 largely moot. 1264 8.4. Session Identifiers 1266 Instead of storing session information directly in a cookie (where it 1267 might be exposed to or replayed by an attacker), servers commonly 1268 store a nonce (or "session identifier") in a cookie. When the server 1269 receives an HTTP request with a nonce, the server can look up state 1270 information associated with the cookie using the nonce as a key. 1272 Using session identifier cookies limits the damage an attacker can 1273 cause if the attacker learns the contents of a cookie because the 1274 nonce is useful only for interacting with the server (unlike non- 1275 nonce cookie content, which might itself be sensitive). Furthermore, 1276 using a single nonce prevents an attacker from "splicing" together 1277 cookie content from two interactions with the server, which could 1278 cause the server to behave unexpectedly. 1280 Using session identifiers is not without risk. For example, the 1281 server SHOULD take care to avoid "session fixation" vulnerabilities. 1282 A session fixation attack proceeds in three steps. First, the 1283 attacker transplants a session identifier from his or her user agent 1284 to the victim's user agent. Second, the victim uses that session 1285 identifier to interact with the server, possibly imbuing the session 1286 identifier with the user's credentials or confidential information. 1287 Third, the attacker uses the session identifier to interact with 1288 server directly, possibly obtaining the user's authority or 1289 confidential information. 1291 8.5. Weak Confidentiality 1293 Cookies do not provide isolation by port. If a cookie is readable by 1294 a service running on one port, the cookie is also readable by a 1295 service running on another port of the same server. If a cookie is 1296 writable by a service on one port, the cookie is also writable by a 1297 service running on another port of the same server. For this reason, 1298 servers SHOULD NOT both run mutually distrusting services on 1299 different ports of the same host and use cookies to store security- 1300 sensitive information. 1302 Cookies do not provide isolation by scheme. Although most commonly 1303 used with the http and https schemes, the cookies for a given host 1304 might also be available to other schemes, such as ftp and gopher. 1305 Although this lack of isolation by scheme is most apparent in via 1306 non-HTTP APIs that permit access to cookies (e.g., HTML's 1307 document.cookie API), the lack of isolation by scheme is actually 1308 present in requirements for processing cookies themselves (e.g., 1309 consider retrieving a URI with the gopher scheme via HTTP). 1311 Cookies do not always provide isolation by path. Although the 1312 network-level protocol does not send cookie stored for one path to 1313 another, some user agents expose cookies via non-HTTP APIs, such as 1314 HTML's document.cookie API. Because some of these user agents (e.g., 1315 web browsers) do not isolate resources received from different paths, 1316 a resource retrieved from one path might be able to access cookies 1317 stored for another path. 1319 8.6. Weak Integrity 1321 Cookies do not provide integrity guarantees for sibling domains (and 1322 their subdomains). For example, consider foo.example.com and 1323 bar.example.com. The foo.example.com server can set a cookie with a 1324 Domain attribute of "example.com" (possibly overwriting an existing 1325 "example.com" cookie set by bar.example.com), and the user agent will 1326 include that cookie in HTTP requests to bar.example.com. In the 1327 worst case, bar.example.com will be unable to distinguish this cookie 1328 from a cookie it set itself. The foo.example.com server might be 1329 able to leverage this ability to mount an attack against 1330 bar.example.com. 1332 Even though the Set-Cookie header supports the Path attribute, the 1333 Path attribute does not provide any integrity protection because the 1334 user agent will accept an arbitrary Path attribute in a Set-Cookie 1335 header. For example, an HTTP response to a request for 1336 http://example.com/foo/bar can set a cookie with a Path attribute of 1337 "/qux". Consequently, servers SHOULD NOT both run mutually 1338 distrusting services on different paths of the same host and use 1339 cookies store security-sensitive information. 1341 An active network attacker can also inject cookies into the Cookie 1342 header sent to https://example.com/ by impersonating a response from 1343 http://example.com/ and injecting a Set-Cookie header. The HTTPS 1344 server at example.com will be unable to distinguish these cookies 1345 from cookies that it set itself in an HTTPS response. An active 1346 network attacker might be able to leverage this ability to mount an 1347 attack against example.com even if example.com uses HTTPS 1348 exclusively. 1350 Servers can partially mitigate these attacks by encrypting and 1351 signing the contents of their cookies. However, using cryptography 1352 does not mitigate the issue completely because an attacker can replay 1353 a cookie he or she received from the authentic example.com server in 1354 the user's session, with unpredictable results. 1356 Finally, an attacker might be able to force the user agent to delete 1357 cookies by storing large number of cookies. Once the user agent 1358 reaches its storage limit, the user agent will be forced to evict 1359 some cookies. Servers SHOULD NOT rely upon user agents retaining 1360 cookies. 1362 8.7. Reliance on DNS 1364 Cookies rely upon the Domain Name System (DNS) for security. If the 1365 DNS is partially or fully compromised, the cookie protocol might fail 1366 to provide the security properties required by applications. 1368 9. References 1370 9.1. Normative References 1372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1373 Requirement Levels", BCP 14, RFC 2119, March 1997. 1375 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1376 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1377 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1379 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1380 for Internationalized Domain Names in Applications 1381 (IDNA)", RFC 3492, March 2003. 1383 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1384 10646", STD 63, RFC 3629, November 2003. 1386 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1387 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1389 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1390 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1392 9.2. Informative References 1394 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 1395 Mechanism", RFC 2109, February 1997. 1397 Appendix A. Acknowledgements 1399 This document borrows heavily from RFC 2109 [RFC2109]. We are 1400 indebted to David M. Kristol and Lou Montulli for their efforts to 1401 specify the cookie protocol. David M. Kristol, in particular, 1402 provided invaluable advice on navigating the IETF process. We would 1403 also like to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, 1404 Lisa Dusseault, Roy T. Fielding, Blake Frantz, Eran Hammer-Lahav, 1405 Jeff Hodges, Achim Hoffmann, Georg Koppen, Dean McNamee, Mark Miller, 1406 Mark Pauley, Yngve N. Pettersen, Julian Reschke, Mark Seaborn, Maciej 1407 Stachowiak, Daniel Stenberg, David Wagner, Dan Winship, and Dan Witte 1408 for their valuable feedback on this document. 1410 Author's Address 1412 Adam Barth 1413 University of California, Berkeley 1415 Email: abarth@eecs.berkeley.edu 1416 URI: http://www.adambarth.com/