One document matched: draft-ietf-websec-origin-05.xml
<?xml version="1.0"?>
<?rfc toc="yes"?>
<?xml-stylesheet type="text/xml" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-ietf-websec-origin-05" category="std">
<front>
<title abbrev="The Web Origin Concept">
The Web Origin Concept
</title>
<author initials="A." surname="Barth" fullname="Adam Barth">
<organization>
Google, Inc.
</organization>
<address>
<email>ietf@adambarth.com</email>
<uri>http://www.adambarth.com/</uri>
</address>
</author>
<date month="September" year="2011" />
<workgroup>websec</workgroup>
<abstract>
<t>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 field,
named "Origin", that indicates which origins are associated with an HTTP
request.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="HTML" /> and WebSockets <xref
target="WEBSOCKETS" />, because the details are often
application-specific.</t>
</section>
<section anchor="conventions" title="Conventions">
<section anchor="conformance-criteria" title="Conformance Criteria">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="syntax-notation" title="Syntax Notation">
<t>This specification uses the Augmented Backus-Naur Form (ABNF)
notation of <xref target="RFC5234"/>.</t>
<t>The following core rules are included by reference, as defined in
<xref target="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).</t>
<t>The OWS (optional whitespace) rule is used where zero or more
linear whitespace characters MAY appear:
<figure>
<artwork type="abnf">
OWS = *( [ obs-fold ] WSP )
; "optional" whitespace
obs-fold = CRLF
</artwork>
</figure>
OWS SHOULD either not be produced or be produced as a single SP
character.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification (<xref
target="RFC2616" />, Section 1.3).</t>
<t>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. 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</t>
<t>For the purposes of this document, we define "idna-canonicalized
host name" as the string generated by the following algorithm:
<list style="numbers">
<t>Convert the host name to a sequence of NR-LDH labels (see
Section 2.3.2.2 of <xref target="RFC5890" />) and/or A-labels
according to the appropriate IDNA specification <xref
target="RFC5891" /> or <xref target="RFC3490" /> (see <xref
target="idna-migration" /> of this specification)</t>
<t>Convert the labels to lower case (using the i;ascii-casemap
collation defined in <xref target="RFC4790"/>).</t>
<t>Concatenate the labels, separating each label from the next
with a %x2E (".") character.</t>
</list>
</t>
</section>
</section>
<section anchor="principles" title="Principles of the Same-Origin Policy">
<t>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.</t>
<t>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.</t>
<section anchor="trust" title="Trust">
<t>The same-origin policy specifies trust by URI. For example, HTML
documents designate which script to run with a URI:
<figure>
<artwork>
<![CDATA[
<script src="https://example.com/library.js"></script>
]]>
</artwork>
</figure>
</t>
<t>When a user agent processes 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.</t>
<t>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:
<figure>
<artwork>
<![CDATA[
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>
]]>
</artwork>
</figure>
</t>
<t>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.</t>
<section title="Pitfalls">
<t>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 <xref target="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.</t>
</section>
</section>
<section anchor="origin" title="Origin">
<t>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.</t>
<t>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 <xref target="origin-of-a-uri" /> for
full details.)</t>
<t>Q: Why not just use the host?</t>
<t>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 <xref
target="RFC5246" />.</t>
<t>Q: Why use the fully qualified host name instead of just the
"top-level" domain?</t>
<t>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/.</t>
<t>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.</t>
<section title="Examples">
<t>All of the following resources have the same origin:
<figure>
<artwork>
<![CDATA[
http://example.com/
http://example.com:80/
http://example.com/path/file
]]>
</artwork>
</figure>
Each of the URIs has the same scheme, host, and port components.</t>
<t>Each of the following resources has a different origin from the
others.
<figure>
<artwork>
<![CDATA[
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/
]]>
</artwork>
</figure>
In each case, at least one of the scheme, host, and port component
will differ from the others in the list.</t>
</section>
</section>
<section anchor="authority" title="Authority">
<t>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 <xref target="RFC3986" /> 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.</t>
<t>User agents 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.</t>
<t>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.</t>
<section title="Pitfalls">
<t>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.</t>
<t>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 <xref
target="SNIFF" />.</t>
</section>
</section>
<section anchor="policy" title="Policy">
<t>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.</t>
<section title="Object Access">
<t>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.</t>
<t>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
example, 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.</t>
</section>
<section title="Network Access">
<t>Access to network resources varies depending on whether the
resources are in the same origin as the content attempting to access
them.</t>
<t>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 <xref
target="CORS" />. In these cases, access is typically granted on a
per-origin basis.</t>
<t>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 <xref
target="WEBSOCKETS" />.</t>
</section>
<section title="Pitfalls">
<t>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 <xref target="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.</t>
<t>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) <xref target="BOFGO" />.</t>
</section>
</section>
<section anchor="conclusion" title="Conclusion">
<t>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.</t>
</section>
</section>
<section anchor="origin-of-a-uri" title="Origin of a URI">
<t>The origin of a URI is the value computed by the following algorithm:
<list style="numbers">
<t>If the URI does not use a hierarchical element as a naming
authority (see <xref target="RFC3986" />, Section 3.2), or if the URI
is not an absolute URI, then generate a fresh globally unique
identifier and return that value.
<list>
<t>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.</t>
</list>
</t>
<t>Let uri-scheme be the scheme component of the URI, converted to
lowercase.</t>
<t>If the implementation doesn't support the protocol given by
uri-scheme, then return generate a fresh globally unique identifier
and return that value.</t>
<t>If uri-scheme is "file", the implementation MAY return an
implementation-defined value.
<list>
<t>NOTE: Historically, user agents have granted content from the
file scheme a tremendous amount of privilege. However, granting all
local files such wide privileges can lead to privilege escalation
attacks. Some user agents have had success granting local files
directory-based privileges, but this approach has not been widely
adopted. Other user agents use globally unique identifiers for each
file URI, which is the most secure option.</t>
</list>
</t>
<t>Let uri-host be the idna-canonicalized form of the host component
of the URI.</t>
<t>If there is no port component of the URI:
<list>
<t>Let uri-port be the default port for the protocol given by
uri-scheme.</t>
</list>
Otherwise:
<list>
<t>Let uri-port be the port component of the URI.</t>
</list>
</t>
<t>Return the triple (uri-scheme, uri-host, uri-port).</t>
</list>
</t>
</section>
<section anchor="same-origin" title="Comparing Origins">
<t>Two origins are "the same" if, and only if, they are identical. In
particular:
<list style="symbols">
<t>If the two origins are scheme/host/port triples, the two origins
are the same if, and only if, they have identical schemes, hosts, and
ports.</t>
<t>An origin that is a globally unique identifier cannot be the same
as an origin that is a scheme/host/port triple.</t>
</list>
</t>
<t>Two URIs are the same-origin if their origins are the same.
<list>
<t>NOTE: A URI is not necessarily same-origin with itself. For
example, a data URI <xref target="RFC2397" /> is not same-origin with
itself because data URIs do not use a server-based naming authority
and therefore have globally unique identifiers as origins.</t>
</list>
</t>
</section>
<section anchor="serialization" title="Serializing Origins">
<t>This section defines how to serialize an origin to a unicode <xref
target="Unicode52" /> string and to an ASCII <xref target="RFC20" />
string.</t>
<section anchor="unicode-serialization"
title="Unicode Serialization of an Origin">
<t>The unicode-serialization of an origin is the value returned by the
following algorithm:
<list style="numbers">
<t>If the origin is not a scheme/host/port triple, then return the
string
<list style="empty">
<t>null</t>
</list>
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and
abort these steps.</t>
<t>Otherwise, let result be the scheme part of the origin
triple.</t>
<t>Append the string "://" to result.</t>
<t>Apply the IDNA ToUnicode algorithm (from the appropriate IDNA
specification <xref target="RFC5891" /> or <xref target="RFC3490" />,
see <xref target="idna-migration" /> of this specification) to
each component of the host part of the origin triple, and append the
results of each component, in the same order, separated by U+002E
FULL STOP code points (".") to result.</t>
<t>If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the origin
triple:
<list>
<t>Append a U+003A COLON code point (":") and the given port, in
base ten, to result.</t>
</list>
</t>
<t>Return result.</t>
</list>
</t>
</section>
<section anchor="ascii-serialization"
title="ASCII Serialization of an Origin">
<t>The ascii-serialization of an origin is the value returned by the
following algorithm:
<list style="numbers">
<t>If the origin is not a scheme/host/port triple, then return the
string
<list style="empty">
<t>null</t>
</list>
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and
abort these steps.</t>
<t>Otherwise, let result be the scheme part of the origin
triple.</t>
<t>Append the string "://" to result.</t>
<t>Append the host part of the origin triple to result.</t>
<t>If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the origin
triple:
<list>
<t>Append a U+003A COLON code points (":") and the given port, in
base ten, to result.</t>
</list>
</t>
<t>Return result.</t>
</list>
</t>
</section>
</section>
<section anchor="origin-header" title="The HTTP Origin header field">
<t>This section defines the HTTP Origin header field.</t>
<section anchor="origin-header-syntax" title="Syntax">
<t>The Origin header field has the following syntax:
<figure>
<artwork type="abnf">
<![CDATA[
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
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="origin-header-semantics" title="Semantics">
<t>When included in an HTTP request, the Origin header field 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.</t>
<t>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 MAY use the Origin header field to inform
the server of the security context in which the script was executing
when it caused the user agent to issue the request.</t>
<t>In some cases, a number of origins contribute to causing the user
agents to issue an HTTP request. In those cases, the user agent MAY
list all the origins in the Origin header field. For example, if the
HTTP request was initially issued by one origin but then later
redirected by another origin, the user agent MAY inform the server that
two origins were involved in causing the user agent to issue the
request.</t>
</section>
<section anchor="origin-header-ua-requirements"
title="User Agent Requirements">
<t>The user agent MAY include an Origin header field in any HTTP
request.</t>
<t>The user agent MUST NOT include more than one Origin header field
in any HTTP request.</t>
<t>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 field.
<list>
<t>NOTE: This document does not define the notion of a
privacy-sensitive context. Applications that generate HTTP requests
can designate contexts as privacy-sensitive to impose restrictions
on how user agents generate Origin header fields.</t>
</list>
</t>
<t>When generating an Origin header field, the user agent MUST meet the
following requirements:
<list style="symbols">
<t>Each of the serialized-origin productions in the grammar MUST be
the ascii-serialization of an origin.</t>
<t>No two consecutive serialized-origin productions in the grammar
can be identical. In particular, if the user agent would generate
two consecutive serialized-origins, the user agent MUST NOT generate
the second one.</t>
</list>
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>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 models proved difficult to implement at the
time (although there has been recent interest in reviving some of these
ideas).</t>
<t>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.</t>
<section anchor="reliance-on-dns" title="Reliance on DNS">
<t>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.</t>
<t>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 <xref target="CRX" />), use a public-key-based
naming authority and are fully secure against DNS compromise.</t>
<t>That the web origin concept isolates content retrieved from
different URI schemes is essential to containing the effects of DNS
compromise.</t>
</section>
<section anchor="divergence" title="Divergent Units of Isolation">
<t>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 <xref target="RFC6265" />,
pre-date the modern web origin concept. These technologies often have
different isolation units, leading to vulnerabilities.</t>
<t>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:
<list style="numbers">
<t>The notion of a "registry-controlled" domain is a function of
human practice surrounding the DNS rather than a property of the DNS
itself. For example, many municipalities in Japan run public
registries quite deep in the DNS hierarchy. There are widely used
"public suffix lists", but these lists are difficult to keep up to
date and vary between implementations.</t>
<t>This practice is incompatible with URI schemes that do not use a
DNS-based naming authority. For example, if a given URI scheme uses
public keys as naming authorities, the notion of a
"registry-controlled" public key is somewhat incoherent. Worse, some
URI schemes, such as nntp, used dotted delegation in the opposite
direction from DNS (e.g., alt.usenet.kooks) and others use the DNS,
but present the labels in the reverse of the usual order (e.g.,
com.example.www).</t>
</list>
At best, using registry-controlled domains is URI-scheme- and
implementation-specific. At worst, differences between URI schemes and
implementations can lead to vulnerabilities.</t>
</section>
<section anchor="ambient-authority" title="Ambient Authority">
<t>When using the same-origin policy, user agents grant authority to
content based on its URI rather than based which objects the content
can designate. This disentangling of designation from authority is an
example of ambient authority and can lead to vulnerabilities.</t>
<t>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.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>The permanent message header field registry (see <xref
target="RFC3864"/>) should be updated with the following
registrations:</t>
<section title="Origin">
<t>Header field name: Origin</t>
<t>Applicable protocol: http</t>
<t>Status: standard</t>
<t>Author/Change controller: IETF</t>
<t>Specification document: this specification (<xref target="origin-header"/>)</t>
</section>
</section>
<section anchor="idna-migration" title="IDNA dependency and migration">
<t>IDNA2008 <xref target="RFC5890" /> supersedes IDNA2003 <xref
target="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 <xref target="RFC5890" /> and MAY
implement <xref target="UnicodeTR46" /> in order to facilitate a smoother
IDNA transition. If a user agent does not implement IDNA2008, the user
agent MUST implement IDNA2003 <xref target="RFC3490" />.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- http://xml.resource.org/public/rfc/bibxml/reference.RFC.XXXX.xml -->
<reference anchor="RFC20">
<front>
<title>ASCII format for network interchange</title>
<author initials="V." surname="Cerf" fullname="Vint Cerf">
<organization>University California Los Angeles (UCLA)</organization>
</author>
<date year="1969" day="16" month="October"/>
<abstract>
<t>For concreteness, we suggest the use of standard 7-bit ASCII
embedded in an 8 bit byte whose high order bit is always 0.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="20"/>
<format type="TXT" octets="18504" target="http://www.rfc-editor.org/rfc/rfc20.txt"/>
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">
Key words for use in RFCs to Indicate Requirement Levels
</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document:
<list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list>
</t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723"
target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
<format type="HTML" octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
<reference anchor="RFC2616">
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization>University of California, Irvine</organization>
<address><email>fielding@ics.uci.edu</email></address>
</author>
<author initials="J." surname="Gettys" fullname="J. Gettys">
<organization>W3C</organization>
<address><email>jg@w3.org</email></address>
</author>
<author initials="J." surname="Mogul" fullname="J. Mogul">
<organization>Compaq Computer Corporation</organization>
<address><email>mogul@wrl.dec.com</email></address>
</author>
<author initials="H." surname="Frystyk" fullname="H. Frystyk">
<organization>MIT Laboratory for Computer Science</organization>
<address><email>frystyk@w3.org</email></address>
</author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization>Xerox Corporation</organization>
<address><email>masinter@parc.xerox.com</email></address>
</author>
<author initials="P." surname="Leach" fullname="P. Leach">
<organization>Microsoft Corporation</organization>
<address><email>paulle@microsoft.com</email></address>
</author>
<author initials="T." surname="Berners-Lee"
fullname="T. Berners-Lee">
<organization>W3C</organization>
<address><email>timbl@w3.org</email></address>
</author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
</reference>
<reference anchor="RFC3490">
<front>
<title>Internationalizing Domain Names in Applications (IDNA)</title>
<author initials="P." surname="Faltstrom" fullname="P. Faltstrom">
<organization />
</author>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization />
</author>
<author initials="A." surname="Costello" fullname="A. Costello">
<organization />
</author>
<date year="2003" month="March" />
<abstract>
<t>Until now, there has been no standard method for domain names
to use characters outside the ASCII repertoire. This document
defines internationalized domain names (IDNs) and a mechanism
called Internationalizing Domain Names in Applications (IDNA) for
handling them in a standard fashion. IDNs use characters drawn
from a large repertoire (Unicode), but IDNA allows the non-ASCII
characters to be represented using only the ASCII characters
already allowed in so-called host names today. This
backward-compatible representation is required in existing
protocols like DNS, so that IDNs can be introduced with no
changes to the existing infrastructure. IDNA is only meant for
processing domain names, not free text. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3490" />
<format type="TXT" octets="51943" target="http://www.rfc-editor.org/rfc/rfc3490.txt" />
<annotation>
See <xref target="idna-migration" /> for an explanation why the
normative reference to an obsoleted specification is needed.
</annotation>
</reference>
<reference anchor="RFC3864">
<front>
<title>Registration Procedures for Message Header Fields</title>
<author initials="G." surname="Klyne" fullname="G. Klyne"/>
<author initials="M." surname="Nottingham" fullname="M. Nottingham"/>
<author initials="J." surname="Mogul" fullname="J. Mogul"/>
<date year="2004" month="September" />
</front>
<seriesInfo name="BCP" value="90" />
<seriesInfo name="RFC" value="3864" />
</reference>
<reference anchor="RFC3986">
<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
</author>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="Day Software">Day Software</organization>
</author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
</author>
<date year="2005" month="January"/>
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of
characters that identifies an abstract or physical resource. This
specification defines the generic URI syntax and a process for
resolving URI references that might be in relative form, along with
guidelines and security considerations for the use of URIs on the
Internet. The URI syntax defines a grammar that is a superset of all
valid URIs, allowing an implementation to parse the common
components of a URI reference without knowing the scheme-specific
requirements of every possible identifier. This specification does
not define a generative grammar for URIs; that task is performed by
the individual specifications of each URI scheme.</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<format type="TXT" octets="141811" target="http://www.rfc-editor.org/rfc/rfc3986.txt"/>
<format type="HTML" octets="213584" target="http://xml.resource.org/public/rfc/html/rfc3986.html"/>
<format type="XML" octets="163534" target="http://xml.resource.org/public/rfc/xml/rfc3986.xml"/>
</reference>
<reference anchor="RFC4790">
<front>
<title>Internet Application Protocol Collation Registry</title>
<author initials="C." surname="Newman" fullname="C. Newman">
<organization />
</author>
<author initials="M." surname="Duerst" fullname="M. Duerst">
<organization />
</author>
<author initials="A." surname="Gulbrandsen"
fullname="A. Gulbrandsen">
<organization />
</author>
<date year="2007" month="March" />
<abstract>
<t>Many Internet application protocols include string-based
lookup, searching, or sorting operations. However, the problem
space for searching and sorting international strings is large,
not fully explored, and is outside the area of expertise for the
Internet Engineering Task Force (IETF). Rather than attempt to
solve such a large problem, this specification creates an
abstraction framework so that application protocols can precisely
identify a comparison function, and the repertoire of comparison
functions can be extended in the future.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4790" />
<format type="TXT" octets="55591"
target="http://www.rfc-editor.org/rfc/rfc4790.txt" />
</reference>
<reference anchor="UnicodeTR46"
target="http://unicode.org/reports/tr46/">
<front>
<title>Unicode IDNA Compatibility Processing</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="Unicode52"
target="http://www.unicode.org/versions/Unicode5.2.0/">
<front>
<title>The Unicode Standard, Version 5.1.0</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year="2008" />
</front>
<seriesInfo name="Unicode 5.0.0, Boston, MA, Addison-Wesley" value="ISBN 0-321-48091-0" />
<seriesInfo name="as amended by" value="Unicode 5.1.0 http://www.unicode.org/versions/Unicode5.1.0/" />
</reference>
<reference anchor="RFC5234">
<front>
<title abbrev="ABNF for Syntax Specifications">
Augmented BNF for Syntax Specifications: ABNF
</title>
<author initials="D." surname="Crocker"
fullname="Dave Crocker" role="editor">
<organization>Brandenburg InternetWorking</organization>
<address>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author initials="P." surname="Overell" fullname="Paul Overell">
<organization>THUS plc.</organization>
<address>
<email>paul.overell@thus.net</email>
</address>
</author>
<date month="January" year="2008"/>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
</reference>
<reference anchor="RFC5890">
<front>
<title>Internationalized Domain Names for Applications (IDNA):
Definitions and Document Framework</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization />
</author>
<date year="2010" month="August" />
<abstract>
<t>This document is one of a collection that, together, describe
the protocol and usage context for a revision of Internationalized
Domain Names for Applications (IDNA), superseding the earlier
version. It describes the document collection and provides
definitions and other material that are common to the set.
[STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5890" />
<format type="TXT" octets="54245" target="http://www.rfc-editor.org/rfc/rfc5890.txt" />
</reference>
<reference anchor="RFC5891">
<front>
<title>Internationalized Domain Names in Applications (IDNA):
Protocol</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization />
</author>
<date year="2010" month="August" />
<abstract>
<t>This document is the revised protocol definition for
Internationalized Domain Names (IDNs). The rationale for changes,
the relationship to the older specification, and important
terminology are provided in other documents. This document
specifies the protocol mechanism, called Internationalized Domain
Names in Applications (IDNA), for registering and looking up IDNs
in a way that does not require changes to the DNS itself. IDNA is
only meant for processing domain names, not free text. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5891" />
<format type="TXT" octets="38105" target="http://www.rfc-editor.org/rfc/rfc5891.txt" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC5246">
<front>
<title>
The Transport Layer Security (TLS) Protocol Version 1.2
</title>
<author initials="T." surname="Dierks" fullname="T. Dierks">
<organization />
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization />
</author>
<date year="2008" month="August" />
</front>
<seriesInfo name="RFC" value="5246" />
</reference>
<reference anchor="RFC2397">
<front>
<title abbrev="The "data" URL scheme">The "data" URL scheme</title>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization>Xerox Palo Alto Research Center</organization>
<address>
<postal>
<street>3333 Coyote Hill Road</street>
<street>Palo Alto</street>
<street>CA 94304</street>
</postal>
<email>masinter@parc.xerox.com</email>
</address>
</author>
<date year="1998" month="August"/>
<area>Applications</area>
<keyword>URL</keyword>
<keyword>uniform resource</keyword>
</front>
<seriesInfo name="RFC" value="2397"/>
<format type="TXT" octets="9514" target="http://www.rfc-editor.org/rfc/rfc2397.txt"/>
<format type="HTML" octets="20874" target="http://xml.resource.org/public/rfc/html/rfc2397.html"/>
<format type="XML" octets="9931" target="http://xml.resource.org/public/rfc/xml/rfc2397.xml"/>
</reference>
<reference anchor="RFC2817">
<front>
<title>Upgrading to TLS Within HTTP/1.1</title>
<author initials="R." surname="Khare" fullname="R. Khare">
<organization />
</author>
<author initials="S." surname="Lawrence" fullname="S. Lawrence">
<organization />
</author>
<date year="2000" month="May" />
<abstract>
<t>This memo explains how to use the Upgrade mechanism in HTTP/1.1
to initiate Transport Layer Security (TLS) over an existing TCP
connection. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2817" />
<format type="TXT" octets="27598" target="http://www.rfc-editor.org/rfc/rfc2817.txt" />
</reference>
<reference anchor="RFC6265">
<front>
<title>HTTP State Management Mechanism</title>
<author initials="A." surname="Barth" fullname="A. Barth">
<organization />
</author>
<date year="2011" month="April" />
<abstract>
<t>This document defines the HTTP Cookie and Set-Cookie header
fields. These header fields can be used by HTTP servers to store
state (called cookies) at HTTP user agents, letting the servers
maintain a stateful session over the mostly stateless HTTP
protocol. Although cookies have many historical infelicities that
degrade their security and privacy, the Cookie and Set-Cookie
header fields are widely used on the Internet. This document
obsoletes RFC 2965. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6265" />
<format type="TXT" octets="79724" target="http://www.rfc-editor.org/rfc/rfc6265.txt" />
</reference>
<reference anchor="WEBSOCKETS">
<front>
<title>The WebSocket protocol</title>
<author initials="I" surname="Fette" fullname="Ian Fette">
<organization/>
</author>
<date month="June" day="13" year="2011"/>
<abstract>
<t>The WebSocket protocol enables two-way communication between a
client running untrusted code running in a controlled environment
to a remote host that has opted-in to communications from that
code. The security model used for this is the Origin-based security
model commonly used by Web browsers. The protocol consists of an
opening handshake followed by basic message framing, layered over
TCP. (In theory, any transport protocol could be used so long as it
provides for reliable transport, is byte clean, and supports
relatively large message sizes. However, for this document, we
consider only TCP.) The goal of this technology is to provide a
mechanism for browser- based applications that need two-way
communication with servers that does not rely on opening multiple
HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long
polling). Please send feedback to the hybi@ietf.org mailing list.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-hybi-thewebsocketprotocol-09"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-09.txt"/>
</reference>
<reference anchor="SNIFF">
<front>
<title>Media Type Sniffing</title>
<author initials="A" surname="Barth" fullname="Adam Barth">
<organization/>
</author>
<author initials="I" surname="Hickson" fullname="Ian Hickson">
<organization/>
</author>
<date month="May" day="7" year="2011"/>
<abstract>
<t>Many web servers supply incorrect Content-Type header fields
with their HTTP responses. In order to be compatible with these
servers, user agents consider the content of HTTP responses as well
as the Content-Type header fields when determining the effective
media type of the response. This document describes an algorithm
for determining the effective media type of HTTP responses that
balances security and compatibility considerations. Please send
feedback on this draft to websec@ietf.org.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-websec-mime-sniff-03"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-websec-mime-sniff-03.txt"/>
</reference>
<reference anchor="HTML" target="http://www.w3.org/TR/2011/WD-html5-20110525/">
<front>
<title>HTML5</title>
<author fullname="Ian Hickson" surname="Hickson" initials="I."/>
<date year="2011" month="May" day="25"/>
</front>
<seriesInfo name="W3C Working Draft" value="WD-html5-20110525"/>
<annotation>
Latest version available at
<eref target="http://www.w3.org/TR/html5/"/>.
</annotation>
</reference>
<reference anchor="CORS" target="http://www.w3.org/TR/2010/WD-cors-20100727/">
<front>
<title>Cross-Origin Resource Sharing</title>
<author fullname="Anne van Kesteren" surname="van Kesteren" initials="A."/>
<date year='2010' month='July' day='27'/>
</front>
<seriesInfo name="W3C Working Draft" value="WD-cors-20100727"/>
<annotation>
Latest version available at
<eref target="http://www.w3.org/TR/cors/"/>.
</annotation>
</reference>
<reference anchor="CSRF" target="http://portal.acm.org/citation.cfm?id=1455770.1455782">
<front>
<title>Robust Defenses for Cross-Site Request Forgery</title>
<author initials="A." surname="Barth" fullname="Adam Barth">
<organization />
</author>
<author initials="C." surname="Jackson" fullname="Collin Jackson">
<organization />
</author>
<author initials="J." surname="Mitchell" fullname="John C. Mitchell">
<organization />
</author>
<date year="2008" />
</front>
</reference>
<reference anchor="BOFGO" target="http://w2spconf.com/2008/papers/s2p1.pdf">
<front>
<title>Beware of Finer-Grained Origins</title>
<author initials="C." surname="Jackson" fullname="Collin Jackson">
<organization />
</author>
<author initials="A." surname="Barth" fullname="Adam Barth">
<organization />
</author>
<date year="2008" />
</front>
</reference>
<reference anchor="CRX" target="http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf">
<front>
<title>Protecting Browsers from Extension Vulnerabilities</title>
<author initials="A." surname="Barth" fullname="Adam Barth">
<organization />
</author>
<author initials="A." surname="Felt" fullname="Adrienne Porter Felt">
<organization />
</author>
<author initials="P." surname="Saxena" fullname="Prateek Saxena">
<organization />
</author>
<author initials="A." surname="Boodman" fullname="Aaron Boodman">
<organization />
</author>
<date year="2010" />
</front>
</reference>
</references>
<section title="Acknowledgements">
<t>We would like to thank Lucas Adamski, Stephen Farrell, Miguel A.
Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Collin Jackson,
Larry Masinter, Alexey Melnikov, Mark Nottingham, Julian Reschke, Jonas
Sicking, Sid Stamm, Daniel Veditz, and Chris Weber for their valuable
feedback on this document.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:17:43 |