One document matched: draft-ietf-websec-origin-00.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-00" 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="December" year="2010"/>
    <workgroup>websec</workgroup>
    <abstract>
      <t>This document defines the concept of an "origin", which represents a
      web principal. Typically, user agents isolate content retrieved from
      different origins to prevent a malicious web site operator from
      interfering with the operation of benign web sites. In particular, this
      document defines how to compute an origin from a URI, how to serialize
      an origin to a string, and an HTTP header, named "Origin", for
      indicating which origin caused the user agent to issue a particular
      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 does not describe the restrictions user agents ought to
      impose on cross-origin interaction. Instead, this document defines the
      origin concept itself in such a way that other specifications, such for
      HTTP [cite] or for HTML [cite], can refer to this document for a
      precise, common definition of the web origin concept.</t>

      <t>Specifically, a user agent can compute the origin of a piece of
      content based on the URI from which the user agent retrieved the
      content. Given two origins computed in this way, the user agent can
      compare the origins to determine if they are "the same", which is useful
      for performing some security checks. Finally, given an origin, the user
      agent can serialize that origin into either an ASCII or a Unicode
      representation.</t>

      <t>This document also defines one use of the ASCII serialization: the
      HTTP Origin header. An Origin header attached to an HTTP request
      contains the ASCII serializations of the origins that caused the user
      agent to issue the HTTP request. The Origin header has a number of uses,
      including for cross-origin resource sharing [cite].</t>
    </section>
    <section anchor="conventions" title="Conventions">
      <section anchor="conformance-criteria" title="Conformance Criteria">
        <t>The keywords "MUST", "MUST NOT", "REQUIRED", "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.</t>

        <t>A idna-canonicalization host name is 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.</t>

          <t>Concatenate the labels, separating each label from the next
          with a %x2E (".") character.</t>
        </list>
        </t>
      </section>
    </section>
    <section anchor="origin" title="Origin">
      <t>An origin represents a web principal. Typically, user agents
      determine the origin of a piece of content from the URI from which they
      retrieved the content. In this section, we define how to compute an
      origin from a URI.</t>

      <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 server-based naming authority, or if the
        URI is not an absolute URI, then return a globally unique
        identifier.</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 a globally unique identifier.</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 number of privileges. 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 agent use a globally unique identifier each file
          URI, which is the most secure option.</t>
        </list>
        </t>

        <t>Let uri-host be the idna-canonicalization 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>

      <t>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 addition "sandbox" bits to a
      scheme/host/port triple.</t>
    </section>
    <section anchor="same-origin" title="Comparing Origins">
      <t>To 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 triple, the two origins are
        the same if, and only if, they have identical schemes, hosts, and
        ports.</t>

        <t>An origin that is globally unique identifier cannot be the same as
        an origin that is a scheme/host/port triple.</t>

        <t>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.</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 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 string
      and to an ASCII 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>Append the [TODO: IDNA ToUnicode] algorithm 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>

        <t>[TODO: Check that we handle IPv6 literals correctly.]</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 port 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">
      <t>This section defines the HTTP Origin header.</t>

      <section anchor="origin-header-syntax" title="Syntax">
        <t>The Origin header 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 indicates the
        origin(s) that caused 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 might wish to use the Origin header to
        inform the server that the request was issued by the script.</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 can
        list all the origins in the Origin header. For example, if the HTTP
        request was initially issued by one origin but then later redirected
        by another origin, the user agent might wish to inform the server that
        two origins were involved in causing the user agent to issue the
        request.</t>
      </section>
      <section anchor="origin-header-ua-requirements"
               title="User Agent Requirements">
        <t>The user agent MAY include an Origin header 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.
        <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 headers.</t>
        </list>
        </t>

        <t>When generating an Origin header, 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>

        <t>If the user agent issued an HTTP request current-request because
        the user agent received 3xx Status Code response to another HTTP
        request previous-request for URI previous-uri:
        <list style="symbols">
          <t>The HTTP request current-request MUST include an Origin
          header.</t>

          <t>The value of the Origin header MUST be either:
          <list style="symbols">
            <t>The string "null" (i.e., the byte sequence %x6E, %x75, %x6C,
            %x6C).</t>

            <t>The value of the Origin header in the previous-request.  The
            user agent MUST NOT choose this option if the ascii-serialization
            of previous-uri is not identical to the last serialized-origin in
            the Origin header of the previous request.</t>

            <t>The value of the Origin header in previous header extended with
            a space and the ascii-serialization of the origin of previous-uri.
            The user agent MUST NOT choose this option if the
            ascii-serialization of the origin of previous-uri is "null".</t>
          </list>
          </t>
        </list>
        </t>
      </section>

      <t>The user agent SHOULD include the Origin header in an HTTP request if
      the user agent issues the HTTP request on behalf of an origin (e.g., not
      by the user operating a trusted user interface surface). In this case,
      the user agent SHOULD set the value of the Origin header to the
      ascii-serialization of that origin.
      <list>
        <t>NOTE: This behavior differs from the usual user agent behavior for
        the HTTP Referer header, which user agents often suppress when an
        origin with an "https" scheme issues a request for a URI with an
        "http" scheme.</t>
      </list>
      </t>
    </section>
    <section anchor="privacy" title="Privacy Considerations">
      <t>[TODO: Privacy considerations.]</t>
    </section>
    <section anchor="security" title="Security Considerations">
      <t>[TODO: Security considerations.]</t>
    </section>
    <section anchor="iana" title="IANA Considerations">
      <t>[TODO: Register the Origin header.]</t>
    </section>
    <section anchor="implementation-considerations"
             title="Implementation Considerations">
      <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 [Unicode Technical Standard #46
        <http://unicode.org/reports/tr46/>] in order to facilitate a
        smoother IDNA transition. If a user agent does not implement IDNA2008,
        the user agent MUST implement IDNA2003 <xref target="RFC3490" />.</t>
      </section>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <!-- http://xml.resource.org/public/rfc/bibxml/reference.RFC.XXXX.xml -->
      <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="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="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="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>
    <section title="Acknowledgements">
      We would like to thank Lucas Adamski, Ian Hickson, Anne van Kesteren,
      Collin Jackson, Larry Masinter, Jonas Sicking, Sid Stamm, and Daniel
      Veditz for their valuable feedback on this document.
    </section>
  </back>
</rfc>