idnits 2.17.1 draft-ietf-httpstate-cookie-09.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. (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 (June 5, 2010) is 5073 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: 'RFC 2616' is mentioned on line 345, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Unused Reference: 'RFC1034' is defined on line 1377, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2109 (Obsoleted by RFC 2965) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 5 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) June 5, 2010 5 Intended status: Standards Track 6 Expires: December 7, 2010 8 HTTP State Management Mechanism 9 draft-ietf-httpstate-cookie-09 11 Abstract 13 This document defines the HTTP Cookie and Set-Cookie header fields. 14 These header fields can be used by HTTP servers to store state 15 (called cookies) at HTTP user agents, letting the servers maintain a 16 stateful session over the mostly stateless HTTP protocol. Although 17 cookies have many historical infelicities that degrade their security 18 and privacy, the Cookie and Set-Cookie header fields are widely used 19 on the Internet. 21 Editorial Note (To be removed by RFC Editor) 23 If you have suggestions for improving this document, please send 24 email to . Suggestions with test cases 25 are especially appreciated. Further Working Group information is 26 available from 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on December 7, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 6 83 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 84 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 85 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 10 88 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 10 89 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 90 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11 91 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 93 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 14 94 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 15 95 5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 15 96 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 15 97 5.1.2. Domains . . . . . . . . . . . . . . . . . . . . . . . 17 98 5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 17 99 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 18 100 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 19 101 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 20 102 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 20 103 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 21 104 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 21 105 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 21 106 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 21 107 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 25 108 6. Implementation Considerations . . . . . . . . . . . . . . . . 27 109 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 27 110 6.2. Application Programming Interfaces . . . . . . . . . . . . 27 111 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28 112 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 28 113 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 28 114 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 115 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 30 117 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 31 118 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 31 119 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 32 120 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 32 121 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 33 122 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 123 9.1. Normative References . . . . . . . . . . . . . . . . . . . 34 124 9.2. Informative References . . . . . . . . . . . . . . . . . . 34 125 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 126 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 128 1. Introduction 130 This document defines the HTTP Cookie and Set-Cookie header fields. 131 Using the Set-Cookie header field, an HTTP server can pass name/value 132 pairs and associated metadata (called cookies) to a user agent. When 133 the user agent makes subsequent requests to the server, the user 134 agent uses the metadata and other information to determine whether to 135 return the name/value pairs in the Cookie header. 137 Although simple on its surface, cookies have a number of 138 complexities. For example, the server indicates a scope for each 139 cookie when sending them to the user agent. The scope indicates the 140 maximum amount of time the user agent should return the cookie, the 141 servers to which the user agent should return the cookie, and the 142 protocols for which the cookie is applicable. 144 For historical reasons, cookies contain a number of security and 145 privacy infelicities. For example, a server can indicate that a 146 given cookie is intended for "secure" connections, but the Secure 147 attribute provides only confidentiality (not integrity) from active 148 network attackers. Similarly, cookies for a given host are shared 149 across all the ports on that host, even though the usual "same-origin 150 policy" used by web browsers isolates content retrieved from 151 different ports. 153 Prior to this document, there were at least three descriptions of 154 cookies: the so-called "Netscape cookie specification" [Netscape], 155 RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these 156 documents describe how the Cookie and Set-Cookie headers are actually 157 used on the Internet (see [Kri2001] for historical context). This 158 document attempts to specify the syntax and semantics of these 159 headers as they are actually used on the Internet. 161 2. Conventions 163 2.1. Conformance Criteria 165 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 166 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 167 interpreted as described in [RFC2119]. 169 Requirements phrased in the imperative as part of algorithms (such as 170 "strip any leading space characters" or "return false and abort these 171 steps") are to be interpreted with the meaning of the key word 172 ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. 174 Conformance requirements phrased as algorithms or specific steps can 175 be implemented in any manner, so long as the end result is 176 equivalent. In particular, the algorithms defined in this 177 specification are intended to be easy to understand and are not 178 intended to be performant. 180 2.2. Syntax Notation 182 This specification uses the Augmented Backus-Naur Form (ABNF) 183 notation of [RFC5234]. 185 The following core rules are included by reference, as defined in 186 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 187 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 188 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 189 sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US- 190 ASCII character), VCHAR (any visible US-ASCII character), and WSP 191 (whitespace). 193 The OWS (optional whitespace) rule is used where zero or more linear 194 whitespace characters MAY appear: 196 OWS = *( [ obs-fold ] WSP ) 197 ; "optional" whitespace 198 obs-fold = CRLF 200 OWS SHOULD either not be produced or be produced as a single SP 201 character. 203 2.3. Terminology 205 The terms user agent, client, server, proxy, and origin server have 206 the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 207 1.3). 209 The terms request-host and request-uri refer to the values the user 210 agent would send to the server as, respectively, the host (but not 211 port) and the absoluteURI (http_URL) of the HTTP Request-Line. 213 Two sequence of octets are said to case-insensitively match each 214 other if and only if they are equivalent under the i;ascii-casemap 215 collation defined in [RFC4790]. 217 3. Overview 219 This section outlines a way for an origin server to send state 220 information to a user agent and for the user agent to return the 221 state information to the origin server. 223 To store state, the origin server includes a Set-Cookie header in an 224 HTTP response. In subsequent requests, the user agent returns a 225 Cookie request header to the origin server. The Cookie header 226 contains a number of cookies the user agent received in previous Set- 227 Cookie headers. The origin server is free to ignore the Cookie 228 header or use its contents for an application-defined purpose. 230 Servers can send a Set-Cookie response header with any response. An 231 origin server can include multiple Set-Cookie header fields in a 232 single response. Note that folding multiple Set-Cookie header fields 233 into a single header field might change the semantics of the header 234 because the U+002C (",") character is used by the Set-Cookie header 235 in a way that conflicts with such folding. 237 3.1. Examples 239 Using the Set-Cookie header, a server can send the user agent a short 240 string in an HTTP response that the user agent will return in future 241 HTTP requests. For example, the server can send the user agent a 242 "session identifier" named SID with the value 31d4d96e407aad42. The 243 user agent then returns the session identifier in subsequent 244 requests. 246 == Server -> User Agent == 248 Set-Cookie: SID=31d4d96e407aad42 250 == User Agent -> Server == 252 Cookie: SID=31d4d96e407aad42 254 The server can alter the default scope of the cookie using the Path 255 and Domain attributes. For example, the server can instruct the user 256 agent to return the cookie to every path and every subdomain of 257 example.com. 259 == Server -> User Agent == 261 Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com 262 == User Agent -> Server == 264 Cookie: SID=31d4d96e407aad42 266 As shown the next example, the server can store multiple cookies at 267 the user agent. For example, the server can store a session 268 identifier as well as the user's preferred language by returning two 269 Set-Cookie header fields. Notice that the server uses the Secure and 270 HttpOnly attributes to provide additional security protections for 271 the more-sensitive session identifier (see Section 4.1.2. 273 == Server -> User Agent == 275 Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly 276 Set-Cookie: lang=en-US; Path=/; Domain=example.com 278 == User Agent -> Server == 280 Cookie: SID=31d4d96e407aad42; lang=en-US 282 If the server wishes the user agent to persist the cookie over 283 multiple "sessions," the server can specify an expiration date in the 284 Expires attribute. Note that the user agent might delete the cookie 285 before the expiration date if the user agent's cookie store exceeds 286 its quota or if the user manually deletes the server's cookie. 288 == Server -> User Agent == 290 Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT 292 == User Agent -> Server == 294 Cookie: SID=31d4d96e407aad42; lang=en-US 296 Finally, to remove a cookie, the server returns a Set-Cookie header 297 with an expiration date in the past. The server will be successful 298 in removing the cookie only if the Path and the Domain attribute in 299 the Set-Cookie header match the values used when the cookie was 300 created. 302 == Server -> User Agent == 304 Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT 306 == User Agent -> Server == 308 Cookie: SID=31d4d96e407aad42 310 4. Server Requirements 312 This section describes the syntax and semantics of a well-behaved 313 profile of the Cookie and Set-Cookie headers. Servers SHOULD use the 314 profile described in this section, both to maximize interoperability 315 with existing user agents and because a future version of the Cookie 316 or Set-Cookie headers could remove support for some of the esoteric 317 semantics described in the next section. User agents, however, MUST 318 implement the full semantics to ensure interoperability with servers 319 making use of the full semantics. 321 4.1. Set-Cookie 323 The Set-Cookie header is used to send cookies from the server to the 324 user agent. 326 4.1.1. Syntax 328 Informally, the Set-Cookie response header contains the header name 329 "Set-Cookie" followed by a ":" and a cookie. Each cookie begins with 330 a name-value pair, followed by zero or more attribute-value pairs. 331 Servers SHOULD NOT send Set-Cookie headers that fail to conform to 332 the following grammar: 334 set-cookie-header = "Set-Cookie:" SP set-cookie-string 335 set-cookie-string = cookie-pair *( ";" SP cookie-av ) 336 cookie-pair = cookie-name "=" cookie-value 337 cookie-name = token 338 cookie-value = token 339 token = 341 cookie-av = expires-av / max-age-av / domain-av / 342 path-av / secure-av / httponly-av / 343 extension-av 344 expires-av = "Expires=" sane-cookie-date 345 sane-cookie-date = 346 ; Note that RFC 2616 uses a different grammatical 347 ; notation than this document (which uses ABNF 348 ; from [RFC5234]). 349 max-age-av = "Max-Age=" 1*DIGIT 350 domain-av = "Domain=" domain-value 351 domain-value = 352 path-av = "Path=" path-value 353 path-value = 354 secure-av = "Secure" 355 httponly-av = "HttpOnly" 356 extension-av = 357 The semantics of the cookie-value are not defined by this document. 359 To maximize compatibility with user agents, servers that wish to 360 store non-ASCII data in a cookie-value SHOULD encode that data using 361 a printable ASCII encoding. 363 The portions of the set-cookie-string produced by the cookie-av term 364 are known as attributes. To maximize compatibility with user agents, 365 servers SHOULD NOT produce two attributes with the same name in the 366 same set-cookie-string. 368 Servers SHOULD NOT include more than one Set-Cookie header fields in 369 the same response with the same cookie-name. 371 If a server sends multiple responses containing Set-Cookie headers 372 concurrently to the user agent (e.g., when communicating with the 373 user agent over multiple sockets), these responses create a "race 374 condition" that can lead to unpredictable behavior. 376 NOTE: Some user agents represent dates using 32-bit UNIX time_t 377 values. Some of these user agents might contain bugs that cause them 378 process dates after the year 2038 incorrectly. Servers wishing to 379 interoperate with these user agents might wish to use dates before 380 2038. 382 4.1.2. Semantics (Non-Normative) 384 This section describes a simplified semantics of the Set-Cookie 385 header. These semantics are detailed enough to be useful for 386 understanding the most common uses of cookies. The full semantics 387 are described in Section 5. 389 When the user agent receives a Set-Cookie header, the user agent 390 stores the cookie. Subsequently, when the user agent makes an HTTP 391 request, the user agent includes the applicable, non-expired cookies 392 in the Cookie header. 394 If the user agent receives a new cookie with the same cookie-name, 395 domain-value, and path-value as a cookie that it has already stored, 396 the existing cookie is evicted and replaced with the new cookie. 397 Notice that servers can delete cookies by sending the user agent a 398 new cookie with an Expires attribute with a value in the past. 400 Unless the cookie's attributes indicate otherwise, the cookie is 401 returned only to the origin server, and it expires at the end of the 402 current session (as defined by the user agent). User agents ignore 403 unrecognized cookie attributes. 405 4.1.2.1. The Expires Attribute 407 The Expires attribute indicates the maximum lifetime of the cookie, 408 represented as the date and time at which the cookie expires. The 409 user agent is not required to retain the cookie until the specified 410 date has passed. In fact, user agents often evict cookies due to 411 memory pressure or privacy concerns. 413 4.1.2.2. The Max-Age Attribute 415 The Max-Age attribute indicates the maximum lifetime of the cookie, 416 represented as the number of seconds until the cookie expires. The 417 user agent is not required to retain the cookie for the specified 418 duration. In fact, user agents often evict cookies from due to 419 memory pressure or privacy concerns. 421 NOTE: Some legacy user agents do not support the Max-Age 422 attribute. User agents that do not support the Max-Age attribute 423 ignore the attribute. 425 If a cookie has both the Max-Age and the Expires attribute, the Max- 426 Age attribute has precedence and controls the expiration date of the 427 cookie. If a cookie has neither the Max-Age nor the Expires 428 attribute, the user agent will retain the cookie until "the current 429 session is over" (as defined by the user agent). 431 4.1.2.3. The Domain Attribute 433 The Domain attribute specifies those hosts to which the cookie will 434 be sent. For example, if the value of the Domain attribute is 435 "example.com", the user agent will include the cookie in the Cookie 436 header when making HTTP requests to example.com, www.example.com, and 437 www.corp.example.com. (Note that a leading U+002E ("."), if present, 438 is ignored even though that character is not permitted.) If the 439 server omits the Domain attribute, the user agent will return the 440 cookie only to the origin server. 442 WARNING: Some legacy user agents treat an absent Domain attribute 443 as if the Domain attribute were present and contained the current 444 host name. For example, if example.com returns a Set-Cookie 445 header without a Domain attribute, these user agents will 446 erroneously send the cookie to www.example.com as well. 448 The user agent will reject cookies unless the Domain attribute 449 specifies a scope for the cookie that would include the origin 450 server. For example, the user agent will accept a cookie with a 451 Domain attribute of "example.com" or of "foo.example.com" from 452 foo.example.com, but the user agent will not accept a cookie with a 453 Domain attribute of "bar.example.com" or of "baz.foo.example.com". 455 NOTE: For security reasons, many user agents are configured to reject 456 Domain attributes that correspond to "public suffixes." For example, 457 some user agents will reject Domain attributes of "com" or "co.uk". 459 4.1.2.4. The Path Attribute 461 The scope of each cookie is limited to a set of paths, controlled by 462 the Path attribute. If the server omits the Path attribute, the user 463 agent will use the "directory" of the request-uri's path component as 464 the default value. (See Section 5.1.3 for more details.) 466 The user agent will include the cookie in an HTTP request only if the 467 path portion of the request-uri matches (or is a subdirectory of) the 468 cookie's Path attribute, where the U+002F ("/") character is 469 interpreted as a directory separator. 471 Although seemingly useful for isolating cookies between different 472 paths within a given domain, the Path attribute cannot be relied upon 473 for security (see Section 8). 475 4.1.2.5. The Secure Attribute 477 The Secure attribute limits the scope of the cookie to "secure" 478 channels (where "secure" is defined by the user agent). When a 479 cookie has the Secure attribute, the user agent will include the 480 cookie in an HTTP request only if the request is transmitted over a 481 secure channel (typically HTTP over SSL, HTTP over TLS [RFC2818], and 482 TLS [RFC5246] itself). 484 Although seemingly useful for protecting cookies from active network 485 attackers, the Secure attribute protects only the cookie's 486 confidentiality. An active network attacker can overwrite Secure 487 cookies from an insecure channel, disrupting their integrity. 489 4.1.2.6. The HttpOnly Attribute 491 The HttpOnly attribute limits the scope of the cookie to HTTP 492 requests. In particular, the attribute instructs the user agent to 493 omit the cookie when providing access to cookies via "non-HTTP" APIs 494 (such as a web browser API that exposes cookies to scripts). 496 4.2. Cookie 497 4.2.1. Syntax 499 The user agent sends stored cookies to the origin server in the 500 Cookie header. If the server conforms to the requirements in 501 Section 4.1 (and the user agent conforms to the requirements in the 502 Section 5), the user agent will send a Cookie header that conforms to 503 the following grammar: 505 cookie-header = "Cookie:" OWS cookie-string OWS 506 cookie-string = cookie-pair *( ";" SP cookie-pair ) 508 4.2.2. Semantics 510 Each cookie-pair represents a cookie stored by the user agent. The 511 cookie-name and the cookie-value are returned from the corresponding 512 parts of the Set-Cookie header. 514 Notice that the cookie attributes are not returned. In particular, 515 the server cannot determine from the Cookie header alone when a 516 cookie will expire, for which domains the cookie is valid, for which 517 paths the cookie is valid, or whether the cookie was set with the 518 Secure or HttpOnly attributes. 520 The semantics of individual cookies in the Cookie header are not 521 defined by this document. Servers are expected to imbue these 522 cookies with application-specific semantics. 524 Although cookies are serialized linearly in the Cookie header, 525 servers SHOULD NOT rely upon the serialization order. In particular, 526 if the Cookie header contains two cookies with the same name (e.g., 527 with different Path or Domain attributes), servers SHOULD NOT rely 528 upon the order in which these cookies appear in the header. 530 5. User Agent Requirements 532 For historical reasons, the full semantics of cookies contain a 533 number of exotic quirks. This section is intended to specify the 534 Cookie and Set-Cookie headers in sufficient detail to allow a user 535 agent implementing these requirements precisely to interoperate with 536 existing servers. 538 5.1. Algorithms 540 This section defines a number of algorithms used by user agents to 541 process the Cookie and Set-Cookie headers. 543 5.1.1. Dates 545 The user agent MUST use an algorithm equivalent to the following 546 algorithm to parse a cookie-date: 548 1. Using the grammar below, divide the cookie-date into date-tokens. 550 cookie-date = *delimiter date-token-list *delimiter 551 date-token-list = date-token *( 1*delimiter date-token ) 552 delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E 553 date-token = day-of-month / month / year / time / mystery 554 day-of-month = 1*2DIGIT 555 month = "jan" [ mystery ] / "feb" [ mystery ] / 556 "mar" [ mystery ] / "apr" [ mystery ] / 557 "may" [ mystery ] / "jun" [ mystery ] / 558 "jul" [ mystery ] / "aug" [ mystery ] / 559 "sep" [ mystery ] / "oct" [ mystery ] / 560 "nov" [ mystery ] / "dec" [ mystery ] 561 year = 1*4DIGIT 562 time = time-field ":" time-field ":" time-field 563 time-field = 1*2DIGIT 564 CTLwoHTAB = %x00-08 / %x0A-1F / %x7F 565 ; CTL except HTAB 566 mystery = CTLwoHTAB / ":" / ALPHA / DIGIT / %x80-FF 567 ; any OCTET except a delimiter 569 2. Process each date-token sequentially in the order the date-tokens 570 appear in the cookie-date: 572 1. If the found-day-of-month flag is not set and the date-token 573 matches the day-of-month production, set the found-day-of- 574 month flag and set the day-of-month-value to the number 575 denoted by the date-token. Skip the remaining sub-steps and 576 continue to the next date-token. 578 2. If the found-month flag is not set and the date-token matches 579 the month production, set the found-month flag and set the 580 month-value to the month denoted by the date-token. Skip the 581 remaining sub-steps and continue to the next date-token. 583 3. If the found-year flag is not set and the date-token matches 584 the year production, set the found-year flag and set the 585 year-value to the number denoted by the date-token. Skip the 586 remaining sub-steps and continue to the next date-token. 588 4. If the found-time flag is not set and the token matches the 589 time production, set the found-time flag and set the hour- 590 value, minute-value, and second-value to the numbers denoted 591 by the digits in the date-token, respectively. Skip the 592 remaining sub-steps and continue to the next date-token. 594 3. If the year-value is greater than 68 and less than 100, increment 595 the year-value by 1900. 597 4. If the year-value is greater than or equal to 0 and less than 69, 598 increment the year-value by 2000. 600 5. Abort these steps and fail to parse the cookie-date if 602 * at least one of the found-day-of-month, found-month, found- 603 year, or found-time flags is not set, 605 * the day-of-month-value is less than 1 or greater than 31, 607 * the year-value is less than 1601, 609 * the hour-value is greater than 23, 611 * the minute-value is greater than 59, or 613 * the second-value is greater than 59. 615 6. Let the parsed-cookie-date be the date whose day-of-month, month, 616 year, hour, minute, and second (in GMT) are the day-of-month- 617 value, the month-value, the year-value, the hour-value, the 618 minute-value, and the second-value, respectively. If no such 619 date exists, abort these steps and fail to parse the cookie-date. 621 7. Return the parsed-cookie-date as the result of this algorithm. 623 5.1.2. Domains 625 A canonicalized string is the string converted to lower case and 626 converted to ASCII according to the IDNA specification [RFC3490]. 628 A string domain-matches a cookie-domain if at least one of the 629 following conditions hold: 631 o The cookie-domain and the string are identical. 633 o All of the following conditions hold: 635 * The cookie-domain is a suffix of the string. 637 * The last character of the string that is not included in the 638 cookie-domain is a U+002E (".") character. 640 * The string is a host name (i.e., not an IP address). 642 5.1.3. Paths 644 The user agent MUST use an algorithm equivalent to the following 645 algorithm to compute the default-path of a cookie: 647 1. Let uri-path be the path portion of the request-uri if such a 648 portion exists (and empty otherwise). For example, if the 649 request-uri contains just a path (and optional query string), 650 then the uri-path is that path (without the U+003F ("?") 651 character or query string), and if the request-uri contains a 652 full absoluteURI, the uri-path is the path component of that URI. 654 2. If the uri-path is empty or if first character of the uri-path is 655 not a U+002F ("/") character, output U+002F ("/") and skip the 656 remaining steps. 658 3. If the uri-path contains only a single U+002F ("/") character, 659 output U+002F ("/") and skip the remaining steps. 661 4. Output the characters of the uri-path from the first character up 662 to, but not including, the right-most U+002F ("/"). 664 A request-path path-matches a cookie-path if at least one of the 665 following conditions hold: 667 o The cookie-path and the request-path are identical. 669 o The cookie-path is a prefix of the request-path and the last 670 character of the cookie-path is U+002F ("/"). 672 o The cookie-path is a prefix of the request-path and the first 673 character of the request-path that is not included in the cookie- 674 path is a U+002F ("/") character. 676 5.2. The Set-Cookie Header 678 When a user agent receives a Set-Cookie header field in an HTTP 679 response, the user agent receives a set-cookie-string consisting of 680 the contents of the header field. 682 A user agent MUST use an algorithm equivalent to the following 683 algorithm to parse set-cookie-strings: 685 1. If the set-cookie-string contains a U+003B (";") character: 687 The name-value-pair string consists of the characters up to, 688 but not including, the first U+003B (";"), and the unparsed- 689 attributes consist of the remainder of the set-cookie-string 690 (including the U+003B (";") in question). 692 Otherwise: 694 The name-value-pair string consists of all the characters 695 contained in the set-cookie-string, and the unparsed- 696 attributes is the empty string. 698 2. If the name-value-pair string lacks a U+003D ("=") character, 699 ignore the set-cookie-string entirely. 701 3. The (possibly empty) name string consists of the characters up 702 to, but not including, the first U+003D ("=") character, and the 703 (possibly empty) value string consists of the characters after 704 the first U+003D ("=") character. 706 4. Remove any leading or trailing WSP characters from the name 707 string and the value string. 709 5. If the name string is empty, ignore the set-cookie-string 710 entirely. 712 6. The cookie-name is the name string, and the cookie-value is the 713 value string. 715 The user agent MUST use an algorithm equivalent to the following 716 algorithm to parse the unparsed-attributes: 718 1. If the unparsed-attributes string is empty, skip the rest of 719 these steps. 721 2. Discard the first character of the unparsed-attributes (which 722 will be a U+003B (";") character). 724 3. If the remaining unparsed-attributes contains a U+003B (";") 725 character: 727 Consume the characters of the unparsed-attributes up to, but 728 not including, the first U+003B (";") character. 730 Otherwise: 732 Consume the remainder of the unparsed-attributes. 734 Let the cookie-av string be the characters consumed in this step. 736 4. If the cookie-av string contains a U+003D ("=") character: 738 The (possibly empty) attribute-name string consists of the 739 characters up to, but not including, the first U+003D ("=") 740 character, and the (possibly empty) attribute-value string 741 consists of the characters after the first U+003D ("=") 742 character. 744 Otherwise: 746 The attribute-name string consists of the entire cookie-av 747 string, and the attribute-value string is empty. 749 5. Remove any leading or trailing WSP characters from the attribute- 750 name string and the attribute-value string. 752 6. Process the attribute-name and attribute-value according to the 753 requirements in the following subsections. (Notice that 754 attributes with unrecognized attribute-names are ignored.) 756 7. Return to Step 1. 758 When the user agent finishes parsing the set-cookie-string, the user 759 agent receives a cookie from the request-uri with name cookie-name, 760 value cookie-value, and attributes cookie-attribute-list. 762 5.2.1. The Expires Attribute 764 If the attribute-name case-insensitively matches the string 765 "Expires", the user agent MUST process the cookie-av as follows. 767 Let the expiry-time be the result of parsing the attribute-value as 768 cookie-date (see Section 5.1.1). 770 If the attribute-value failed to parse as a cookie date, ignore the 771 cookie-av. 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 earliest date the user agent 778 can represent, the user agent MAY replace the expiry-time with the 779 earliest 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 or the user agent might not wish to 870 store cookies that exceed some size. 872 2. Create a new cookie with name cookie-name, value cookie-value. 873 Set the creation-time and the last-access-time to the current 874 date and time. 876 3. If the cookie-attribute-list contains an attribute with an 877 attribute-name of "Max-Age": 879 Set the cookie's persistent-flag to true. 881 Set the cookie's expiry-time to attribute-value of the last 882 attribute in the cookie-attribute-list with an attribute-name 883 of "Max-Age". 885 Otherwise, if the cookie-attribute-list contains an attribute 886 with an attribute-name of "Expires" (and does not contain an 887 attribute with an attribute-name of "Max-Age"): 889 Set the cookie's persistent-flag to true. 891 Set the cookie's expiry-time to attribute-value of the last 892 attribute in the cookie-attribute-list with an attribute-name 893 of "Expires". 895 Otherwise: 897 Set the cookie's persistent-flag to false. 899 Set the cookie's expiry-time to the latest representable 900 date. 902 4. If the cookie-attribute-list contains an attribute with an 903 attribute-name of "Domain": 905 Let the domain-attribute be the attribute-value of the last 906 attribute in the cookie-attribute-list with an attribute-name 907 of "Domain". 909 Otherwise: 911 Let the domain-attribute be the empty string. 913 5. If the user agent is configured to reject "public suffixes" and 914 the domain-attribute is a public suffix: 916 If the domain-attribute is identical to the canonicalized 917 request-host: 919 Let the domain-attribute be the empty string. 921 Otherwise: 923 Ignore the cookie entirely and abort these steps 925 NOTE: A "public suffix" is a domain that is controlled by a 926 public registry, such as "com", "co.uk", and "pvt.k12.wy.us". 927 This step is essential for preventing attacker.com from 928 disrupting the integrity of example.com by setting a cookie 929 with a Domain attribute of "com". Unfortunately, the set of 930 public suffixes (also known as "registry controlled domains") 931 changes over time. If feasible, user agents SHOULD use an 932 up-to-date public suffix list, such as the one maintained by 933 the Mozilla project at . 935 6. If the domain-attribute is non-empty: 937 If the canonicalized request-host does not domain-match the 938 domain-attribute, ignore the cookie entirely and abort these 939 steps. 941 Set the cookie's host-only-flag to false. 943 Set the cookie's domain to the domain-attribute. 945 Otherwise: 947 Set the cookie's host-only-flag to true. 949 Set the cookie's domain to the canonicalized request-host. 951 7. If the cookie-attribute-list contains an attribute with an 952 attribute-name of "Path", set the cookie's path to attribute- 953 value of the last attribute in the cookie-attribute-list with an 954 attribute-name of "Path". Otherwise, set cookie's path to the 955 default-path of the request-uri. 957 8. If the cookie-attribute-list contains an attribute with an 958 attribute-name of "Secure", set the cookie's secure-only-flag to 959 true. Otherwise, set cookie's secure-only-flag to false. 961 9. If the cookie-attribute-list contains an attribute with an 962 attribute-name of "HttpOnly", set the cookie's http-only-flag to 963 true. Otherwise, set cookie's http-only-flag to false. 965 10. If the cookie was received from a non-HTTP API and the cookie's 966 http-only-flag is set, abort these steps and ignore the cookie 967 entirely. 969 11. If the cookie store contains a cookie with the same name, 970 domain, and path as the newly created cookie: 972 1. Let old-cookie be the existing cookie with the same name, 973 domain, and path as the newly created cookie. (Notice that 974 this algorithm maintains the invariant that there is at most 975 one such cookie.) 977 2. If the newly created cookie was received from an non-HTTP 978 API and the old-cookie's http-only-flag is set, abort these 979 steps and ignore the newly created cookie entirely. 981 3. Update the creation-time of the newly created cookie to 982 match the creation-time of the old-cookie. 984 4. Remove the old-cookie from the cookie store. 986 12. Insert the newly created cookie into the cookie store. 988 A cookie is "expired" if the cookie has an expiry date in the past. 990 The user agent MUST evict all expired cookies from the cookie store 991 if, at any time, an expired cookie exists in the cookie store. 993 At any time, the user agent MAY "remove excess cookies" from the 994 cookie store if the number of cookies sharing a domain field exceeds 995 some predetermined upper bound (such as 50 cookies). 997 At any time, the user agent MAY "remove excess cookies" from the 998 cookie store if the cookie store exceeds some predetermined upper 999 bound (such as 3000 cookies). 1001 When the user agent removes excess cookies from the cookie store, the 1002 user agent MUST evict cookies in the following priority order: 1004 1. Expired cookies. 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 earliest 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 an algorithm equivalent to the following 1029 algorithm to compute the cookie-string from a cookie store and a 1030 request-uri: 1032 1. Let cookie-list be the set of cookies from the cookie store that 1033 meet all of the following requirements: 1035 * Either: 1037 The cookie's host-only-flag is true and the canonicalized 1038 request-host is identical to the cookie's domain. 1040 Or: 1042 The cookie's host-only-flag is false and the canonicalized 1043 request-host domain-matches cookie's domain. 1045 * The request-uri's path path-matches cookie's path. 1047 * If the cookie's secure-only-flag is true, then the request- 1048 uri's scheme must denote a "secure" protocol (as defined by 1049 the user agent). 1051 NOTE: The notion of a "secure" protocol is not defined by 1052 this document. Typically, user agents consider a protocol 1053 secure if the protocol makes use of transport-layer 1054 security, such as SSL or TLS. For example, most user 1055 agents consider "https" to be a scheme that denotes a 1056 secure protocol. 1058 * If the cookie's http-only-flag is true, then exclude the 1059 cookie unless the cookie-string is being generated for an 1060 "HTTP" API (as defined by the user agent). 1062 2. The user agent SHOULD sort the cookie-list in the following 1063 order: 1065 * Cookies with longer paths are listed before cookies with 1066 shorter paths. 1068 * Among cookies that have equal length path fields, cookies with 1069 earlier creation-times are listed before cookies with later 1070 creation-times. 1072 NOTE: Not all user agents sort the cookie-list in this order, but 1073 this order reflects common practice when this document was 1074 written, and, historically, there have been servers that 1075 (erroneously) depended on this order. 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 (or components thereof) into a sequence of characters (e.g., for 1092 presentation to the user), the user agent SHOULD use the UTF-8 1093 character encoding [RFC3629]. 1095 6. Implementation Considerations 1097 6.1. Limits 1099 Practical user agent implementations have limits on the number and 1100 size of cookies that they can store. General-use user agents SHOULD 1101 provide each of the following minimum capabilities: 1103 o At least 4096 bytes per cookie (as measured by the sum of the 1104 length of the cookie's name, value, and attributes). 1106 o At least 50 cookies per domain. 1108 o At least 3000 cookies total. 1110 Servers SHOULD use as few and as small cookies as possible to avoid 1111 reaching these implementation limits and to minimize network 1112 bandwidth due to the Cookie header being included in every request. 1114 Servers SHOULD gracefully degrade if the user agent fails to return 1115 one or more cookies in the Cookie header because the user agent might 1116 evict any cookie at any time on orders from the user. 1118 6.2. Application Programming Interfaces 1120 One reason the Cookie and Set-Cookie headers uses such esoteric 1121 syntax is because many platforms (both in servers and user agents) 1122 provide a string-based application programmer interface (API) to 1123 cookies, requiring application-layer programmers to generate and 1124 parse the syntax used by the Cookie and Set-Cookie headers, which 1125 many programmers have done incorrectly, resulting in interoperability 1126 problems. 1128 Instead of providing string-based APIs to cookies, platforms would be 1129 well-served by providing more semantic APIs. It is beyond the scope 1130 of this document to recommend specific API designs, but there are 1131 clear benefits to accepting an abstract "Date" object instead of a 1132 serialized date string. 1134 7. Privacy Considerations 1136 Cookies are often criticized for letting servers track users. For 1137 example, a number of "web analytics" companies use cookies to 1138 recognize when a user returns to a web site or visits another web 1139 site. Although cookies are not the only mechanism servers can use to 1140 track users across HTTP requests, cookies facilitate tracking because 1141 they are persistent across user agent sessions and can be shared 1142 between domains. 1144 7.1. Third-Party Cookies 1146 Particularly worrisome are so-called "third-party" cookies. In 1147 rendering an HTML document, a user agent often requests resources 1148 from other servers (such as advertising networks). These third-party 1149 servers can use cookies to track the user even if the user never 1150 visits the server directly. 1152 Some user agents restrict how third-party cookies behave. For 1153 example, some of these user agents refuse to send the Cookie header 1154 in third-party requests. Others refuse to process the Set-Cookie 1155 header in responses to third-party requests. User agents vary widely 1156 in their third-party cookie policies. This document grants user 1157 agents wide latitude to experiment with third-party cookie policies 1158 that balance the privacy and compatibility needs of their users. 1159 However, this document does not endorse any particular third-party 1160 cookie policy. 1162 Third-party cookie blocking policies are often ineffective at 1163 achieving their privacy goals if servers attempt to work around their 1164 restrictions to track users. In particular, two collaborating 1165 servers can often track users without using cookies at all. 1167 7.2. User Controls 1169 User agents should provide users with a mechanism for managing the 1170 cookies stored in the cookie store. For example, a user agent might 1171 let users delete all cookies received during a specified time period 1172 or all the cookies related to a particular domain. In addition, many 1173 user agent include a user interface element that lets users examine 1174 the cookies stored in their cookie store. 1176 User agents should provide users with a mechanism for disabling 1177 cookies. When cookies are disabled, the user agent MUST NOT include 1178 a Cookie header in outbound HTTP requests and the user agent MUST NOT 1179 process Set-Cookie headers in inbound HTTP responses. 1181 Some user agents provide users the option of preventing persistent 1182 storage of cookies across sessions. When configured thusly, user 1183 agents MUST treat all received cookies as if the persistent-flag were 1184 set to false. 1186 Some user agents provide users with the ability to approve individual 1187 writes to the cookie store. In many common usage scenarios, these 1188 controls generate a large number of prompts. However, some privacy- 1189 conscious users find these controls useful nonetheless. 1191 8. Security Considerations 1193 8.1. Overview 1195 Cookies have a number of security pitfalls. This section overviews a 1196 few of the more salient issues. 1198 In particular, cookies encourage developers to rely on ambient 1199 authority for authentication, often becoming vulnerable to attacks 1200 such as cross-site request forgery. Also, when storing session 1201 identifiers in cookies, developers often create session fixation 1202 vulnerabilities. 1204 Transport-layer encryption, such as that employed in HTTPS, is 1205 insufficient to prevent a network attacker from obtaining or altering 1206 a victim's cookies because the cookie protocol itself has various 1207 vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", 1208 below). In addition, by default, cookies do not provide 1209 confidentiality or integrity from network attackers, even when used 1210 in conjunction with HTTPS. 1212 8.2. Ambient Authority 1214 A server that uses cookies to authenticate users can suffer security 1215 vulnerabilities because some user agents let remote parties issue 1216 HTTP requests from the user agent (e.g., via HTTP redirects or HTML 1217 forms). When issuing those requests, user agents attach cookies even 1218 if the remote party does not know the contents of the cookies, 1219 potentially letting the remote party exercise authority at an unwary 1220 server. 1222 Although this security concern goes by a number of names (e.g., 1223 cross-site request forgery, confused deputy), the issue stems from 1224 cookies being a form of ambient authority. Cookies encourage server 1225 operators to separate designation (in the form of URLs) from 1226 authorization (in the form of cookies). Consequently, the user agent 1227 might supply the authorization for a resource designated by the 1228 attacker, possibly causing the server or its clients to undertake 1229 actions designated by the attacker as though they were authorized by 1230 the user. 1232 Instead of using cookies for authorization, server operators might 1233 wish to consider entangling designation and authorization by treating 1234 URLs as capabilities. Instead of storing secrets in cookies, this 1235 approach stores secrets in URLs, requiring the remote entity to 1236 supply the secret itself. Although this approach is not a panacea, 1237 judicious application of these principles can lead to more robust 1238 security. 1240 8.3. Clear Text 1242 Unless sent over a secure channel (such as TLS), the information in 1243 the Cookie and Set-Cookie headers is transmitted in the clear. 1245 1. All sensitive information conveyed in these headers is exposed to 1246 an eavesdropper. 1248 2. A malicious intermediary could alter the headers as they travel 1249 in either direction, with unpredictable results. 1251 3. A malicious client could alter the Cookie header before 1252 transmission, with unpredictable results. 1254 Servers SHOULD encrypt and sign the contents of cookies when 1255 transmitting them to the user agent (even when sending the cookies 1256 over a secure channel). However, encrypting and signing cookie 1257 contents does not prevent an attacker from transplanting a cookie 1258 from one user agent to another or from replaying the cookie at a 1259 later time. 1261 In addition to encrypting and signing the contents of every cookie, 1262 servers that require a higher level of security SHOULD use the Cookie 1263 and Set-Cookie headers only over a secure channel. When using 1264 cookies over a secure channel, servers SHOULD set the Secure 1265 attribute (see Section 4.1.2.5) for every cookie. If a server does 1266 not set the Secure attribute, the protection provided by the secure 1267 channel will be largely moot. 1269 8.4. Session Identifiers 1271 Instead of storing session information directly in a cookie (where it 1272 might be exposed to or replayed by an attacker), servers commonly 1273 store a nonce (or "session identifier") in a cookie. When the server 1274 receives an HTTP request with a nonce, the server can look up state 1275 information associated with the cookie using the nonce as a key. 1277 Using session identifier cookies limits the damage an attacker can 1278 cause if the attacker learns the contents of a cookie because the 1279 nonce is useful only for interacting with the server (unlike non- 1280 nonce cookie content, which might itself be sensitive). Furthermore, 1281 using a single nonce prevents an attacker from "splicing" together 1282 cookie content from two interactions with the server, which could 1283 cause the server to behave unexpectedly. 1285 Using session identifiers is not without risk. For example, the 1286 server SHOULD take care to avoid "session fixation" vulnerabilities. 1287 A session fixation attack proceeds in three steps. First, the 1288 attacker transplants a session identifier from his or her user agent 1289 to the victim's user agent. Second, the victim uses that session 1290 identifier to interact with the server, possibly imbuing the session 1291 identifier with the user's credentials or confidential information. 1292 Third, the attacker uses the session identifier to interact with 1293 server directly, possibly obtaining the user's authority or 1294 confidential information. 1296 8.5. Weak Confidentiality 1298 Cookies do not provide isolation by port. If a cookie is readable by 1299 a service running on one port, the cookie is also readable by a 1300 service running on another port of the same server. If a cookie is 1301 writable by a service on one port, the cookie is also writable by a 1302 service running on another port of the same server. For this reason, 1303 servers SHOULD NOT both run mutually distrusting services on 1304 different ports of the same host and use cookies to store security- 1305 sensitive information. 1307 Cookies do not provide isolation by scheme. Although most commonly 1308 used with the http and https schemes, the cookies for a given host 1309 might also be available to other schemes, such as ftp and gopher. 1310 Although this lack of isolation by scheme is most apparent in non- 1311 HTTP APIs that permit access to cookies (e.g., HTML's document.cookie 1312 API), the lack of isolation by scheme is actually present in 1313 requirements for processing cookies themselves (e.g., consider 1314 retrieving a URI with the gopher scheme via HTTP). 1316 Cookies do not always provide isolation by path. Although the 1317 network-level protocol does not send cookies stored for one path to 1318 another, some user agents expose cookies via non-HTTP APIs, such as 1319 HTML's document.cookie API. Because some of these user agents (e.g., 1320 web browsers) do not isolate resources received from different paths, 1321 a resource retrieved from one path might be able to access cookies 1322 stored for another path. 1324 8.6. Weak Integrity 1326 Cookies do not provide integrity guarantees for sibling domains (and 1327 their subdomains). For example, consider foo.example.com and 1328 bar.example.com. The foo.example.com server can set a cookie with a 1329 Domain attribute of "example.com" (possibly overwriting an existing 1330 "example.com" cookie set by bar.example.com), and the user agent will 1331 include that cookie in HTTP requests to bar.example.com. In the 1332 worst case, bar.example.com will be unable to distinguish this cookie 1333 from a cookie it set itself. The foo.example.com server might be 1334 able to leverage this ability to mount an attack against 1335 bar.example.com. 1337 Even though the Set-Cookie header supports the Path attribute, the 1338 Path attribute does not provide any integrity protection because the 1339 user agent will accept an arbitrary Path attribute in a Set-Cookie 1340 header. For example, an HTTP response to a request for 1341 http://example.com/foo/bar can set a cookie with a Path attribute of 1342 "/qux". Consequently, servers SHOULD NOT both run mutually 1343 distrusting services on different paths of the same host and use 1344 cookies to store security-sensitive information. 1346 An active network attacker can also inject cookies into the Cookie 1347 header sent to https://example.com/ by impersonating a response from 1348 http://example.com/ and injecting a Set-Cookie header. The HTTPS 1349 server at example.com will be unable to distinguish these cookies 1350 from cookies that it set itself in an HTTPS response. An active 1351 network attacker might be able to leverage this ability to mount an 1352 attack against example.com even if example.com uses HTTPS 1353 exclusively. 1355 Servers can partially mitigate these attacks by encrypting and 1356 signing the contents of their cookies. However, using cryptography 1357 does not mitigate the issue completely because an attacker can replay 1358 a cookie he or she received from the authentic example.com server in 1359 the user's session, with unpredictable results. 1361 Finally, an attacker might be able to force the user agent to delete 1362 cookies by storing a large number of cookies. Once the user agent 1363 reaches its storage limit, the user agent will be forced to evict 1364 some cookies. Servers SHOULD NOT rely upon user agents retaining 1365 cookies. 1367 8.7. Reliance on DNS 1369 Cookies rely upon the Domain Name System (DNS) for security. If the 1370 DNS is partially or fully compromised, the cookie protocol might fail 1371 to provide the security properties required by applications. 1373 9. References 1375 9.1. Normative References 1377 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1378 STD 13, RFC 1034, November 1987. 1380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1381 Requirement Levels", BCP 14, RFC 2119, March 1997. 1383 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1384 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1385 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1387 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1388 "Internationalizing Domain Names in Applications (IDNA)", 1389 RFC 3490, March 2003. 1391 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1392 10646", STD 63, RFC 3629, November 2003. 1394 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 1395 Application Protocol Collation Registry", RFC 4790, 1396 March 2007. 1398 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1399 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1401 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1402 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1404 9.2. Informative References 1406 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 1407 Mechanism", RFC 2109, February 1997. 1409 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1410 Mechanism", RFC 2965, October 2000. 1412 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1414 [Netscape] 1415 "Persistent Client State -- HTTP Cookies". 1417 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 1418 Politics", ACM Transactions on Internet Technology Vol. 1, 1419 #2, November 2001, . 1421 Appendix A. Acknowledgements 1423 This document borrows heavily from RFC 2109 [RFC2109]. We are 1424 indebted to David M. Kristol and Lou Montulli for their efforts to 1425 specify the cookie protocol. David M. Kristol, in particular, 1426 provided invaluable advice on navigating the IETF process. We would 1427 also like to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, 1428 Lisa Dusseault, Roy T. Fielding, Blake Frantz, Eran Hammer-Lahav, 1429 Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg Koppen, Dean 1430 McNamee, Mark Miller, Mark Pauley, Yngve N. Pettersen, Julian 1431 Reschke, Peter Saint-Andre, Mark Seaborn, Maciej Stachowiak, Daniel 1432 Stenberg, David Wagner, Dan Winship, and Dan Witte for their valuable 1433 feedback on this document. 1435 Author's Address 1437 Adam Barth 1438 University of California, Berkeley 1440 Email: abarth@eecs.berkeley.edu 1441 URI: http://www.adambarth.com/