idnits 2.17.1 draft-abarth-origin-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 89: '...lowing algorithm MUST be used to compu...' RFC 2119 keyword, line 105: '..., then the implementation MAY return a...' RFC 2119 keyword, line 126: '... Implementations MAY define other type...' RFC 2119 keyword, line 133: '... Implementations MUST use the followin...' RFC 2119 keyword, line 157: '... Implementations MUST using the follow...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 25, 2009) is 5264 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 section? 'RFC3490' on line 204 looks like a reference -- Missing reference section? 'RFC5234' on line 225 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group A. Barth 3 Internet-Draft U.C. Berkeley 4 Expires: May 29, 2010 C. Jackson 5 Stanford University 6 I. Hickson 7 Google, Inc. 8 November 25, 2009 10 The Web Origin Concept 11 draft-abarth-origin-06 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 29, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document defines the concept of an "origin," which is used by 50 web browsers to isolate content retrieved from different parties. 51 The origin concept is defined by a "same-origin" relation and a 52 serialization algorithm. This document also defines an HTTP Origin 53 header, which a user agent can use to describe the security contexts 54 that caused the user agent to initiate an HTTP request. HTTP servers 55 can use the Origin header to mitigate against Cross-Site Request 56 Forgery (CSRF) vulnerabilities. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Unicode Serialization of an Origin . . . . . . . . . . . . 6 65 4.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 6 66 5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8 67 6. HTTP Server Behavior . . . . . . . . . . . . . . . . . . . . . 9 68 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 10. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 This document defines the concept of an "origin," which is used by 77 web browsers to isolate content retrieved from different parties. 78 The origin concept is defined by a "same-origin" relation and a 79 serialization algorithm. This document also defines an HTTP Origin 80 header, which a user agent can use to describe the security contexts 81 that caused the user agent to initiate an HTTP request. HTTP servers 82 can use the Origin header to mitigate against Cross-Site Request 83 Forgery (CSRF) vulnerabilities. 85 TODO: Discuss other CSRF defenses. 87 2. Origin 89 The following algorithm MUST be used to compute the origin of a URI. 91 1. Let /uri/ be the URI for which the origin is being determined. 93 2. Parse /uri/. 95 3. If /uri/ does not use a server-based naming authority, or if 96 parsing /uri/ failed, or if /uri/ is not an absolute URI, then 97 return an implementation-defined value. 99 4. Let /scheme/ be the scheme component of /uri/, converted to 100 lowercase. 102 5. If the implementation doesn't support the protocol given by 103 /scheme/, then return an implementation-defined value. 105 6. If /scheme/ is "file", then the implementation MAY return a 106 implementation-defined value. 108 7. Let /host/ be the host component of /uri/. 110 8. Apply the IDNA ToASCII algorithm [RFC3490] to /host/, with both 111 the AllowUnassigned and UseSTD3ASCIIRules flags set. Let /host/ 112 be the result of the ToASCII algorithm. 114 9. If ToASCII fails to convert one of the components of the string 115 (e.g. because it is too long or because it contains invalid 116 characters), then return an implementation-defined value. 118 10. Let /host/ be the result of converting /host/ to lowercase. 120 11. If there is no port component of /uri/, then let /port/ be the 121 default port for the protocol given by /scheme/. Otherwise, let 122 /port/ be the port component of /uri/. 124 12. Return the tuple (/scheme/, /host/, /port/). 126 Implementations MAY define other types of origins in addition to the 127 scheme/host/port tuple type defined above. (For example, user agents 128 could implement globally unique origins or certificate-based 129 origins.) 131 3. Comparing Origins 133 Implementations MUST use the following algorithm to test whether two 134 origins are the "same origin". 136 1. Let /A/ be the first origin being compared, and let /B/ be the 137 second origin being compared. 139 2. If either /A/ or /B/ is not a scheme/host/port tuple, return an 140 implementation-defined value. 142 3. If /A/ and /B/ have scheme components that are not identical, 143 return false. 145 4. If /A/ and /B/ have host components that are not identical, 146 return false. 148 5. If /A/ and /B/ have port components that are not identical, 149 return false. 151 6. Return true. 153 4. Serializing Origins 155 4.1. Unicode Serialization of an Origin 157 Implementations MUST using the following algorithm to compute the 158 Unicode serialization of an origin: 160 1. If the origin in question is not a scheme/host/port tuple, then 161 return the string 163 null 165 (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) 166 and abort these steps. 168 2. Otherwise, let /result/ be the scheme part of the origin tuple. 170 3. Append the string "://" to /result/. 172 4. Apply the IDNA ToUnicode algorithm [RFC3490] to each component of 173 the host part of the origin tuple, and append the results of each 174 component, in the same order, separated by U+002E FULL STOP code 175 points (".") to /result/. 177 5. If the port part of the origin tuple gives a port that is 178 different from the default port for the protocol given by the 179 scheme part of the origin tuple, then append a U+003A COLON code 180 points (":") and the given port, in base ten, to /result/. 182 6. Return /result/. 184 TODO: Check that we handle IPv6 literals correctly. 186 4.2. ASCII Serialization of an Origin 188 Implementations MUST using the following algorithm to compute the 189 ASCII serialization of an origin: 191 1. If the origin in question is not a scheme/host/port tuple, then 192 return the string 194 null 196 (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) 197 and abort these steps. 199 2. Otherwise, let /result/ be the scheme part of the origin tuple. 201 3. Append the string "://" to /result/. 203 4. If the host part of the origin tuple is in the form of a DNS 204 domain name, apply the IDNA conversion algorithm ([RFC3490] 205 section 4) to it, with both the AllowUnassigned and 206 UseSTD3ASCIIRules flags set, employ the ToASCII operation, and 207 append the result to /result/. 209 5. If ToASCII fails to convert one of the components of the string, 210 e.g. because it is too long or because it contains invalid 211 characters, then return the literal string "null" and abort these 212 steps. 214 6. If the port part of the origin tuple gives a port that is 215 different from the default port for the protocol given by the 216 scheme part of the origin tuple, then append a U+003A COLON code 217 point (":") and the given port, in base ten, to /result/. 219 7. Return /result/. 221 5. User Agent Behavior 223 Whenever a user agent issues an HTTP request, the user agent MUST 224 include exactly one HTTP header named "Origin" that conforms to the 225 following ABNF [RFC5234] grammar: 227 origin = "origin" ":" origin-list-or-null 228 origin-list-or-null = OWS [ "null" / origin-list ] OWS 229 origin-list = serialized-origin *( SP serialized-origin ) 230 serialized-origin = scheme "://" host [ ":" port ] 231 ; , , productions from RFC3986 233 Whenever a user agent would send a Origin header containing two 234 consecutive, identical origin serializations, the user agent MUST 235 remove one such origin serialization from the header. 237 Whenever a user agent issues an HTTP request from a "privacy- 238 sensitive" context, the user agent MUST send the value "null" in the 239 Origin header. 241 If /B/ is the Request-URI in the Request-Line of an HTTP request, 242 then the associated HTTP response is an "HTTP redirect from URI /B/" 243 if the response contains a 3xx Status Code (all terms RFC2616). 245 Whenever a user agent issues an HTTP request to URI /A/ as a result 246 of an HTTP redirect from URI /B/, the user agent MUST either: 248 1. set the value of the Origin header in the HTTP request to /A/ to 249 "null" (i.e., the code point sequence U+006E, U+0075, U+006C, 250 U+006C), 252 2. set the value of the Origin header in the /A/ request to the 253 value of the Origin header in the /B/ request extended with a 254 space and the ASCII serialization of the origin of /B/, unless 255 this would result in the header containing the origin 256 serialization "null" in a component. 258 Whenever a user agent issues an HTTP request that (1) is *not* the 259 result of an HTTP redirect and (2) is *not* initiated from a 260 "privacy-sensitive" context, the user agent SHOULD set the value of 261 the Origin header to the ASCII serialization of the origin that 262 initiated the HTTP request. 264 Note: This behavior differs from that of the HTTP Referer header, 265 which user agents often suppress when an origin with an "https" 266 scheme issues a request for a URI with an "http" scheme. 268 6. HTTP Server Behavior 270 HTTP Servers MAY use the Origin header to "defend themselves against 271 CSRF attacks." Such servers are known as "participating servers" in 272 this section. 274 Let the /origin white list/ of a participating server be a set of 275 strings selected by the operator of that server. 277 The string "null" MUST NOT be a member of the /origin white list/ for 278 any participating server. 280 Example: The origin white list for the example.com Web server 281 could be the strings "http://example.com", "https://example.com", 282 "http://www.example.com", and "https://www.example.com". 284 A participating server MUST use the following algorithm when 285 determining whether to modify state in response to an HTTP request: 287 1. If the request method is safe (as defined by RFC 2616, Section 288 9.1.1, e.g. either "GET" nor "HEAD"), return "MUST NOT modify 289 state" and abort these steps. 291 2. If the request does not contain a header named "Origin", return 292 "MAY modify state" abort these steps. 294 3. For each request header named "Origin", let the /initiating 295 origin list/ be the list of origins represented in the header: 297 1. If there exists a origin in the /initiating origin list/ is 298 not a member of the /origin white list/ for this server, 299 return "MUST NOT modify state" and abort these steps. 301 4. Return "MAY modify state". 303 Example: A Web server could modify state in response to POST 304 requests that lack an Origin header (because these requests are 305 sent by non-supporting user agents) and could modify state in 306 response to POST requests that have an Origin header of 307 "http://example.com", "https://example.com", 308 "http://www.example.com", or "https://www.example.com". 310 7. Privacy Considerations 312 This section is not normative. 314 The Origin header improves on the Referer header by respecting the 315 user's privacy: The Origin header includes only the information 316 required to identify the principal that initiated the request 317 (typically the scheme, host, and port of initiating origin). In 318 particular, the Origin header does not contain the path or query 319 portions of the URI included in the Referer header that invade 320 privacy without providing additional security. 322 The Origin header also improves on the Referer header by not leaking 323 intranet host names to external web sites when a user follows a 324 hyperlink from an intranet host to an external site because 325 hyperlinks generate privacy-sensitive requests. 327 8. Security Considerations 329 This section is not normative. 331 Because a supporting user agent will always include the Origin header 332 when making HTTP requests, HTTP servers can detect that a request was 333 initiated by a supporting user agent by observing the presence of the 334 header. This design prevents a malicious web site from making a 335 supporting user agent appear to be a non-supporting user agent. 336 Unlike the Referer header, which is absent when suppressed by the 337 user agent, the Origin header takes on the value "null" when 338 suppressed by the user agent. 340 In some legacy user agents, The Origin header can be spoofed for 341 same-site XMLHttpRequests. Sites that rely only on network 342 connectivity for authentication should use a DNS rebinding defense, 343 such as validating the HTTP Host header, in addition to CSRF 344 protection. 346 9. IANA Considerations 348 TODO: The "Origin" header should be registered. 350 10. TODO 352 Think about how this interacts with proxies. 354 Think about how this interacts with caches. 356 Think about how this interacts with IPv6. 358 Authors' Addresses 360 Adam Barth 361 University of California, Berkeley 363 Email: abarth@eecs.berkeley.edu 364 URI: http://www.adambarth.com/ 366 Collin Jackson 367 Stanford University 369 Email: collinj@cs.stanford.edu 370 URI: http://www.collinjackson.com/ 372 Ian Hickson 373 Google, Inc. 375 Email: ian@hixie.ch 376 URI: http://ln.hixie.ch/