idnits 2.17.1 draft-ietf-httpstate-cookie-08.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 23, 2010) is 5110 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) ** 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) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 23, 2010 5 Intended status: Standards Track 6 Expires: October 25, 2010 8 HTTP State Management Mechanism 9 draft-ietf-httpstate-cookie-08 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 25, 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 . . . . . . . . . . . . . . . . . . . . . . . 7 83 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 return the cookie, the 139 servers to which the user agent should return the cookie, and the 140 protocols for which 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 Prior to this document, there were at least three descriptions of 152 cookies: the so-called "Netscape cookie specification," RFC 2109 153 [RFC2109], and RFC 2965 [RFC2965]. However, none of these documents 154 describe how the Cookie and Set-Cookie headers are actually used on 155 the Internet. By contrast, this document attempts to specify the 156 syntax and semantics of these headers as they are actually used on 157 the Internet. 159 2. General Nonsense 161 2.1. Conformance Criteria 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 164 "RECOMMENDED", "MAY", and "OPTIONAL" in document are to be 165 interpreted as described in [RFC2119]. 167 Requirements phrased in the imperative as part of algorithms (such as 168 "strip any leading space characters" or "return false and abort these 169 steps") are to be interpreted with the meaning of the key word 170 ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. 172 Conformance requirements phrased as algorithms or specific steps can 173 be implemented in any manner, so long as the end result is 174 equivalent. In particular, the algorithms defined in this 175 specification are intended to be easy to understand and are not 176 intended to be performant. 178 2.2. Syntax Notation 180 This specification uses the Augmented Backus-Naur Form (ABNF) 181 notation of [RFC5234]. 183 The following core rules are included by reference, as defined in 184 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 185 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 186 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 187 sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US- 188 ASCII character), VCHAR (any visible US-ASCII character), and WSP 189 (whitespace). 191 The OWS (optional whitespace) rule is used where zero or more linear 192 whitespace characters MAY appear: 194 OWS = *( [ obs-fold ] WSP ) 195 ; "optional" whitespace 196 obs-fold = CRLF 198 OWS SHOULD either not be produced or be produced as a single SP 199 character. Multiple OWS characters that occur within field-content 200 SHOULD be replaced with a single SP before interpreting the field 201 value or forwarding the message downstream. 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]). 208 The terms request-host and request-uri refer to the values the user 209 agent would send to the server as, respectively, the host (but not 210 port) and the absoluteURI (http_URL) of the HTTP Request-Line. 212 3. Overview 214 We outline here a way for an origin server to send state information 215 to a user agent and for the user agent to return the state 216 information to the origin server. 218 To store state, the origin server includes a Set-Cookie header in an 219 HTTP response. In subsequent requests, the user agent returns a 220 Cookie request header to the origin server. The Cookie header 221 contains a number of cookies the user agent received in previous Set- 222 Cookie headers. The origin server is free to ignore the Cookie 223 header or use its contents for an application-defined purpose. The 224 origin server MAY send the user agent a Set-Cookie response header 225 with the same or different information, or it MAY send no Set-Cookie 226 header at all. 228 Servers MAY return a Set-Cookie response header with any response. 229 An origin server MAY include multiple Set-Cookie header fields in a 230 single response. Gateways that wish to be transparent to cookies 231 MUST NOT fold multiple Set-Cookie header fields into a single header 232 field. 234 3.1. Examples 236 Using the Set-Cookie header, a server can send the user agent a short 237 string in an HTTP response that the user agent will return in future 238 HTTP requests. For example, the server can send the user agent a 239 "session identifier" named SID with the value 31d4d96e407aad42. The 240 user agent then returns the session identifier in subsequent 241 requests. 243 == Server -> User Agent == 244 Set-Cookie: SID=31d4d96e407aad42 246 == User Agent -> Server == 247 Cookie: SID=31d4d96e407aad42 249 The server can alter the default scope of the cookie using the Path 250 and Domain attributes. For example, the server can instruct the user 251 agent to return the cookie to every path and every subdomain of 252 example.com. 254 == Server -> User Agent == 255 Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com 256 == User Agent -> Server == 257 Cookie: SID=31d4d96e407aad42 259 The server can store multiple cookies at the user agent. For 260 example, the server can store a session identifier as well as the 261 user's preferred language by returning two Set-Cookie header fields. 262 Notice that the server uses the Secure and HttpOnly attributes to 263 provide additional security protections for the more-sensitive 264 session identifier. 266 == Server -> User Agent == 267 Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly 268 Set-Cookie: lang=en-US; Path=/; Domain=example.com 270 == User Agent -> Server == 271 Cookie: SID=31d4d96e407aad42; lang=en-US 273 If the server wishes the user agent to persist the cookie over 274 multiple sessions, the server can specify a expiration date in the 275 Expires attribute. Note that the user agent might delete the cookie 276 before the expiration date if the user agent's cookie store exceeds 277 its quota or if the user manually deletes the server's cookie. 279 == Server -> User Agent == 280 Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT 282 == User Agent -> Server == 283 Cookie: SID=31d4d96e407aad42; lang=en-US 285 Finally, to remove a cookie, the server returns a Set-Cookie header 286 with an expiration date in the past. The server will be successful 287 in removing the cookie only if the Path and the Domain attribute in 288 the Set-Cookie header match the values used when the cookie was 289 created. 291 == Server -> User Agent == 292 Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT 294 == User Agent -> Server == 295 Cookie: SID=31d4d96e407aad42 297 4. Server Requirements 299 This section describes the syntax and semantics of a well-behaved 300 profile of the Cookie and Set-Cookie headers. Servers SHOULD use the 301 profile described in this section, both to maximize interoperability 302 with existing user agents and because a future version of the Cookie 303 or Set-Cookie headers could remove support for some of the most 304 esoteric semantics. User agents, however, MUST implement the full 305 semantics to ensure interoperability with servers making use of the 306 full semantics. 308 4.1. Set-Cookie 310 The Set-Cookie header is used to send cookies from the server to the 311 user agent. 313 4.1.1. Syntax 315 Informally, the Set-Cookie response header contains the header name 316 "Set-Cookie" followed by a ":" and a cookie. Each cookie begins with 317 a name-value pair, followed by zero or more attribute-value pairs. 318 Servers SHOULD NOT send Set-Cookie headers that fail to conform to 319 the following grammar: 321 set-cookie-header = "Set-Cookie:" SP set-cookie-string 322 set-cookie-string = cookie-pair *( ";" SP cookie-av ) 323 cookie-pair = cookie-name "=" cookie-value 324 cookie-name = token 325 cookie-value = token 326 token = 328 cookie-av = expires-av / max-age-av / domain-av / 329 path-av / secure-av / httponly-av / 330 extension-av 331 expires-av = "Expires=" sane-cookie-date 332 sane-cookie-date = 333 max-age-av = "Max-Age=" 1*DIGIT 334 domain-av = "Domain=" domain-value 335 domain-value = 336 path-av = "Path=" path-value 337 path-value = 338 secure-av = "Secure" 339 httponly-av = "HttpOnly" 340 extension-av = 342 Servers SHOULD NOT include two attributes with the same name. 344 Servers SHOULD NOT include two Set-Cookie header fields in the same 345 response with the same cookie-name. 347 The cookie-value is opaque to the user agent and MAY be anything the 348 origin server chooses to send. "Opaque" implies that the content is 349 of interest and relevance only to the origin server. The content is, 350 in fact, readable by anyone who examines the Set-Cookie header. 352 To maximize compatibility with user agents, servers that wish to 353 store non-ASCII data in a cookie-value SHOULD encode that data using 354 a printable ASCII encoding. 356 If a server sends multiple responses containing Set-Cookie headers 357 concurrently to the user agent (e.g., when communicating with the 358 user agent over multiple sockets), these responses create a "race 359 condition" that can lead to unpredictable behavior. 361 NOTE: Some user agents represent dates using 32-bit UNIX time_t 362 values. Some of these user agents might contain bugs that cause them 363 process dates after the year 2038 incorrectly. Servers wishing to 364 interoperate with these user agents might wish to use dates before 365 2038. 367 4.1.2. Semantics (Non-Normative) 369 This section describes a simplified semantics of the Set-Cookie 370 header. These semantics are detailed enough to be useful for 371 understanding the most common uses of cookies. The full semantics 372 are described in Section 5. 374 When the user agent receives a Set-Cookie header, the user agent 375 stores the cookie in its cookie store. Subsequently, when the user 376 agent makes an HTTP request, the user agent consults its cookie store 377 and includes the applicable, non-expired cookies in the Cookie 378 header. 380 If the user agent receives a new cookie with the same cookie-name, 381 domain-value, and path-value as a cookie that already exists in its 382 cookie store, the existing cookie is evicted from the cookie store 383 and replaced with the new cookie. Notice that servers can delete 384 cookies by sending the user agent a new cookie with an Expires 385 attribute with a value in the past. 387 Unless the cookie's attributes indicate otherwise, the cookie is 388 returned only to the origin server, and it expires at the end of the 389 current session (as defined by the user agent). User agents ignore 390 unrecognized cookie attributes. 392 4.1.2.1. The Expires Attribute 394 The Expires attribute indicates the maximum lifetime of the cookie, 395 represented as the date and time at which the cookie expires. The 396 user agent is not required to retain the cookie until the specified 397 date has passed. In fact, user agents often evict cookies from the 398 cookie store due to memory pressure or privacy concerns. 400 4.1.2.2. The Max-Age Attribute 402 The Max-Age attribute indicates the maximum lifetime of the cookie, 403 represented as the number of seconds until the cookie expires. The 404 user agent is not required to retain the cookie until the specified 405 date has passed. In fact, user agents often evict cookies from the 406 cookie store due to memory pressure or privacy concerns. 408 WARNING: Not all user agents support the Max-Age attribute. User 409 agents that do not support the Max-Age attribute will ignore the 410 attribute. 412 If a cookie has both the Max-Age and the Expires attribute, the Max- 413 Age attribute has precedence and controls the expiration date of the 414 cookie. If a cookie has neither the Max-Age nor the Expires 415 attribute, the user agent will retain the cookie until "the current 416 session is over" (as defined by the user agent). 418 4.1.2.3. The Domain Attribute 420 The Domain attribute specifies those hosts to which the cookie will 421 be sent. For example, if the Domain attribute contains the value 422 "example.com", the user agent will include the cookie in the Cookie 423 header when making HTTP requests to example.com, www.example.com, and 424 www.corp.example.com. (Note that a leading U+002E ("."), if present, 425 is ignored even though that character is not permitted by the 426 subdomain production in [RFC1034].) If the server omits the Domain 427 attribute, the user agent will return the cookie only to the origin 428 server. 430 WARNING: Some legacy user agents treat an absent Domain attribute 431 as if the Domain attribute were present and contained the current 432 host name. For example, if example.com returns a Set-Cookie 433 header without a Domain attribute, these user agents will 434 erroneously send the cookie to www.example.com as well. 436 The user agent will reject cookies (refuse to store them in the 437 cookie store) unless the Domain attribute specifies a scope for the 438 cookie that would include the origin server. For example, the user 439 agent will accept a Domain attribute of "example.com" or of 440 "foo.example.com" from foo.example.com, but the user agent will not 441 accept a Domain attribute of "bar.example.com" or of 442 "baz.foo.example.com". 444 NOTE: For security reasons, some user agents are configured to reject 445 Domain attributes that correspond to "public suffixes." For example, 446 some user agents will reject Domain attributes of "com" or "co.uk". 448 4.1.2.4. The Path Attribute 450 The scope of each cookie is limited to a set of paths, controlled by 451 the Path attribute. If the server omits the Path attribute, the user 452 agent will use the directory of the request-uri's path component as 453 the default value. 455 The user agent will include the cookie in an HTTP request only if the 456 path portion of the request-uri matches (or is a subdirectory of) the 457 cookie's Path attribute, where the U+002F ("/") character is 458 interpreted as a directory separator. 460 Although seemingly useful for isolating cookies between different 461 paths within a given domain, the Path attribute cannot be relied upon 462 for security (see Section 8). 464 4.1.2.5. The Secure Attribute 466 The Secure attribute limits the scope of the cookie to "secure" 467 channels (where "secure" is defined by the user agent). When a 468 cookie has the Secure attribute, the user agent will include the 469 cookie in an HTTP request only if the request is transmitted over a 470 secure channel (typically TLS [RFC5246]). 472 Although seemingly useful for protecting cookies from active network 473 attackers, the Secure attribute protects only the cookie's 474 confidentiality. An active network attacker can overwrite Secure 475 cookies from an insecure channel, disrupting its integrity. 477 4.1.2.6. The HttpOnly Attribute 479 The HttpOnly attribute limits the scope of the cookie to HTTP 480 requests. In particular, the attribute instructs the user agent to 481 omit the cookie when providing access to its cookie store via "non- 482 HTTP" APIs (such as HTML's document.cookie API). 484 4.2. Cookie 485 4.2.1. Syntax 487 The user agent returns stored cookies to the origin server in the 488 Cookie header. If the server conforms to the requirements in 489 Section 4.1, the requirements in the Section 5 will cause the user 490 agent to return a Cookie header that conforms to the following 491 grammar: 493 cookie-header = "Cookie:" OWS cookie-string OWS 494 cookie-string = cookie-pair *( ";" SP cookie-pair ) 496 4.2.2. Semantics 498 Each cookie-pair represents a cookie stored by the user agent. The 499 cookie-name and the cookie-value are returned from the corresponding 500 parts of the Set-Cookie header. 502 Notice that the cookie attributes are not returned. In particular, 503 the server cannot determine from the Cookie header alone when a 504 cookie will expire, for which domains the cookie is valid, for which 505 paths the cookie is valid, or whether the cookie was set with the 506 Secure or HttpOnly attributes. 508 The semantics of individual cookies in the Cookie header is not 509 defined by this document. Servers are expected to imbue these 510 cookies with application-specific semantics. 512 Although cookies are serialized linearly in the Cookie header, 513 servers SHOULD NOT rely upon the serialization order. In particular, 514 if the Cookie header contains two cookies with the same name (e.g., 515 with different Path or Domain attributes), servers SHOULD NOT rely 516 upon the order in which these cookies appear in the header. 518 5. User Agent Requirements 520 For historical reasons, the full semantics of cookies contains a 521 number of exotic quirks. This section is intended to specify the 522 Cookie and Set-Cookie headers in sufficient detail to allow a user 523 agent implementing these requirements precisely to interoperate with 524 existing servers. 526 5.1. Algorithms 528 This section defines a number of algorithms used by user agents to 529 process the Cookie and Set-Cookie headers. 531 5.1.1. Dates 533 The user agent MUST use an algorithm equivalent to the following 534 algorithm to parse a cookie-date: 536 1. Using the grammar below, divide the cookie-date into date-tokens. 538 cookie-date = *delimiter date-token-list *delimiter 539 date-token-list = date-token *( 1*delimiter date-token ) 540 delimiter = %x09 / %x20 / %x21 / %x22 / %x23 / %x24 / 541 %x25 / %x26 / %x27 / %x28 / %x29 / %x2A / 542 %x2B / %x2C / %x2D / %x2E / %x2F / %x3B / 543 %x3C / %x3D / %x3E / %x3F / %x40 / %x5B / 544 %x5C / %x5D / %x5E / %x5F / %x60 / %x7B / 545 %x7C / %x7D / %x7E 546 date-token = day-of-month / month / year / time / mystery 547 day-of-month = 2DIGIT / DIGIT 548 month = "jan" [ mystery ] / "feb" [ mystery ] / 549 "mar" [ mystery ] / "apr" [ mystery ] / 550 "may" [ mystery ] / "jun" [ mystery ] / 551 "jul" [ mystery ] / "aug" [ mystery ] / 552 "sep" [ mystery ] / "oct" [ mystery ] / 553 "nov" [ mystery ] / "dec" [ mystery ] 554 year = 4DIGIT / 3DIGIT / 2DIGIT / DIGIT 555 time = time-field ":" time-field ":" time-field 556 time-field = 2DIGIT / DIGIT 557 CTLwoHTAB = %x00-08 / %x0A-1F / %x7F 558 ; CTL except HTAB 559 mystery = CTLwoHTAB / ":" / ALPHA / DIGIT / %x80-FF 560 ; any OCTET except a delimiter 562 2. Process each date-token sequentially in the order the date-tokens 563 appear in the cookie-date: 565 1. If the found-day-of-month flag is not set and the date-token 566 matches the day-of-month production, set the found-day-of- 567 month flag and set the day-of-month-value to the number 568 denoted by the date-token. Skip the remaining sub-steps and 569 continue to the next date-token. 571 2. If the found-month flag is not set and the date-token matches 572 the month production, set the found-month flag and set the 573 month-value to the month denoted by the date-token. Skip the 574 remaining sub-steps and continue to the next date-token. 576 3. If the found-year flag is not set and the date-token matches 577 the year production, set the found-year flag and set the 578 year-value to the number denoted by the date-token. Skip the 579 remaining sub-steps and continue to the next date-token. 581 4. If the found-time flag is not set and the token matches the 582 time production, set the found-time flag and set the hour- 583 value, minute-value, and second-value to the numbers denoted 584 by the digits in the date-token, respectively. Skip the 585 remaining sub-steps and continue to the next date-token. 587 3. If the year-value is greater than 68 and less than 100, increment 588 the year-value by 1900. 590 4. If the year-value is greater than or equal to 0 and less than 69, 591 increment the year-value by 2000. 593 5. Abort these steps and fail to parse if 595 * at least one of the found-day-of-month, found-month, found- 596 year, or found-time flags is not set, 598 * the day-of-month-value is less than 1 or greater than 31, 600 * the year-value is less than 1601, 602 * the hour-value is greater than 23, 604 * the minute-value is greater than 59, or 606 * the second-value is greater than 59. 608 6. Let the parsed-cookie-date be the date whose day-of-month, month, 609 year, hour, minute, and second (in GMT) are the day-of-month- 610 value, the month-value, the year-value, the hour-value, the 611 minute-value, and the second-value, respectively. 613 7. Return the parsed-cookie-date as the result of this algorithm. 615 5.1.2. Domains 617 A canonicalized host-name is the host-name converted to lower case 618 and converted to ASCII according to the IDNA specification [RFC3490]. 620 A host-name domain-matches a cookie-domain if at least one of the 621 following conditions hold: 623 o The cookie-domain and the host-name are identical. 625 o All of the following conditions hold: 627 * The cookie-domain is a suffix of the host-name. 629 * The last character of the host-name that is not included in the 630 cookie-domain is a U+002E (".") character. 632 * The host-name is a host name (i.e., not an IP address). 634 5.1.3. Paths 636 The user agent MUST use an algorithm equivalent to the following 637 algorithm to compute the default-path of a cookie: 639 1. Let uri-path be the path portion of the request-uri. That is, if 640 the request-uri contains just a path (and optional query string), 641 then the uri-path is that path (without the U+003F ("?") 642 character or query string), and if the request-uri contains a 643 full absoluteURI, the uri-path is the abs_path component of that 644 URI. 646 2. If the uri-path is empty or if first character of the uri-path is 647 not a U+002F ("/") character, output U+002F ("/") and skip the 648 remaining steps. 650 3. If the uri-path contains only a single U+002F ("/") character, 651 output U+002F ("/") and skip the remaining steps. 653 4. Output the characters of the uri-path from the first character up 654 to, but not including, the right-most U+002F ("/"). 656 A request-path path-matches a cookie-path if at least one of the 657 following conditions hold: 659 o The cookie-path and the request-path are identical. 661 o The cookie-path is a prefix of the request-path and the last 662 character of the cookie-path is U+002F ("/"). 664 o The cookie-path is a prefix of the request-path and the first 665 character of the request-path that is not included in the cookie- 666 path is a U+002F ("/") character. 668 5.2. The Set-Cookie Header 670 When a user agent receives a Set-Cookie header in an HTTP response, 671 the user agent receives a set-cookie-string consisting of the value 672 of the header. 674 A user agent MUST use an algorithm equivalent to the following 675 algorithm to parse set-cookie-strings: 677 1. If the set-cookie-string contains a U+003B (";") character: 679 The name-value-pair string consists of the characters up to, 680 but not including, the first U+003B (";"), and the unparsed- 681 attributes consist of the remainder of the set-cookie-string 682 (including the U+003B (";") in question). 684 Otherwise: 686 The name-value-pair string consists of all the characters 687 contained in the set-cookie-string, and the unparsed- 688 attributes is the empty string. 690 2. If the name-value-pair string lacks a U+003D ("=") character, 691 ignore the set-cookie-string entirely. 693 3. The (possibly empty) name string consists of the characters up 694 to, but not including, the first U+003D ("=") character, and the 695 (possibly empty) value string consists of the characters after 696 the first U+003D ("=") character. 698 4. Remove any leading or trailing WSP characters from the name 699 string and the value string. 701 5. If the name string is empty, ignore the set-cookie-string 702 entirely. 704 6. The cookie-name is the name string, and the cookie-value is the 705 value string. 707 The user agent MUST use an algorithm equivalent to the following 708 algorithm to parse the unparsed-attributes: 710 1. If the unparsed-attributes string is empty, skip the rest of 711 these steps. 713 2. Discard the first character of the unparsed-attributes (which 714 will be a U+003B (";") character). 716 3. If the remaining unparsed-attributes contains a U+003B (";") 717 character: 719 Consume the characters of the unparsed-attributes up to, but 720 not including, the first U+003B (";") character. 722 Otherwise: 724 Consume the remainder of the unparsed-attributes. 726 Let the cookie-av string be the characters consumed in this step. 728 4. If the cookie-av string contains a U+003D ("=") character: 730 The (possibly empty) attribute-name string consists of the 731 characters up to, but not including, the first U+003D ("=") 732 character, and the (possibly empty) attribute-value string 733 consists of the characters after the first U+003D ("=") 734 character. 736 Otherwise: 738 The attribute-name string consists of the entire cookie-av 739 string, and the attribute-value string is empty. 741 5. Remove any leading or trailing WSP characters from the attribute- 742 name string and the attribute-value string. 744 6. Process the attribute-name and attribute-value according to the 745 requirements in the following subsections. (Notice that 746 attributes with unrecognizeed attribute-names are ignored.) 748 7. Return to Step 1. 750 When the user agent finishes parsing the set-cookie-string, the user 751 agent receives a cookie from the request-uri with name cookie-name, 752 value cookie-value, and attributes cookie-attribute-list. 754 5.2.1. The Expires Attribute 756 If the attribute-name case-insensitively matches the string 757 "Expires", the user agent MUST process the cookie-av as follows. 759 Let the parsed-cookie-date be the result of parsing the attribute- 760 value as cookie-date. 762 If the attribute-value failed to parse as a cookie date, ignore the 763 cookie-av. 765 If the user agent received the set-cookie-string from an HTTP 766 response that contains a Date header field and the contents of the 767 last Date header field successfully parse as a cookie-date: 769 Let server-date be the date obtained by parsing the contents of 770 the last Date header field as a cookie-date. 772 Let delta-seconds be the number of seconds between the server-date 773 and the parsed-cookie-date (i.e., parsed-cookie-date - server- 774 date). 776 Let the expiry-time be the current date and time plus delta- 777 seconds seconds. 779 Otherwise: 781 Let the expiry-time be the parsed-cookie-date. 783 If the expiry-time is later than the last date the user agent can 784 represent, the user agent MAY replace the expiry-time with the last 785 representable date. 787 If the expiry-time is earlier than the first date the user agent can 788 represent, the user agent MAY replace the expiry-time with the first 789 representable date. 791 Append an attribute to the cookie-attribute-list with an attribute- 792 name of Expires and an attribute-value of expiry-time. 794 5.2.2. The Max-Age Attribute 796 If the attribute-name case-insensitively matches the string "Max- 797 Age", the user agent MUST process the cookie-av as follows. 799 If the first character of the attribute-value is not a DIGIT or a "-" 800 character, ignore the cookie-av. 802 If the remainder of attribute-value contains a non-DIGIT character, 803 ignore the cookie-av. 805 Let delta-seconds be the attribute-value converted to an integer. 807 If delta-seconds is less than or equal to zero (0), let expiry-time 808 be the earliest representable date and time. Otherwise, let the 809 expiry-time be the current date and time plus delta-seconds seconds. 811 Append an attribute to the cookie-attribute-list with an attribute- 812 name of Max-Age and an attribute-value of expiry-time. 814 5.2.3. The Domain Attribute 816 If the attribute-name case-insensitively matches the string "Domain", 817 the user agent MUST process the cookie-av as follows. 819 If the attribute-value is empty, the behavior is undefined. However, 820 user agent SHOULD ignore the cookie-av entirely. 822 If the first character of the attribute-value string is U+002E ("."): 824 Let cookie-domain be the attribute-value without the leading 825 U+002E (".") character. 827 Otherwise: 829 Let cookie-domain be the entire attribute-value. 831 Convert the cookie-domain to lower case. 833 Append an attribute to the cookie-attribute-list with an attribute- 834 name of Domain and an attribute-value of cookie-domain. 836 5.2.4. The Path Attribute 838 If the attribute-name case-insensitively matches the string "Path", 839 the user agent MUST process the cookie-av as follows. 841 If the attribute-value is empty or if the first character of the 842 attribute-value is not U+002F ("/"): 844 Let cookie-path be the default-path. 846 Otherwise: 848 Let cookie-path be the attribute-value. 850 Append an attribute to the cookie-attribute-list with an attribute- 851 name of Path and an attribute-value of cookie-path. 853 5.2.5. The Secure Attribute 855 If the attribute-name case-insensitively matches the string "Secure", 856 the user agent MUST append an attribute to the cookie-attribute-list 857 with an attribute-name of Secure and an empty attribute-value. 859 5.2.6. The HttpOnly Attribute 861 If the attribute-name case-insensitively matches the string 862 "HttpOnly", the user agent MUST append an attribute to the cookie- 863 attribute-list with an attribute-name of HttpOnly and an empty 864 attribute-value. 866 5.3. Storage Model 868 The user agent stores the following fields about each cookie: name, 869 value, expiry-time, domain, path, creation-time, last-access-time, 870 persistent-flag, host-only-flag, secure-only-flag, and http-only- 871 flag. 873 When the user agent receives a cookie from a request-uri with name 874 cookie-name, value cookie-value, and attributes cookie-attribute- 875 list, the user agent MUST process the cookie as follows: 877 1. A user agent MAY ignore a received cookie in its entirety. For 878 example, the user agent might wish to block receiving cookies 879 from "third-party" responses or the user agent might not wish to 880 store cookie that exceed some size. 882 2. Create a new cookie with name cookie-name, value cookie-value. 883 Set the creation-time and the last-access-time to the current 884 date and time. 886 3. If the cookie-attribute-list contains an attribute with an 887 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 "Max-Age". 895 Otherwise, if the cookie-attribute-list contains an attribute 896 with an attribute-name of "Expires" (and does not contain an 897 attribute with an attribute-name of "Max-Age"): 899 Set the cookie's persistent-flag to true. 901 Set the cookie's expiry-time to attribute-value of the last 902 attribute in the cookie-attribute-list with an attribute-name 903 of "Expires". 905 Otherwise: 907 Set the cookie's persistent-flag to false. 909 Set the cookie's expiry-time to the latest representable 910 date. 912 4. If the cookie-attribute-list contains an attribute with an 913 attribute-name of "Domain": 915 Let the domain-attribute be the attribute-value of the last 916 attribute in the cookie-attribute-list with an attribute-name 917 of "Domain". 919 Otherwise: 921 Let the domain-attribute be the empty string. 923 5. If the user agent is configured to reject "public suffixes" and 924 the domain-attribute is a public suffix: 926 If the domain-attribute is identical to the canonicalized 927 request-host: 929 Let the domain-attribute be the empty string. 931 Otherwise: 933 Ignore the cookie entirely and abort these steps 935 NOTE: A "public suffix" is a domain that is controlled by a 936 public registry, such as "com", "co.uk", and "pvt.k12.wy.us". 937 This step is essential for preventing attacker.com from 938 disrupting the integrity of example.com by setting a cookie 939 with a Domain attribute of "com". Unfortunately, the set of 940 public suffixes (also known as "registry controlled domains") 941 changes over time. If feasible, user agents SHOULD use an 942 up-to-date public suffix list, such as the one maintained by 943 the Mozilla project at http://publicsuffix.org/. 945 6. If the domain-attribute is non-empty: 947 If the cannonicalized request-host does not domain-match the 948 domain-attribute, ignore the cookie entirely and abort these 949 steps. 951 Set the cookie's host-only-flag to false. 953 Set the cookie's domain to the domain-attribute. 955 Otherwise: 957 Set the cookie's host-only-flag to true. 959 Set the cookie's domain to the canonicalized request-host. 961 7. If the cookie-attribute-list contains an attribute with an 962 attribute-name of "Path", set the cookie's path to attribute- 963 value of the last attribute in the cookie-attribute-list with an 964 attribute-name of "Path". Otherwise, set cookie's path to the 965 default-path of the request-uri. 967 8. If the cookie-attribute-list contains an attribute with an 968 attribute-name of "Secure", set the cookie's secure-only-flag to 969 true. Otherwise, set cookie's secure-only-flag to false. 971 9. If the cookie-attribute-list contains an attribute with an 972 attribute-name of "HttpOnly", set the cookie's http-only-flag to 973 true. Otherwise, set cookie's http-only-flag to false. 975 10. If the cookie was received from a non-HTTP API and the cookie's 976 http-only-flag is set, abort these steps and ignore the cookie 977 entirely. 979 11. If the cookie store contains a cookie with the same name, 980 domain, and path as the newly created cookie: 982 1. Let old-cookie be the existing cookie with the same name, 983 domain, and path as the newly created cookie. (Notice that 984 this algorithm maintains the invariant that there is at most 985 one such cookie.) 987 2. If the newly created cookie was received from an non-HTTP 988 API and the old-cookie's http-only-flag is set, abort these 989 steps and ignore the newly created cookie entirely. 991 3. Update the creation-time of the newly created cookie to 992 match the creation-time of the old-cookie. 994 4. Remove the old-cookie from the cookie store. 996 12. Insert the newly created cookie into the cookie store. 998 A cookie is "expired" if the cookie has an expiry date in the past. 1000 The user agent MUST evict all expired cookies from the cookie store 1001 if, at any time, an expired cookie exists in the cookie store. 1003 At any time, the user agent MAY "remove excess cookies" from the 1004 cookie store if the number of cookies sharing a domain field exceeds 1005 some predetermined upper bound (such as 50 cookies). 1007 At any time, the user agent MAY "remove excess cookies" form the 1008 cookie store if the cookie store exceeds some predetermined upper 1009 bound (such as 3000 cookies). 1011 When the user agent removes excess cookies from the cookie store, the 1012 user agent MUST evict cookies in the following priority order: 1014 1. Expired cookies. 1016 2. Cookies that share a domain field with more than a predetermined 1017 number of other cookies. 1019 3. All cookies. 1021 If two cookies have the same removal priority, the user agent MUST 1022 evict the cookie with the least recent last-access date first. 1024 When "the current session is over" (as defined by the user agent), 1025 the user agent MUST remove from the cookie store all cookies with the 1026 persistent-flag set to false. 1028 5.4. The Cookie Header 1030 When the user agent generates an HTTP request, the user agent SHOULD 1031 attach exactly one HTTP header named Cookie if the cookie-string 1032 (defined below) for the request-uri is non-empty. 1034 A user agent MAY omit the Cookie header in its entirety. For 1035 example, the user agent might wish to block sending cookies during 1036 "third-party" requests. 1038 The user agent MUST use an algorithm equivalent to the following 1039 algorithm to compute the cookie-string from a cookie store and a 1040 request-uri: 1042 1. Let cookie-list be the set of cookies from the cookie store that 1043 meet all of the following requirements: 1045 * Either: 1047 The cookie's host-only-flag is true and the canonicalized 1048 request-host is identical to the cookie's domain. 1050 Or: 1052 The cookie's host-only-flag is false and the canonicalized 1053 request-host domain-matches cookie's domain. 1055 * The request-uri's path path-matches cookie's path. 1057 * If the cookie's secure-only-flag is true, then the request- 1058 uri's scheme must denote a "secure" protocol (as defined by 1059 the user agent). 1061 NOTE: The notion of a "secure" protocol is not defined by 1062 this document. Typically, user agents consider a protocol 1063 secure if the protocol makes use of transport-layer 1064 security, such as TLS. For example, most user agents 1065 consider "https" to be a scheme that denotes a secure 1066 protocol. 1068 * If the cookie's http-only-flag is true, then exclude the 1069 cookie unless the cookie-string is being generated for an 1070 "HTTP" API (as defined by the user agent). 1072 2. The user agent SHOULD sort the cookie-list in the following 1073 order: 1075 * Cookies with longer paths are listed before cookies with 1076 shorter paths. 1078 * Among cookies that have equal length path fields, cookies with 1079 earlier creation-times are listed before cookies with later 1080 creation-times. 1082 NOTE: Not all user agents sort the cookie-list in this order, but 1083 this order reflects common practice when this document was 1084 written, and, historically, there have been servers that 1085 (erroneously) depended on this order. 1087 3. Update the last-access-time of each cookie in the cookie-list to 1088 the current date and time. 1090 4. Serialize the cookie-list into a cookie-string by processing each 1091 cookie in the cookie-list in order: 1093 1. Output the cookie's name, the U+003D ("=") character, and the 1094 cookie's value. 1096 2. If there is an unprocessed cookie in the cookie-list, output 1097 the characters U+003B and U+0020 ("; "). 1099 NOTE: Despite its name, the cookie-string is actually a sequence of 1100 octets, not a sequence of characters. To convert the cookie-string 1101 (or components thereof) into a sequence of characters (e.g., for 1102 presentation to the user), the user agent SHOULD use the UTF-8 1103 character encoding [RFC3629]. 1105 6. Implementation Considerations 1107 6.1. Limits 1109 Practical user agent implementations have limits on the number and 1110 size of cookies that they can store. General-use user agents SHOULD 1111 provide each of the following minimum capabilities: 1113 o At least 4096 bytes per cookie (as measured by the sum of the 1114 length of the cookie's name, value, and attributes). 1116 o At least 50 cookies per domain. 1118 o At least 3000 cookies total. 1120 Servers SHOULD use as few and as small cookies as possible to avoid 1121 reaching these implementation limits and to minimize network 1122 bandwidth due to the Cookie header being included in every request. 1124 Servers SHOULD gracefully degrade if the user agent fails to return 1125 one or more cookies in the Cookie header because the user agent might 1126 evict any cookie at any time on orders from the user. 1128 6.2. Application Programmer Interfaces 1130 One reason the Cookie and Set-Cookie headers uses such esoteric 1131 syntax is because many platforms (both in servers and user agents) 1132 provide a string-based application programmer interface (API) to 1133 cookies, requiring application-layer programmers to generate and 1134 parse the syntax used by the Cookie and Set-Cookie headers, which 1135 many programmers have done incorrectly, resulting in interoperability 1136 problems. 1138 Instead of providing string-based APIs to cookies, platforms would be 1139 well-served by providing more semantic APIs. It is beyond the scope 1140 of this document to recommend specific API designs, but there are 1141 clear benefits to accepting a abstract "Date" object instead of a 1142 serialized date string. 1144 7. Privacy Considerations 1146 Cookies are often criticized for letting servers track users. For 1147 example, a number of "web analytics" companies use cookies to 1148 recognize when a user returns to a web site or visits another web 1149 site. Although cookies are not the only mechanism servers can use to 1150 track users across HTTP requests, cookies facilitate tracking because 1151 they are persistent across user agent sessions and can be shared 1152 between domains. 1154 7.1. Third-Party Cookies 1156 Particularly worrisome are so-called "third-party" cookies. In 1157 rendering an HTML document, a user agent often requests resources 1158 from other servers (such as advertising networks). These third-party 1159 servers can use cookies to track the user even if the user never 1160 visits the server directly. 1162 Some user agents restrict how third-party cookies behave. For 1163 example, some user agents refuse to send the Cookie header in third- 1164 party requests. Other user agents refuse to process the Set-Cookie 1165 header in responses to third-party requests. User agents vary widely 1166 in their third-party cookie policies. This document grants user 1167 agents wide latitude to experiment with third-party cookie policies 1168 that balance the privacy and compatibility needs of their users. 1169 However, this document does not endorse any particular third-party 1170 cookie policy. 1172 Third-party cookie blocking policies are often ineffective at 1173 achieving their privacy goals if servers attempt to work around their 1174 restrictions to track users. In particular, two collaborating 1175 servers can often track users without using cookies at all. 1177 7.2. User Controls 1179 User agents SHOULD provide users with a mechanism for managing the 1180 cookies stored in the cookie store. For example, a user agent might 1181 let users delete all cookies received during a specified time period 1182 or all the cookies related to a particular domain. In addition, many 1183 user agent include a user interface element that lets users examine 1184 the cookies stored in their cookie store. 1186 User agents SHOULD provide users with a mechanism for disabling 1187 cookies. When cookies are disabled, the user agent MUST NOT include 1188 a Cookie header in outbound HTTP requests and the user agent MUST NOT 1189 process Set-Cookie headers in inbound HTTP responses. 1191 Some user agents provide users the option of preventing persistent 1192 storage of cookies across sessions. When configured thusly, user 1193 agents MUST treat all received cookies as if the persistent-flag were 1194 set to false. 1196 Some user agents provide users with the ability to approve individual 1197 writes to the cookie store. In many common usage scenarios, these 1198 controls generate a large number of prompts. However, some privacy- 1199 conscious users find these controls useful nonetheless. 1201 8. Security Considerations 1203 8.1. Overview 1205 Cookies have a number of security pitfalls. This section overviews a 1206 few of the more salient issues. 1208 In particular, cookies encourage developers to rely on ambient 1209 authority for authentication, often becoming vulnerable to attacks 1210 such as cross-site request forgery. Also, when storing session 1211 identifiers in cookies, developers often create session fixation 1212 vulnerabilities. 1214 Transport-layer encryption, such as that employed in HTTPS, is 1215 insufficient to prevent a network attacker from obtaining or altering 1216 a victim's cookies because the cookie protocol itself has various 1217 vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", 1218 below). In addition, by default, cookies do not provide 1219 confidentiality or integrity from network attackers, even when used 1220 in conjunction with HTTPS. 1222 8.2. Ambient Authority 1224 A server that uses cookies to authenticate users can suffer security 1225 vulnerabilities because some user agents let remote parties issue 1226 HTTP requests from the user agent (e.g., via HTTP redirects or HTML 1227 forms). When issuing those requests, user agents attach cookies even 1228 if the remote party does not know the contents of the cookies, 1229 potentially letting the remote party exercise authority at an unwary 1230 server. 1232 Although this security concern goes by a number of names (e.g., 1233 cross-site request forgery, confused deputy), the issue stems from 1234 cookies being a form of ambient authority. Cookies encourage server 1235 operators to separate designation (in the form of URLs) from 1236 authorization (in the form of cookies). Consequently, the user agent 1237 might supply the authorization for a resource designated by the 1238 attacker, possibly causing the server or its clients to undertake 1239 actions designated by the attacker as though they were authorized by 1240 the user. 1242 Instead of using cookies for authorization, server operators might 1243 wish to consider entangling designation and authorization by treating 1244 URLs as capabilities. Instead of storing secrets in cookies, this 1245 approach stores secrets in URLs, requiring the remote entity to 1246 supply the secret itself. Although this approach is not a panacea, 1247 judicious use of these principles can lead to more robust security. 1249 8.3. Clear Text 1251 Unless sent over a secure channel (such as TLS), the information in 1252 the Cookie and Set-Cookie headers is transmitted in the clear. 1254 1. All sensitive information conveyed in these headers is exposed to 1255 an eavesdropper. 1257 2. A malicious intermediary could alter the headers as they travel 1258 in either direction, with unpredictable results. 1260 3. A malicious client could alter the Cookie header before 1261 transmission, with unpredictable results. 1263 Servers SHOULD encrypt and sign the contents of cookies when 1264 transmitting them to the user agent (even when sending the cookies 1265 over a secure channel). However, encrypting and signing cookie 1266 contents does not prevent an attacker from transplanting a cookie 1267 from one user agent to another or from replaying the cookie at a 1268 later time. 1270 In addition to encrypting and signing the contents of every cookie, 1271 servers that require a higher level of security SHOULD use the Cookie 1272 and Set-Cookie headers only over a secure channel. When using 1273 cookies over a secure channel, servers SHOULD set the Secure 1274 attribute for every cookie. If a server does not set the Secure 1275 attribute, the protection provided by the secure channel will be 1276 largely moot. 1278 8.4. Session Identifiers 1280 Instead of storing session information directly in a cookie (where it 1281 might be exposed to or replayed by an attacker), servers commonly 1282 store a nonce (or "session identifier") in a cookie. When the server 1283 receives an HTTP request with a nonce, the server can look up state 1284 information associated with the cookie using the nonce as a key. 1286 Using session identifier cookies limits the damage an attacker can 1287 cause if the attacker learns the contents of a cookie because the 1288 nonce is useful only for interacting with the server (unlike non- 1289 nonce cookie content, which might itself be sensitive). Furthermore, 1290 using a single nonce prevents an attacker from "splicing" together 1291 cookie content from two interactions with the server, which could 1292 cause the server to behave unexpectedly. 1294 Using session identifiers is not without risk. For example, the 1295 server SHOULD take care to avoid "session fixation" vulnerabilities. 1296 A session fixation attack proceeds in three steps. First, the 1297 attacker transplants a session identifier from his or her user agent 1298 to the victim's user agent. Second, the victim uses that session 1299 identifier to interact with the server, possibly imbuing the session 1300 identifier with the user's credentials or confidential information. 1301 Third, the attacker uses the session identifier to interact with 1302 server directly, possibly obtaining the user's authority or 1303 confidential information. 1305 8.5. Weak Confidentiality 1307 Cookies do not provide isolation by port. If a cookie is readable by 1308 a service running on one port, the cookie is also readable by a 1309 service running on another port of the same server. If a cookie is 1310 writable by a service on one port, the cookie is also writable by a 1311 service running on another port of the same server. For this reason, 1312 servers SHOULD NOT both run mutually distrusting services on 1313 different ports of the same host and use cookies to store security- 1314 sensitive information. 1316 Cookies do not provide isolation by scheme. Although most commonly 1317 used with the http and https schemes, the cookies for a given host 1318 might also be available to other schemes, such as ftp and gopher. 1319 Although this lack of isolation by scheme is most apparent in via 1320 non-HTTP APIs that permit access to cookies (e.g., HTML's 1321 document.cookie API), the lack of isolation by scheme is actually 1322 present in requirements for processing cookies themselves (e.g., 1323 consider retrieving a URI with the gopher scheme via HTTP). 1325 Cookies do not always provide isolation by path. Although the 1326 network-level protocol does not send cookies stored for one path to 1327 another, some user agents expose cookies via non-HTTP APIs, such as 1328 HTML's document.cookie API. Because some of these user agents (e.g., 1329 web browsers) do not isolate resources received from different paths, 1330 a resource retrieved from one path might be able to access cookies 1331 stored for another path. 1333 8.6. Weak Integrity 1335 Cookies do not provide integrity guarantees for sibling domains (and 1336 their subdomains). For example, consider foo.example.com and 1337 bar.example.com. The foo.example.com server can set a cookie with a 1338 Domain attribute of "example.com" (possibly overwriting an existing 1339 "example.com" cookie set by bar.example.com), and the user agent will 1340 include that cookie in HTTP requests to bar.example.com. In the 1341 worst case, bar.example.com will be unable to distinguish this cookie 1342 from a cookie it set itself. The foo.example.com server might be 1343 able to leverage this ability to mount an attack against 1344 bar.example.com. 1346 Even though the Set-Cookie header supports the Path attribute, the 1347 Path attribute does not provide any integrity protection because the 1348 user agent will accept an arbitrary Path attribute in a Set-Cookie 1349 header. For example, an HTTP response to a request for 1350 http://example.com/foo/bar can set a cookie with a Path attribute of 1351 "/qux". Consequently, servers SHOULD NOT both run mutually 1352 distrusting services on different paths of the same host and use 1353 cookies store security-sensitive information. 1355 An active network attacker can also inject cookies into the Cookie 1356 header sent to https://example.com/ by impersonating a response from 1357 http://example.com/ and injecting a Set-Cookie header. The HTTPS 1358 server at example.com will be unable to distinguish these cookies 1359 from cookies that it set itself in an HTTPS response. An active 1360 network attacker might be able to leverage this ability to mount an 1361 attack against example.com even if example.com uses HTTPS 1362 exclusively. 1364 Servers can partially mitigate these attacks by encrypting and 1365 signing the contents of their cookies. However, using cryptography 1366 does not mitigate the issue completely because an attacker can replay 1367 a cookie he or she received from the authentic example.com server in 1368 the user's session, with unpredictable results. 1370 Finally, an attacker might be able to force the user agent to delete 1371 cookies by storing a large number of cookies. Once the user agent 1372 reaches its storage limit, the user agent will be forced to evict 1373 some cookies. Servers SHOULD NOT rely upon user agents retaining 1374 cookies. 1376 8.7. Reliance on DNS 1378 Cookies rely upon the Domain Name System (DNS) for security. If the 1379 DNS is partially or fully compromised, the cookie protocol might fail 1380 to provide the security properties required by applications. 1382 9. References 1384 9.1. Normative References 1386 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1387 STD 13, RFC 1034, November 1987. 1389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1390 Requirement Levels", BCP 14, RFC 2119, March 1997. 1392 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1393 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1394 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1396 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1397 "Internationalizing Domain Names in Applications (IDNA)", 1398 RFC 3490, March 2003. 1400 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1401 10646", STD 63, RFC 3629, November 2003. 1403 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1404 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1406 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1407 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1409 9.2. Informative References 1411 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 1412 Mechanism", RFC 2109, February 1997. 1414 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1415 Mechanism", RFC 2965, October 2000. 1417 Appendix A. Acknowledgements 1419 This document borrows heavily from RFC 2109 [RFC2109]. We are 1420 indebted to David M. Kristol and Lou Montulli for their efforts to 1421 specify the cookie protocol. David M. Kristol, in particular, 1422 provided invaluable advice on navigating the IETF process. We would 1423 also like to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, 1424 Lisa Dusseault, Roy T. Fielding, Blake Frantz, Eran Hammer-Lahav, 1425 Jeff Hodges, Achim Hoffmann, Georg Koppen, Dean McNamee, Mark Miller, 1426 Mark Pauley, Yngve N. Pettersen, Julian Reschke, Mark Seaborn, Maciej 1427 Stachowiak, Daniel Stenberg, David Wagner, Dan Winship, and Dan Witte 1428 for their valuable feedback on this document. 1430 Author's Address 1432 Adam Barth 1433 University of California, Berkeley 1435 Email: abarth@eecs.berkeley.edu 1436 URI: http://www.adambarth.com/