idnits 2.17.1 draft-ietf-httpstate-cookie-05.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 (March 7, 2010) is 5156 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'USASCII' is mentioned on line 167, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2109 (Obsoleted by RFC 2965) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 httpstate A. Barth 3 Internet-Draft U.C. Berkeley 4 Obsoletes: 2109 (if approved) March 7, 2010 5 Intended status: Standards Track 6 Expires: September 8, 2010 8 HTTP State Management Mechanism 9 draft-ietf-httpstate-cookie-05 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 on HTTP user 15 agents, letting the servers maintain a stateful session over the 16 mostly stateless HTTP protocol. The cookie protocol has many 17 historical infelicities that degrade its security and privacy. 19 NOTE: If you have suggestions for improving the draft, please send 20 email to http-state@ietf.org. Suggestions with test cases are 21 especially appreciated. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 8, 2010. 46 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. General Nonsense . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 5 77 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 78 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 4. A Well-Behaved Profile . . . . . . . . . . . . . . . . . . . . 9 82 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 10 85 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 87 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 12 88 5. The Cookie Protocol . . . . . . . . . . . . . . . . . . . . . 14 89 5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 14 90 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 14 91 5.1.2. Domains . . . . . . . . . . . . . . . . . . . . . . . 16 92 5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 16 93 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 17 94 5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 19 95 5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 19 96 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 20 97 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 20 98 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 21 99 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 21 100 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 21 101 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 24 102 6. Implementation Considerations . . . . . . . . . . . . . . . . 27 103 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 6.2. Application Programmer Interfaces . . . . . . . . . . . . 27 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 106 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 7.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 28 108 7.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 29 109 7.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 29 110 7.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 30 111 7.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 30 112 7.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 31 113 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 114 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 115 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 116 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33 117 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 119 1. Introduction 121 This document defines the HTTP Cookie and Set-Cookie header. Using 122 the Set-Cookie header, an HTTP server can store name/value pairs and 123 associated metadata (called cookies) at the user agent. When the 124 user agent makes subsequent requests to the server, the user agent 125 uses the metadata to determine whether to return the name/value pairs 126 in the Cookie header. 128 Although simple on its surface, the cookie protocol has a number of 129 complexities. For example, the server indicates a scope for each 130 cookie when sending them to the user agent. The scope indicates the 131 maximum amount of time the user agent should retain the cookie, to 132 which servers the user agent should return the cookie, and for which 133 protocols the cookie is applicable. 135 For historical reasons, the cookie protocol contains a number of 136 security and privacy infelicities. For example, a server can 137 indicate that a given cookie is intended for "secure" connections, 138 but the Secure attribute provides only confidentiality (not 139 integrity) from active network attackers. Similarly, cookies for a 140 given host are shared across all the ports on that host, even though 141 the usual "same-origin policy" used by web browsers isolates content 142 retrieved from different ports. 144 2. General Nonsense 146 2.1. Conformance Criteria 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 149 "RECOMMENDED", "MAY", and "OPTIONAL" in document are to be 150 interpreted as described in [RFC2119]. 152 Requirements phrased in the imperative as part of algorithms (such as 153 "strip any leading space characters" or "return false and abort these 154 steps") are to be interpreted with the meaning of the key word 155 ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. 157 2.2. Syntax Notation 159 This specification uses the Augmented Backus-Naur Form (ABNF) 160 notation of [RFC5234]. 162 The following core rules are included by reference, as defined in 163 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 164 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 165 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 166 sequence of data), SP (space), HTAB (horizontal tab), VCHAR (any 167 visible [USASCII] character), and WSP (whitespace). 169 2.3. Terminology 171 The terms user agent, client, server, proxy, and origin server have 172 the same meaning as in the HTTP/1.1 specification ([RFC2616]). 174 The terms request-host and request-URI refer to the values the user 175 agent would send to the server as, respectively, the host (but not 176 port) and abs_path portions of the absoluteURI (http_URL) of the HTTP 177 Request-Line. 179 3. Overview 181 We outline here a way for an origin server to send state information 182 to a user agent, and for the user agent to return the state 183 information to the origin server. 185 To initiate a session, the origin server includes a Set-Cookie header 186 in an HTTP response. (Note that "session" here does not refer to a 187 persistent network connection but to a logical session created from 188 HTTP requests and responses. The presence or absence of a persistent 189 connection should have no effect on the use of cookie-derived 190 sessions). 192 The user agent returns a Cookie request header to the origin server 193 if it chooses to continue a session. The Cookie header contains a 194 number of cookies the user agent received in previous Set-Cookie 195 headers. The origin server MAY ignore the Cookie header or use the 196 header to determine the current state of the session. The origin 197 server MAY send the user agent a Set-Cookie response header with the 198 same or different information, or it MAY send no Set-Cookie header at 199 all. 201 Servers MAY return a Set-Cookie response header with any response. 202 User agents SHOULD send a Cookie request header, subject to other 203 rules detailed below, with every request. 205 An origin server MAY include multiple Set-Cookie header fields in a 206 single response. Note that an intervening gateway MUST NOT fold 207 multiple Set-Cookie header fields into a single header field. 209 3.1. Examples 211 Using the cookie protocol, a server can send the user agent a short 212 string in an HTTP response that the user agent will return in future 213 HTTP requests. For example, the server can send the user agent a 214 "session identifier" named SID with the value 31d4d96e407aad42. The 215 user agent then returns the session identifier in subsequent 216 requests. 218 == Server -> User Agent == 219 Set-Cookie: SID=31d4d96e407aad42 221 == User Agent -> Server == 222 Cookie: SID=31d4d96e407aad42 224 The server can alter the default scope of the cookie using the Path 225 and Domain attributes. For example, the server can instruct the user 226 agent to return the cookie to every path and every subdomain of 227 example.com. 229 == Server -> User Agent == 230 Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=.example.com 232 == User Agent -> Server == 233 Cookie: SID=31d4d96e407aad42 235 The server can store multiple cookies in the user agent. For 236 example, the server can store a session identifier as well as the 237 user's preferred language by returning two Set-Cookie response 238 headers. Notice that the server uses the Secure and HttpOnly 239 attributes to provide additional security protections for the more- 240 sensitive session identifier. 242 == Server -> User Agent == 243 Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure, HttpOnly 244 Set-Cookie: lang=en-US; Path=/; Domain=.example.com 246 == User Agent -> Server == 247 Cookie: SID=31d4d96e407aad42; lang=en-US 249 If the server wishes the user agent to persist the cookie over 250 multiple sessions, the server can specify a expiration date in the 251 Expires attribute. Note that the user agent might might delete the 252 cookie before the expiration date if the user agent's cookie store 253 exceeds its quota or if the user manually deletes the server's 254 cookie. 256 == Server -> User Agent == 257 Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT 259 == User Agent -> Server == 260 Cookie: lang=en-US 262 Finally, to remove a cookie, the server returns a Set-Cookie header 263 with an expiration date in the past. The server will be successful 264 in removing the cookie only if the Path and the Domain attribute in 265 the Set-Cookie header match the values used when the cookie was 266 created. 268 == Server -> User Agent == 269 Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT 271 == User Agent -> Server == 272 (No Cookie header) 274 4. A Well-Behaved Profile 276 This section describes the syntax and semantics of a well-behaved 277 profile of the protocol. Servers SHOULD use the profile described in 278 this section, both to maximize interoperability with existing user 279 agents and because a future version of the cookie protocol could 280 remove support for some of the most esoteric aspects of the protocol. 281 User agents, however, MUST implement the full protocol to ensure 282 interoperability with servers making use of the full protocol. 284 4.1. Set-Cookie 286 The Set-Cookie header is used to send cookies from the server to the 287 user agent. 289 4.1.1. Syntax 291 Informally, the Set-Cookie response header comprises the token Set- 292 Cookie:, followed by a cookie. Each cookie begins with a name-value- 293 pair, followed by zero or more attribute-value pairs. Servers SHOULD 294 NOT send Set-Cookie headers that fail to conform to the following 295 grammar: 297 set-cookie-header = "Set-Cookie:" OWS set-cookie-string OWS 298 set-cookie-string = cookie-pair *( ";" cookie-av ) 299 cookie-pair = cookie-name "=" cookie-value 300 cookie-name = token 301 cookie-value = token 302 token = 304 cookie-av = expires-av / domain-av / path-av / 305 secure-av / httponly-av 306 expires-av = "Expires" "=" sane-cookie-date 307 sane-cookie-date = 308 domain-av = "Domain" "=" domain-value 309 domain-value = token 310 path-av = "Path" "=" path-value 311 path-value = 312 secure-av = "Secure" 313 httponly-av = "HttpOnly" 315 Servers SHOULD NOT include two attributes with the same name. 317 The cookie-value is opaque to the user agent and MAY be anything the 318 origin server chooses to send. "Opaque" implies that the content is 319 of interest and relevance only to the origin server. The content is, 320 in fact, readable by anyone who examines the Set-Cookie header. 322 To maximize compatibility with user agents, servers that wish to 323 store non-ASCII data in a cookie-value SHOULD encode that data using 324 a printable ASCII encoding, such as base64. 326 NOTE: The syntax above allows whitespace between the attribute and 327 the U+003D ("=") character. Servers wishing to interoperate with 328 some legacy user agents might wish to elide this whitespace. 330 4.1.2. Semantics (Non-Normative) 332 This section describes a simplified semantics of the Set-Cookie 333 header. These semantics are detailed enough to be useful for 334 understanding the most common uses of the cookie protocol. The full 335 semantics are described in Section 5. 337 When the user agent receives a Set-Cookie header, the user agent 338 stores the cookie in its cookie store. When the user agent 339 subsequently makes an HTTP request, the user agent consults its 340 cookie store and includes the applicable, non-expired cookies in the 341 Cookie header. 343 If the cookie store already contains a cookie with the same cookie- 344 name, domain-value, and path-value, the existing cookie is evicted 345 from the cookie store and replaced with the new value. Notice that 346 servers can delete cookies by including an Expires attribute with a 347 value in the past. 349 Unless the cookie's attributes indicate otherwise, the cookie is 350 returned only to the origin server, and it expires at the end of the 351 current session (as defined by the user agent). User agents ignore 352 unrecognized cookie attributes. 354 4.1.2.1. Expires 356 The Expires attribute indicates the maximum lifetime of the cookie, 357 represented as the date and time at which the cookie expires. The 358 user agent is not required to retain the cookie until the specified 359 date has passed. In fact, user agents often evict cookies from the 360 cookie store due to memory pressure or privacy concerns. 362 4.1.2.2. Domain 364 The Domain attribute specifies those hosts for which the cookie will 365 be sent. For example, if the Domain attribute contains the value 366 ".example.com", the user agent will include the cookie in the Cookie 367 header when making HTTP requests to example.com, www.example.com, and 368 www.corp.example.com. (Note that a leading U+002E ("."), if present, 369 is ignored.) If the server omits the Domain attribute, the user 370 agent will return the cookie only to the origin server. 372 WARNING: Some legacy user agents treat an absent Domain attribute 373 as if the Domain attribute were present and contained the current 374 host name. For example, if example.com returns a Set-Cookie 375 header without a Domain attribute, these user agents will send the 376 cookie to www.example.com. 378 The user agent will reject cookies (refuse to store them in the 379 cookie store) unless the Domain attribute specifies a scope for the 380 cookie that would include the origin server. For example, the user 381 agent will accept a Domain attribute of ".example.com" or of 382 ".foo.example.com" from foo.example.com, but the user agent will not 383 accept a Domain attribute of ".bar.example.com" or of 384 ".baz.foo.example.com". 386 NOTE: For security reasons, some user agents are configured to reject 387 Domain attributes that do not correspond to a "registry controlled" 388 domain (or a subdomain of a registry controlled domain). For 389 example, some user agents will reject Domain attributes of ".com". 391 4.1.2.3. Path 393 The Path attribute limits the scope of the cookie to a set of paths. 394 When a cookie has a Path attribute, the user agent will include the 395 cookie in an HTTP request only if the path portion of the Request-URI 396 matches (or is a subdirectory of) the cookie's Path attribute, where 397 the U+002F ("/") character is interpreted as a directory separator. 398 If the server omits the Path attribute, the user agent will use the 399 directory of the Request-URI's path component as the default value. 401 Although seemingly useful for isolating cookies between different 402 paths within a given domain, the Path attribute cannot be relied upon 403 for security for two reasons: First, user agents do not prevent one 404 path from overwriting the cookies for another path. For example, if 405 a response to a request for /foo/bar.html attempts to set a cookie 406 with a Path attribute of "/baz" the user agent will store that cookie 407 in the cookie store. Second, the "same-origin" policy implemented by 408 many user agents does not isolate different paths within an origin. 409 For example, /foo/bar.html can read cookies with a Path attribute of 410 "/baz" because they are within the "same origin". 412 4.1.2.4. Secure 414 The Secure attribute limits the scope of the cookie to "secure" 415 channels (where "secure" is defined by the user agent). When a 416 cookie has the Secure attribute, the user agent will include the 417 cookie in an HTTP request only if the request is transmitted over a 418 secure channel (typically TLS [RFC5246]). 420 Although seemingly useful for protecting cookies from active network 421 attackers, the Secure attribute protects only the cookie's 422 confidentiality. An active network attacker can overwrite Secure 423 cookies from an insecure channel, disrupting the integrity of the 424 cookies. 426 4.1.2.5. HttpOnly 428 The HttpOnly attribute limits the scope of the cookie to HTTP 429 requests. In particular, the attribute instructs the user agent to 430 elide the cookie when providing access to its cookie store via "non- 431 HTTP" APIs (as defined by the user agent). 433 4.2. Cookie 435 4.2.1. Syntax 437 The user agent returns stored cookies to the origin server in the 438 Cookie header. If the server conforms to the requirements in this 439 section, the requirements in the next section will cause the user 440 agent to return a Cookie header that conforms to the following 441 grammar: 443 cookie-header = "Cookie:" OWS cookie-string OWS 444 cookie-string = cookie-pair *( ";" cookie-pair ) 446 4.2.2. Semantics 448 Each cookie-pair represents a cookie stored by the user agent. The 449 cookie-name and the cookie-value are returned verbatim from the 450 corresponding parts of the Set-Cookie header. 452 Notice that the cookie attributes are not returned. In particular, 453 the server cannot determine from the Cookie header alone when a 454 cookie will expire, for which domains the cookie is valid, for which 455 paths the cookie is valid, or whether the cookie was set with the 456 Secure or HttpOnly attributes. 458 The semantics of individual cookies in the Cookie header is not 459 defined by this document. Servers are expected to imbue these 460 cookies with server-specific semantics. 462 Although cookies are serialized linearly in the Cookie header, 463 servers SHOULD NOT rely upon the serialization order. In particular, 464 if the Cookie header contains two cookies with the same name, servers 465 SHOULD NOT rely upon the order in which these cookies appear in the 466 header. 468 5. The Cookie Protocol 470 For historical reasons, the full cookie protocol contains a number of 471 exotic quirks. This section is intended to specify the cookie 472 protocol in enough detail to enable a user agent that implements the 473 protocol precisely as specified to interoperate with existing 474 servers. 476 Conformance requirements phrased as algorithms or specific steps may 477 be implemented in any manner, so long as the end result is 478 equivalent. (In particular, the algorithms defined in this 479 specification are intended to be easy to follow, and not intended to 480 be performant.) 482 5.1. Algorithms 484 This section defines a number of algorithms used by the cookie 485 protocol. 487 5.1.1. Dates 489 The user agent MUST use the following algorithm to *parse a cookie- 490 date*: 492 1. Using the grammar below, divide the cookie-date into date-tokens. 494 cookie-date = *delimiter date-token-list *delimiter 495 date-token-list = date-token *( 1*delimiter date-token ) 496 delimiter = %x09 / %x20 / %x21 / %x22 / %x23 / %x24 / 497 %x25 / %x26 / %x27 / %x28 / %x29 / %x2A / 498 %x2B / %x2C / %x2D / %x2E / %x2F / %x3B / 499 %x3C / %x3D / %x3E / %x3F / %x40 / %x5B / 500 %x5C / %x5D / %x5E / %x5F / %x60 / %x7B / 501 %x7C / %x7D / %x7E 502 date-token = day-of-month / month / year / time / mystery 503 day-of-month = 2DIGIT / DIGIT 504 month = "jan" [ mystery ] / "feb" [ mystery ] / 505 "mar" [ mystery ] / "apr" [ mystery ] / 506 "may" [ mystery ] / "jun" [ mystery ] / 507 "jul" [ mystery ] / "aug" [ mystery ] / 508 "sep" [ mystery ] / "oct" [ mystery ] / 509 "nov" [ mystery ] / "dec" [ mystery ] 510 year = 5DIGIT / 4DIGIT / 3DIGIT / 2DIGIT / DIGIT 511 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 512 mystery = 513 2. Process each date-token sequentially in the order the date-tokens 514 appear in the cookie-date: 516 1. If the found-day-of-month flag is not set and the date-token 517 matches the day-of-month production, set the found-day-of- 518 month flag and set the day-of-month-value to the number 519 denoted by the date-token. Skip the remaining sub-steps and 520 continue to the next date-token. 522 2. If the found-month flag is not set and the date-token matches 523 the month production, set the found-month flag and set the 524 month-value to the month denoted by the date-token. Skip the 525 remaining sub-steps and continue to the next date-token. 527 3. If the found-year flag is not set and the date-token matches 528 the year production, set the found-year flag and set the 529 year-value to the number denoted by the date-token. Skip the 530 remaining sub-steps and continue to the next date-token. 532 4. If the found-time flag is not set and the token matches the 533 time production, set the found-time flag and set the hour- 534 value, minute-value, and second-value to the numbers denoted 535 by the digits in the date-token, respectively. Skip the 536 remaining sub-steps and continue to the next date-token. 538 3. Abort these steps and *fail to parse* if 540 * at least one of the found-day-of-month, found-month, found- 541 year, or found-time flags is not set, 543 * the day-of-month-value is less than 1 or greater than 31, 545 * the year-value is less than 1601 or greater than 30827, 547 * the hour-value is greater than 23, 549 * the minute-value is greater than 59, or 551 * the second-value is greater than 59. 553 4. If the year-value is greater than 68 and less than 100, increment 554 the year-value by 1900. 556 5. If the year-value is greater than or equal to 0 and less than 69, 557 increment the year-value by 2000. 559 6. Let the parsed-cookie-date be the date whose day-of-month, month, 560 year, hour, minute, and second (in GMT) are the day-of-month- 561 value, the month-value, the year-value, the hour-value, the 562 minute-value, and the second-value, respectively. 564 7. Return the parsed-cookie-date as the result of this algorithm. 566 5.1.2. Domains 568 A *canonicalized* host-name is the host-name converted to lower case. 570 A request-host *domain-matches* a cookie-domain if at least one of 571 the following conditions hold: 573 o The cookie-domain and the canonicalized request-host are 574 identical. 576 o All of the following conditions hold: 578 * The cookie-domain is a suffix of the canonicalized request- 579 host. 581 * The last character of the canonicalized request-host that is 582 not included in the cookie-domain is a U+002E (".") character. 584 * The request-host is a host name (i.e., not an IP address). 586 5.1.3. Paths 588 The user agent MUST use the following algorithm to compute the 589 *default-path* of a cookie: 591 1. Let uri-path be the path portion of the Request-URI. 593 2. If the first character of the uri-path is not a U+002F ("/") 594 character, output U+002F ("/") and skip the remaining steps. 596 3. If the uri-path contains only a single U+002F ("/") character, 597 output U+002F ("/") and skip the remaining steps. 599 4. Output the characters of the uri-path from the first character up 600 to, but not including, the right-most U+002F ("/"). 602 A request-path *path-matches* a cookie-path if at least one of the 603 following conditions hold: 605 o The cookie-path and the request-path are identical. 607 o The cookie-path is a prefix of the request-path and the last 608 character of the cookie-path is U+002F ("/"). 610 o The cookie-path is a prefix of the request-path and the first 611 character of the request-path that is not included in the cookie- 612 path is a U+002F ("/") character. 614 5.2. The Set-Cookie Header 616 When a user agent receives a Set-Cookie header in an HTTP response, 617 the user agent *receives a set-cookie-string* consisting of the value 618 of the header. 620 A user agent MUST use the following algorithm to parse set-cookie- 621 strings: 623 1. If the set-cookie-string is empty or consists entirely of WSP 624 characters, the user agent MAY ignore the set-cookie-string 625 entirely. 627 2. If the set-cookie-string contains a U+003B (";") character: 629 The name-value-pair string consists of the characters up to, 630 but not including, the first U+003B (";"), and the unparsed- 631 attributes consist of the remainder of the set-cookie-string 632 (including the U+003B (";") in question). 634 Otherwise: 636 The name-value-pair string consists of all the characters 637 contained in the set-cookie-string, and the unparsed- 638 attributes is the empty string. 640 3. If the name-value-pair string contains a U+003D ("=") character: 642 The (possibly empty) name string consists of the characters up 643 to, but not including, the first U+003D ("=") character, and 644 the (possibly empty) value string consists of the characters 645 after the first U+003D ("=") character. 647 Otherwise: 649 The name string is empty, and the value string consists of the 650 entire name-value-pair string. 652 4. Remove any leading or trailing WSP characters from the name 653 string and the value string. 655 5. The cookie-name is the name string, and the cookie-value is the 656 value string. 658 The user agent MUST use the following algorithm to parse the 659 unparsed-attributes: 661 1. If the unparsed-attributes string is empty, skip the rest of 662 these steps. 664 2. Consume the first character of the unparsed-attributes (which 665 will be a U+003B (";") character). 667 3. If the remaining unparsed-attributes contains a U+003B (";") 668 character: 670 Consume the characters of the unparsed-attributes up to, but 671 not including, the first U+003B (";") character. 673 Otherwise: 675 Consume the remainder of the unparsed-attributes. 677 Let the cookie-av string be the characters consumed in this step. 679 4. If the cookie-av string contains a U+003D ("=") character: 681 The (possibly empty) attribute-name string consists of the 682 characters up to, but not including, the first U+003D ("=") 683 character, and the (possibly empty) attribute-value string 684 consists of the characters after the first U+003D ("=") 685 character. 687 Otherwise: 689 The attribute-name string consists of the entire cookie-av 690 string, and the attribute-value string is empty. (Note that 691 this step differs from the analogous step when parsing the 692 name-value-pair string.) 694 5. Remove any leading or trailing WSP characters from the attribute- 695 name string and the attribute-value string. 697 6. Process the attribute-name and attribute-value according to the 698 requirements in the following subsections. 700 7. Return to Step 1. 702 When the user agent finishes parsing the set-cookie-string, the user 703 agent *receives a cookie* from the Request-URI with name cookie-name, 704 value cookie-value, and attributes cookie-attribute-list. 706 5.2.1. The Max-Age Attribute 708 If the attribute-name case-insensitively matches the string "Max- 709 Age", the user agent MUST process the cookie-av as follows. 711 If the first character of the attribute-value is not a DIGIT or a "-" 712 character, ignore the cookie-av. 714 If the remainder of attribute-value contains a non-DIGIT character, 715 ignore the cookie-av. 717 Let delta-seconds be the attribute-value converted to an integer. 719 If delta-seconds is less than or equal to zero (0), let expiry-time 720 be the current date and time. Otherwise, let the expiry-time be the 721 current date and time plus delta-seconds seconds. 723 Append an attribute to the cookie-attribute-list with an attribute- 724 name of Max-Age and an attribute-value of expiry-time. 726 5.2.2. The Expires Attribute 728 If the attribute-name case-insensitively matches the string 729 "Expires", the user agent MUST process the cookie-av as follows. 731 Let the parsed-cookie-date be the result of parsing the attribute- 732 value as cookie-date. 734 If the attribute-value failed to parse as a cookie date, ignore the 735 cookie-av. 737 If the user agent received the set-cookie-string from an HTTP 738 response that contains a Date header field and the contents of the 739 last Date header field successfully parse as a cookie-date: 741 Let server-date be the date obtained by parsing the contents of 742 the last Date header field as a cookie-date. 744 Let delta-seconds be the number of seconds between the server-date 745 and the parsed-cookie-date (i.e., parsed-cookie-date - server- 746 date). 748 Let the expiry-time be the current date and time plus delta- 749 seconds seconds. 751 Otherwise: 753 Let the expiry-time be the parsed-cookie-date. 755 If the expiry-time is later than the last date the user agent can 756 represent, the user agent MAY replace the expiry-time with the last 757 representable date. 759 If the expiry-time is earlier than the first date the user agent can 760 represent, the user agent MAY replace the expiry-time with the first 761 representable date. 763 Append an attribute to the cookie-attribute-list with an attribute- 764 name of Expires and an attribute-value of expiry-time. 766 5.2.3. The Domain Attribute 768 If the attribute-name case-insensitively matches the string "Domain", 769 the user agent MUST process the cookie-av as follows. 771 If the attribute-value is empty, the behavior is undefined. However, 772 user agent SHOULD ignore the cookie-av entirely. 774 If the first character of the attribute-value string is U+002E ("."): 776 Let cookie-domain be the attribute-value without the leading 777 U+002E (".") character. 779 Otherwise: 781 Let cookie-domain be the entire attribute-value. 783 Convert the cookie-domain to lower case. 785 Append an attribute to the cookie-attribute-list with an attribute- 786 name of Domain and an attribute-value of cookie-domain. 788 5.2.4. The Path Attribute 790 If the attribute-name case-insensitively matches the string "Path", 791 the user agent MUST process the cookie-av as follows. 793 If the attribute-value is empty or if the first character of the 794 attribute-value is not U+002F ("/"): 796 Let cookie-path be the default-path. 798 Otherwise: 800 Let cookie-path be the attribute-value. 802 Append an attribute to the cookie-attribute-list with an attribute- 803 name of Path and an attribute-value of cookie-path. 805 5.2.5. The Secure Attribute 807 If the attribute-name case-insensitively matches the string "Secure", 808 the user agent MUST append an attribute to the cookie-attribute-list 809 with an attribute-name of Secure and an empty attribute-value. 811 5.2.6. The HttpOnly Attribute 813 If the attribute-name case-insensitively matches the string 814 "HttpOnly", the user agent MUST append an attribute to the cookie- 815 attribute-list with an attribute-name of HttpOnly and an empty 816 attribute-value. 818 5.3. Storage Model 820 When the user agent receives a cookie, the user agent SHOULD record 821 the cookie in its cookie store as follows. 823 A user agent MAY ignore a received cookie in its entirety if the user 824 agent is configured to block receiving cookies. For example, the 825 user agent might wish to block receiving cookies from "third-party" 826 responses. 828 The user agent stores the following fields about each cookie: name, 829 value, expiry-time, domain, path, creation-time, last-access-time, 830 persistent-flag, host-only-flag, secure-only-flag, and http-only- 831 flag. 833 When the user agent receives a cookie from a Request-URI with name 834 cookie-name, value cookie-value, and attributes cookie-attribute- 835 list, the user agent MUST process the cookie as follows: 837 1. Create a new cookie with name cookie-name, value cookie-value. 838 Set the creation-time and the last-access-time to the current 839 date and time. 841 2. If the cookie-attribute-list contains an attribute with an 842 attribute-name of "Max-Age": 844 Set the cookie's persistent-flag to true. 846 Set the cookie's expiry-time to attribute-value of the last 847 attribute in the cookie-attribute-list with an attribute-name 848 of "Max-Age". 850 Otherwise, if the cookie-attribute-list contains an attribute 851 with an attribute-name of "Expires" (and does not contain an 852 attribute with an attribute-name of "Max-Age"): 854 Set the cookie's persistent-flag to true. 856 Set the cookie's expiry-time to attribute-value of the last 857 attribute in the cookie-attribute-list with an attribute-name 858 of "Expires". 860 Otherwise: 862 Set the cookie's persistent-flag to false. 864 Set the cookie's expiry-time to the latest representable 865 date. 867 3. If the cookie-attribute-list contains an attribute with an 868 attribute-name of "Domain": 870 Let the domain-attribute be the attribute-value of the last 871 attribute in the cookie-attribute-list with an attribute-name 872 of "Domain". 874 Otherwise: 876 Let the domain-attribute be the empty string. 878 4. If the user agent is configured to use a "public suffix" list 879 and the domain-attribute is a public suffix: 881 If the domain-attribute is identical to the canonicalized 882 Request-URI's host: 884 Let the domain-attribute be the empty string. 886 Otherwise: 888 Ignore the cookie entirely and abort these steps 890 NOTE: A "public suffix" is a domain that is controlled by a 891 public registry, such as "com", "co.uk", and "pvt.k12.wy.us". 892 This step is essential for preventing attacker.com from 893 disrupting the integrity of example.com by setting a cookie 894 with a Domain attribute of "com". Unfortunately, the set of 895 public suffixes (also known as "registry controlled domains") 896 changes over time. If feasible, user agents SHOULD use an 897 up-to-date public suffix list, such as the one maintained by 898 the Mozilla project at http://publicsuffix.org/. 900 5. If the domain-attribute is non-empty: 902 If the Request-URI's host does not domain-match the domain- 903 attribute, ignore the cookie entirely and abort these steps. 905 Set the cookie's host-only-flag to false. 907 Set the cookie's domain to the domain-attribute. 909 Otherwise: 911 Set the cookie's host-only-flag to true. 913 Set the cookie's domain to the host of the Request-URI. 915 6. If the cookie-attribute-list contains an attribute with an 916 attribute-name of "Path", set the cookie's path to attribute- 917 value of the last attribute in the cookie-attribute-list with an 918 attribute-name of "Path". Otherwise, set cookie's path to the 919 default-path of the Request-URI. 921 7. If the cookie-attribute-list contains an attribute with an 922 attribute-name of "Secure", set the cookie's secure-only-flag to 923 true. Otherwise, set cookie's secure-only-flag to false. 925 8. If the cookie-attribute-list contains an attribute with an 926 attribute-name of "HttpOnly", set the cookie's http-only-flag to 927 true. Otherwise, set cookie's http-only-flag to false. 929 9. If the cookie's name and value are both empty, abort these steps 930 and ignore the cookie entirely. 932 10. If the cookie's expiry-time is not in the future, abort these 933 steps and ignore the cookie entirely. 935 11. If the cookie was received from a non-HTTP context and the 936 cookie's http-only-flag is set, abort these steps and ignore the 937 cookie entirely. 939 12. If the cookie store contains a cookie with the same name, 940 domain, and path as the newly created cookie: 942 1. Let old-cookie be the existing cookie with the same name, 943 domain, and path as the newly created cookie. (Notice that 944 this algorithm maintains the invariant that there is at most 945 one such cookie.) 947 2. If the newly created cookie was received from an non-HTTP 948 context and the old-cookie's host-only-flag is set, abort 949 these steps and ignore the newly created cookie entirely. 951 3. Update the creation-time of the newly created cookie to 952 match the creation-time of the old-cookie. 954 4. Remove the old-cookie from the cookie store. 956 13. Insert the newly created cookie into the cookie store. 958 The user agent MUST evict a cookie from the cookie store if, at any 959 time, a cookie exists in the cookie store with an expiry date in the 960 past. 962 The user agent MAY evict a cookie from the cookie store if the number 963 of cookies sharing a domain field exceeds some predetermined upper 964 bound (such as 50 cookies). 966 The user agent MAY evict a cookie from the cookie store if the cookie 967 store exceeds some predetermined upper bound (such as 3000 cookies). 969 When the user agent evicts a cookie from the cookie store, the user 970 agent MUST evict cookies in the following priority order: 972 1. Cookies with an expiry date in the past. 974 2. Cookies that share a domain field with more than a predetermined 975 number of other cookies. 977 3. All cookies. 979 If two cookies have the same removal priority, the user agent MUST 980 evict the cookie with the least recent last-access date first. 982 When "the current session is over" (as defined by the user agent), 983 the user agent MUST remove from the cookie store all cookies with the 984 persistent-flag set to false. 986 5.4. The Cookie Header 988 When the user agent generates an HTTP request, the user agent SHOULD 989 attach exactly one HTTP header named Cookie if the cookie-string 990 (defined below) for the Request-URI is non-empty. 992 A user agent MAY elide the Cookie header in its entirety if the user 993 agent is configured to block sending cookies. For example, the user 994 agent might wish to block sending cookies during "third-party" 995 requests. 997 The user agent MUST use the following algorithm to compute the 998 cookie-string from a cookie store and a Request-URI: 1000 1. Let cookie-list be the set of cookies from the cookie store that 1001 meet all of the following requirements: 1003 * Let request-host be the Request-URI's host. Either: 1005 The cookie's host-only-flag is true and the canonicalized 1006 request-host is identical to the cookie's domain. 1008 Or: 1010 The cookie's host-only-flag is false and the request-host 1011 domain-matches cookie's domain. 1013 * The Request-URI's path patch-matches cookie's path. 1015 * If the cookie's secure-only-flag is true, then the Request- 1016 URI's scheme must denote a "secure" protocol (as defined by 1017 the user agent). 1019 NOTE: The notion of a "secure" protocol is not defined by 1020 this document. Typically, user agents consider a protocol 1021 secure if the protocol makes use of transport-layer 1022 security, such as TLS. For example, most user agents 1023 consider "https" to be a scheme that denotes a secure 1024 protocol. 1026 * If the cookie's http-only-flag is true, then exclude the 1027 cookie unless the cookie-string is being generated for an 1028 "HTTP" API (as defined by the user agent). 1030 2. Sort the cookie-list in the following order: 1032 * Cookies with longer paths are listed before cookies with 1033 shorter paths. 1035 * Among cookies that have equal length path fields, cookies with 1036 earlier creation-times are listed before cookies with later 1037 creation-times. 1039 3. Update the last-access-time of each cookie in the cookie-list to 1040 the current date and time. 1042 4. Serialize the cookie-list into a cookie-string by processing each 1043 cookie in the cookie-list in order: 1045 1. If the cookie's name is non-empty, output the cookie's name 1046 followed by the U+003D ("=") character. 1048 2. Output the cookie's value. 1050 3. If there is an unprocessed cookie in the cookie-list, output 1051 the characters U+003B and U+0020 ("; "). 1053 Note: Despite its name, the cookie-string is actually a sequence of 1054 octets, not a sequence of characters. To convert the cookie-string 1055 into a sequence of characters (e.g., for presentation to the user), 1056 the user agent SHOULD use the UTF-8 character encoding [RFC3629]. 1058 6. Implementation Considerations 1060 6.1. Limits 1062 Practical user agent implementations have limits on the number and 1063 size of cookies that they can store. General-use user agents SHOULD 1064 provide each of the following minimum capabilities: 1066 o At least 4096 bytes per cookie (as measured by the sum of the 1067 length of the cookie's name, value, and attributes). 1069 o At least 50 cookies per domain. 1071 o At least 3000 cookies total. 1073 Servers SHOULD use as few and as small cookies as possible to avoid 1074 reaching these implementation limits and to avoid network latency due 1075 to the Cookie header being included in every request. 1077 Servers should gracefully degrade if the user agent fails to return 1078 one or more cookies in the Cookie header because the user agent might 1079 evict any cookie at any time on orders from the user. 1081 6.2. Application Programmer Interfaces 1083 One reason the cookie protocol uses such an esoteric syntax is 1084 because many platforms (both in servers and user agents) provide 1085 string-based application programmer interfaces (APIs), requiring 1086 application-layer programmers to generate and parse the syntax used 1087 by the cookie protocol. 1089 Instead of providing string-based APIs to the cookie protocols, 1090 implementations would be well-served by providing more semantic APIs. 1091 It is beyond the scope of this document to recommend specific API 1092 designs, but there are clear benefits to accepting a abstract "Date" 1093 object instead of a serialized date string. 1095 7. Security Considerations 1097 7.1. Overview 1099 The cookie protocol has a number of security and privacy pitfalls. 1101 In particular, cookies encourage developers to rely on ambient 1102 authority for authentication, often creating vulnerabilities such as 1103 cross-site request forgery. When storing session identifiers in 1104 cookies, developers often create session fixation vulnerabilities. 1106 Transport-layer encryption, such as that employed in HTTPS, is 1107 insufficient to prevent a network attacker from obtaining or altering 1108 a victim's cookies because the cookie protocol itself has various 1109 vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", 1110 below). In addition, by default, the cookie protocol does not 1111 provide confidentiality or integrity from network attackers, even 1112 when used in conjunction with HTTPS. 1114 7.2. Ambient Authority 1116 A server that uses cookies to authenticate users can suffer security 1117 vulnerabilities because some user agents let remote parties issue 1118 HTTP requests from the user agent (e.g., via HTTP redirects and HTML 1119 forms). When issuing those requests, user agent attaches cookies 1120 even if the entity does not know the contents of the cookies, 1121 possibly letting the remote entity exercise authority at an unwary 1122 server. 1124 Although this security concern goes by a number of names (e.g., 1125 cross-site request forgery, confused deputy), the issue stems from 1126 cookies being a form of ambient authority. Cookies encourage server 1127 operators to separate designation (in the form of URLs) from 1128 authorization (in the form of cookies). Consequently, the user agent 1129 might supply the authorization for a resource designated by the 1130 attacker, possibly causing the server or its clients to undertake 1131 actions designated by the attacker as though they were authorized by 1132 the user. 1134 Instead of using cookies for authorization, server operators might 1135 wish to consider entangling designation and authorization by treating 1136 URLs as capabilities. Instead of storing secrets in cookies, this 1137 approach stores secrets in URLs, requiring the remote entity to 1138 supply the secret itself. Although this approach is not a panacea, 1139 judicious use of these principles can lead to more robust security. 1141 7.3. Clear Text 1143 Unless sent over a secure channel (such as TLS), the information in 1144 the Set-Cookie and Cookie headers is transmitted in the clear. 1146 1. All sensitive information conveyed in these headers is exposed to 1147 an eavesdropper. 1149 2. A malicious intermediary could alter the headers as they travel 1150 in either direction, with unpredictable results. 1152 3. A malicious client could alter the Cookie header before 1153 transmission, with unpredictable results. 1155 Servers SHOULD encrypt and sign the contents of cookies when 1156 transmitting them to the user agent (even when sending the cookies 1157 over a secure channel). However, encrypting and signing cookie 1158 contents does not prevent an attacker from transplanting a cookie 1159 from one user agent to another or from replaying the cookie at a 1160 later time. 1162 In addition to encrypting and signing the contents of every cookie, 1163 servers that require a higher level of security SHOULD use the cookie 1164 protocol only over a secure channel. When using the cookie protocol 1165 over a secure channel, servers SHOULD set the Secure attribute in 1166 every cookie. If a server does not set the Secure attribute, the 1167 protection provided by the secure channel will be largely moot. 1169 7.4. Session Identifiers 1171 Instead of storing session information directly in a cookie (where it 1172 might be exposed to or replayed by an attacker), servers commonly 1173 store a nonce (or "session identifier") in a cookie. When the server 1174 receives an HTTP request with a nonce, the server can look up state 1175 information associated with the cookie using the nonce as a key. 1177 Using session identifier cookies limits the damage an attacker can 1178 cause if the attacker learns the contents of a cookie because the 1179 nonce is useful only for interacting with the server (unlike non- 1180 nonce cookie content, which might itself be sensitive). Furthermore, 1181 using a single nonce prevents an attacker from "splicing" together 1182 cookie content from two interactions with the server, which could 1183 cause the server to behave unexpectedly. 1185 Using session identifiers is not without risk. For example, the 1186 server SHOULD take care to avoid "session fixation" vulnerabilities. 1187 A session fixation attack proceeds in three steps. First, the 1188 attacker transplants a session identifier from his or her user agent 1189 to the victim's user agent. Second, the victim uses that session 1190 identifier to interact with the server, possibly imbuing the session 1191 identifier with the user's credentials or confidential information. 1192 Third, the attacker uses the session identifier to interact with 1193 server directly, possibly obtaining the user's authority or 1194 confidential information. 1196 7.5. Weak Confidentiality 1198 Cookies do not provide isolation by port. If a cookie is readable by 1199 a service running on one port, the cookie is also readable by a 1200 service running on another port of the same server. If a cookie is 1201 writable by a service on one port, the cookie is also writable by a 1202 service running on another port of the same server. For this reason, 1203 servers SHOULD NOT both run mutually distrusting services on 1204 different ports of the same host and use cookies to store security- 1205 sensitive information. 1207 Cookies do not provide isolation by scheme. Although most commonly 1208 used with the http and https schemes, the cookies for a given host 1209 might also available to other schemes, such as ftp and gopher. 1210 Although this lack of isolation by scheme is most apparent in via 1211 non-HTTP APIs that permit access to cookies (e.g., HTML's 1212 document.cookie API), the lack of isolation by scheme is actually 1213 present in the cookie protocol itself (e.g., consider retrieving a 1214 URI with the gopher scheme via HTTP). 1216 Cookies do not always provide isolation by path. Although the 1217 network-level protocol does not send cookie stored for one path to 1218 another, some user agents expose cookies via non-HTTP APIs, such as 1219 HTML's document.cookie API. Because some of these user agents (e.g., 1220 web browsers) do not isolate resources received from different paths, 1221 a resource retrieved from one path might be able to access cookies 1222 stored for another path. 1224 7.6. Weak Integrity 1226 Cookies do not provide integrity guarantees for sibling domains (and 1227 their subdomains). For example, consider foo.example.com and 1228 bar.example.com. The foo.example.com server can set a cookie with a 1229 Domain attribute of ".example.com" (possibly overwriting an existing 1230 ".example.com" cookie set by bar.example.com), and the user agent 1231 will include that cookie in HTTP requests to bar.example.com. In the 1232 worst case, bar.example.com will be unable to distinguish this cookie 1233 from a cookie it set itself. The foo.example.com server might be 1234 able to leverage this ability to mount an attack against 1235 bar.example.com. 1237 Even though the cookie protocol supports the Path attribute, the Path 1238 attribute does not provide any integrity protection because the user 1239 agent will accept an arbitrary Path attribute in a Set-Cookie header. 1240 For example, an HTTP response to a request for 1241 http://example.com/foo/bar can set a cookie with a Path attribute of 1242 "/qux". Consequently, servers SHOULD NOT both run mutually 1243 distrusting services on different paths of the same host and use 1244 cookies store security sensitive information. 1246 An active network attacker can also inject cookies into the Cookie 1247 header sent to https://example.com/ by impersonating a response from 1248 http://example.com/ and injecting a Set-Cookie header. The HTTPS 1249 server at example.com will be unable to distinguish these cookies 1250 from cookies that it set itself in an HTTPS response. An active 1251 network attacker might be able to leverage this ability to mount an 1252 attack against example.com even if example.com uses HTTPS 1253 exclusively. 1255 Servers can partially mitigate these attacks by encrypting and 1256 signing the contents of their cookies. However, using cryptography 1257 does not mitigate the issue completely because an attacker can replay 1258 a cookie he or she received from the authentic example.com server in 1259 the user's session, with unpredictable results. 1261 Finally, an attacker might be able to force the user agent to delete 1262 cookies by storing large number of cookies. Once the user agent 1263 reaches its storage limit, the user agent will be forced to evict 1264 some cookies. Servers SHOULD NOT rely upon user agents retaining 1265 cookies. 1267 7.7. Reliance on DNS 1269 The cookie protocol relies upon the Domain Name System (DNS) for 1270 security. If the DNS is partially or fully compromised, the cookie 1271 protocol might fail to provide the security properties required by 1272 applications. 1274 8. References 1276 8.1. Normative References 1278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1279 Requirement Levels", BCP 14, RFC 2119, March 1997. 1281 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1282 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1283 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1285 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1286 10646", STD 63, RFC 3629, November 2003. 1288 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1289 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1291 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1292 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1294 8.2. Informative References 1296 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 1297 Mechanism", RFC 2109, February 1997. 1299 Appendix A. Acknowledgements 1301 This document borrows heavily from RFC 2109 [RFC2109]. We are 1302 indebted to David M. Kristol and Lou Montulli for their efforts to 1303 specify the cookie protocol. David M. Kristol, in particular, 1304 provided invaluable advice on navigating the IETF process. We would 1305 also like to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, Roy 1306 T. Fielding, Blake Frantz, Eran Hammer-Lahav, Jeff Hodges, Achim 1307 Hoffmann, Georg Koppen, Dean McNamee, Mark Miller, Yngve N. 1308 Pettersen, Julian Reschke, Mark Seaborn, Maciej Stachowiak, Daniel 1309 Stenberg, David Wagner, Dan Winship, and Dan Witte for their valuable 1310 feedback on this document. 1312 Author's Address 1314 Adam Barth 1315 University of California, Berkeley 1317 Email: abarth@eecs.berkeley.edu 1318 URI: http://www.adambarth.com/