Internet Engineering Task Force (IETF)
RFC 6454
分類 Standards Track
ISSN 2070-1721
編集 A. Barth, Google, Inc.
発行 2011 年 12 月

The Web Origin Concept — ウェブ生成元の概念

要約

この文書は、UA (ユーザエージェント)により,権限または特権の対象範囲としてよく用いられている語, “生成元”origin )の概念( concept )を定義する。 通常、 UA は,悪意のあるウェブサイトの運用者が無害なウェブサイトの運用に干渉できないようにするために、異なる生成元から取得された内容を互いに隔離する。 この文書は、生成元の概念の背景にある原理の概要に加え、 URI の生成元を決定する方法と, 生成元を文字列に直列化する方法についての,詳細を述べる。 また、どの生成元が HTTP リクエストに結び付けられているかを指示するための, "Origin" と命名される HTTP ヘッダフィールドも定義する。 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 details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request.

【 “UA”( user agent ):当訳ではこの略記に統一する。 】【 “生成元” : この訳語は、(おそらく) HTTP/1.1 仕様の用語 “生成する( generate )” に由来する。 通例、 “生成元サーバ が, HTTP 応答を新たに生成する。 】

このメモの位置付け

これは、 Internet Standards Track 文書である。 This is an Internet Standards Track document.

この文書は、 IETF よる成果物であり, IETF コミュニティの合意を表現するものである。 それは、公開の評価を受け, IESG から発行が承認されたものである。 Internet 標準についての更なる情報は RFC 5741, 2 節 に見られる。 This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

この文書の現在の位置付け, 正誤表, フィードバックの仕方についての情報は、 http://www.rfc-editor.org/info/rfc6454 から得られる。 Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6454.

著作権の告知

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

この文書は、その発行の日付から有効な、 BCP 78, および IETF Trust の IETF Documents に対する Legal Provisions Relating の対象になる( http://trustee.ietf.org/license-info )。 これらの文書には,この文書に関するあなたの権利と制約条項が述べらているので、入念に査読されたし。 この文書から取り出された Code Components は、 Trust Legal Provisions の Section 4.e に述べられるように, Simplified BSD License テキストを含んでいなければならず、 Simplified BSD License に記されるように,無保証で提供される。 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 Simplified BSD License.

1. 序論

UA は,無数の作者により作成された内容と 相互にやりとりする。 それらのほとんどは善意によるものだが、中には悪意によるものもあるかもしれない。 UA の実装者は、 UA がその処理対象の内容に基づいてアクションを請け負う範囲において,悪意のある作者が他の内容の, あるいはサーバの, 機密性( confidentiality )や完全性( integrity 完全性 ) を侵害する能を、制約する必要がある。 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.

例として、様々なサーバから取得される HTML 内容を出力する, HTTP UA を考えてみる。 UA の実装者は、 UA がそれらの文書に包含されているスクリプトを実行する際に、悪意のあるサーバから取得されたスクリプトが,(例えばファイアウォールの背後の)正直なサーバに保持されている文書を読み取れないようにする必要がある。 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.

伝統的に, UA は内容をその “生成元” に応じて分け隔ててきた。 より明確には、 UA は,ある生成元から取得された内容と, 同じ生成元から取得された別の内容とのやりとりは自由に許容する一方で、それらの内容と別の生成元からの内容とのやりとりの仕方については制約する。 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.

この文書は、いわゆる同一生成元ポリシーの背後にある原理について,および生成元の比較と直列化のための基礎をなす部分について述べる。 この文書は、同一生成元ポリシーのすべての側面を述べるものではない。 そういった詳細は,しばしば アプリケーション固有のものであり、 HTML [HTML] や WebSockets [RFC6455] などの,他の仕様に委ねられる。 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 [HTML] and WebSockets [RFC6455], because the details are often application-specific.

2. 表記規約

2.1. 適合性基準

この文書におけるキーワード: 「〜しなければ(〜しては)ならない」 = “MUST (NOT)”, 「要求される」= REQUIRED, 「〜すべきである(でない)」 = “SHOULD (NOT)”, 「推奨される」 = “RECOMMENDED”, 「〜してもよい」 = “MAY”, 「任意選択 」 = “OPTIONAL”, は、 [RFC2119] に則って解釈されるものとする。 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 [RFC2119].

アルゴリズムの中の命令的言い回しによる要件(例えば「先頭部のスペース文字並びを取り除く」, 「 false を返してこの手続きを中止する」など)は、アルゴリズムを引用する際に利用されているキーワード(「〜しなければならない」(MUST), 「〜すべき」(SHOULD), 「〜してもよい」(MAY), 等々)の意味の下に解釈されることになる。 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.

アルゴリズムまたは特定の手続きとして記される適合性の要件は、最終的な結果が等価になるのであれば,どのように実装されてもよい。 特に、この仕様で定義されるアルゴリズムは 理解し易くなるように記述されており,パフォーマンスは考慮されていない。 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.

2.2. 構文の表記

この仕様は [RFC5234] の ABNF ( Augmented Backus Naur Form )記法を用いる。 This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].

