idnits 2.17.1 draft-abarth-principles-of-origin-00.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 a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2011) is 4807 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 websec A. Barth 3 Internet-Draft Google, Inc. 4 Intended status: Informational February 21, 2011 5 Expires: August 25, 2011 7 Principles of the Same-Origin Policy 8 draft-abarth-principles-of-origin-00 10 Abstract 12 The security model of the web platform has evolved over time to meet 13 the needs of new applications and to correct earlier mistakes. 14 Although web security has evolved largely organically, the security 15 model has converged towards a handful of key concepts. This document 16 presents those concepts and provides advice to designers of new 17 pieces of the web platform. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 25, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Object Access . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Network Access . . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The security model of the web platform has evolved over time to meet 76 the needs of new applications and to correct earlier mistakes. 77 Although web security has evolved largely organically, the security 78 model has converged towards a handful of key concepts. This document 79 presents those concepts and provides advice to designers of new 80 pieces of the web platform. 82 2. Trust 84 On the web, trust is specified by URL. For example, HTML documents 85 designate which script to run with a URL: 87 89 When a user agent process this element, the user agent will fetch the 90 script at that URL and execute the script with the privileges of the 91 document. In this way, the document grants all the privileges it has 92 to the resource specified by the URL. In essence, the document 93 declares that it trusts the integrity of information retrieved from 94 that URL. 96 In addition to importing libraries from URLs, user agents also let 97 principals export data to URLs. For example, consider the HTML form 98 element: 100
101 ... ... 102
104 When the user enters his or her password and submits the form, the 105 password is sent to the network endpoint designated by the URL. In 106 this way, the document exports its secret data to that URL. In 107 essence, the document declares that it trusts the confidentiality of 108 information sent to that URL. 110 2.1. Pitfalls 112 When designing new pieces of the web platform, make sure that 113 important trust distinctions are visible in URLs. For example, if 114 both TLS and non-TLS protected resources used the "http" URL scheme, 115 a document would be unable to specify that it wished to retrieve a 116 script over TLS. By using the "https" URL scheme, documents are able 117 to indicate that they wish to interact with resources that are 118 protected from active network attackers. 120 3. Origin 122 In principle, user agents could treat every URL as a separate 123 principal and isolate each document from every other URL unless the 124 document explicitly indicated that it trusted that URL. 125 Unfortunately, this design is cumbersome for developers because web 126 applications often consist of a number of resource acting in concert. 128 As an approximation, user agents group URLs together into protection 129 domains called origins. In particular, two URLs are part of the same 130 origin (i.e., represent the same principal) if they have the same 131 scheme, host, and port. 133 Q: Why not just use the host? 135 A: Including the scheme in the origin tuple is essential for 136 security. If user agents did not include the scheme, there would be 137 no isolation between documents from http://example.com and 138 https://example.com because the two have the same host. However, 139 without this isolation, an active network attacker could corrupt the 140 document retrieved from http://example.com and then use that document 141 as a stepping stone to compromise the confidentiality and integrity 142 of the document retrieved from https://example.com, bypassing the 143 protections afforded by TLS. 145 Q: Why use the fully qualified host name instead of just the "top- 146 level" domain? 148 A: Although the DNS has hierarchical delegation, the trust 149 relationships between host names vary by deployment. For example, at 150 many educational institutions, students can host content at 151 https://example.edu/~student/, but that does not mean a document 152 authored by a student should be part of the same origin (i.e., 153 represent the same principal) as a web application for managing 154 grades hosted at https://grades.example.edu/. 156 4. Authority 158 Although user agents group URLs into origins, not every resource in 159 an origin carries the same authority. For example, an image is 160 passive content and, therefore, carries no authority, meaning the 161 image has no access to the objects and resources available to its 162 origin. By contrast, an HTML document contains active content and, 163 therefore, carries the full authority of its origin. The user agent 164 determines how much authority to grant a resource by examining its 165 MIME type. For example, resources with a MIME type of image/png are 166 treated as images and resources with a MIME type of text/html are 167 treated as HTML documents. 169 When hosting untrusted content (such as user-generated content), web 170 applications can limit that content's authority by restricting its 171 MIME type. For example, serving user-generated content as image/png 172 is less risky than serving user-generated content as text/html. Of 173 course many web applications incorporate untrusted content in their 174 HTML documents. If not done carefully, these applications risk 175 leaking their origin's authority to the untrusted content, a 176 vulnerability commonly known as cross-site scripting. 178 4.1. Pitfalls 180 When designing new pieces of the web platform, be careful not to 181 grant authority to resources irrespective of MIME type. Many web 182 applications server untrusted content with restricted MIME types. A 183 new web platform feature that grants authority to these pieces of 184 content risks introducing vulnerabilities into existing applications. 185 Instead, prefer to grant authority to MIME types that already possess 186 the origin's full authority or to new MIME types designed 187 specifically to carry the new authority. 189 5. Policy 191 Generally speaking, user agents isolate different origins and permit 192 controlled communication between origins. The details of how user 193 agents provide isolation and communication vary depending on several 194 factors. 196 5.1. Object Access 198 Most objects (also known as application programming interfaces or 199 APIs) exposed by the user agent respect the same-origin policy. 200 Specifically, a script running on behalf of one document can access 201 objects associated with another document if, and only if, the two 202 documents belong to the same origin, e.g., were retrieved from URLs 203 with the same scheme, host, and port. 205 There are some exceptions to this general policy. For example, some 206 parts of HTML's Location interface are available across origins 207 (e.g., to allow for navigating other browsing contexts). As another 208 sample, HTML's postMessage interface is visible across origins to 209 facilitate cross-origin communication. Exposing objects to foreign 210 origins is dangerous and should be done only with great care because 211 doing so exposes these objects to potential attackers. 213 5.2. Network Access 215 Access to network resources varies depending on whether the resources 216 are in the same origin as the document attempting to access them. 218 Generally, reading information from another origin is forbidden. 219 However, a document is permitted use some kinds of resources 220 retrieved from other origins. For example, a document is permitted 221 to execute script, render images, and apply style sheets from any 222 origin. Likewise, a document can display a document from another 223 origin in a frame. 225 Generally, sending information to another origin is permitted. 226 However, sending information over the network in arbitrary formats is 227 dangerous. For this reason, user agents restrict documents to 228 sending information using particular protocols, such as in an HTTP 229 request without custom headers. 231 5.3. Pitfalls 233 Whenever user agents allow documents from one origin to interact with 234 resources in another origin, they invite security issues. For 235 example, the ability to display images from another origin leaks 236 their height and width across origins. Similarly, the ability to 237 send network requests to another origin gives rise to cross-site 238 request forgery vulnerabilities. However, user agents tolerate these 239 risks when the value proposition is high enough. For example, a user 240 agent that blocked cross-origin network requests would prevent its 241 users from following hyperlinks, a core component of the web 242 architecture. 244 When designing new pieces of the web platform, it can be tempting to 245 grant a privilege to one document but to withhold that privilege from 246 another document in the same origin. However, withholding privileges 247 in this way is ineffective because the document without the privilege 248 can usually obtain the privilege anyway because user agents do not 249 isolate documents within an origin. Instead, new pieces of the 250 platform should grant or withhold privileges from origins as a whole 251 (rather than discriminating between individual documents within an 252 origin). 254 6. Conclusion 256 The web security model designates trust relationships with URLs. 257 URLs are grouped together into origins, which represent principals. 258 Some resources in an origin (active content) are granted the origin's 259 full authority, whereas other resources in the origin (passive 260 content) are not granted the origin's authority. Documents that 261 carry their origin's authority are granted access to objects and 262 network resources within their own origin. These documents are also 263 granted limited access to objects and network resources of other 264 origins, but these cross-origin privileges must be carefully designed 265 to avoid introducing security vulnerabilities into the web platform. 267 Appendix A. Acknowledgements 269 We would like to thank Ian Hickson, Collin Jackson, Thomas Roessler, 270 Jesse Ruderman, and Daniel Veditz for their valuable feedback on this 271 document. 273 Author's Address 275 Adam Barth 276 Google, Inc. 278 Email: ietf@adambarth.com 279 URI: http://www.adambarth.com/