One document matched: draft-abarth-principles-of-origin-00.txt
websec A. Barth
Internet-Draft Google, Inc.
Intended status: Informational February 21, 2011
Expires: August 25, 2011
Principles of the Same-Origin Policy
draft-abarth-principles-of-origin-00
Abstract
The security model of the web platform has evolved over time to meet
the needs of new applications and to correct earlier mistakes.
Although web security has evolved largely organically, the security
model has converged towards a handful of key concepts. This document
presents those concepts and provides advice to designers of new
pieces of the web platform.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Barth Expires August 25, 2011 [Page 1]
Internet-Draft Principles of the Same-Origin Policy February 2011
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Object Access . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Network Access . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Barth Expires August 25, 2011 [Page 2]
Internet-Draft Principles of the Same-Origin Policy February 2011
1. Introduction
The security model of the web platform has evolved over time to meet
the needs of new applications and to correct earlier mistakes.
Although web security has evolved largely organically, the security
model has converged towards a handful of key concepts. This document
presents those concepts and provides advice to designers of new
pieces of the web platform.
Barth Expires August 25, 2011 [Page 3]
Internet-Draft Principles of the Same-Origin Policy February 2011
2. Trust
On the web, trust is specified by URL. For example, HTML documents
designate which script to run with a URL:
<script src="https://example.com/library.js"></script>
When a user agent process this element, the user agent will fetch the
script at that URL and execute the script with the privileges of the
document. In this way, the document grants all the privileges it has
to the resource specified by the URL. In essence, the document
declares that it trusts the integrity of information retrieved from
that URL.
In addition to importing libraries from URLs, user agents also let
principals export data to URLs. For example, consider the HTML form
element:
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>
When the user enters his or her password and submits the form, the
password is sent to the network endpoint designated by the URL. In
this way, the document exports its secret data to that URL. In
essence, the document declares that it trusts the confidentiality of
information sent to that URL.
2.1. Pitfalls
When designing new pieces of the web platform, make sure that
important trust distinctions are visible in URLs. For example, if
both TLS and non-TLS protected resources used the "http" URL scheme,
a document would be unable to specify that it wished to retrieve a
script over TLS. By using the "https" URL scheme, documents are able
to indicate that they wish to interact with resources that are
protected from active network attackers.
Barth Expires August 25, 2011 [Page 4]
Internet-Draft Principles of the Same-Origin Policy February 2011
3. Origin
In principle, user agents could treat every URL as a separate
principal and isolate each document from every other URL unless the
document explicitly indicated that it trusted that URL.
Unfortunately, this design is cumbersome for developers because web
applications often consist of a number of resource acting in concert.
As an approximation, user agents group URLs together into protection
domains called origins. In particular, two URLs are part of the same
origin (i.e., represent the same principal) if they have the same
scheme, host, and port.
Q: Why not just use the host?
A: Including the scheme in the origin tuple is essential for
security. If user agents did not include the scheme, there would be
no isolation between documents from http://example.com and
https://example.com because the two have the same host. However,
without this isolation, an active network attacker could corrupt the
document retrieved from http://example.com and then use that document
as a stepping stone to compromise the confidentiality and integrity
of the document retrieved from https://example.com, bypassing the
protections afforded by TLS.
Q: Why use the fully qualified host name instead of just the "top-
level" domain?
A: Although the DNS has hierarchical delegation, the trust
relationships between host names vary by deployment. For example, at
many educational institutions, students can host content at
https://example.edu/~student/, but that does not mean a document
authored by a student should be part of the same origin (i.e.,
represent the same principal) as a web application for managing
grades hosted at https://grades.example.edu/.
Barth Expires August 25, 2011 [Page 5]
Internet-Draft Principles of the Same-Origin Policy February 2011
4. Authority
Although user agents group URLs into origins, not every resource in
an origin carries the same authority. 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 contains active content and,
therefore, carries the full authority of its origin. The user agent
determines how much authority to grant a resource by examining its
MIME type. For example, resources with a MIME type of image/png are
treated as images and resources with a MIME type of text/html are
treated as HTML documents.
When hosting untrusted content (such as user-generated content), web
applications can limit that content's authority by restricting its
MIME 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.
4.1. Pitfalls
When designing new pieces of the web platform, be careful not to
grant authority to resources irrespective of MIME type. Many web
applications server untrusted content with restricted MIME 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 MIME types that already possess
the origin's full authority or to new MIME types designed
specifically to carry the new authority.
Barth Expires August 25, 2011 [Page 6]
Internet-Draft Principles of the Same-Origin Policy February 2011
5. Policy
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.
5.1. Object Access
Most objects (also known as application programming interfaces or
APIs) exposed by the user agent respect the same-origin policy.
Specifically, a script running on behalf of one document can access
objects associated with another document if, and only if, the two
documents belong to the same origin, e.g., were retrieved from URLs
with the same scheme, host, and port.
There are some exceptions to this general policy. For example, some
parts of HTML's Location interface are available across origins
(e.g., to allow for navigating other browsing contexts). As another
sample, HTML's postMessage interface is visible across origins 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.
5.2. Network Access
Access to network resources varies depending on whether the resources
are in the same origin as the document attempting to access them.
Generally, reading information from another origin is forbidden.
However, a document is permitted use some kinds of resources
retrieved from other origins. For example, a document is permitted
to execute script, render images, and apply style sheets from any
origin. Likewise, a document can display a document from another
origin in a frame.
Generally, 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.
5.3. Pitfalls
Whenever user agents allow documents from one origin to interact with
resources in another origin, they invite security issues. For
example, the ability to display images from another origin leaks
their height and width across origins. Similarly, the ability to
Barth Expires August 25, 2011 [Page 7]
Internet-Draft Principles of the Same-Origin Policy February 2011
send network requests to another origin gives rise to cross-site
request forgery vulnerabilities. However, user agents tolerate these
risks when the value proposition is high enough. For example, a user
agent that blocked cross-origin network requests would prevent its
users from following hyperlinks, a core component of the web
architecture.
When designing new pieces of the web platform, it can be tempting to
grant a privilege to one document but to withhold that privilege from
another document in the same origin. However, withholding privileges
in this way is ineffective because the document without the privilege
can usually obtain the privilege anyway because user agents do not
isolate documents within an origin. Instead, new pieces of the
platform should grant or withhold privileges from origins as a whole
(rather than discriminating between individual documents within an
origin).
Barth Expires August 25, 2011 [Page 8]
Internet-Draft Principles of the Same-Origin Policy February 2011
6. Conclusion
The web security model designates trust relationships with URLs.
URLs are grouped together into origins, which represent principals.
Some resources in an origin (active content) are granted the origin's
full authority, whereas other resources in the origin (passive
content) are not granted the origin's authority. Documents that
carry their origin's authority are granted access to objects and
network resources within their own origin. These documents are also
granted limited access to objects and network resources of other
origins, but these cross-origin privileges must be carefully designed
to avoid introducing security vulnerabilities into the web platform.
Barth Expires August 25, 2011 [Page 9]
Internet-Draft Principles of the Same-Origin Policy February 2011
Appendix A. Acknowledgements
We would like to thank Ian Hickson, Collin Jackson, Thomas Roessler,
Jesse Ruderman, and Daniel Veditz for their valuable feedback on this
document.
Barth Expires August 25, 2011 [Page 10]
Internet-Draft Principles of the Same-Origin Policy February 2011
Author's Address
Adam Barth
Google, Inc.
Email: ietf@adambarth.com
URI: http://www.adambarth.com/
Barth Expires August 25, 2011 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 15:17:08 |