次の中核規則は RFC 5234, Appendix B.1 による定義を参照する: CR( carriage return ), CRLF( CR LF ), LF( line feed ), SP( space ), HTAB(水平タブ — horizontal tab ), WSP(空白 — whitespace ) 【この訳では、利用されていない規則は省略している。】 The following core rules are included by reference, as defined in [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).

ゼロ個以上の連続する空白オクテットが現れ得る所では, OWS 規則が用いられる。 OWS は、生成されないか, または1個の SP として生成されるべきである。 フィールド内容に現れる複数個の OWS オクテット並びは、そのフィールド値が解釈される前, またはメッセージを下流に転送する前に、1個の SP 置換されるか, または SP のみからなるオクテットに変換( SP 以外の各オクテットは SP に置換)されるべきである。 The OWS rule is used where zero or more linear whitespace octets might appear. OWS SHOULD either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content SHOULD either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting the field value or forwarding the message downstream.

OWS            = *( SP / HTAB / obs-fold )
               ;  “オプションの” 空白
obs-fold       = CRLF ( SP / HTAB )
               ; 廃用の行折り返し

2.3. 用語

語 “UA”, “クライアント”, “サーバ”, “プロキシ”, “生成元サーバ” は、 HTTP/1.1仕様( RFC 2616, 1.3 節 )によるものと同じ意味を持つものとする。 The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3).

大域的一意識別子( GUID — globally unique identifier )は、既存の他のすべての値と異なる値である。 十分に長いランダムな文字列は,ほぼ確実に大域的一意識別子になる。 If the origin value never leaves the user agent, 【 UA が生成元の値を決して忘れないのであれば?】、 UA に局所的な単調増加するカウンタでも,大域的一意識別子として機能できる。 A globally unique identifier is a value that 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.

3. 同一生成元ポリシーの原理

多くの UA は、リモートの主体に成り代わってアクションを請け負う。 例えば、 HTTP UA は,リモートのサーバから指示されるリダイレクトに追従し、 HTML UA は,リモートのサーバから取得されたスクリプトに, 文書オブジェクト­モデル( DOM )インタフェースを公開する。 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 Document Object Model (DOM) interfaces to scripts retrieved from remote servers.

セキュリティモデルがなければ、 UA は利用者その他の主体にとって有害なアクションも請け負い得ることになる。 年月と伴に,多くのウェブ関連の技術は、通称 “同一生成元ポリシー”として知られている,共通のセキュリティモデルに収束してきた。 この 同一生成元ポリシーによるセキュリティモデルは、広く有機的に発展してきたものだが,一握りの主要な概念から理解できる。 この節では、その概念を示し,それをセキュアに用いる方法についてのアドバイスを提供する。 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.

3.1. 信頼関係

同一生成元ポリシーは URI により,信頼関係を指定する。 例えば HTML 文書は、 URI を通して実行するスクリプトを指名する: The same-origin policy specifies trust by URI. For example, HTML documents designate which script to run with a URI:

<script src="https://example.com/library.js"></script>

【 指名 — designate : “指定” の対訳が普通だが、 “選定して役割をあてがう” 含みも込めて。 この和訳では(この段落に限らず — やや見慣れない表現になる箇所もあるが)、 “specify” を意味する 指定 との区別を優先させる。 】

UA がこのプロトコル要素を処理する際には、 UA は指名された URI のスクリプトを取得し, 文書が持つ特権の下にスクリプトを実行することになる。 このようにして,文書は、自身が持つすべての特権を URI により指名されたリソースに与える。 本質的には、文書は,その URI から取得された情報の完全性を信用することを宣言している。 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.

URI からの【スクリプトなどの】ライブラリの取り込みに加えて、 UA はまた, URI により指名されたリモート主体へ向けて情報を送信する。 例えば HTML の form 要素を考える: 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:

<form method="POST" action="https://example.com/login">
 ... <input type="password"> ...
</form>

利用者が自身のパスワードを入力してフォームを送信するとき、 UA は,その URI により指名されたネットワーク端点へ向けてパスワードを送信する。 このようにして、文書はその秘匿データをその URI に開示する。 すなわち、その URI へ向けて送信される情報の機密性を信用することを宣言する。 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.

3.1.1. 落とし穴

同一生成元ポリシーを利用する新たなプロトコルを設計する際には、信用の区別が URI において可視になることを確保する必要がある。 例えば, TLS ( Transport Layer Security )と非 TLS で保護されるリソースのいずれもが( [RFC2817] のように) "http" URI スキームを用いた場合、文書は,スクリプトを TLS を通してのみ取得するように指定できなくなる。 "https" URI スキームを用いることにより、文書は,ネットワーク攻撃者から保護されたリソースとのやりとりを指示できるようになる。 When designing new protocols that use the same-origin policy, make sure that important trust distinctions are visible in URIs. For example, if both Transport Layer Security (TLS) and non-TLS protected resources use the "http" URI scheme (as in [RFC2817]), a document would be unable to specify that it wishes 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.

3.2. 生成元 — Origin

