[要約] RFC 6454は、Web Originの概念とその目的について説明している。Web Originは、ウェブアプリケーションのセキュリティとプライバシーを保護するために使用される。
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
Web Originの概念
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サイトオペレーターが良性のWebサイトの動作を妨害しないようにします。起源の概念の根底にある原則の概要に加えて、このドキュメントは、URIの起源を決定する方法と、原点を文字列にシリアル化する方法を詳しく説明しています。また、「Origin」という名前の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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]やWebSockets [RFC6455]など、その詳細がHTML [HTML]やWebSockets [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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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を返す」など）の一部としてフレーティングされます。5月」など）アルゴリズムの導入に使用されます。
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]の拡張されたBackus-NAURフォーム（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：アルファ（文字）、CR（キャリッジリターン）、CRLF（CR LF）、CTL（コントロール）、数字（10-9）で定義されているように、次のコアルールが参照により含まれます。、、dquote（二重引用）、hexdig（hexadecimal 0-9/a-f/a-f）、lf（ラインフィード）、オクテット（データの8ビットシーケンス）、sp（スペース）、htab（水平タブ）、char（任意のUS-ASCII文字）、VCHAR（目に見えるUS-ASCII文字）、およびWSP（Whitespace）。
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以外の各オクテット）に変換する必要があります。
OWS = *( SP / HTAB / obs-fold )
; "optional" whitespace
obs-fold = CRLF ( SP / HTAB )
; obsolete line folding
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).
「ユーザーエージェント」、「クライアント」、「サーバー」、「プロキシ」、および「Origin Server」という用語は、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.
グローバルに一意の識別子は、以前に既存の他のすべての値とは異なる値です。たとえば、十分に長いランダムな文字列は、グローバルに一意の識別子である可能性があります。Originの値がユーザーエージェントを離れない場合、ユーザーエージェントにローカルなカウンターを単調に増加させることも、グローバルに一意の識別子として機能します。
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,
セキュリティモデルがなければ、ユーザーエージェントは、ユーザーまたは他の関係者にとって有害なアクションを引き受ける可能性があります。時間が経つにつれて、多くのWeb関連のテクノロジーは共通のセキュリティモデルに収束しています。
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.
口語的には「同じオリジン政策」として知られています。このセキュリティモデルは主に有機的に進化しましたが、同性のポリシーは、少数の重要な概念の観点から理解できます。このセクションでは、これらの概念を紹介し、これらの概念を安全に使用する方法に関するアドバイスを提供します。
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>
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:
URISからライブラリをインポートすることに加えて、ユーザーエージェントはURIが指定したリモートパーティーにも情報を送信します。たとえば、HTMLフォーム要素を考慮してください。
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>
When the user enters his or her password and submits the form, the 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保護リソースの両方が「HTTP」URIスキーム（[RFC2817]のように）を使用している場合、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と対話するためにある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を「Origins」と呼ばれる保護ドメインにグループ化します。大まかに言えば、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/.
A：DNSには階層的な代表団がありますが、ホスト名間の信頼関係は展開によって異なります。たとえば、多くの教育機関では、学生はhttps://example.edu/~student/でコンテンツをホストできますが、学生によって作成された文書が同じ起源の一部であることを意味するものではありません（すなわち、同じ保護に居住しますdomain）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.
例。EDUの展開は、原点ごとにリソースをグループ化することは、すべての展開シナリオと常に完全に一致するとは限らないことを示しています。この展開では、すべての学生のWebサイトが同じ起源に生息しているため、望ましくない可能性があります。ある意味では、起源の粒度は、セキュリティモデルがどのように進化したかの歴史的アーティファクトです。
All of the following resources have the same origin:
次のすべてのリソースには同じ起源があります。
http://example.com/ http://example.com:80/ http://example.com/path/file
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.
いずれの場合も、スキーム、ホスト、およびポートコンポーネントの少なくとも1つは、リストの他のものとは異なります。
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を持つリソースは画像として扱われ、メディアタイプのテキスト/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から取得されたコンテンツに関連付けられたオブジェクトにアクセスできます。たとえば、同じ原点に属している場合にのみ、同じスキーム、ホスト、ポートを持っています。
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のロケーションインターフェイスの一部は、Origins全体で利用できます（たとえば、他のブラウジングコンテキストをナビゲートできるように）。別の例として、HTMLのポストメッサージインターフェイスは、オリジン全体に明示的に表示され、オリジンクロスコミュニケーションを促進します。オブジェクトを外国の起源にさらすことは危険であり、そうすることでこれらのオブジェクトが潜在的な攻撃者にさらされるため、細心の注意を払ってのみ行う必要があります。
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.
一般的に、別の起源から情報を読むことは禁止されています。ただし、起源は他の起源から取得されたある種のリソースを使用することができます。たとえば、原点は、スクリプトを実行し、画像をレンダリングし、あらゆるオリジンからスタイルシートを適用することが許可されています。同様に、Originは、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ユーザーエージェントは、ユーザーがWebのコア機能であるHyperLinksをフォローすることを妨げます。
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プラットフォームに新しい機能を追加する場合、あるリソースに特権を付与することは魅力的ですが、同じ起源の別のリソースからその特権を差し控えることができます。ただし、この方法での源泉徴収特権は、特権のないリソースは通常、ユーザーエージェントが原点内でリソースを分離しないため、とにかく特権を取得できるため、効果がありません。代わりに、特権は、起源全体の個々のリソースを区別するのではなく、Origins全体から許可または源泉徴収される必要があります[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は、保護ドメインを表す起源にグループ化されます。起源の一部のリソース（アクティブなコンテンツなど）には、起源の完全な権限が付与されますが、起源の他のリソース（パッシブコンテンツなど）には、起源の権限が付与されません。Originの権限を搭載するコンテンツは、オブジェクトとネットワークリソースへのアクセスが自体のオリジン内で許可されています。このコンテンツには、他の起源のオブジェクトやネットワークリソースへのアクセスが制限されていますが、これらのクロスオリジン特権は、セキュリティの脆弱性を回避するために慎重に設計する必要があります。
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.
注：同じURIに対してこのアルゴリズムを複数回実行すると、毎回異なる値を生成できます。通常、ユーザーエージェントは、たとえば、HTMLドキュメントの原点を一度計算し、各セキュリティチェックのオリジンを再計算するのではなく、その原点をその後のセキュリティチェックに使用します。
2. Let uri-scheme be the scheme component of the URI, converted to lowercase.
2. URI-Schemeを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-Schemeによって与えられたプロトコルをサポートしていない場合、新鮮なグローバルに一意の識別子を生成し、その値を返します。
4. If uri-scheme is "file", the implementation MAY return an implementation-defined value.
4. URI-Schemeが「ファイル」の場合、実装は実装定義値を返す場合があります。
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.
注：歴史的に、ユーザーエージェントはファイルスキームからコンテンツに多大な特権を与えてきました。ただし、そのような幅広い特権をすべてのローカルファイルに付与すると、特権エスカレーション攻撃につながる可能性があります。一部のユーザーエージェントは、ローカルファイルディレクトリベースの特権を付与することに成功していますが、このアプローチは広く採用されていません。他のユーザーエージェントは、各ファイルURIにグローバルに一意の識別子を使用します。これは最も安全なオプションです。
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-HostをURIのホストコンポーネントとし、小文字に変換します（[RFC4790]で定義されているi; 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.
注：このドキュメントでは、ユーザーエージェントがURIの構築時にアプリケーション（IDNA）処理と検証で国際化ドメイン名を実行することを前提としています。特に、このドキュメントでは、URI-HostにはLDHラベルのみが含まれると想定しています。これは、ユーザーエージェントが既にASCII以外のラベルを対応するAラベルに変換しているためです（[RFC5890]を参照）。このため、オリジンベースのセキュリティポリシーは、ユーザーエージェントが採用するIDNAアルゴリズムに敏感です。詳細については、セクション8.4を参照してください。
6. If there is no port component of the URI:
6. URIのポートコンポーネントがない場合：
1. Let uri-port be the default port for the protocol given by uri-scheme.
1. URI-PortをURI-Schemeによって与えられたプロトコルのデフォルトポートとします。
Otherwise:
さもないと：
2. Let uri-port be the port component of the URI.
2. Uri-PortをURIのポートコンポーネントにします。
7. Return the triple (uri-scheme, uri-host, uri-port).
7. トリプル（uri-scheme、uri-host、uri-port）を返します。
Two origins are "the same" if, and only if, they are identical. In particular:
2つの起源は、「同じ」の場合、そしてそれらが同一である場合にのみです。特に：
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）、これらのステップを中止します。
2. Otherwise, let result be the scheme part of the origin triple.
2. それ以外の場合は、結果をオリジントリプルのスキーム部分とします。
3. Append the string "://" to result.
3. 結果に文字列「：//」を追加します。
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. Origin Tripleのホスト部分の各コンポーネント（次のように変換）を結果に追加し、U 002Eフルストップコードポイント（ "。"）で区切ります。
1. If the component is an A-label, use the corresponding U-label instead (see [RFC5890] and [RFC5891]).
1. コンポーネントがAラベルの場合、代わりに対応するUラベルを使用します（[RFC5890]および[RFC5891]を参照）。
2. Otherwise, use the component verbatim.
2. それ以外の場合は、コンポーネントの逐語を使用します。
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. Origin Tripleのポート部分が、Origin Tripleのスキーム部分によって与えられたプロトコルのデフォルトポートとは異なる場合：
1. Append a U+003A COLON code point (":") and the given port, in base ten, to result.
1. u 003aコロンコードポイント（ "："）を追加し、与えられたポートをベース10に追加します。
6. Return result.
6. 返品結果。
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）、これらのステップを中止します。
2. Otherwise, let result be the scheme part of the origin triple.
2. それ以外の場合は、結果をオリジントリプルのスキーム部分とします。
3. Append the string "://" to result.
3. 結果に文字列「：//」を追加します。
4. Append the host part of the origin triple to result.
4. 結果のトリプルのホスト部分を追加します。
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. Origin Tripleのポート部分が、Origin Tripleのスキーム部分によって与えられたプロトコルのデフォルトポートとは異なる場合：
1. Append a U+003A COLON code point (":") and the given port, in base ten, to result.
1. u 003aコロンコードポイント（ "："）を追加し、与えられたポートをベース10に追加します。
6. Return result.
6. 返品結果。
This section defines the HTTP Origin header field.
このセクションでは、HTTP Origin Headerフィールドを定義します。
The Origin header field has the following syntax:
Origin Headerフィールドには次の構文があります。
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
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リクエストに含まれる場合、Origin Headerフィールドは、ユーザーエージェントがリクエストを発行するようにトリガーしたAPIで定義されているように、ユーザーエージェントがリクエストを「」要求を「発行」した原点を示します。
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.
たとえば、Originsに代わってスクリプトを実行するユーザーエージェントを検討してください。これらのスクリプトのいずれかがユーザーエージェントに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
場合によっては、多くの起源がユーザーエージェントにHTTP要求を発行することに貢献します。そのような場合、ユーザーエージェントは、Origin Headerフィールドのすべての起源をリストすることができます。たとえば、HTTPリクエストが最初に1つの起源によって発行された場合、その後後で
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.
別のオリジンによってリダイレクトされたユーザーエージェントは、ユーザーエージェントがリクエストを発行するために2つの起源が関与していることをサーバーに通知する場合があります。
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リクエストに複数のOrigin Headerフィールドを含めてはなりません。
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要求を発行するたびに、ユーザーエージェントはOrigin Headerフィールドに値「null」を送信する必要があります。
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:
Origin Headerフィールドを生成する場合、ユーザーエージェントは次の要件を満たす必要があります。
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つの連続したシリアル化オリジンを生成する場合、ユーザーエージェントは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ブラウザーを含む多くのユーザーエージェントにとって、セキュリティの基礎の1つです。歴史的に、一部のユーザーエージェントは、汚染追跡や剥離防止など、他のセキュリティモデルを試しましたが、これらのモデルは当時実装が困難であることが判明しました（ただし、これらのアイデアのいくつかを復活させることに最近関心がありましたが）。
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.
Origin Concept自体がセキュリティ環境でこのような中心的な役割を果たしているため、同種のポリシーのセキュリティを評価することは困難です。概念の起源自体は、単なる隔離の単位であり、ほとんどのサイズの概念と同様に不完全です。とはいえ、以下で説明するいくつかの体系的な弱点があります。
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.
HTTPSなどの一部のURIスキームは、ユーザーエージェントが証明書などの他のメカニズムを使用してこれらのURIから取得されたコンテンツのソースを検証するため、DNSの妥協に対してより耐性があります。Chrome-Extension URIスキーム（[CRX]のセクション4.3を参照）などの他のURIスキームは、パブリックキーベースの命名権限を使用し、DNSの妥協に対して完全に安全です。
The web origin concept isolates content retrieved from different URI schemes; this is essential to containing the effects of DNS compromise.
Web Origin Conceptは、さまざまな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 Originの概念に収束しています。ただし、Cookie [RFC6265]など、現在使用されている多くのテクノロジーは、現代のWeb Originの概念を事前にしています。これらのテクノロジーには、多くの場合、異なる分離ユニットがあり、脆弱性につながります。
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つの選択肢は、完全に適格なドメイン名ではなく、「www.example.com」の代わりに「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]を使用するかどうかに応じて、いくつかの国際ドメイン名（U 00DF文字を含むもの）を異なるASCII表現にマッピングする場合があります。
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.
あるIDNAアルゴリズムから別のIDNAアルゴリズムに移行すると、いくつかのセキュリティ境界を再描画し、新しいセキュリティ境界を立てる可能性があるか、さらに悪いことに、2つの相互に不信感のあるエンティティ間のセキュリティ境界を取り壊す可能性があります。セキュリティの境界を変更すると、2つの相互に不信感のあるエンティティを同じ起源に組み合わせることで、一方が他方を攻撃できる可能性があるため、危険です。
The permanent message header field registry (see [RFC3864]) has been updated with the following registration:
永続的なメッセージヘッダーフィールドレジストリ（[RFC3864]を参照）は、次の登録で更新されました。
Header field name: Origin
ヘッダーフィールド名：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] Cerf、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC4790] Newman、C.、Duerst、M。、およびA. Gulbrandsen、「Internet Application Protocol Collation Registry」、RFC 4790、2007年3月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。および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]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]クレンシン、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 Consortium、「Unicode Standard、バージョン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] Jackson、C。and A. Barth、「細かい粒子の起源に注意してください」、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/>.
[CORS] Van Kesteren、A。、「クロスオリジンリソース共有」、W3CワーキングドラフトWD-CORS-2010100727、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] Barth、A.、Felt、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] Barth、A.、Jackson、C。、およびJ. Mitchell、「クロスサイトリクエスト偽造のための堅牢な防御」、2008年、<http://portal.acm.org/citation.cfm?id=145570.1455782>。
[HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5- 20110525, May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>.
[HTML] Hickson、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/>.
<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. Lawrence、「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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265] Barth、A。、「HTTP状態管理メカニズム」、RFC 6265、2011年4月。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
[RFC6455] Fette、I。およびA. Melnikov、「The Websocket Protocol」、RFC 6455、2011年12月。
[SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing", Work in Progress, May 2011.
[Sniff] Barth、A。およびI. Hickson、「Media Type Sniffing」、2011年5月の進行中。
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・ガルシア、トビアス・ゴンドロム、イアン・ヒクソン、アン・ヴァン・ケスターン、ジェフ・ホッジス、コリン・ジャクソン、ラリー・マシン、アレクセイ・メルニコフ、マーク・ノッティンガム、ジュリアン・レシュケ、ピーター・サンとジョナスこの文書に関する貴重なフィードバックについて、Sidking、Sid Stamm、Daniel Veditz、およびChris Weber。
Author's Address
著者の連絡先
Adam Barth Google, Inc.
Adam Barth Google、Inc。
EMail: ietf@adambarth.com
URI: http://www.adambarth.com/