idnits 2.17.1 draft-abarth-origin-01.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 83: '...llowing algoritm MUST be used to compu...' RFC 2119 keyword, line 99: '..., then the implementation MAY return a...' RFC 2119 keyword, line 120: '... Implementations MAY define other type...' RFC 2119 keyword, line 127: '... Implementations MUST use the followin...' RFC 2119 keyword, line 151: '... Implementations MUST using the follow...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 24, 2009) is 5420 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: December 26, 2009 C. Jackson 5 Stanford University 6 I. Hickson 7 Google, Inc. 8 June 24, 2009 10 The HTTP Sec-From Header 11 draft-abarth-origin-01 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 December 26, 2009. 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 HTTP Sec-From header. The Sec-From header 50 is added by the user agent to describe the security contexts that 51 caused the user agent to initiate an HTTP request. HTTP servers can 52 use the Sec-From header to mitigate against Cross-Site Request 53 Forgery (CSRF) vulnerabilities. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Unicode Serialization of an Origin . . . . . . . . . . . . 6 62 4.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 6 63 5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8 64 6. HTTP Server Behavior . . . . . . . . . . . . . . . . . . . . . 9 65 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 10. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 This document describes the HTTP Sec-From header. The Sec-From 74 header identifies the security contexts that caused the user agent to 75 initiate an HTTP request. HTTP servers can mitigate cross-site 76 request forgery vulnerabilies by accepting requests only if the Sec- 77 From header contains only white-listed origins. 79 TODO: Discuss other CSRF defenses. 81 2. Origin 83 The following algoritm MUST be used to compute the origin of a URI. 85 1. Let /uri/ be the URI for which the origin is being determined. 87 2. Parse /uri/. 89 3. If /uri/ does not use a server-based naming authority, or if 90 parsing /uri/ failed, or if /uri/ is not an absolute URI, then 91 return an implementation-defined value. 93 4. Let /scheme/ be the scheme component of /uri/, converted to 94 lowercase. 96 5. If the implementation doesn't support the protocol given by 97 /scheme/, then return an implementaion-defined value. 99 6. If /scheme/ is "file", then the implementation MAY return a 100 implementation-defined value. 102 7. Let /host/ be the host component of /uri/. 104 8. Apply the IDNA ToASCII algorithm to /host/, with both the 105 AllowUnassigned and UseSTD3ASCIIRules flags set. Let /host/ be 106 the result of the ToASCII algorithm. 108 9. If ToASCII fails to convert one of the components of the string 109 (e.g. because it is too long or because it contains invalid 110 characters), then return an implementation-defined value. 112 10. Let /host/ be the result of converting /host/ to lowercase. 114 11. If there is no port component of /uri/, then let /port/ be the 115 default port for the protocol given by /scheme/. Otherwise, let 116 /port/ be the port component of /uri/. 118 12. Return the tuple (/scheme/, /host/, /port/). 120 Implementations MAY define other types of origins in addition to the 121 scheme/host/port tuple type defined above. (For example, user agents 122 could implement globally unique origins or certificate-based 123 origins.) 125 3. Comparing Origins 127 Implementations MUST use the following algorithm to test whether two 128 origins are the "same origin". 130 1. Let /A/ be the first origin being compared, and let /B/ be the 131 second origin being compared. 133 2. If either /A/ or /B/ is not a scheme/host/port tuple, return an 134 implementation-defined value. 136 3. If /A/ and /B/ have scheme components that are not identical, 137 return false. 139 4. If /A/ and /B/ have host components that are not identical, 140 return false. 142 5. If /A/ and /B/ have port components that are not identical, 143 return false. 145 6. Return true. 147 4. Serializing Origins 149 4.1. Unicode Serialization of an Origin 151 Implementations MUST using the following algorithm to compute the 152 Unicode serialization of an origin: 154 1. If the origin in question is not a scheme/host/port tuple, then 155 return the string 157 null 159 (i.e., the character sequence U+006E, U+0075, U+006C, U+006C) and 160 abort these steps. 162 2. Otherwise, let /result/ be the scheme part of the origin tuple. 164 3. Append the string "://" to /result/. 166 4. Apply the IDNA ToUnicode algorithm to each component of the host 167 part of the origin tuple, and append the results of each 168 component, in the same order, separated by U+002E FULL STOP 169 characters (".") to /result/. 171 5. If the port part of the origin tuple gives a port that is 172 different from the default port for the protocol given by the 173 scheme part of the origin tuple, then append a U+003A COLON 174 character (":") and the given port, in base ten, to /result/. 176 6. Return /result/. 178 TODO: Check that we handle IPv6 literals correctly. 180 4.2. ASCII Serialization of an Origin 182 Implementations MUST using the following algorithm to compute the 183 ASCII serialization of an origin: 185 1. If the origin in question is not a scheme/host/port tuple, then 186 return the string 188 null 190 (i.e., the character sequence U+006E, U+0075, U+006C, U+006C) and 191 abort these steps. 193 2. Otherwise, let /result/ be the scheme part of the origin tuple. 195 3. Append the string "://" to /result/. 197 4. Apply the IDNA ToASCII algorithm the host part of the origin 198 tuple, with both the AllowUnassigned and UseSTD3ASCIIRules flags 199 set, and append the result to /result/. 201 5. If ToASCII fails to convert one of the components of the string, 202 e.g. because it is too long or because it contains invalid 203 characters, then return the literal string "null" and abort these 204 steps. 206 6. If the port part of the origin tuple gives a port that is 207 different from the default port for the protocol given by the 208 scheme part of the origin tuple, then append a U+003A COLON 209 character (":") and the given port, in base ten, to /result/. 211 7. Return /result/. 213 5. User Agent Behavior 215 Whenever a user agent issues an HTTP request, the user agent MUST 216 include exactly one HTTP header named "Sec-From". 218 The value of the Sec-From header MUST either be 220 1. the string "null" (i.e., the character sequence U+006E, U+0075, 221 U+006C, U+006C) or 223 2. a sequence of non-"null" ASCII serializations of origins 224 separated by at least one LWS character. 226 Whenever a user agent would send a Sec-From header containing two 227 consecutive, idential origin serializations, the user agent MAY 228 remove one such origin serialization from the header. 230 Whenever a user agent issues an HTTP request from a "privacy- 231 sensitive" context, the user agent MUST send the value "null" in the 232 Sec-From header. 234 Whenever a user agent issues an HTTP request to URI /A/ as a result 235 of an HTTP redirect from URI /B/, the user agent MUST either: 237 1. set the value of the Sec-From header in the HTTP request to /A/ 238 to "null" (i.e., the character sequence U+006E, U+0075, U+006C, 239 U+006C), 241 2. set the value of the Sec-From header in the /A/ request to the 242 value of the Sec-From header in the /B/ request extended with a 243 space and the ASCII serialization of the origin of /B/, unless 244 this would result in the header containing the origin 245 serialization "null". 247 Whenever a user agent issues an HTTP request that (1) is *not* the 248 result of an HTTP redirect and (2) is *not* initiated from a 249 "privacy-sensitive" context, the user agent SHOULD set the value of 250 the Sec-From header to the ASCII serialization of the origin that 251 initiated the HTTP request. 253 Note: This behavior differs from that of the HTTP Referer header, 254 which user agents often suppress when an origin with an "https" 255 scheme issues a request for a URI with an "http" scheme. 257 6. HTTP Server Behavior 259 HTTP Servers MAY use the Sec-From header to "defend themselves 260 against CSRF attacks." Such servers are known as "participating 261 servers" in this section. 263 Let the /origin white list/ of a participating server be a set of 264 strings selected by the operator of that server. 266 The string "null" MUST NOT be a member of the /origin white list/ for 267 any participating server. 269 Example: The origin white list for the example.com Web server 270 could be the strings "http://example.com", "https://example.com", 271 "http://www.example.com", and "https://www.example.com". 273 A participating server MUST use the following algorithm when 274 determining whether to modify state in response to an HTTP request: 276 1. If the request method is safe (as defined by RFC 2616, Section 277 9.1.1, e.g. either "GET" nor "HEAD"), return "MUST NOT modify 278 state" and abort these steps. 280 2. If the request does not contain a header named "Sec-From", return 281 "MAY modify state" abort these stepts. 283 3. For each request header named "Sec-From", let the /initiating 284 origin list/ be the list of origins represented in the header: 286 1. If there exists a origin in the /initiating origin list/ is 287 not a member of the /origin white list/ for this server, 288 return "MUST NOT modify state" and abort these steps. 290 4. Return "MAY modify state". 292 Example: A Web server could modify state in response to POST 293 requests that lack an Sec-From header (because these requests are 294 sent by non-supporting user agents) and could modify state in 295 response to POST requests that have an Sec-From header of 296 "http://example.com", "https://example.com", 297 "http://www.example.com", or "https://www.example.com". 299 7. Privacy Considerations 301 This section is not normative. 303 The Sec-From header improves on the Referer header by respecting the 304 user's privacy: The Sec-From header includes only the information 305 required to identify the principal that initiated the request 306 (typically the scheme, host, and port of initiating origin). In 307 particular, the Sec-From header does not contain the path or query 308 portions of the URI included in the Referer header that invade 309 privacy without providing additional security. 311 The Sec-From header also improves on the Referer header by NOT 312 leaking intranet host names to external Web sites when a user follows 313 a hyperlink from an intranet host to an external site because 314 hyperlinks generate privacy-sensitive requests. 316 8. Security Considerations 318 This section is not normative. 320 Because a supporting user agent will always include the Sec-From 321 header when making HTTP requests, HTTP servers can detect that a 322 request was initiated by a supporting user agent by observing the 323 presence of the header. This design prevents an attacker from making 324 a supporting user agent appear to be a non-supporting user agent. 325 Unlike the Referer header, which is absent when suppressed by the 326 user agent, the Sec-From header takes on the value "null" when 327 suppressed by the user agent. 329 In some legacy user agents, The Sec-From header can be spoofed for 330 same-site XMLHttpRequests. Sites that rely only on network 331 connectivity for authentication should use a DNS rebinding defense, 332 such as validating the HTTP Host header, in addition to CSRF 333 protection. 335 9. IANA Considerations 337 TODO: The "Sec-From" header should be registered. 339 10. TODO 341 Think about how this interacts with proxies. 343 Think about how this interacts with caches. 345 Authors' Addresses 347 Adam Barth 348 University of California, Berkeley 350 Email: abarth@eecs.berkeley.edu 351 URI: http://www.adambarth.com/ 353 Collin Jackson 354 Stanford University 356 Email: collinj@cs.stanford.edu 357 URI: http://www.collinjackson.com/ 359 Ian Hickson 360 Google, Inc. 362 Email: ian@hixie.ch 363 URI: http://ln.hixie.ch/