原理的には、 UA がどの URI も別個の保護ドメインとして扱い,ある URI から取得された内容と 別の URI とのやりとりに,明示的な合意を要するようにすることも考えられる。 しかしながら、ウェブアプリケーションはしばしば,協調して働くいくつものリソースからなるので、この設計は開発者にとっては厄介なものになる。 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.

代案として、 UA は URI を “生成元” と呼ばれる保護ドメインに,ひとまとめにする。 大雑把に言えば、2つの URI は,それらが同じ[スキーム, ホスト, ポート]を持つならば,同じ生成元に属する(すなわち,同じ主体を表現する)。 (全部的な詳細は 4 節 に。) 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 Section 4 for full details.)

Q: 単にホスト名だけでも十分ではありませんか? Q: Why not just use the host?

A: スキームを生成元に組み入れることは、セキュリティにとって本質的です。 UA がスキームを組み入れなかったなら、 http://example.comhttps://example.com は同じホストを持つことになり,隔離されなくなります。 しかしながら,この隔離がなければ、ネットワーク攻撃者は, 【 TLS などによる保護のない,】 http://example.com から取得される内容に細工を施すことにより,その内容から https://example.com から取得される内容の機密性と完全性を弱体化させる指示を UA に出せてしまいます。 その結果、 TLS [RFC5246] が提供する保護は迂回されてしまいます。 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 [RFC5246].

Q: 何故、単に “トップレベル” のドメインではなく,完全修飾ホスト名を用いるのですか? Q: Why use the fully qualified host name instead of just the "top-level" domain?

A: DNS は階層的な委譲を備えていますが、ホスト名の間の信頼関係は、配置­状況により様々です。 例えば,多くの教育機関では、学生たちは https://example.edu/~student/ の下に内容をホストできますが、一学生が作成した文書と https://grades.example.edu/ の下にホストされている成績管理用のウェブアプリケーションとが,同じ生成元に属する(すなわち,同じ保護ドメイン下にある)と見なされるべきではないでしょう。 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/.

example.edu の配置の例は、生成元によるリソースの仕分けが,どの配置­状況にも常に完璧に沿えるわけではないことを示してもいます。 この配置の場合,どの学生のウェブサイトも同じ生成元の下にあり、望まれるものではないかもしれません。 ある意味、生成元の粒度は,セキュリティモデルの発展過程で生じた歴史的な歪みです。 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.

3.2.1. 例

次のリソースの生成元はどれも同じである: All of the following resources have the same origin:

http://example.com/
http://example.com:80/
http://example.com/path/file

それぞれの URI は同じ スキーム, ホスト, ポート, の成分を持っている。 【 http スキームの既定のポート番号は 80 と定められている。】 Each of the URIs has the same scheme, host, and port components.

次のリソースの生成元は、それぞれ他のものと異なる: Each of the following resources has a different origin from the others.

http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/

いずれも、少なくとも,スキーム, ホスト, ポート, いずれかの成分がリストの中の他のものと異なっている。 In each case, at least one of the scheme, host, and port component will differ from the others in the list.

3.3. 権限

