draft-ietf-websec-origin-02.txt   draft-ietf-websec-origin-03.txt 
websec A. Barth websec A. Barth
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track June 24, 2011 Intended status: Standards Track August 16, 2011
Expires: December 26, 2011 Expires: February 17, 2012
The Web Origin Concept The Web Origin Concept
draft-ietf-websec-origin-02 draft-ietf-websec-origin-03
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 underly the origin concept, this document defines how principles that underlie the concept of origin, this document defines
to determine the origin of a URI, how to serialize an origin into a how to determine the origin of a URI, how to serialize an origin into
string, and an HTTP header, named "Origin", that indicates which a string, and an HTTP header, named "Origin", that indicates which
origins are associated with an HTTP request. origins are associated with an HTTP request.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2011. This Internet-Draft will expire on February 17, 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 6, line 9 skipping to change at page 6, line 9
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.
A idna-canonicalized host name is the string generated by the An idna-canonicalized host name is the string generated by the
following algorithm: 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.1 of this specification)
2. Convert the labels to lower case. 2. Convert the labels to lower case (using the i;ascii-casemap
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
example, HTTP user agents follow redirects, which are instructions example, HTTP user agents follow redirects, which are instructions
from remote servers and HTML user agents expose rich DOM interfaces from remote servers and HTML user agents expose rich DOM interfaces
to scripts retrieved from remote servers. to scripts retrieved from remote servers.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
Generally speaking, user agents isolate different origins and permit Generally speaking, user agents isolate different origins and permit
controlled communication between origins. The details of how user controlled communication between origins. The details of how user
agents provide isolation and communication vary depending on several agents provide isolation and communication vary depending on several
factors. factors.
3.4.1. Object Access 3.4.1. Object Access
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 retrieve 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 sample, 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.
Generally, reading information from another origin is forbidden. Generally, reading information from another origin is forbidden.
However, an origin is permitted use some kinds of resources retrieved However, an origin is permitted to use some kinds of resources
from other origins. For example, an origin is permitted to execute retrieved from other origins. For example, an origin is permitted to
script, render images, and apply style sheets from any origin. execute script, render images, and apply style sheets from any
Likewise, an origin can display content from another origin, such as origin. Likewise, an origin can display content from another origin,
an HTML document in an HTML frame. Network resources can also opt such as an HTML document in an HTML frame. Network resources can
into letting other origins read their information, for example using also opt into letting other origins read their information, for
Cross-Origin Resource Sharing [CORS]. In these cases, access is example using Cross-Origin Resource Sharing [CORS]. In these cases,
typically granted on a per-origin basis. access is typically granted on a per-origin basis.
Sending information to another origin is permitted. However, sending Sending information to another origin is permitted. However, sending
information over the network in arbitrary formats is dangerous. For information over the network in arbitrary formats is dangerous. For
this reason, user agents restrict documents to sending information this reason, user agents restrict documents to sending information
using particular protocols, such as in an HTTP request without custom using particular protocols, such as in an HTTP request without custom
headers. Expanding the set of allowed protocols, for example by headers. Expanding the set of allowed protocols, for example by
adding support for WebSockets, must be done carefully to avoid adding support for WebSockets, must be done carefully to avoid
introducing vulnerabilities [WEBSOCKETS]. introducing vulnerabilities [WEBSOCKETS].
3.4.3. Pitfalls 3.4.3. Pitfalls
skipping to change at page 13, line 31 skipping to change at page 13, line 31
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 agent
use a globally unique identifier each file URI, which is the use a globally unique identifier each file URI, which is the
most secure option. most secure option.
5. Let uri-host be the idna-canonicalization 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.
skipping to change at page 14, line 7 skipping to change at page 14, line 7
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 Implementations MAY define other types of origins in addition to the
scheme/host/port triple type defined above. For example, an scheme/host/port triple type defined above. For example, an
implementation might define an origin based on a public key or an implementation might define an origin based on a public key or an
implementation might append additional "sandbox" bits to a scheme/ implementation might append additional "sandbox" bits to a scheme/
host/port triple. host/port triple.
5. Comparing Origins 5. Comparing Origins
To 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 o Two origins that are globally unique identifiers cannot be the
skipping to change at page 15, line 27 skipping to change at page 15, line 27
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 [RFC5891] to each component of 4. Apply the IDNA ToUnicode algorithm (from the appropriate IDNA
the host part of the origin triple, and append the results of specification [RFC5891] or [RFC3490], see Section 10.1 of this
each component, in the same order, separated by U+002E FULL STOP specification) to each component of the host part of the origin
code points (".") to result. triple, and append the results of each component, in the same
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.
6. Return result. 6. Return result.
skipping to change at page 17, line 29 skipping to change at page 17, line 29
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 indicates the
origin(s) that "caused" the user agent to issue the request, as 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 might wish to use the Origin header to
inform the server that the request was issued by the script. 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 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 can
list all the origins in the Origin header. For example, if the HTTP list all the origins in the Origin header. For example, if the HTTP
request was initially issued by one origin but then later redirected request was initially issued by one origin but then later redirected
by another origin, the user agent might wish to inform the server 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 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
skipping to change at page 19, line 31 skipping to change at page 19, line 31
In practice, the same-origin policy relies upon the Domain Name In practice, the same-origin policy relies upon the Domain Name
System (DNS) for security because many commonly used URI schemes, System (DNS) for security because many commonly used URI schemes,
such as http, use DNS-based naming authorities. If the DNS is such as http, use DNS-based naming authorities. If the DNS is
partially or fully compromised, the same-origin policy might fail to partially or fully compromised, the same-origin policy might fail to
provide the security properties required by applications. provide the security properties required by applications.
Some URI schemes, such as https, are more resistant to DNS compromise Some URI schemes, such as https, are more resistant to DNS compromise
because user agents employ other mechanisms, such as certificates, to because user agents employ other mechanisms, such as certificates, to
verify the source of content retrieved from these URIs. Other URI verify the source of content retrieved from these URIs. Other URI
schemes, such as the chrome-extension URI scheme, use a public-key- schemes, such as the chrome-extension URI scheme (see Section 4.3 of
based naming authority and are fully secure against DNS compromise. [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 That the web origin concept isolates content retrieved from different
URI schemes is essential to containing the effects of DNS compromise. URI schemes is essential to containing the effects of DNS compromise.
8.2. Divergent Units of Isolation 8.2. Divergent Units of Isolation
Over time, a number of technologies have converged on the web origin Over time, a number of technologies have converged on the web origin
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
skipping to change at page 20, line 8 skipping to change at page 20, line 9
(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 a function of human
practice surrounding the DNS rather than a property of the DNS practice surrounding the DNS rather than a property of the DNS
itself. For example, many municipalities in Japan run public 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 URIs 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 worse, differences between URI schemes
skipping to change at page 23, line 27 skipping to change at page 23, line 27
"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.1 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.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790,
March 2007.
[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.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
skipping to change at page 23, line 49 skipping to change at page 24, line 4
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[WEBSOCKETS] [WEBSOCKETS]
Fette, I., "The WebSocket protocol", <http:// Fette, I., "The WebSocket protocol",
tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol>. draft-ietf-hybi-thewebsocketprotocol-09 (work in
progress), June 2011.
[SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing", [SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing",
<http://tools.ietf.org/html/draft-ietf-websec-mime-sniff>. draft-ietf-websec-mime-sniff-03 (work in progress),
May 2011.
[HTML] Hickson, I., "HTML5: A vocabulary and associated APIs for [HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525,
HTML and XHTML", <http://www.w3.org/TR/html5/>. May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>.
[CORS] van Kesteren, A., "Cross-Origin Resource Sharing", Latest version available at <http://www.w3.org/TR/html5/>.
<http://www.w3.org/TR/cors/>.
[CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C
Working Draft WD-cors-20100727, July 2010,
<http://www.w3.org/TR/2010/WD-cors-20100727/>.
Latest version available at <http://www.w3.org/TR/cors/>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
for Cross-Site Request Forgery", 2008, for Cross-Site Request Forgery", 2008,
<http://portal.acm.org/citation.cfm?id=1455770.1455782>. <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[BOFGO] Jackson, C. and A. Barth, "Beware of Finer-Grained [BOFGO] Jackson, C. and A. Barth, "Beware of Finer-Grained
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,
"Protecting Browsers from Extension Vulnerabilities",
2010,
<http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
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. 20 change blocks. 
35 lines changed or deleted 55 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/