draft-ietf-websec-origin-04.txt   draft-ietf-websec-origin-05.txt 
websec A. Barth websec A. Barth
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track August 23, 2011 Intended status: Standards Track September 23, 2011
Expires: February 24, 2012 Expires: March 26, 2012
The Web Origin Concept The Web Origin Concept
draft-ietf-websec-origin-04 draft-ietf-websec-origin-05
Abstract Abstract
This document defines the concept of an "origin", which is often used This document defines the concept of an "origin", which is often used
as the scope of authority or privilege by user agents. Typically, as the scope of authority or privilege by user agents. Typically,
user agents isolate content retrieved from different origins to user agents isolate content retrieved from different origins to
prevent malicious web site operators from interfering with the prevent malicious web site operators from interfering with the
operation of benign web sites. In addition to outlining the operation of benign web sites. In addition to outlining the
principles that underlie the concept of origin, this document defines principles that underlie the concept of origin, this document defines
how to determine the origin of a URI, how to serialize an origin into 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 a string, and an HTTP header field, named "Origin", that indicates
origins are associated with an HTTP request. which origins are associated with an HTTP request.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 24, 2012. This Internet-Draft will expire on March 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 9 3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 10 3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 10
3.4.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 12 4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 12
5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 13 5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 14
6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 14 6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 15
6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 14 6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15
6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 14 6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15
7. The HTTP Origin header . . . . . . . . . . . . . . . . . . . . 16 7. The HTTP Origin header field . . . . . . . . . . . . . . . . . 17
7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 16 7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 18 8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 19
8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 18 8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 19
8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 19 8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Implementation Considerations . . . . . . . . . . . . . . . . 21 10. IDNA dependency and migration . . . . . . . . . . . . . . . . 22
10.1. IDNA dependency and migration . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
User agents interact with content created by a large number of User agents interact with content created by a large number of
authors. Although many of those authors are well-meaning, some authors. Although many of those authors are well-meaning, some
authors might be malicious. To the extent that user agents undertake authors might be malicious. To the extent that user agents undertake
actions based on content they process, user agent implementors might actions based on content they process, user agent implementors might
wish to restrict the ability of malicious authors to disrupt the wish to restrict the ability of malicious authors to disrupt the
confidentiality or integrity of other content or servers. confidentiality or integrity of other content or servers.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
character. character.
2.3. Terminology 2.3. Terminology
The terms user agent, client, server, proxy, and origin server have The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification ([RFC2616], Section the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
1.3). 1.3).
A globally unique identifier is a value which is different from all A globally unique identifier is a value which is different from all
other previously existing values. For example, a sufficiently long other previously existing values. For example, a sufficiently long
random string is likely to be a globally unique identifier. random string is likely to be a globally unique identifier. If the
origin value never leaves the user agent, a monotonically increasing
counter local to the user agent can also serve as a globally unique
identifier
An idna-canonicalized host name is the string generated by the For the purposes of this document, we define "idna-canonicalized host
following algorithm: name" as the string generated by the following algorithm:
1. Convert the host name to a sequence of NR-LDH labels (see Section 1. Convert the host name to a sequence of NR-LDH labels (see Section
2.3.2.2 of [RFC5890]) and/or A-labels according to the 2.3.2.2 of [RFC5890]) and/or A-labels according to the
appropriate IDNA specification [RFC5891] or [RFC3490] (see appropriate IDNA specification [RFC5891] or [RFC3490] (see
Section 10.1 of this specification) Section 10 of this specification)
2. Convert the labels to lower case (using the i;ascii-casemap 2. Convert the labels to lower case (using the i;ascii-casemap
collation defined in [RFC4790]). collation defined in [RFC4790]).
3. Concatenate the labels, separating each label from the next with 3. Concatenate the labels, separating each label from the next with
a %x2E (".") character. a %x2E (".") character.
3. Principles of the Same-Origin Policy 3. Principles of the Same-Origin Policy
Many user agents undertake actions on behalf of remote parties. For Many user agents undertake actions on behalf of remote parties. For
skipping to change at page 8, line 38 skipping to change at page 8, line 38
http://example.org/ http://example.org/
http://ietf.org/ http://ietf.org/
In each case, at least one of the scheme, host, and port component In each case, at least one of the scheme, host, and port component
will differ from the others in the list. will differ from the others in the list.
3.3. Authority 3.3. Authority
Although user agents group URIs into origins, not every resource in Although user agents group URIs into origins, not every resource in
an origin carries the same authority (in the security sense of the an origin carries the same authority (in the security sense of the
word "authority", not in the RFC 3986 sense). For example, an image word "authority", not in the [RFC3986] sense). For example, an image
is passive content and, therefore, carries no authority, meaning the is passive content and, therefore, carries no authority, meaning the
image has no access to the objects and resources available to its image has no access to the objects and resources available to its
origin. By contrast, an HTML document carries the full authority of origin. By contrast, an HTML document carries the full authority of
its origin and scripts within (or imported into) the document can its origin and scripts within (or imported into) the document can
access every resource in its origin. access every resource in its origin.
User agent determine how much authority to grant a resource by User agents determine how much authority to grant a resource by
examining its media type. For example, resources with a media type 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 of image/png are treated as images and resources with a media type of
text/html are treated as HTML documents. text/html are treated as HTML documents.
When hosting untrusted content (such as user-generated content), web When hosting untrusted content (such as user-generated content), web
applications can limit that content's authority by restricting its applications can limit that content's authority by restricting its
media type. For example, serving user-generated content as image/png media type. For example, serving user-generated content as image/png
is less risky than serving user-generated content as text/html. Of is less risky than serving user-generated content as text/html. Of
course many web applications incorporate untrusted content in their course many web applications incorporate untrusted content in their
HTML documents. If not done carefully, these applications risk HTML documents. If not done carefully, these applications risk
skipping to change at page 10, line 5 skipping to change at page 10, line 5
Most objects (also known as application programming interfaces or Most objects (also known as application programming interfaces or
APIs) exposed by the user agent are available only to the same APIs) exposed by the user agent are available only to the same
origin. Specifically, content retrieved from one URI can access origin. Specifically, content retrieved from one URI can access
objects associated with content retrieved from another URI if, and objects associated with content retrieved from another URI if, and
only if, the two URIs belong to the same origin, e.g., have same only if, the two URIs belong to the same origin, e.g., have same
scheme, host, and port. scheme, host, and port.
There are some exceptions to this general rule. For example, some There are some exceptions to this general rule. For example, some
parts of HTML's Location interface are available across origins parts of HTML's Location interface are available across origins
(e.g., to allow for navigating other browsing contexts). As another (e.g., to allow for navigating other browsing contexts). As another
sample, HTML's postMessage interface is visible across origins example, HTML's postMessage interface is visible across origins
explicitly to facilitate cross-origin communication. Exposing explicitly to facilitate cross-origin communication. Exposing
objects to foreign origins is dangerous and should be done only with objects to foreign origins is dangerous and should be done only with
great care because doing so exposes these objects to potential great care because doing so exposes these objects to potential
attackers. attackers.
3.4.2. Network Access 3.4.2. Network Access
Access to network resources varies depending on whether the resources Access to network resources varies depending on whether the resources
are in the same origin as the content attempting to access them. are in the same origin as the content attempting to access them.
skipping to change at page 12, line 11 skipping to change at page 12, line 11
content is also granted limited access to objects and network content is also granted limited access to objects and network
resources of other origins, but these cross-origin privileges must be resources of other origins, but these cross-origin privileges must be
designed carefully to avoid security vulnerabilities. designed carefully to avoid security vulnerabilities.
4. Origin of a URI 4. Origin of a URI
The origin of a URI is the value computed by the following algorithm: The origin of a URI is the value computed by the following algorithm:
1. If the URI does not use a hierarchical element as a naming 1. If the URI does not use a hierarchical element as a naming
authority (see [RFC3986], Section 3.2), or if the URI is not an authority (see [RFC3986], Section 3.2), or if the URI is not an
absolute URI, then return a globally unique identifier. absolute URI, then generate a fresh globally unique identifier
and return that value.
1. NOTE: Running this algorithm multiple times for the same URI
can produce different values each time. Typically, user
agents compute the origin of, for example, an HTML document
once and use that origin for subsequent security checks
rather than recomputing the origin for each security check.
2. Let uri-scheme be the scheme component of the URI, converted to 2. Let uri-scheme be the scheme component of the URI, converted to
lowercase. lowercase.
3. If the implementation doesn't support the protocol given by uri- 3. If the implementation doesn't support the protocol given by uri-
scheme, then return a globally unique identifier. scheme, then return generate a fresh globally unique identifier
and return that value.
4. If uri-scheme is "file", the implementation MAY return an 4. If uri-scheme is "file", the implementation MAY return an
implementation-defined value. implementation-defined value.
1. NOTE: Historically, user agents have granted content from the 1. NOTE: Historically, user agents have granted content from the
file scheme a tremendous amount of privilege. However, file scheme a tremendous amount of privilege. However,
granting all local files such wide privileges can lead to granting all local files such wide privileges can lead to
privilege escalation attacks. Some user agents have had privilege escalation attacks. Some user agents have had
success granting local files directory-based privileges, but success granting local files directory-based privileges, but
this approach has not been widely adopted. Other user agent this approach has not been widely adopted. Other user agents
use a globally unique identifier each file URI, which is the use globally unique identifiers for each file URI, which is
most secure option. the most secure option.
5. Let uri-host be the idna-canonicalized form of the host component 5. Let uri-host be the idna-canonicalized form of the host component
of the URI. of the URI.
6. If there is no port component of the URI: 6. If there is no port component of the URI:
1. Let uri-port be the default port for the protocol given by 1. Let uri-port be the default port for the protocol given by
uri-scheme. uri-scheme.
Otherwise: Otherwise:
2. Let uri-port be the port component of the URI. 2. Let uri-port be the port component of the URI.
7. Return the triple (uri-scheme, uri-host, uri-port). 7. Return the triple (uri-scheme, uri-host, uri-port).
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.
5. Comparing Origins 5. Comparing Origins
Two origins are "the same" if, and only if, they are identical. In Two origins are "the same" if, and only if, they are identical. In
particular: particular:
o If the two origins are scheme/host/port triples, the two origins o If the two origins are scheme/host/port triples, the two origins
are the same if, and only if, they have identical schemes, hosts, are the same if, and only if, they have identical schemes, hosts,
and ports. and ports.
o An origin that is a globally unique identifier cannot be the same o An origin that is a globally unique identifier cannot be the same
as an origin that is a scheme/host/port triple. as an origin that is a scheme/host/port triple.
o Two origins that are globally unique identifiers cannot be the
same if they were created at different times, even if they were
created for the same URI.
Two URIs are the same-origin if their origins are the same. Two URIs are the same-origin if their origins are the same.
NOTE: A URI is not necessarily same-origin with itself. For NOTE: A URI is not necessarily same-origin with itself. For
example, a data URI [RFC2397] is not same-origin with itself example, a data URI [RFC2397] is not same-origin with itself
because data URIs do not use a server-based naming authority and because data URIs do not use a server-based naming authority and
therefore have globally unique identifiers as origins. therefore have globally unique identifiers as origins.
6. Serializing Origins 6. Serializing Origins
This section defines how to serialize an origin to a unicode This section defines how to serialize an origin to a unicode
skipping to change at page 14, line 28 skipping to change at page 15, line 28
null null
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)
and abort these steps. and abort these steps.
2. Otherwise, let result be the scheme part of the origin triple. 2. Otherwise, let result be the scheme part of the origin triple.
3. Append the string "://" to result. 3. Append the string "://" to result.
4. Apply the IDNA ToUnicode algorithm (from the appropriate IDNA 4. Apply the IDNA ToUnicode algorithm (from the appropriate IDNA
specification [RFC5891] or [RFC3490], see Section 10.1 of this specification [RFC5891] or [RFC3490], see Section 10 of this
specification) to each component of the host part of the origin specification) to each component of the host part of the origin
triple, and append the results of each component, in the same triple, and append the results of each component, in the same
order, separated by U+002E FULL STOP code points (".") to result. order, separated by U+002E FULL STOP code points (".") to result.
5. If the port part of the origin triple is different than the 5. If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the default port for the protocol given by the scheme part of the
origin triple: origin triple:
1. Append a U+003A COLON code point (":") and the given port, in 1. Append a U+003A COLON code point (":") and the given port, in
base ten, to result. base ten, to result.
skipping to change at page 16, line 5 skipping to change at page 17, line 5
5. If the port part of the origin triple is different than the 5. If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the default port for the protocol given by the scheme part of the
origin triple: origin triple:
1. Append a U+003A COLON code points (":") and the given port, 1. Append a U+003A COLON code points (":") and the given port,
in base ten, to result. in base ten, to result.
6. Return result. 6. Return result.
7. The HTTP Origin header 7. The HTTP Origin header field
This section defines the HTTP Origin header. This section defines the HTTP Origin header field.
7.1. Syntax 7.1. Syntax
The Origin header has the following syntax: The Origin header field has the following syntax:
origin = "Origin:" OWS origin-list-or-null OWS origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = "null" / origin-list origin-list-or-null = "null" / origin-list
origin-list = serialized-origin *( SP serialized-origin ) origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ] serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> productions from RFC3986 ; <scheme>, <host>, <port> productions from RFC3986
7.2. Semantics 7.2. Semantics
When included in an HTTP request, the Origin header indicates the When included in an HTTP request, the Origin header field indicates
origin(s) that "caused" the user agent to issue the request, as 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 defined by the API that triggered the user agent to issue the
request. request.
For example, consider a user agent that executes scripts on behalf of 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 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 HTTP request, the user agent MAY use the Origin header field to
inform the server of the security context in which the script was inform the server of the security context in which the script was
executing when it caused the user agent to issue the request. executing when it caused the user agent to issue the request.
In some cases, a number of origins contribute to causing the user 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 agents to issue an HTTP request. In those cases, the user agent MAY
list all the origins in the Origin header. For example, if the HTTP list all the origins in the Origin header field. For example, if the
request was initially issued by one origin but then later redirected HTTP request was initially issued by one origin but then later
by another origin, the user agent might wish to inform the server redirected by another origin, the user agent MAY inform the server
that two origins were involved in causing the user agent to issue the that two origins were involved in causing the user agent to issue the
request. request.
7.3. User Agent Requirements 7.3. User Agent Requirements
The user agent MAY include an Origin header in any HTTP request. The user agent MAY include an Origin header field in any HTTP
request.
The user agent MUST NOT include more than one Origin header field in The user agent MUST NOT include more than one Origin header field in
any HTTP request. any HTTP request.
Whenever a user agent issues an HTTP request from a "privacy- Whenever a user agent issues an HTTP request from a "privacy-
sensitive" context, the user agent MUST send the value "null" in the sensitive" context, the user agent MUST send the value "null" in the
Origin header. Origin header field.
NOTE: This document does not define the notion of a privacy- NOTE: This document does not define the notion of a privacy-
sensitive context. Applications that generate HTTP requests can sensitive context. Applications that generate HTTP requests can
designate contexts as privacy-sensitive to impose restrictions on designate contexts as privacy-sensitive to impose restrictions on
how user agents generate Origin headers. how user agents generate Origin header fields.
When generating an Origin header, the user agent MUST meet the When generating an Origin header field, the user agent MUST meet the
following requirements: following requirements:
o Each of the serialized-origin productions in the grammar MUST be o Each of the serialized-origin productions in the grammar MUST be
the ascii-serialization of an origin. the ascii-serialization of an origin.
o No two consecutive serialized-origin productions in the grammar o No two consecutive serialized-origin productions in the grammar
can be identical. In particular, if the user agent would generate can be identical. In particular, if the user agent would generate
two consecutive serialized-origins, the user agent MUST NOT two consecutive serialized-origins, the user agent MUST NOT
generate the second one. generate the second one.
8. Security Considerations 8. Security Considerations
The same-origin policy is one of the cornerstones of security for The same-origin policy is one of the cornerstones of security for
many user agents, including web browsers. Historically, some user many user agents, including web browsers. Historically, some user
agents tried other security models, including taint tracking and agents tried other security models, including taint tracking and
exfiltration prevention, but those model proved difficult to exfiltration prevention, but those models proved difficult to
implement at the time (although there has been recent interest in implement at the time (although there has been recent interest in
reviving some of these ideas). reviving some of these ideas).
Evaluating the security of the same-origin policy is difficult Evaluating the security of the same-origin policy is difficult
because the origin concept itself plays such a central role in the because the origin concept itself plays such a central role in the
security landscape. The notional origin itself is just a unit of security landscape. The notional origin itself is just a unit of
isolation, imperfect as are most one-size-fits-all notions. That isolation, imperfect as are most one-size-fits-all notions. That
said, there are some systemic weaknesses, discussed below. said, there are some systemic weaknesses, discussed below.
8.1. Reliance on DNS 8.1. Reliance on DNS
skipping to change at page 18, line 51 skipping to change at page 19, line 51
concept as a convenient unit of isolation. However, many concept as a convenient unit of isolation. However, many
technologies in use today, such as cookies [RFC6265], pre-date the technologies in use today, such as cookies [RFC6265], pre-date the
modern web origin concept. These technologies often have different modern web origin concept. These technologies often have different
isolation units, leading to vulnerabilities. isolation units, leading to vulnerabilities.
One alternative is to use only the "registry-controlled" domain One alternative is to use only the "registry-controlled" domain
rather than the fully qualified domain name as the unit of isolation rather than the fully qualified domain name as the unit of isolation
(e.g., "example.com" instead of "www.example.com"). This practice is (e.g., "example.com" instead of "www.example.com"). This practice is
problematic for a number of reasons, and is NOT RECOMMENDED: problematic for a number of reasons, and is NOT RECOMMENDED:
1. The notion of a "registry-controlled" domain a function of human 1. The notion of a "registry-controlled" domain is a function of
practice surrounding the DNS rather than a property of the DNS human practice surrounding the DNS rather than a property of the
itself. For example, many municipalities in Japan run public DNS itself. For example, many municipalities in Japan run public
registries quite deep in the DNS hierarchy. There are widely registries quite deep in the DNS hierarchy. There are widely
used "public suffix lists", but these lists are difficult to keep used "public suffix lists", but these lists are difficult to keep
up to date and vary between implementations. up to date and vary between implementations.
2. This practice is incompatible with URI schemes that do not use a 2. This practice is incompatible with URI schemes that do not use a
DNS-based naming authority. For example, if a given URI scheme DNS-based naming authority. For example, if a given URI scheme
uses public keys as naming authorities, the notion of a uses public keys as naming authorities, the notion of a
"registry-controlled" public key is somewhat incoherent. Worse, "registry-controlled" public key is somewhat incoherent. Worse,
some URI schemes, such as nntp, used dotted delegation in the some URI schemes, such as nntp, used dotted delegation in the
opposite direction from DNS (e.g., alt.usenet.kooks) and others opposite direction from DNS (e.g., alt.usenet.kooks) and others
use the DNS, but present the labels in the reverse of the usual use the DNS, but present the labels in the reverse of the usual
order (e.g., com.example.www). order (e.g., com.example.www).
At best, using registry-controlled domains is URI-scheme- and At best, using registry-controlled domains is URI-scheme- and
implementation-specific. At worse, differences between URI schemes implementation-specific. At worst, differences between URI schemes
and implementations can lead to vulnerabilities. and implementations can lead to vulnerabilities.
8.3. Ambient Authority 8.3. Ambient Authority
When using the same-origin policy, user agents grant authority to When using the same-origin policy, user agents grant authority to
content based on the URI from which the user agent retrieved the content based on its URI rather than based which objects the content
content rather than based on the objects which the content is able to can designate. This disentangling of designation from authority is
designate. This disentangling of designation from authority is an an example of ambient authority and can lead to vulnerabilities.
example of ambient authority and can lead to vulnerabilities.
Consider, for example, cross-site scripting in HTML documents. If an Consider, for example, cross-site scripting in HTML documents. If an
attacker can inject script content into an HTML document, those attacker can inject script content into an HTML document, those
scripts will run with the authority of the document's origin, perhaps scripts will run with the authority of the document's origin, perhaps
allowing the script access to sensitive information, such as the allowing the script access to sensitive information, such as the
user's medical records. If, however, the script's authority were user's medical records. If, however, the script's authority were
limited to those objects that the script could designate, the limited to those objects that the script could designate, the
attacker would not gain any advantage by injecting the script into an attacker would not gain any advantage by injecting the script into an
HTML document hosted by a third party. HTML document hosted by a third party.
skipping to change at page 21, line 5 skipping to change at page 22, line 5
Header field name: Origin Header field name: Origin
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 7) Specification document: this specification (Section 7)
10. Implementation Considerations 10. IDNA dependency and migration
10.1. IDNA dependency and migration
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not
backwards-compatible. For this reason, there will be a transition backwards-compatible. For this reason, there will be a transition
period (possibly of a number of years). User agents SHOULD implement period (possibly of a number of years). User agents SHOULD implement
IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46 IDNA2008 [RFC5890] and MAY implement [UnicodeTR46] in order to
<http://unicode.org/reports/tr46/>] in order to facilitate a smoother facilitate a smoother IDNA transition. If a user agent does not
IDNA transition. If a user agent does not implement IDNA2008, the implement IDNA2008, the user agent MUST implement IDNA2003 [RFC3490].
user agent MUST implement IDNA2003 [RFC3490].
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
See Section 10.1 for an explanation why the normative See Section 10 for an explanation why the normative
reference to an obsoleted specification is needed. reference to an obsoleted specification is needed.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, Application Protocol Collation Registry", RFC 4790,
March 2007. March 2007.
[UnicodeTR46]
The Unicode Consortium, "Unicode IDNA Compatibility
Processing", 2010, <http://unicode.org/reports/tr46/>.
[Unicode52] [Unicode52]
The Unicode Consortium, "The Unicode Standard, Version The Unicode Consortium, "The Unicode Standard, Version
5.1.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN 5.1.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN
0-321-48091-0, as amended by Unicode 5.1.0 0-321-48091-0, as amended by Unicode 5.1.0
http://www.unicode.org/versions/Unicode5.1.0/, 2008, http://www.unicode.org/versions/Unicode5.1.0/, 2008,
<http://www.unicode.org/versions/Unicode5.2.0/>. <http://www.unicode.org/versions/Unicode5.2.0/>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 24, line 7 skipping to change at page 26, line 7
Origins", 2008, Origins", 2008,
<http://w2spconf.com/2008/papers/s2p1.pdf>. <http://w2spconf.com/2008/papers/s2p1.pdf>.
[CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman, [CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman,
"Protecting Browsers from Extension Vulnerabilities", "Protecting Browsers from Extension Vulnerabilities",
2010, 2010,
<http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>. <http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
We would like to thank Lucas Adamski, Tobias Gondrom, Ian Hickson, We would like to thank Lucas Adamski, Stephen Farrell, Miguel A.
Anne van Kesteren, Collin Jackson, Larry Masinter, Alexey Melnikov, Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Collin
Mark Nottingham, Julian Reschke, Jonas Sicking, Sid Stamm, Daniel Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham, Julian
Veditz, and Chris Weber for their valuable feedback on this document. Reschke, Jonas Sicking, Sid Stamm, Daniel Veditz, and Chris Weber for
their valuable feedback on this document.
Author's Address Author's Address
Adam Barth Adam Barth
Google, Inc. Google, Inc.
Email: ietf@adambarth.com Email: ietf@adambarth.com
URI: http://www.adambarth.com/ URI: http://www.adambarth.com/
 End of changes. 36 change blocks. 
85 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/