UA は URI を生成元により仕分けるが、同じ生成元に属するどのリソースも同じ権限( “authority” — [RFC3986] による意味の “authority”† ではなく,セキュリティの意味で)を有するとは限らない。 例えば,画像は受動的な内容なので、何ら権限を有しない††。 すなわち,画像は、その生成元にて可用なオブジェクトやリソースへのアクセスを持たない。 対して、 HTML 文書は,その生成元に対する全権限を有し、その文書­内の(またはそれに取り込まれた)スクリプトは,その生成元に属するどのリソースにもアクセスし得る。 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 [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.

【† URI 構文の一部を成す “authority” 】【†† 同じ画像でも, SVG のような HTML と同程度に高機能になり得る画像は、通常の画像と同程度に低リスクなものと見なすためには,その能動的な部分の機能を制約する必要があることになる。 】

UA は,リソースのメディア型を吟味することにより、リソースに与える権限の度合いを決定する。 例えば、メディア型 image/png のリソースは画像として扱われ,メディア型 text/html のリソースは HTML 文書として扱われる。 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.

ウェブアプリケーションは、信用できない内容(利用者により生成された内容など)をホストする際に、そのメディア型を制約することにより,内容の権限を制限できる。 例えば、利用者により生成された内容を image/png としてサービス供与するリスクは, text/html としてサービス供与するより小さい。 無論、多くのウェブアプリケーションは,信用できない内容を自身の HTML 文書に統合するが、注意深く行わなければ、これらのアプリケーションは,その生成元の権限を,信用できない内容にも漏洩するリスクにさらすことになる。 これは、一般に XSS (クロスサイトスクリプティング)として知られている脆弱性である。 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.

3.3.1. 落とし穴

ウェブ プラットフォームの新たな部品を設計する際には、そのメディア型を問わず,その部品を供するリソースに権限を与えないように注意深くあるべきである。 多くのウェブアプリケーションは、信用できない内容を,限られたメディア型に制約してサービス供与する。 これらの内容の部品に権限を与えるような,ウェブ­プラットフォームの新たな特色機能は、既存のアプリケーションに脆弱性をもたらすリスクがある。 代わりに、すでに生成元に対する全権限を有しているメディア型に与えるか,または 新たな権限を有するように特に設計された, 新たなメディア型に与える方が望ましい。 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.

一部の UA は、【 HTTP ヘッダを通して】誤ったメディア型をサービス供与するサーバとの互換性をとるために, “content sniffing” (内容­型の推定)を使役し、その内容を,サーバから供されるメディア型と異なるメディア型を持つかのように扱うことがある。 内容­型の推定は、注意深く行われなければ,セキュリティの脆弱性をもたらす。 何故なら、 UA は画像などの低­権限のメディア型に, HTML 文書などの高­権限のメディア型の特権を与えることにもなりかねないからである [SNIFF] 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 [SNIFF].

3.4. ポリシー

一般に、 UA は異なる生成元を隔離しつつ,生成元どうしの通信は制御された形で許可する。 UA が隔離と通信をどのような形で提供するかについての詳細は、いくつかの要因に依存して様々になる。 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.

3.4.1. オブジェクト アクセス

UA から公開されるほとんどのオブジェクト(アプリケーション プログラミング インタフェース,略して API とも呼ばれる)は、同じ生成元に属する場合にのみ利用し得る。 特に、ある URI から取得された内容が,別の URI から取得された内容に結び付けられているオブジェクトにアクセスし得るのは、2つの URI が同じ生成元に属する,すなわち同じ[スキーム, ホスト, ポート]を持つとき,そのときに限られる。 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 the same scheme, host, and port.

この一般原則には一部例外がある。 例えば、 HTML の Location インタフェースの一部は、生成元を超えて利用し得る(例えば、他の閲覧文脈( browsing context )に対するページ遷移を許容するため)。 別の例として、 HTML の postMessage インタフェースは、異なる生成元 間( cross-origin )の通信を手助けするために,生成元を超えて明示的に可視化されている。 外来の生成元にオブジェクトを公開するのは危険であり,これらのオブジェクトが攻撃者に晒される可能性があるので、細心の注意の下に行われるべきである。 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.

3.4.2. ネットワーク­アクセス

ネットワークリソースへのアクセスの可否は、そのリソースが,それへのアクセスを試みている内容と同じ生成元に属しているかどうかに依存する。 Access to network resources varies depending on whether the resources are in the same origin as the content attempting to access them.

原則として、別の生成元から情報を読み取ることは許可されない。 しかしながら,一部の種類のリソースの利用については、他の生成元から取得される場合でも許可される。 例えば生成元には、任意の生成元からの[ スクリプトの実行, 画像の描画, スタイルシートの適用 ]が許可されている。 同様に生成元は、 HTML のフレーム内の HTML 文書など,別の生成元からの内容を表示できる。 ネットワークリソースには、他の生成元に自身の情報を読み取らせるオプトインを備えるものもある。 例えば Cross-Origin Resource Sharing を用いて [CORS] 。 これらの事例でアクセスが是認されるかどうかは、概して生成元ごとに基づく。 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 [CORS]. In these cases, access is typically granted on a per-origin basis.

別の生成元への情報の送信は許可される。 しかしながら、任意の形式による,ネットワークを通した情報の送信は危険である。 この理由から、 UA は文書による情報送信を、例えばカスタム­ヘッダを持たない HTTP リクエストなど,特定のプロトコルの利用に制約している。 許容されるプロトコルの集合を拡大させるような,例えば WebSockets [RFC6455] などのサポートの追加は、脆弱性がもたらされないように注意深く行われなければならない。 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 [RFC6455].

3.4.3. 落とし穴

UA が,ある生成元と, 別の生成元からのリソースとの間でのやりとりを許容するときは、常に,セキュリティの問題が招かれ得る。 例えば、別の生成元からの画像を表示する能は,その高さ/幅を漏洩する。 同様に、別の生成元へネットワークリクエストを送信する能は, CSRF(クロスサイト・リクエストフォージェリ:サイト(生成元)をまたがるリクエストの偽造) [CSRF] の脆弱性をもたらし得る。 しかしながら、 UA の実装者はしばしば,これらのリスクと, 異なる生成元 間( cross-origin )のやりとりの許容から得られる便益とのバランスをとる。 例えば、 HTML UA が異なる生成元 間のネットワークリクエストを阻止すれば、その利用者はウェブの中核機能であるハイパーリンクを辿れなくなってしまう。 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 [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.

ウェブ­プラットフォームに新たな機能性を付け加える際には、一方のリソースに特権を与えつつ,同じ生成元に属する別のリソースに対してはその特権を差し止めれば良さそうに見える。 しかしながら、このような方法で特権を差し止めても, UA は同じ生成元に属するリソースを隔離しないので、通常は特権を持たないリソースも結局は特権を得ることになり,効果的でない。 代わりに、特権は(生成元に属する個別のリソースごとに区分けするのでなく)一つの生成元に総体として与えるか差し止められるべきである [BOFGO] 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) [BOFGO].

3.5. 要約

同一生成元ポリシーは、信頼関係の指名に URI を用いる。 各 URI は生成元ごとにまとめられ,保護ドメインを表現する。 生成元に属する一部のリソース(例えば,能動的な内容)には,その生成元の全権限が与えられる一方で、生成元に属する他のリソース(例えば,受動的な内容)には,生成元の権限は与えられない。 その生成元の権限を有する内容は、自身の生成元に属する オブジェクトやネットワークリソース へのアクセス権が与えられる。 この内容には,他の生成元の オブジェクトやネットワークリソース への制限されたアクセス権も与えられるが、これらの非同一生成元 特権は,セキュリティ脆弱性を避けるように注意深く設計されなければならない。 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.

4. URI の生成元

URI の生成元は、次のアルゴリズムから算出される値である: The origin of a URI is the value computed by the following algorithm:

  1. URI に命名機関( naming authority )として階層的なプロトコル要素が用いられていない場合( RFC3986, 3.2 節 参照), または URI が絶対 URI でない場合、新規の大域的一意識別子を生成して,その値を返す。 If the URI does not use a hierarchical element as a naming authority (see [RFC3986], Section 3.2) or if the URI is not an absolute URI, then generate a fresh globally unique identifier and return that value.

    注記: このアルゴリズムは、同じ URI に対し複数回実行された場合,回ごとに異なる値を生成し得る。 概して UA は、例えば HTML 文書の生成元をそれぞれのセキュリティ検査ごとに再計算するのでなく,一度だけ計算して、後続のセキュリティ検査にその生成元を用いる。 NOTE: Running this algorithm multiple times for the same URI can produce different values each time. Typically, user agents compute the origin of, for example, an HTML document once and use that origin for subsequent security checks rather than recomputing the origin for each security check.

  2. uri-scheme を URI のスキーム成分を小文字化したものとする。 Let uri-scheme be the scheme component of the URI, converted to lowercase.
  3. 実装が uri-scheme で与えられるプロトコルをサポートしない場合、新規に大域的一意識別子を生成して,その値を返す。 If the implementation doesn't support the protocol given by uri- scheme, then generate a fresh globally unique identifier and return that value.
  4. uri-scheme が "file" である場合、実装は自身が定義する値を返してよい If uri-scheme is "file", the implementation MAY return an implementation-defined value.

    注記: 歴史的に、 UA は file スキームからの内容に過大な特権を与えてきた。 しかしながら、すべてのローカルファイルにそのような広範な特権を与えることは、段階的な特権の拡大­攻撃につながるおそれがある。 ローカルファイル ディレクトリに基づいて特権を与えることにより成功を得た UA も中にはあるが、このアプローチは広く受入れられてはいない。 別の UA は各 file URI ごとに大域的一意識別子をあてがう。 これは、最もセキュアな選択である。 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.

  5. uri-host を, URI のホスト成分を( [RFC4790] にて定義される i;ascii-casemap 照合を用いて)小文字化したものとする。 Let uri-host be the host component of the URI, converted to lower case (using the i;ascii-casemap collation defined in [RFC4790]).

    注記: この文書は、 UA が URI を構築するにあたり, IDNA ( Internationalized Domain Names in Applications — アプリケーションにおける国際化ドメイン名)の処理とその妥当性検証を行うことを前提にしている。 特に,この文書は、 uri-host が LDH ラベルのみを包含するものとみなしている — UA はどの非 ASCII ラベルについても,対応する A-label への変換を既に済ませることになるので( [RFC5890] 参照)。 この理由から、生成元に基づくセキュリティ­ポリシーは, UA に使役されている IDNA アルゴリズムから影響を受けやすい。 更なる論は 8.4 節 に。 NOTE: This document assumes that the user agent performs Internationalizing Domain Names in Applications (IDNA) processing and validation when constructing the URI. In particular, this document assumes the uri-host will contain only LDH labels because the user agent will have already converted any non-ASCII labels to their corresponding A-labels (see [RFC5890]). For this reason, origin-based security policies are sensitive to the IDNA algorithm employed by the user agent. See Section 8.4 for further discussion.

    1. URI にポート成分が無い場合: If there is no port component of the URI:

      uri-port を, uri-scheme で与えられるプロトコルの既定ポートとする。 Let uri-port be the default port for the protocol given by uri-scheme.

    2. 他の場合: Otherwise:

      uri-port を, URI のポート成分とする。 Let uri-port be the port component of the URI.

  6. (uri-scheme, uri-host, uri-port) を返す。 Return the triple (uri-scheme, uri-host, uri-port).

5. 生成元の比較

2つの生成元が “同じ” であるとは、それらが一致することを言う。 特に: Two origins are "the same" if, and only if, they are identical. In particular:

2つの URI は、それらの生成元が同じであるとき, “同一生成元( same origin )” と呼ばれる。 Two URIs are same-origin if their origins are the same.

注記: URI は、必ずしも自身と同じ生成元にはならない。 例えば, data URI [RFC2397] は、サーバに基づく命名機関を利用せずに,大域的一意識別子を生成元として持つので、その生成元は自身と同じにならない。 NOTE: A URI is not necessarily same-origin with itself. For example, a data URI [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.

6. 生成元の直列化

この節では、生成元を unicode [Unicode6] 文字列に直列化する方法, および ASCII [RFC20] 文字列に直列化する方法を定義する。 This section defines how to serialize an origin to a unicode [Unicode6] string and to an ASCII [RFC20] string.

6.1. Unicode による生成元の直列化

生成元の unicode 直列化とは、次のアルゴリズムにより返される値である: The unicode-serialization of an origin is the value returned by the following algorithm:

  1. 生成元が スキーム/ホスト/ポート の三つ組でないならば、文字列 null (すなわち,符号位置の並び U+006E, U+0075, U+006C, U+006C )を返してこの手続きを中止する。 If the origin is not a scheme/host/port triple, then return the string null (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
  2. 他の場合、 結果 を三つ組 生成元のスキーム部とする。 Otherwise, let result be the scheme part of the origin triple.
  3. 文字列 "://" を 結果 の末尾に付加する。 Append the string "://" to result.
  4. 三つ組 生成元のホスト部の各­成分を(次の様に変換してから) U+002E FULL STOP 符号位置( "." )で区切って 結果 の末尾に付加する: Append each component of the host part of the origin triple (converted as follows) to the result, separated by U+002E FULL STOP code points ("."):

    1. 成分が A-label であるならば、対応する U-label を代わりに用いる( [RFC5890], [RFC5891] 参照)。 If the component is an A-label, use the corresponding U-label instead (see [RFC5890] and [RFC5891]).
    2. 他の場合、その成分をそのまま用いる。 Otherwise, use the component verbatim.
  5. 三つ組 生成元のポート部がスキーム部で与えられるプロトコルに対する既定ポートとは異なるならば: If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple:

    1. U+003A COLON 符号位置( ":" )に続けて,与えられたポートの十進表記を 結果 の末尾に付加する。 Append a U+003A COLON code point (":") and the given port, in base ten, to result.
  6. 結果 を返す。 Return result.

6.2. ASCII による生成元の直列化

生成元の ASCII 直列化とは、次のアルゴリズムにより返される値である: The ascii-serialization of an origin is the value returned by the following algorithm:

  1. 生成元が スキーム/ホスト/ポート の三つ組でないならば、文字列 null (すなわち,符号位置の並び U+006E, U+0075, U+006C, U+006C )を返してこの手続きを中止する。 If the origin is not a scheme/host/port triple, then return the string null (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
  2. 他の場合、 結果 を三つ組 生成元のスキーム部とする。 Otherwise, let result be the scheme part of the origin triple.
  3. 文字列 "://" を 結果 の末尾に付加する。 Append the string "://" to result.
  4. 三つ組 生成元のホスト部を 結果 の末尾に付加する。 Append the host part of the origin triple to result.
  5. 三つ組 生成元のポート部が, 三つ組 生成元のスキーム部で与えられるプロトコルに対する既定ポートと異なるならば: If the port part of the origin triple is different from the default port for the protocol given by the scheme part of the origin triple:

    1. U+003A COLON 符号位置( ":" )に続けて,与えられたポートの十進表記を 結果 の末尾に付加する。 Append a U+003A COLON code point (":") and the given port, in base ten, to result.
  6. 結果 を返す。 Return result.

7. HTTP Origin ヘッダフィールド

この節では、 HTTP Origin ヘッダフィールドを定義する。 This section defines the HTTP Origin header field.

7.1. 構文

Origin ヘッダフィールドの構文は次で与えられる: The Origin header field has the following syntax:

origin              = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list         = serialized-origin *( SP serialized-origin )
serialized-origin   = scheme "://" host [ ":" port ]
                    ; <scheme>, <host>, <port> from RFC 3986

【 この構文では、ヘッダフィールド値が,複数個の生成元を含み得るが、現時点のウェブ­プラットフォームでは,1 個に限るように制約が追加されている。 したがって、以下の 7.2, 7.3 節の記述も,実際には より単純化し得るであろう。 】

7.2. 意味論

HTTP リクエストに含められている Origin ヘッダフィールドは、 UA によるリクエストの発行を( UA が供するリクエスト発行のための API の定義に従って) “誘発” した生成元(複数個もあり得る)を指示する。 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.

例えば、生成元を代表するスクリプトを実行する UA を考える。 UA は、これらのスクリプトのいずれかが UA による HTTP リクエストの発行を誘発した際に、 Origin ヘッダフィールドを用いて,スクリプトを実行中のセキュリティ文脈をサーバに伝達してもよい 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.

場合によっては、複数の生成元が UA による HTTP リクエスト発行の誘発に寄与することがある。 そのような場合、 UA は Origin ヘッダフィールド内にそれらの生成元すべてをリストしてもよい。 例えば、初期時は ある生成元により HTTP リクエストが発行されていて,後で別の生成元にリダイレクトされた場合、 UA は UA に対するリクエスト発行の誘発に2つの生成元が寄与していることをサーバに伝達してもよい 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.

【 “リスト”しても… — 次節最後の要件も考慮するなら,誘発への寄与の順序も考慮されるべき? 】

7.3. UA に課される要件

UA はどの HTTP リクエストにも, Origin ヘッダフィールドを含めてもよい The user agent MAY include an Origin header field in any HTTP request.

UA はどの HTTP リクエストにも,複数個の Origin ヘッダフィールドを含めてはならない The user agent MUST NOT include more than one Origin header field in any HTTP request.

UA が “プライバシーに敏感な” 文脈の下から HTTP リクエストを発行するときは,常に、 Origin ヘッダフィールドに値 “null” を送信しなければならない 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.

注記: この文書は、どのような表層概念( notion )をもって “プライバシーに敏感な” 文脈 とされるかは,定義しない。 HTTP リクエストを生成するアプリケーションは、文脈をプライバシーに敏感であるものと指名して, UA による Origin ヘッダフィールドの生成の仕方に制約を課すことができる。 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.

Origin ヘッダフィールドの生成­時には、 UA は次の要件に従わなければならない When generating an Origin header field, the user agent MUST meet the following requirements:

  • serialized-origin 生成規則によるそれぞれの生成結果は、生成元の ASCII 直列化でなければならない Each of the serialized-origin productions in the grammar MUST be the ascii-serialization of an origin.

  • 連続するどの2つの生成結果も,一致することはない。 特に、 UA が【同じ?】生成結果を連続して生成することになる場合、2個目を生成してはならない 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.

8. セキュリティ上の考慮点

同一生成元ポリシーは、ウェブ­ブラウザを含む多くの UA にとり,セキュリティの根幹の一つをなすものである。 歴史的に、一部の UA は taint tracking †や exfiltration ††の防止を含む他のセキュリティモデルを試してきたが、それらのモデルは当時においては,実装が困難であることが判明した(最近になって、これらのうちの一部のアイデアの復活に関心が持たれつつあるが)。 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).

【† 外部からの “汚れた( taint )” 入力に “標識” を付けて追跡する( tracking ) 】【†† 内部から外部へ “裏口” を通じてデータを転送する 】

同一生成元ポリシーのセキュリティについての評価は、生成元の概念­自体がセキュリティにおける中心的な役割を占めているため、【他との比較は】困難である。 表層概念( notion )上の生成元­自体は、単なる隔離単位でしかなく,万能ではない。 それには、以下に論じられる,ある種の体系的な弱点がある。 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.

8.1. DNS への依存性

実施においては、 http などの共通して用いられる URI スキームの多くは, DNS ( Domain Name System )に基づく命名機関を利用しているので、同一生成元ポリシーのセキュリティは DNS に立脚することになる。 DNS が部分的にでも弱体化された場合、同一生成元ポリシーは,アプリケーションが要求するセキュリティの特質を満たせなくなるであろう。 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.

https など一部の URI スキームは、 UA がこれらの URI から取得された内容のソースを検証するために,証明書のような他の仕組みを使役しているので、 DNS の汚染に対し,より抵抗力がある。 chrome-extension URI スキーム( [CRX] 4.3 節を参照)などの他の URI スキームは、公開鍵に基づく命名機関を用いるものであり, DNS 汚染に対し十分にセキュアである。 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 [CRX]), use a public-key-based naming authority and are fully secure against DNS compromise.

ウェブ生成元の概念は、異なる URI スキームから取得された内容を隔離する。 これは、 DNS 汚染による影響を一定範囲に封じ込めることに本質的である。 The web origin concept isolates content retrieved from different URI schemes; this is essential to containing the effects of DNS compromise.

8.2. 隔離単位の分岐

これまで,いくつもの技術が、便利な隔離単位として,ウェブ生成元の概念に収束してきた。 しかしながら,クッキー [RFC6265] などの今日用いられる多くの技術が、現代のウェブ生成元の概念に先行して存在している。 これらの技術における隔離­単位は,生成元とは異なることも多いため、脆弱性がもたらされる。 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 [RFC6265], pre-date the modern web origin concept. These technologies often have different isolation units, leading to vulnerabilities.

代替案として、隔離単位に完全修飾ドメイン名( FQDN )ではなく, “登録制” によるドメインのみを利用することも考えられるが(例えば "www.example.com" の代わりに "example.com" )、この実施にはいくつもの理由から問題があり,推奨されない 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:

  1. “登録制” ドメインの表層概念は、 DNS 自体に備わる特質ではなく, DNS を取り巻く,人による実施の役割になる。 例えば、日本の多くの地方自治体の公共レジストリは,極めて深い DNS 階層で運用されている。 広く利用されている "public suffix lists" があるが、これらのリストは最新の状態に保つことが困難であり,実装間で様々になる。 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.
  2. この実施は DNS に基づく命名機関を利用しない URI スキームと互換性が無い。 例えば,命名機関として公開鍵を利用する URI スキームの場合、 “登録制” 公開鍵の表層概念には矛盾を孕む部分がある。 加えて、 nntp などの一部の URI スキームは,委譲­関係に DNS とは逆順のドット区切りを用いており(例えば alt.usenet.kooks )、また, DNS を用いつつ, 通常とは逆順にラベルを表示するものもある(例えば com.example.www )。 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, use 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).

“登録制” ドメインの利用は、良くても URI スキームと実装に固有である。 最悪の場合、 URI スキームと実装との相違から脆弱性がもたらされ得る。 At best, using "registry-controlled" domains is URI-scheme- and implementation-specific. At worst, differences between URI schemes and implementations can lead to vulnerabilities.

8.3. ambient 権限

同一生成元ポリシーが利用される下では、 UA は内容に対し、その内容がどのオブジェクトを指名し得るか ではなく,内容の URI に基づいて権限を与える。 この、指名が,権限から分離されることは、 ambient 権限の一例であり,脆弱性をもたらし得る。 When using the same-origin policy, user agents grant authority to content based on its URI rather than based on which objects the content can designate. This disentangling of designation from authority is an example of ambient authority and can lead to vulnerabilities.

【 ambient 権限 :環境から暗黙的に与えられる権限 — 参考

例えば HTML 文書における XSS を考える。 もし攻撃者が HTML 文書­内にスクリプト内容を注入できたなら、これらのスクリプトは,文書の生成元の権限の下に実行され、利用者の医療記録など,大事な情報へのスクリプト­アクセスが許容されてしまうことになる。 しかしながら、スクリプトの権限が,スクリプトが指名し得るオブジェクトに制限されるのであれば、攻撃者が,第三者にホストされている HTML 文書にスクリプトを注入することにより優位を得ることもなくなるであろう。 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.

8.4. IDNA への依存とその移行

同一生成元ポリシーのセキュリティの特質は、 UA に使役されている IDNA アルゴリズムの詳細に決定的に依存し得る。 特に,一部の国際化ドメイン名(例えば U+00DF 文字を含むもの )については、 UA が IDNA2003 [RFC3490] か IDNA2008 [RFC5890] のいずれを用いているかに依存して,別々の ASCII 表現に対応付け得る。 The security properties of the same-origin policy can depend crucially on details of the IDNA algorithm employed by the user agent. In particular, a user agent might map some international domain names (for example, those involving the U+00DF character) to different ASCII representations depending on whether the user agent uses IDNA2003 [RFC3490] or IDNA2008 [RFC5890].

IDNA アルゴリズムを別のものへ移行させることは、いくつかのセキュリティ境界を書き換えることになり得る: 新たなセキュリティ境界を敷いたり,より望ましくない方では,互いに信用できない複数の主体­間のセキュリティ境界を取り払ってしまうなど。 特に後者の場合,一方が他方を攻撃することが許容されるので、セキュリティ境界の変更はリスクを伴う。 Migrating from one IDNA algorithm to another might redraw a number of security boundaries, potentially erecting new security boundaries or, worse, tearing down security boundaries between two mutually distrusting entities. Changing security boundaries is risky because combining two mutually distrusting entities into the same origin might allow one to attack the other.

9. IANA Considerations

恒久的メッセージ ヘッダフィールド レジストリ( [RFC3864] 参照)が次の登録にて更新された: The permanent message header field registry (see [RFC3864]) has been updated with the following registration:

ヘッダフィールド名 Origin
適用可能なプロトコル http
位置付け standard
作成/変更管理 IETF
仕様­文書 この仕様(7 節

10. 参照文献

10.1. 文献(規定)

[RFC20]
Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616]
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3864]
Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4790]
Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5890]
Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5891]
Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[Unicode6]
The Unicode Consortium, "The Unicode Standard, Version 6.0.0", 2011, <http://www.unicode.org/versions/Unicode6.0.0/>.

