Internet Engineering Task Force (IETF) A. Barth
Request for Comments: 6454 Google, Inc.
Category: Standards Track December 2011
ISSN: 2070-1721
The Web Origin Concept
Abstract
抽象
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.
この文書では、多くの場合、ユーザエージェントによって権限または特権の範囲として使用され、「起源」の概念を定義します。典型的には、ユーザエージェントは、良性のウェブサイトの動作に干渉する悪意のあるWebサイトオペレータを防止するために、異なる起源から取得したコンテンツを分離します。起源の概念を根底にある原則を概説することに加えて、この文書は、URIの起源を決定する方法と、文字列の中に起源をシリアル化する方法について説明します。それはまた、起源がHTTPリクエストに関連付けられているかを示す「起源」という名前のHTTPヘッダーフィールドを定義します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6454で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 3
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 4
3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 8
3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 9
3.4.3. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Origin of a URI . . . . . . . . . . . . . . . . . . . . . . . 10
5. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 11
6. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 11
6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 12
6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 12
7. The HTTP Origin Header Field . . . . . . . . . . . . . . . . . 13
7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 15
8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 15
8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 16
8.4. IDNA Dependency and Migration . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
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.
ユーザーエージェントは、作者の多数によって作成されたコンテンツと対話します。これらの著者の多くは、よく意味ですが、いくつかの著者は、悪意があるかもしれません。ユーザーエージェントは、彼らが処理内容に基づいてアクションを行う程度に、ユーザエージェントの実装は、他のコンテンツやサーバの機密性や完全性を破壊する悪質な作家の能力を制限することを望むかもしれません。
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.
例として、各種のサーバから取得したHTMLコンテンツをレンダリングするHTTPユーザーエージェントを考えます。ユーザエージェントは、これらの文書に含まれているスクリプトを実行した場合、ユーザーエージェントの実装者は、例えば、ファイアウォールの内側であるかもしれない、正直なサーバー上に保存されたドキュメントを読んでから、悪意のあるサーバーから取得したスクリプトを防ぐことを望むかもしれません。
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.
伝統的に、ユーザーエージェントは、その「起源」に応じてコンテンツを分割しています。具体的には、ユーザエージェントは、その起源から取得他のコンテンツに自由に相互作用するために、1つの起源から取得したコンテンツを許可するが、ユーザーエージェントは、そのコンテンツが他の起源からのコンテンツと相互作用することができる方法を制限します。
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.
この文書では、いわゆる同一生成元ポリシーの原理と同様に起源を比較すると、シリアル化の「ナットとボルト」を説明しています。詳細は、多くの場合、アプリケーション固有であるため、この文書では、そのようなHTML [HTML]とWebSocketを[RFC6455]などの他の仕様に残されている詳細は同一生成元ポリシーのすべての面を、説明していません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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.
（例えば、「任意の先頭の空白文字を削除」または「falseを返し、これらの手順を中止します」など）のアルゴリズムの一部として不可欠に言葉で表現要件のキーワード（「MUST」、「SHOULD」の意味に解釈されるべきです、 " MAY」、など）は、アルゴリズムの導入に使用されます。
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.
アルゴリズムや特定の手順と言う適合要件があれば、最終結果は同等であるように、任意の方法で実施することができます。特に、本明細書で定義されたアルゴリズムは、理解しやすいように意図されており、パフォーマンスであることを意図するものではありません。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
この仕様は、[RFC5234]の増補バッカス - ナウアフォーム（ABNF）の表記を使用します。
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).
[RFC5234]で定義されるように以下のコアルールは、参照により含まれる、付録B.1：ALPHA（文字）、CR（キャリッジリターン）、CRLF（CR LF）、CTL（コントロール）、数字（小数0-9） 、DQUOTE（二重引用符）、HEXDIG（16進数0-9 / AF / AF）、LF（ラインフィード）、OCTET（データの8ビットシーケンス）、SP（空間）、HTAB（水平タブ）、CHAR（任意US-ASCII文字）、VCHAR（目に見えるUS-ASCII文字）、およびWSP（空白）。
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ルールは、ゼロ以上の線形空白のオクテットが表示される場合があります場合に使用されます。 OWSのいずれか生成されないか、単一のSPとして製造します。フィールド・コンテンツ内で生じる複数OWSオクテットは、単一のSPに置き換えあるいはフィールドの値を解釈または下流メッセージを転送する前に、すべてのSPオクテット（SP以外の各オクテットがSPで置き換え）に変換されるべきです。
OWS = *( SP / HTAB / obs-fold ) ; "optional" whitespace obs-fold = CRLF ( SP / HTAB ) ; obsolete line folding
OWS = *（SP / HTAB / OBS倍）。 "オプション" 空白OBS倍= CRLF（SP / HTAB）。廃止されたライン折りたたみ
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).
用語「ユーザエージェント」、「クライアント」、「サーバ」、「プロキシ」、および「オリジンサーバは、」HTTP / 1.1仕様書（[RFC2616]、セクション1.3）と同じ意味を持っています。
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.
グローバル一意識別子は、他のすべての既存の値と異なる値です。例えば、十分に長いランダムな文字列には、グローバル一意識別子である可能性が高いです。原点値はユーザエージェントを離れることがない場合は、ユーザーエージェントにローカルで単調に増加するカウンタもグローバル一意識別子として機能することができます。
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.
多くのユーザエージェントは、リモートの当事者に代わってアクションを行います。例えば、HTTPユーザーエージェントは、リモートサーバからの指示されているリダイレクトに従うと、HTMLユーザエージェントは、リモートサーバーから取得したスクリプトに豊富なドキュメントオブジェクトモデル（DOM）インターフェイスを公開します。
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.
任意のセキュリティモデルがなければ、ユーザエージェントは、ユーザまたは他の当事者にとって有害な行為を行う可能性があります。時間が経つにつれて、多くのWeb関連の技術は、「同一生成元ポリシー」として口語知られている一般的なセキュリティモデルに向かって収束しています。このセキュリティモデルは、主に有機的に進化しますが、同一生成元ポリシーは、重要な概念の一握りの観点から理解することができます。このセクションでは、これらの概念を提示し、安全にこれらの概念を使用する方法についてのアドバイスを提供します。
The same-origin policy specifies trust by URI. For example, HTML documents designate which script to run with a URI:
同一生成元ポリシーは、URIで信頼を指定します。例えば、HTML文書は、URIで実行するスクリプトを指定します：
<script src="https://example.com/library.js"></script>
<スクリプトSRC = "https://example.com/library.js"> </ SCRIPT>
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でスクリプトを取得し、文書の権限でスクリプトを実行します。このように、文書は、URIで指定されたリソースにそれが持っているすべての権限を付与します。本質的には、文書は、それがそのURIから取得した情報の完全性を信頼していることを宣言します。
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:
URIからライブラリをインポートすることに加えて、ユーザエージェントはまた、URIで指定されたリモートパーティに情報を送信します。例えば、HTMLフォーム要素を考慮してください。
<form method="POST" action="https://example.com/login"> ... <input type="password"> ... </form>
<フォームメソッド= "POST" ACTION = "https://example.com/login"> ... <入力タイプ= "パスワード"> ... </フォーム>
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.
ユーザーが自分のパスワードを入力し、フォームを送信すると、ユーザーエージェントは、URIで指定されたネットワークのエンドポイントにパスワードを送信します。このように、文書は、本質的に、それはそのURIに送信された情報の機密性を信頼していることを宣言し、その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.
同一生成元ポリシーを使用して新しいプロトコルを設計するとき、重要な信頼の区別がURIの中に表示されていることを確認してください。トランスポート層セキュリティ（TLS）と非TLS保護されたリソースの両方が（[RFC2817]のように）「HTTP」URIスキームを使用した場合、文書はそれだけでTLS上でスクリプトを取得したいことを指定することができないであろう。 「https」の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.
原則的には、ユーザエージェントは、別の保護ドメインとしてすべてのURIを処理し、別のURIと対話する1つのURIから取得したコンテンツのための明示的な同意を必要とする可能性があります。 Webアプリケーションは、多くの場合、コンサートに作用するリソースの数で構成されているので残念ながら、このデザインは、開発者にとって面倒です。
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.)
代わりに、ユーザーエージェント・グループは、「起源」と呼ばれる保護ドメインに一緒のURI。大まかに言えば、2つのURIが同じ起源の一部である（すなわち、同一の主体を表す）は、同じスキーム、ホスト、およびポートを持っている場合。 （詳細については、セクション4を参照してください。）
Q: Why not just use the host?
Q：なぜちょうどホストを使わないのでしょうか？
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].
A：原点タプルの方式を含むが、セキュリティのために不可欠です。ユーザエージェントはスキームが含まれていなかった場合は2つが同じホストを持っているので、http://example.comとhttps://example.comの間には、分離はないだろう。しかし、この単離することなく、アクティブなネットワーク攻撃者は、破損したコンテンツhttp://example.comから取得でき、その含有量がバイパス、https://example.comから検索されたコンテンツの機密性と完全性を侵害するユーザエージェントに指示していますTLS [RFC5246]によって与えられる保護。
Q: Why use the fully qualified host name instead of just the "top-level" domain?
Q：なぜ、完全修飾ホスト名だけではなく、「トップレベル」のドメインを使うのか？
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/.
：DNSの階層的な委任を持っていますが、ホスト名との間に信頼関係が展開によって異なります。例えば、多くの教育機関では、学生はhttps://example.edu/~student/でコンテンツをホストすることができますが、それは（すなわち、同じ保護に生息学生が作成した文書は、同じ起源の一部であるべきという意味ではありませんhttps://grades.example.edu/でホストされているグレードを管理するためのWebアプリケーションとしてドメイン）。
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.
example.edu展開が起源で、リソースをグループ化すると、常にすべての展開シナリオと完全に一致していないことを示しています。この展開では、すべての学生のウェブサイトは望ましくないかもしれない同じ起源を、生息します。ある意味では、原点粒度はセキュリティモデルがどのように進化したかの歴史的な成果物です。
All of the following resources have the same origin:
次のリソースのすべてが同じ起源を持っています：
http://example.com/ http://example.com:80/ http://example.com/path/file
ｈっｔｐ：／／えぁｍｐぇ。こｍ／ ｈっｔｐ：／／えぁｍｐぇ。こｍ：８０／ ｈっｔｐ：／／えぁｍｐぇ。こｍ／ぱｔｈ／ふぃぇ
Each of the URIs has the same scheme, host, and port components.
URIのそれぞれは同じスキーム、ホスト、およびポートの各コンポーネントを持っています。
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.
各場合において、スキーム、ホスト、ポート成分の少なくとも一方は、リスト内の他のものとは異なるであろう。
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が、原点ではないすべてのリソースが（ない[RFC3986]の意味での単語「権威」のセキュリティ意味で）同一の権限を保有します。例えば、画像は受動的内容であり、従って、画像はその原点に利用可能なオブジェクトおよびリソースへのアクセス権を持たないことを意味、何の権威を運びません。これとは対照的に、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.
ユーザーエージェントは、そのメディアタイプを調べることによって、リソースを付与するためにどれだけの権限を決定します。例えば、画像/ PNG形式のメディアタイプを持つリソースが画像として扱われ、text / htmlでのメディア・タイプを持つリソースは、HTML文書として扱われます。
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.
（ユーザー生成コンテンツなど）信頼できないコンテンツをホストする場合、Webアプリケーションは、そのメディアタイプを制限することによって、そのコンテンツの権限を制限することができます。例えば、画像/ PNGなどのユーザー生成コンテンツを提供するテキスト/ HTMLなどのユーザー生成コンテンツを提供未満危険です。もちろん、多くのWebアプリケーションは、HTML文書に信頼できないコンテンツを組み込みます。注意深く行われていない場合は、これらのアプリケーションは、一般的にクロスサイトスクリプティングの脆弱性として知られているが、信頼できないコンテンツにその起源の権限が漏れて危険性があります。
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.
Webプラットフォームの新しい作品を設計する際に、関係なく、メディアタイプのリソースへの権限を付与しないように注意してください。多くのWebアプリケーションでは、制限されたメディアタイプと信頼できないコンテンツを提供します。既存のアプリケーションに脆弱性を導入するコンテンツリスクのこれらの作品に権限を付与する新しいWebプラットフォームの機能。代わりに、すでに起源の完全な権限を持っているメディアタイプにするか、新しい権限を運ぶために特別に設計された新しいメディアタイプに権限を付与することを好みます。
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].
間違ったメディアタイプを供給サーバとの互換性を保つためには、いくつかのユーザエージェントは、「盗聴内容」を採用し、それがサーバから提供されるメディア・タイプとは異なるメディアタイプを持っていたかのような内容を扱います。注意深く行われていない場合、ユーザエージェントは、このような、そのようなHTMLドキュメント[SNIFF]などの画像、高権限のメディアタイプの権限、などの低権限のメディアタイプを、付与可能性があるため、コンテンツの盗聴は、セキュリティの脆弱性につながることができます。
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.
一般的に言えば、ユーザエージェントは、異なる起源と起点との間の許可制御通信を隔離します。ユーザエージェントは、単離および通信を提供する方法の詳細は、いくつかの要因に依存して変化します。
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.
ユーザエージェントによって露出された（また、アプリケーション・プログラミング・インターフェースまたはAPIとしても知られている）ほとんどのオブジェクトは、同じ起源に入手可能です。具体的には、1つのURIから検索されたコンテンツがあれば、別のURIから取得したコンテンツに関連付けられたオブジェクトにアクセスすることができ、そして、2つのURIが同じ起源に属している場合にのみ、例えば、同じスキーム、ホスト、およびポートを有します。
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.
この一般的な規則にはいくつかの例外があります。例えば、HTMLの場所インターフェイスの一部は、起源（例えば、他のブラウジングコンテキストをナビゲート可能にするために）全体で利用可能です。別の例として、HTMLののpostMessageインタフェースは、起源が明示的にクロスオリジン通信を容易にするために渡って表示されています。外来にオブジェクトを公開する危険であり、そうすることが潜在的な攻撃者にこれらのオブジェクトを公開するためにのみ慎重に行われるべきです。
Access to network resources varies depending on whether the resources are in the same origin as the content attempting to access them.
ネットワークリソースへのアクセスは、リソースがアクセスしようとするコンテンツと同じ起源であるかどうかによって異なります。
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.
一般的に、別の起源から情報を読み取ることは禁止されています。ただし、原点は、他の起源から取得リソースのいくつかの種類を使用することが許可されています。例えば、原点は、スクリプトを実行する画像をレンダリングし、任意の原点からのスタイルシートを適用することが許可されています。同様に、起源は、HTMLフレームでHTMLドキュメントとして、他の原点からコンテンツを表示することができます。ネットワークリソースは、他の起源は[CORS]クロスオリジンリソースの共有を使用して、例えば、その情報を読み取るせるに選ぶことができます。これらのケースでは、アクセスは通常当たり起源基づいて付与されます。
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].
別の原点に情報を送信することは許可されています。しかし、任意のフォーマットで、ネットワークを介して情報を送信することは危険です。このため、ユーザーエージェントは、このようなカスタムヘッダーなしのHTTPリクエストのような特定のプロトコルを使用して情報を送信する文書を制限します。許容されるプロトコルのセットを拡張する、例えば、WebSocketのためのサポートを追加することにより、脆弱性[RFC6455]を導入回避するために慎重に行われなければなりません。
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.
ユーザーエージェントが1起源は別の原点からの資源と対話することを可能にするたびに、彼らはセキュリティ上の問題を招きます。例えば、別の起源からの画像を表示する能力は、それらの高さと幅をリーク。同様に、別の原点にネットワーク要求を送信する機能は、クロスサイトリクエストフォージェリの脆弱性[CSRF]を生じさせます。しかし、ユーザーエージェントの実装は、多くの場合、クロスオリジンの相互作用を可能にする利点に対して、これらのリスクのバランスを取ります。たとえば、次のハイパーリンク、ウェブのコア機能からそのユーザーを妨げるクロスオリジン・ネットワーク要求をブロックされたHTMLのユーザエージェント。
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].
Webプラットフォームに新しい機能を追加する場合、一つのリソースへの権限を付与するのではなく、同じ起源で別のリソースからその特権を保留するために魅力的なことができます。権限のないリソースは通常、とにかく特権を得ることができるので、ユーザエージェントが原点内のリソースを分離していないためしかし、このように権限を源泉徴収することは非効率的です。その代わりに、権限が[BOFGO（原点内の個々のリソースを区別するのではなく）全体としての起源からの許可または保留されるべきです。
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.
同一生成元ポリシーは、信頼関係を指定するURIを使用しています。 URIは、保護ドメインを表し起源に一緒にグループ化されます。起源（例えば、アクティブコンテンツ）の一部のリソースが起源で他のリソースに対し、起源の完全な権限を付与されている（例えば、受動的なコンテンツ）は、原点の権限が付与されていません。その起源の権限を運ぶコンテンツは、独自の起源内のオブジェクトおよびネットワークリソースへのアクセスを許可されます。このコンテンツは、オブジェクトや他の起源のネットワークリソースへの制限されたアクセス権が付与されますが、これらのクロスオリジンの権限は、セキュリティの脆弱性を回避するように注意深く設計されなければなりません。
The origin of a URI is the value computed by the following algorithm:
URIの起源は、以下のアルゴリズムで計算した値です。
1. 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.
1. URIは、命名機関として階層的要素を使用する（[RFC3986]、セクション3.2を参照）またはURIが絶対URIでない場合、次いで、新鮮なグローバル一意識別子を生成し、その値が返されない場合。
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. Let uri-scheme be the scheme component of the URI, converted to lowercase.
2. URI-スキームは小文字に変換URIのスキーマコンポーネント、とします。
3. If the implementation doesn't support the protocol given by uri-scheme, then generate a fresh globally unique identifier and return that value.
3.実装では、新鮮なグローバル一意識別子を生成し、その値を返し、その後、URI-方式で特定のプロトコルをサポートしていない場合。
4. If uri-scheme is "file", the implementation MAY return an implementation-defined value.
4. 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. Let uri-host be the host component of the URI, converted to lower case (using the i;ascii-casemap collation defined in [RFC4790]).
5. URIホストは、URIのホストコンポーネントとする、（Iを使用して、[RFC4790]で定義されたASCII-CASEMAP照合）小文字に変換されます。
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. Let uri-port be the default port for the protocol given by
uri-scheme.
Otherwise:
そうでなければ：
Two origins are "the same" if, and only if, they are identical. In particular:
二つの起源は、のみの場合ならば、それらが同一である「同じ」です。特に：
o If the two origins are scheme/host/port triples, the two origins are the same if, and only if, they have identical schemes, hosts, and ports.
O 2人の起源はスキーム/ホスト/ポートトリプルである場合、2人の起源は、もし同じであり、場合にのみ、それらは同じスキーム、ホスト、およびポートを有します。
o An origin that is a globally unique identifier cannot be the same as an origin that is a scheme/host/port triple.
グローバル一意識別子である、原点oをトリプルスキーム/ホスト/ポートである原点と同じにすることはできません。
Two URIs are same-origin if their origins are the same.
その起源が同じである場合、2つのURIが同一生成元です。
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.
注：URIは、それ自体で必ずしも同一生成元ではありません。データURIがサーバーベースの命名機関を使用しているため起源としてグローバル一意識別子を持っていないので、例えば、データURI [RFC2397]は自身と同じ起源ではありません。
This section defines how to serialize an origin to a unicode [Unicode6] string and to an ASCII [RFC20] string.
このセクションでは、Unicode [Unicode6]ストリングおよびASCII [RFC20]ストリングにオリジンをシリアル化する方法を定義します。
The unicode-serialization of an origin is the value returned by the following algorithm:
起源のユニコードシリアライズは、以下のアルゴリズムによって返される値です。
1. If the origin is not a scheme/host/port triple, then return the string
1.原点はトリプルスキーム/ホスト/ポートでない場合は、文字列を返します
null
ヌル
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
（すなわち、コード・ポイントのシーケンスU + 006E、U + 0075、U + 006C、U + 006C）と、これらの手順を中止します。
4. 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 ("."):
4. U + 002E FULL STOPコードポイント（「」）で区切られた、結果を（次のように変換された）三重起源のホスト部の各構成要素を追加します。
1. If the component is an A-label, use the corresponding U-label
instead (see [RFC5890] and [RFC5891]).
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:
5.起源のポート部分はトリプルトリプル起源のスキーム部分によって与えられたプロトコルのデフォルトのポートと異なる場合：
1. Append a U+003A COLON code point (":") and the given port, in
base ten, to result.
The ascii-serialization of an origin is the value returned by the following algorithm:
起源のASCIIシリアライズは、以下のアルゴリズムによって返される値です。
1. If the origin is not a scheme/host/port triple, then return the string
1.原点はトリプルスキーム/ホスト/ポートでない場合は、文字列を返します
null
ヌル
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) and abort these steps.
（すなわち、コード・ポイントのシーケンスU + 006E、U + 0075、U + 006C、U + 006C）と、これらの手順を中止します。
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:
5.起源のポート部分はトリプルトリプル起源のスキーム部分によって与えられたプロトコルのデフォルトのポートと異なる場合：
1. Append a U+003A COLON code point (":") and the given port, in
base ten, to result.
This section defines the HTTP Origin header field.
このセクションでは、HTTP 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
原点= "起源：" OWS起源リスト-またはヌルOWS起点リスト-またはヌル=％x6E％X75％x6C％x6C /起源リスト原点リスト=シリアライズ-原点*（SPシリアライズ原点）シリアライズ-origin =スキーム "：//" ホスト[ "：" ポート]; RFC 3986から<スキーム>、<ホスト>、<ポート>
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.
HTTPリクエストに含まれる場合、原点ヘッダフィールドは要求を発行するユーザエージェントをトリガAPIによって定義されるように、要求を発行するユーザエージェント「を引き起こした」と原点（S）を示します。
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.
例えば、起源の代わりにスクリプトを実行するユーザエージェントを考えます。これらのスクリプトのいずれかが、HTTPリクエストを発行するために、ユーザエージェントが発生した場合、ユーザーエージェントは、要求を発行するユーザーエージェントを起こしたときにスクリプトが実行されたセキュリティコンテキストのサーバーに通知するために、原点ヘッダフィールドを使用するかもしれません。
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.
いくつかのケースでは、多数の起源は、ユーザエージェントは、HTTPリクエストを発行する原因に貢献しています。そのような場合、ユーザエージェントは、Originヘッダフィールド内のすべての起源を列挙してもよいです。 HTTPリクエストは、最初は1つの起源によって発行されたが、その後、別の起源によってリダイレクトされた場合、例えば、ユーザエージェントは、二つの起源は、ユーザエージェントは要求を発行させることに関与していたサーバーに通知することができます。
The user agent MAY include an Origin header field in any HTTP request.
ユーザエージェントは、任意のHTTPリクエストの原点ヘッダフィールドを含んでいてもよいです。
The user agent MUST NOT include more than one Origin header field in any HTTP request.
ユーザエージェントは、任意のHTTPリクエストで複数のオリジンヘッダーフィールドを含んではいけません。
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.
ユーザエージェントは、「プライバシーに敏感な」コンテキストからのHTTP要求を発行するたびに、ユーザエージェントは、オリジンヘッダフィールドの値「ヌル」を送信しなければなりません。
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.
注：このドキュメントでは、プライバシーに敏感なコンテキストの概念を定義していません。 HTTP要求を生成するアプリケーションは、ユーザエージェントが起源ヘッダフィールドを生成する方法に制限を課すために、プライバシーに敏感なようコンテキストを指定することができます。
When generating an Origin header field, the user agent MUST meet the following requirements:
原点ヘッダフィールドを生成する際に、ユーザーエージェントは、次の要件を満たす必要があります。
o Each of the serialized-origin productions in the grammar MUST be the ascii-serialization of an origin.
O文法でシリアライズ由来プロダクションの各々は、起源のASCIIシリアル化していなければなりません。
o 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.
O文法内の2つの連続したシリアル化され、元の作品は同じになることはできません。ユーザエージェントは、2つの連続したシリアライズ-起源を生成する場合は特に、ユーザエージェントは、第二のものを生成してはいけません。
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).
同一生成元ポリシーは、Webブラウザを含む多くのユーザーエージェント、セキュリティの基礎の一つです。歴史的に、いくつかのユーザエージェントは、汚染の追跡とexfiltration予防を含む他のセキュリティモデルを、しようとしたが、（これらのアイデアのいくつかを復活の最近の関心があったが）これらのモデルは、一度に実現することは困難であることが判明しました。
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.
原点概念自体がセキュリティ風景の中に、このような中心的な役割を果たしているので、同一生成元ポリシーのセキュリティを評価することは困難です。最もフリーサイズ概念がそうであるように想定元本の起源自体は、単に不完全な分離の単位です。それは、以下で説明するいくつかの全身弱点が存在する、と述べました。
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.
httpなどの多くの一般的に使用されるURIスキームは、DNSベースの命名当局を使用しているため、実際には、同一生成元ポリシーは、セキュリティのためのドメインネームシステム（DNS）に依存しています。 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から取得したコンテンツのソースを検証するために、そのような証明書のような他の機構を用いるので、HTTPSなど、いくつかのURIスキームは、DNSの妥協に対してより耐性があります。クロム拡張URIスキームなどの他のURIスキーム、（[CRX]のセクション4.3を参照）、公開鍵ベースの命名機関を使用してDNSの妥協に対して完全に安全です。
The web origin concept isolates content retrieved from different URI schemes; this is essential to containing the effects of DNS compromise.
ウェブ原点概念が異なるURIスキームから取得したコンテンツを隔離します。これは、DNSの妥協の影響を含むために不可欠です。
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.
時間が経つにつれて、多くの技術は、分離の便利な単位としてWeb原点コンセプトに収束しました。しかし、多くのクッキーなど使用中の技術、今日、[RFC6265]、あらかじめ日付最新のWeb原点コンセプト。これらの技術は、多くの場合、脆弱性につながる、異なるアイソレーションユニットを持っています。
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:
一つの代替（例えば、「example.com」の代わりに「www.example.com」の）隔離の単位としてのみ「レジストリ制御」ドメインではなく、完全修飾ドメイン名を使用することです。この方法は、いくつかの理由で問題があり、お勧めできません。
1. 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.
1.「レジストリ・コントロール」ドメインの概念は、DNSではなくDNS自身の財産を取り巻く人間練習の関数です。例えば、日本の多くの自治体は、DNS階層内のかなり深い公共のレジストリを実行します。広く存在し、「公共の接尾辞リスト」を使用しますが、これらのリストは最新に保つことは困難であると実装によって異なります。
2. 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).
2.この練習では、DNSベースの命名権限を使用していないURIスキームと互換性がありません。与えられたURIスキームは命名当局としての公開鍵を使用した場合、「レジストリ・コントロール」公開鍵の概念はやや支離滅裂です。このようNNTPなどさらに悪いことに、いくつかのURIスキームは、DNS（例えば、alt.usenet.kooks）から反対の方向に点線の委任を使用し、他の人は、DNSを使用していますが、通常の順序（例えば、COMの逆にラベルを提示します。 example.www）。
At best, using "registry-controlled" domains is URI-scheme- and implementation-specific. At worst, differences between URI schemes and implementations can lead to vulnerabilities.
せいぜい、「レジストリ・コントロール」ドメインを使用すると、URI-scheme-および実装固有です。最悪の場合、URIスキームと実装の違いは、脆弱性につながることができます。
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.
同一生成元ポリシーを使用する場合、ユーザエージェントは、コンテンツが指定可能なオブジェクトに対して、そのURIに基づいてではなく、ベースのコンテンツへの権限を付与します。機関から指定のこのほぐし、周囲権限の一例であり、脆弱性につながる可能性があります。
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.
例えば、HTML文書におけるクロスサイトスクリプティングを考えてみましょう。攻撃者は、HTMLドキュメントにスクリプトの内容を注入することができた場合は、それらのスクリプトは、ユーザの医療記録として、おそらく機密情報へのスクリプトアクセスを許可する、ドキュメントの原点の権限で実行されます。しかし、スクリプトの権限は、スクリプトが指定することができ、これらのオブジェクトに限定されていた場合、攻撃者は、第三者によってホストされているHTMLドキュメントにスクリプトを注入することにより、任意の優位性を獲得しません。
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アルゴリズムの詳細に決定的に依存することができます。具体的には、ユーザエージェントは、ユーザエージェントがIDNA2003 [RFC3490]またはIDNA2008 [RFC5890]を使用するかどうかに応じて異なるASCII表現するために、いくつかの国際化ドメイン名（U + 00DFの文字を含む、例えば、それらを）マップするかもしれません。
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.
1つのIDNAアルゴリズムから別のものに移行することで、潜在的に新しいセキュリティ境界を正立、セキュリティ界の数を再描画または、悪いことに、二つの相互distrustingエンティティ間のセキュリティ境界を切断することがあります。同じ起源に二つの相互distrusting実体を組み合わせること、一方が他方を攻撃できる可能性があるため、セキュリティの境界を変更することは危険です。
The permanent message header field registry (see [RFC3864]) has been updated with the following registration:
永久的なメッセージヘッダフィールドレジストリは、次の登録で更新されている（[RFC3864]を参照します）。
Header field name: Origin
ヘッダフィールド名：起源
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 7)
仕様書：この仕様書（第7節）
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC20]サーフ、V.、 "ネットワークの交換のためのASCIIフォーマット"、RFC 20、1969年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、ノッティンガム、M.、およびJ.モーグル、BCP 90、RFC 3864、2004年9月 "メッセージヘッダフィールドの登録手順"。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC4790]ニューマン、C.、Duerst、M.、およびA. Gulbrandsenの、 "インターネットアプリケーションプロトコル照合レジストリ"、RFC 4790、2007年3月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J.、 "アプリケーション（IDNA）のための国際化ドメイン名：定義とドキュメントフレームワーク"、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、J.、 "アプリケーション（IDNA）で国際化ドメイン名：プロトコル"、RFC 5891、2010年8月。
[Unicode6] The Unicode Consortium, "The Unicode Standard, Version 6.0.0", 2011, <http://www.unicode.org/versions/Unicode6.0.0/>.
[Unicode6]はUnicodeコンソーシアム、 "Unicode標準、バージョン6.0.0"、2011年、<http://www.unicode.org/versions/Unicode6.0.0/>。
[BOFGO] Jackson, C. and A. Barth, "Beware of Finer-Grained Origins", 2008, <http://w2spconf.com/2008/papers/s2p1.pdf>.
【BOFGO]ジャクソン、C.及びA.バースは、<http://w2spconf.com/2008/papers/s2p1.pdf> 2008年、 "きめ細かな起源に注意します"。
[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/>.
[CORS]バンKesteren氏、A.、 "クロスオリジンリソースの共有"、W3CワーキングドラフトWD-CORS-20100727、2010年7月、<http://www.w3.org/TR/2010/WD-cors-20100727/ >。
Latest version available at <http://www.w3.org/TR/cors/>.
<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>.
【CRX]バース、A.、フェルト、A.、Saxena、P.、およびA. Boodman氏、 "拡張脆弱性から保護するブラウザ" 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>.
[CSRF]バース、A.、ジャクソン、C.、およびJ.ミッチェル、 "クロスサイトリクエストフォージェリのための堅牢な防御"、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/>.
[HTML]ヒクソン、I.、 "HTML5"、W3CワーキングドラフトWD-html5- 20110525、2011年5月、<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.
[RFC2397] Masinter、L.、 " "データ" URLスキーム"、RFC 2397、1998年8月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817] Khare、R.およびS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]バース、A.、 "HTTP状態管理機構"、RFC 6265、2011年4月。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
[RFC6455]たFette、I.およびA.メルニコフ、 "WebSocketのプロトコル"、RFC 6455、2011年12月。
[SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing", Work in Progress, May 2011.
[SNIFF]バース、A.およびI.ヒクソン、 "メディアタイプスニッフィング"、進歩、2011年5月での作業。
Appendix A. Acknowledgements
付録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.
私たちは、ルーカスアダムスキー、スティーブン・ファレル、ミゲルA.ガルシア、トビアスGondrom、イアン・ヒクソン、アンバンKesteren氏、ジェフ・ホッジス、コリン・ジャクソン、ラリーMasinter、アレクセイ・メルニコフ、マーク・ノッティンガム、ジュリアンReschke、ピーター・サン・アンドレ、ジョナスに感謝したいと思いますこのドキュメントの彼らの貴重なフィードバックのためのSicking、シドスタム、ダニエルVeditz、そしてクリス・ウェバー。
Author's Address
著者のアドレス
Adam Barth Google, Inc.
アダム・バースグーグル株式会社
EMail: ietf@adambarth.com URI: http://www.adambarth.com/
電子メール：ietf@adambarth.com URI：http://www.adambarth.com/