| websec | A. Barth |
| Internet-Draft | Google, Inc. |
| Intended status: Standards Track | August 17, 2011 |
| Expires: February 18, 2012 |
The Web Origin Concept
draft-ietf-websec-origin-03
This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document defines how to determine the origin of a URI, how to serialize an origin into a string, and an HTTP header, named "Origin", that indicates which origins are associated with an HTTP request.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
User agents interact with content created by a large number of authors. Although many of those authors are well-meaning, some authors might be malicious. To the extent that user agents undertake actions based on content they process, user agent implementors might wish to restrict the ability of malicious authors to disrupt the confidentiality or integrity of other content or servers.
As an example, consider an HTTP user agent that renders HTML content retrieved from various servers. If the user agent executes scripts contained in those documents, the user agent implementor might wish to prevent scripts retrieved from a malicious server from reading documents stored on an honest server, which might, for example, be behind a firewall.
Traditionally, user agents have divided content according to its "origin". More specifically, user agents allow content retrieved from one origin to interact freely with other content retrieved from that origin, but user agents restrict how that content can interact with content from another origin.
This document describes the principles behind the so-called same-origin policy as well as the "nuts and bolts" of comparing and serializing origins. This document does not describe all the facets of the same-origin policy, the details of which are left to other specifications, such as HTML [HTML] and WebSockets [WEBSOCKETS], because the details are often application-specific.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant.
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-ASCII character), VCHAR (any visible US-ASCII character), and WSP (whitespace).
OWS = *( [ obs-fold ] WSP )
; "optional" whitespace
obs-fold = CRLF
The OWS (optional whitespace) rule is used where zero or more linear whitespace characters MAY appear:
The terms user agent, client, server, proxy, and origin server have the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3).
A globally unique identifier is a value which is different from all other previously existing values. For example, a sufficiently long random string is likely to be a globally unique identifier.
An idna-canonicalized host name is the string generated by the following algorithm:
Many user agents undertake actions on behalf of remote parties. For example, HTTP user agents follow redirects, which are instructions from remote servers and HTML user agents expose rich DOM interfaces to scripts retrieved from remote servers.
Without any security model, user agents might undertake actions detrimental to the user or to other parties. Over time, many web-related technologies have converged towards a common security model, known colloquially as the "same-origin policy". Although this security model evolved largely organically, the same-origin policy can be understood in terms of a handful of key concepts. This section presents those concepts and provides advice about how to use these concepts securely.
<script src="https://example.com/library.js"></script>
The same-origin policy specifies trust by URI. For example, HTML documents designate which script to run with a URI:
When a user agent process this element, the user agent will fetch the script at the designated URI and execute the script with the privileges of the document. In this way, the document grants all the privileges it has to the resource designated by the URI. In essence, the document declares that it trusts the integrity of information retrieved from that URI.
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>
In addition to importing libraries from URIs, user agents also send information to remote parties designated by URI. For example, consider the HTML form element:
When the user enters his or her password and submits the form, the user agent sends the password to the network endpoint designated by the URI. In this way, the document exports its secret data to that URI, in essence declaring that it trusts the confidentiality of information sent to that URI.
When designing new protocols that use the same-origin policy, make sure that important trust distinctions are visible in URIs. For example, if both TLS and non-TLS protected resources used the "http" URI scheme (as in [RFC2817]), a document would be unable to specify that it wished to retrieve a script only over TLS. By using the "https" URI scheme, documents are able to indicate that they wish to interact with resources that are protected from active network attackers.
In principle, user agents could treat every URI as a separate protection domain and require explicit consent for content retrieved from one URI to interact with another URI. Unfortunately, this design is cumbersome for developers because web applications often consist of a number of resources acting in concert.
Instead, user agents group URIs together into protection domains called "origins". Roughly speaking, two URIs are part of the same origin (i.e., represent the same principal) if they have the same scheme, host, and port. (See Section 4 for full details.)
Q: Why not just use the host?
A: Including the scheme in the origin tuple is essential for security. If user agents did not include the scheme, there would be no isolation between http://example.com and https://example.com because the two have the same host. However, without this isolation, an active network attacker could corrupt content retrieved from http://example.com and have that content instruct the user agent to compromise the confidentiality and integrity of content retrieved from https://example.com, bypassing the protections afforded by TLS [RFC5246].
Q: Why use the fully qualified host name instead of just the "top-level" domain?
A: Although the DNS has hierarchical delegation, the trust relationships between host names vary by deployment. For example, at many educational institutions, students can host content at https://example.edu/~student/, but that does not mean a document authored by a student should be part of the same origin (i.e., inhabit the same protection domain) as a web application for managing grades hosted at https://grades.example.edu/.
The example.edu deployment illustrates that grouping resources by origin does not always align perfectly with every deployment scenario. In this deployment every student's web site inhabits the same origin, which might not be desirable. In some sense, the origin granularity is a historical artifact of how the security model evolved.
http://example.com/
http://example.com:80/
http://example.com/path/file
http://example.com/
All of the following resources have the same origin:
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/
Each of the following resources has a different origin from the others.
Although user agents group URIs into origins, not every resource in an origin carries the same authority (in the security sense of the word "authority", not in the RFC 3986 sense). For example, an image is passive content and, therefore, carries no authority, meaning the image has no access to the objects and resources available to its origin. By contrast, an HTML document carries the full authority of its origin and scripts within (or imported into) the document can access every resource in its origin.
User agent determine how much authority to grant a resource by examining its media type. For example, resources with a media type of image/png are treated as images and resources with a media type of text/html are treated as HTML documents.
When hosting untrusted content (such as user-generated content), web applications can limit that content’s authority by restricting its media type. For example, serving user-generated content as image/png is less risky than serving user-generated content as text/html. Of course many web applications incorporate untrusted content in their HTML documents. If not done carefully, these applications risk leaking their origin’s authority to the untrusted content, a vulnerability commonly known as cross-site scripting.
When designing new pieces of the web platform, be careful not to grant authority to resources irrespective of media type. Many web applications serve untrusted content with restricted media types. A new web platform feature that grants authority to these pieces of content risks introducing vulnerabilities into existing applications. Instead, prefer to grant authority to media types that already possess the origin’s full authority or to new media types designed specifically to carry the new authority.
In order to remain compatible with servers that supply incorrect media types, some user agents employ "content sniffing" and treat content as if it had a different media type than the media type supplied by the server. If not done carefully, content sniffing can lead to security vulnerabilities because user agents might grant low-authority media types, such as images, the privileges of high-authority media types, such as HTML documents [SNIFF].
Generally speaking, user agents isolate different origins and permit controlled communication between origins. The details of how user agents provide isolation and communication vary depending on several factors.
Most objects (also known as application programming interfaces or APIs) exposed by the user agent are available only to the same origin. Specifically, content retrieved from one URI can access objects associated with content retrieved from another URI if, and only if, the two URIs belong to the same origin, e.g., have same scheme, host, and port.
There are some exceptions to this general rule. For example, some parts of HTML’s Location interface are available across origins (e.g., to allow for navigating other browsing contexts). As another sample, HTML’s postMessage interface is visible across origins explicitly to facilitate cross-origin communication. Exposing objects to foreign origins is dangerous and should be done only with great care because doing so exposes these objects to potential attackers.
Access to network resources varies depending on whether the resources are in the same origin as the content attempting to access them.
Generally, reading information from another origin is forbidden. However, an origin is permitted to use some kinds of resources retrieved from other origins. For example, an origin is permitted to execute script, render images, and apply style sheets from any origin. Likewise, an origin can display content from another origin, such as an HTML document in an HTML frame. Network resources can also opt into letting other origins read their information, for example using Cross-Origin Resource Sharing [CORS]. In these cases, access is typically granted on a per-origin basis.
Sending information to another origin is permitted. However, sending information over the network in arbitrary formats is dangerous. For this reason, user agents restrict documents to sending information using particular protocols, such as in an HTTP request without custom headers. Expanding the set of allowed protocols, for example by adding support for WebSockets, must be done carefully to avoid introducing vulnerabilities [WEBSOCKETS].
Whenever user agents allow one origin to interact with resources from another origin, they invite security issues. For example, the ability to display images from another origin leaks their height and width. Similarly, the ability to send network requests to another origin gives rise to cross-site request forgery vulnerabilities [CSRF]. However, user agent implementors often balance these risks against the benefits of allowing the cross-origin interaction. For example, an HTML user agent that blocked cross-origin network requests would prevent its users from following hyperlinks, a core feature of the web.
When adding new functionality to the web platform, it can be tempting to grant a privilege to one resource but to withhold that privilege from another resource in the same origin. However, withholding privileges in this way is ineffective because the resource without the privilege can usually obtain the privilege anyway because user agents do not isolate resources within an origin. Instead, privileges should be granted or withheld from origins as a whole (rather than discriminating between individual resources within an origin) [BOFGO].
The same-origin policy uses URIs to designate trust relationships. URIs are grouped together into origins, which represent protection domains. Some resources in an origin (e.g., active content) are granted the origin’s full authority, whereas other resources in the origin (e.g., passive content) are not granted the origin’s authority. Content that carries its origin’s authority is granted access to objects and network resources within its own origin. This content is also granted limited access to objects and network resources of other origins, but these cross-origin privileges must be designed carefully to avoid security vulnerabilities.
The origin of a URI is the value computed by the following algorithm:
Otherwise:
Implementations MAY define other types of origins in addition to the scheme/host/port triple type defined above. For example, an implementation might define an origin based on a public key or an implementation might append additional "sandbox" bits to a scheme/host/port triple.
Two origins are "the same" if, and only if, they are identical. In particular:
Two URIs are the same-origin if their origins are the same.
This section defines how to serialize an origin to a unicode string and to an ASCII string.
The unicode-serialization of an origin is the value returned by the following algorithm:
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
The ascii-serialization of an origin is the value returned by the following algorithm:
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
This section defines the HTTP Origin header.
origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = "null" / origin-list
origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> productions from RFC3986
The Origin header has the following syntax:
When included in an HTTP request, the Origin header indicates the origin(s) that "caused" the user agent to issue the request, as defined by the API that triggered the user agent to issue the request.
For example, consider a user agent that executes scripts on behalf of origins. If one of those scripts causes the user agent to issue an HTTP request, the user agent might wish to use the Origin header to inform the server of the security context in which the script was executing when it caused the user agent to issue the request.
In some cases, a number of origins contribute to causing the user agents to issue an HTTP request. In those cases, the user agent can list all the origins in the Origin header. For example, if the HTTP request was initially issued by one origin but then later redirected by another origin, the user agent might wish to inform the server that two origins were involved in causing the user agent to issue the request.
The user agent MAY include an Origin header in any HTTP request.
The user agent MUST NOT include more than one Origin header field in any HTTP request.
Whenever a user agent issues an HTTP request from a "privacy-sensitive" context, the user agent MUST send the value "null" in the Origin header.
When generating an Origin header, the user agent MUST meet the following requirements:
The same-origin policy is one of the cornerstones of security for many user agents, including web browsers. Historically, some user agents tried other security models, including taint tracking and exfiltration prevention, but those model proved difficult to implement at the time (although there has been recent interest in reviving some of these ideas).
Evaluating the security of the same-origin policy is difficult because the origin concept itself plays such a central role in the security landscape. The notional origin itself is just a unit of isolation, imperfect as are most one-size-fits-all notions. That said, there are some systemic weaknesses, discussed below.
In practice, the same-origin policy relies upon the Domain Name System (DNS) for security because many commonly used URI schemes, such as http, use DNS-based naming authorities. If the DNS is partially or fully compromised, the same-origin policy might fail to provide the security properties required by applications.
Some URI schemes, such as https, are more resistant to DNS compromise because user agents employ other mechanisms, such as certificates, to verify the source of content retrieved from these URIs. Other URI schemes, such as the chrome-extension URI scheme (see Section 4.3 of [CRX]), use a public-key-based naming authority and are fully secure against DNS compromise.
That the web origin concept isolates content retrieved from different URI schemes is essential to containing the effects of DNS compromise.
Over time, a number of technologies have converged on the web origin concept as a convenient unit of isolation. However, many technologies in use today, such as cookies [RFC6265], pre-date the modern web origin concept. These technologies often have different isolation units, leading to vulnerabilities.
One alternative is to use only the "registry-controlled" domain rather than the fully qualified domain name as the unit of isolation (e.g., "example.com" instead of "www.example.com"). This practice is problematic for a number of reasons, and is NOT RECOMMENDED:
At best, using registry-controlled domains is URI-scheme- and implementation-specific. At worse, differences between URI schemes and implementations can lead to vulnerabilities.
When using the same-origin policy, user agents grant authority to content based on the URI from which the user agent retrieved the content rather than based on the objects which the content is able to designate. This disentangling of designation from authority is an example of ambient authority and can lead to vulnerabilities.
Consider, for example, cross-site scripting in HTML documents. If an attacker can inject script content into an HTML document, those scripts will run with the authority of the document's origin, perhaps allowing the script access to sensitive information, such as the user's medical records. If, however, the script's authority were limited to those objects that the script could designate, the attacker would not gain any advantage by injecting the script into an HTML document hosted by a third party.
The permanent message header field registry (see [RFC3864]) should be updated with the following registrations:
Header field name: Origin
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document: this specification (Section 7)
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not backwards-compatible. For this reason, there will be a transition period (possibly of a number of years). User agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46 <http://unicode.org/reports/tr46/>] in order to facilitate a smoother IDNA transition. If a user agent does not implement IDNA2008, the user agent MUST implement IDNA2003 [RFC3490].
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2 ", RFC 5246, August 2008. |
| [RFC2817] | Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. |
| [RFC6265] | Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011. |
| [WEBSOCKETS] | Fette, I, "The WebSocket protocol", Internet-Draft draft-ietf-hybi-thewebsocketprotocol-09, June 2011. |
| [SNIFF] | Barth, A and I Hickson, "Media Type Sniffing", Internet-Draft draft-ietf-websec-mime-sniff-03, May 2011. |
| [HTML] |
Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525, May 2011. Latest version available at |
| [CORS] |
van Kesteren, A., "Cross-Origin Resource Sharing", W3C Working Draft WD-cors-20100727, July 2010. Latest version available at |
| [CSRF] | Barth, A., Jackson, C. and J. Mitchell, "Robust Defenses for Cross-Site Request Forgery", 2008. |
| [BOFGO] | Jackson, C. and A. Barth, "Beware of Finer-Grained Origins", 2008. |
| [CRX] | Barth, A., Felt, A., Saxena, P. and A. Boodman, "Protecting Browsers from Extension Vulnerabilities", 2010. |