10.2. 文献(参考)

[BOFGO]
Jackson, C. and A. Barth, "Beware of Finer-Grained Origins", 2008, <http://w2spconf.com/2008/papers/s2p1.pdf>.
[CORS]
van Kesteren, A., "Cross-Origin Resource Sharing", W3C Working Draft WD-cors-20100727, July 2010, <http://www.w3.org/TR/2010/WD-cors-20100727/>. Latest version available at <http://www.w3.org/TR/cors/>.
[CRX]
Barth, A., Felt, A., Saxena, P., and A. Boodman, "Protecting Browsers from Extension Vulnerabilities", 2010, <http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>.
[CSRF]
Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses for Cross-Site Request Forgery", 2008, <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[HTML]
Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525, May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>. Latest version available at <http://www.w3.org/TR/html5/>.
[RFC2397]
Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.
[RFC2817]
Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC3490]
Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC5246]
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6265]
Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6455]
Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
[SNIFF]
Barth, A. and I. Hickson, "Media Type Sniffing", Work in Progress, May 2011.

Appendix A. 謝辞

この文書への貴重なフィードバックを寄せられた次の方々に謝意を表したい: We would like to thank

Lucas Adamski, Stephen Farrell, Miguel A. Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges, Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham, Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel Veditz, and Chris Weber for their valuable feedback on this document.