| Internet Engineering Task Force (IETF) Request for Comments： 6454 分類： スタンダードトラック ISSN: 2070-1721 |
A. Barth Google, Inc. 2011年12月 |
要旨
本書は、「源泉（origin）」の概念を定義する。これは、しばしば、ユーザエージェントによって権限（authority）もしくは特権（privilege）の範囲として使われる。典型的には、ユーザエージェントは、悪意ある Web サイト運用者から健全な Web サイトの運用を妨げられることを防ぐために、異なる源泉から取得したコンテンツを隔離する。本書は、「源泉」の概念の背後にある原則を概説することに加えて、「どのように（提示された）URI の源泉を判定するか？」と「どのように、源泉（情報）を文字列にシリアライズ（serialize）するか？」についても詳説する。本書は、「どの源泉が（提示された）HTTP request と関連付けられるか？」を示す「Origin」と命名された HTTP ヘッダーフィールドも定義する。
このメモの位置づけ
これは、スタンダードトラック文書である。
本書は、IETF（Internet Engineering Task Force)の成果物である。これは、IETF コミュニティのコンセンサスを表現している。これは、パブリックレビューを受け、IESG（Internet Engineering Steering Group）によって発行を承認されたものである。Internet Standards についての詳細は、RFC 5741の 2 章から得られる。
本書の現在の位置づけ（status）についての情報、あらゆる誤記（errata）および「どのように、これについてフィードバックを提供するか？」は、http://www.rfc-editor.org/info/rfc6454 で入手できる。
著作権表記
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
本書は、本書の発行日において有効な IETF Documents (http://trustee.ietf.org/license-info) に関する BCP 78 および IETF Trust の法的規制の対象となる。これらの文書を注意深く読み返していただきたい。なぜならば、それらは、本書に関するあなたの権利と制約を記述しているからである。本書から抽出されたコードコンポーネントは、Trust Legal Provisions の 4.e節に記述されているように Simplified BSD License text を含まなければならない。そして、Simplified BSD License に記述されているように保証なしで提供されなければならない。
目次
1. はじめに English3.1. 信頼関係
3.1.1. 落とし穴
3.2. 源泉
3.2.1. 例
3.3. 権限
3.3.1. 落とし穴
3.4. ポリシー
3.4.1. オブジェクトアクセス
3.4.2. ネットワークアクセス
3.4.3. 落とし穴
3.5. 結論4. URI の源泉
5. 源泉を比較する
6. 源泉をシリアライズする
ユーザエージェントは、大勢の開発者によって制作されたコンテンツと相互作用を行う。それらの開発者の多くは善意（well-meaning）であるが、開発者には悪意ある者もいる懸念がある。ユーザエージェントの実装者は、ユーザエージェントが処理するコンテンツに基づいて作用を行う程度に応じて、他のコンテンツ（もしくはサーバ）の守秘性もしくはインテグリティを分裂させるような悪意ある開発者の能力を制限することを望む可能性がある。
例として、多様なサーバから取得した HTML コンテンツを表示する HTTP ユーザエージェントを検討する。ユーザエージェントが、それらの文書内に格納されたスクリプトを実行する場合、そのユーザエージェント実装者は、悪意あるサーバから取得した script が正直なサーバ上に保存されたファイルの内容を読むことを防ぐことを望む可能性がある。この正直なサーバは、例えば、ファイアウォールの背後にある可能性がある。
従来、ユーザエージェントは、コンテンツをその「源泉」の違いによって仕分けてきた。より具体的に述べると、ユーザエージェントは、ある源泉から取得したコンテンツには、その源泉から取得された他のコンテンツと自由に相互作用することを許可するが、ユーザエージェントは、「どのように、そのコンテンツが別の源泉からのコンテンツと相互作用できるか？」を制約する。
本書は、いわゆる「同一源泉ポリシー」の背後にある原則と共に、源泉を比較し、源泉をシリアライズすることについての「基本（nuts and bolts）」を記述する。本書は、「同一源泉ポリシー」のすべての側面の詳細までは記述していない。これらは、（HTML [HTML] や WebSockets [RFC6455]のような）他の仕様に委ねられる。なぜならば、詳細は、しばしば、アプリケーション固有であるからである。
本書中の MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、 SHOULD NOT、RECOMMENDED、MAY、OPTIONAL は、BCP 14, RFC 2119 [RFC2119] に記述されたように解釈されるべきものである。
（"strip any leading space characters" や "return false and abort these steps" のような）アルゴリズムの記述の一部分をなす命令法で表現された要件は、そのアルゴリズムを紹介する際に使われているキーワード（MUST、SHOULD、MAY 等）の意味で解釈されるべきものである。
アルゴリズム、もしくは、特定のステップとして表現された準拠性要件は、その最終結果（end result）が等価である限り、あらゆる作法で実装されうる。特に、この仕様中に定義されたアルゴリズムは、容易に理解されることを意図されており、効率的（performant）であることは意図されていない。
この仕様は、[RFC5234] の ABNF（Augmented Backus-Naur Form） 記法を使う。
下記の中心的なルールは、[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 （あらゆるデータの 8-bit sequence）、SP（space）、HTAB（horizontal tab）、CHAR（あらゆる US-ASCII 文字）、VCHAR（あらゆる可視な US-ASCII 文字）および WSP（ホワイトスペース）に定義されているように参考文献に含められている。
OWS ルールは、ホワイトスペースのオクテットがゼロ個以上、連続する可能性がある場合に使われる。OWS は、まったく生成されないか、あるいは、単一の SP として生成されるかのいずれかとする必要がある（SHOULD）。フィールドコンテンツ内に発生する複数の OWS オクテットは、そのフィールド値を解釈したり、あるいは、そのメッセージを downstream に転送する前に、単一の SP に置換されるか、あるいは、すべて SP オクテットに置換される（すなわち、SP 以外の各オクテットが SP に置換される）か、のいずれかである必要がある（SHOULD）。
OWS = *( SP / HTAB / obs-fold )
; "optional" whitespace
obs-fold = CRLF ( SP / HTAB )
; obsolete line folding
用語「ユーザエージェント」、「クライアント」、「サーバ」、「プロキシ」および「源泉サーバ（origin server）」は、HTTP/1.1 仕様（[RFC2616] 1.3節）のものと同一の意味をもつ。
グローバルに一意な識別子は、他の以前から存在しているすべての値とは異なる値である。例えば、十分に長く乱雑な（random）文字列は、グローバルに一意な識別子である傾向がある。その源泉の値がユーザエージェントから決して離れることがない場合、そのユーザエージェントにとってローカルな単調増加するカウンタは、グローバルに一意な識別子としても働く。
多くのユーザエージェントは、遠隔の主体の代わりに作用する。例えば、HTTP ユーザエージェントは、遠隔サーバからの命令であるリダイレクト（redirect）を伴い、HTML ユーザエージェントは、リッチな DOM（Document Object Model）インターフェイスを遠隔サーバから取得した script に露出する。
いかなるセキュリティモデルも無しに、ユーザエージェントは、ユーザ、あるいは、他の主体に対して有害な作用を行う懸念がある。時間と共に、多くの Web 関連技術が共通のセキュリティモデルに収斂してきた。いわゆる「同一源泉ポリシー」として知られているものである。「同一源泉ポリシー」は大きく有機的に進展しているが、このセキュリティモデルは、「ひと握りのキー概念」を通じて理解可能である。本章は、それらの概念を提示し、「どのように、これらの概念をセキュアに使うか？」についてのアドバイスを提供する。
「同一源泉ポリシー」は、URI による信頼関係を規定する。例えば、HTML ファイルの内容は、URI と共に、どのスクリプトを動作させるかを指定する。：
<script src="https://example.com/library.js"></script>
あるユーザエージェントが、この要素を処理するとき、そのユーザエージェントは、その script を指定された URI に取りにいき、その script を、その document の特権で実行する。このように、その document は、URI によって指定されたそのリソースに対して有する、すべての特権（privilege）を許容する。要するに、その document は、「その URI から取得した情報のインテグリティを信頼する」と宣言する。
ライブラリを URI からインポートすることに加えて、ユーザエージェントは、情報を URI によって指定された遠隔の主体宛に送る。例えば、HTML フォーム要素を検討する。：
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>このユーザが自身のパスワードを入力し、そのフォームを送信するとき、そのユーザエージェントは、そのパスワードを URI によって指定されているネットワークの終点（endpoint）宛に送る。このように、その document は、その秘密のデータをその URI 宛にエクスポートする。要するに、「その document は、その URI 宛に送られた情報の守秘性（confidentiality）を信頼すること」を宣言している。
「同一源泉ポリシー」を使う新しいプロトコルを設計するとき、「重要な信頼関係（trust）の区別（distinction）が URI 中に可視であること」を確認する。例えば、TLS（Transport Layer Security）防護リソースと、非 TLS 防護リソースの両方が "http" URI スキームを（[RFC2817]にあるように）使う場合、document は、「これが TLS 越しにのみ、script を取得することを望むこと」を規定できない。"https" URI スキームを使うことによって、document は、「それらは、能動的（active）なネットワーク攻撃者から保護されているリソース相互作用することを望むこと」を示すことができる。
原則として、ユーザエージェントは、すべての URI を分離された保護ドメインとして扱うことができ、ある URI から別の URI と相互作用するために取得したコンテンツについて、明示的な承諾（consent）を要求する。残念ながら、この設計は、開発者にとっては厄介である。なぜならば、Web アプリケーション は、しばしば、共同作用を行う（acting in concert）数多くのリソースから成るからである。
代わりに、ユーザエージェントは、URI を「源泉（origin）」と呼ばれる保護ドメインにまとめる。ザックリと言うと、ふたつの URI は、それらが同一のスキーム、ホストおよびポートをもつ（すなわち、同一の主役（principal）を表現する）場合、同一源泉の部分である。（詳細については 4 章を参照。）
Q: なぜ、単純に「ホスト（host）」を使わないのか？
A: 源泉の組の中に「スキーム」を含めることは、セキュリティのために肝要である。ユーザエージェントが、その「スキーム」を含めなかった場合、http://example.com と https://example.com の間に隔離は無い。なぜならば、これらふたつは、同一の「ホスト（host）」をもつからである。しかし、この分離が無い場合、能動的なネットワーク攻撃者が、http://example.com から取得したコンテンツを壊し、そのコンテンツが、そのユーザエージェントに TLS [RFC5246] によって与えられる防護を迂回して、https://example.com から取得したコンテンツの守秘性とインテグリティを侵すことを指図するようにしてしまう懸念がある。
Q: なぜ、単なる "top-level" ドメインの代わりに完全に修飾されたホスト名を使うのか？
A: DNS は階層的な委任関係（delegation）をもっているが、ホスト名間の信頼関係は、配備によって多様となる。例えば、多くの教育機関において、学生は、コンテンツを https://example.edu/~student/ にホストすることができるが、これは、「学生によって書かれた document は、https://grades.example.edu/ にホストされている学年を管理するための Web アプリケーションと同一源泉の部分（すなわち、同一の保護ドメインに存在する）になければならないこと」は、意味しない。
example.edu の配備は、「リソースを源泉によってまとめることは、すべての配備シナリオと完全に整合するとは限らないこと」を描写する。この配備において、すべての学生の Web サイトは、望まれていない可能性がある同一源泉に存在する。同様に、源泉の粒度（granularity）は、「どのように、そのセキュリティモデルは、進展してきたか？」の経緯上の産物（artifact）である。
下記のリソースのすべては、同一の源泉をもつ。：
http://example.com/
http://example.com:80/
http://example.com/path/fileこれらの URI の各々は、同一のスキーム、ホストおよびポートのコンポーネントをもつ。
下記のリソースの各々は、他のものとは異なる源泉をもつ。
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/各事例において、少なくともそのスキーム、ホスト、ポートのコンポーネントの内のひとつが、リスト中の他のものとは異なる。
ユーザエージェントは、URI を源泉にまとめるが、必ずしもひとつの源泉中のすべてのリソースが同一の権限（authority： セキュリティセンスの単語であり、 [RFC3986] のセンスの用語ではない）を運ぶとは限らない。例えば、画像は受動的（passive）なコンテンツであり、それゆえ、権限（authority）は運ばない。これは、「その画像は、その源泉が利用可能なオブジェクトやリソースにアクセスできないこと」を意味する。対極的に、HTML ファイルの内容は、その源泉の全体（full）の権限（authority）を運び、その document 中の（あるいはインポートされた）script は、その源泉中のすべてのリソースにアクセスできる。
ユーザエージェントは、「あるリソースに対して、どれだけ多くの権限（authority）を、その media type を吟味することによって、許容するか？」を判定する。例えば、media type として image/png をもつリソースは画像として扱われ、media type として text/html をもつリソースは HTML ファイルの内容として扱われる。
（ユーザによって生成されたコンテンツのような）信頼されていないコンテンツをホストするとき、Web アプリケーションは、その media type を制約することによって、そのコンテンツの権限（authority）を制限できる。例えば、ユーザによって生成されたコンテンツを image/png として提供することは、ユーザが生成した（user-generated）コンテンツを text/html として提供するよりもリスクが低い。当然、多くの Web アプリケーションは、信頼できないコンテンツを、その HTML ファイルの内容の中に組み入れる。注意深く行われない場合、これらのアプリケーションは、それらの源泉の権限（authority）を、信頼できないコンテンツに漏らすというリスクにさらす。（これは）「スクリプト注入（cross-site scripting）」として卑近に知られている脆弱性である。
Web プラットフォームの新しいソフトウェア（pieces）を設計するとき、メディアのタイプに関係なく、リソースに権限（authority）を許容しないように注意せよ。多くの Web アプリケーションは、制約された media type で信頼されない（untrusted）コンテンツを提供している。これらのコンテンツに対して権限（authority）を許容する新しい Web プラットフォーム機能は、脆弱性を既存のアプリケーションに招く事態になる。代わりに、その源泉のすべての（full）権限（authority）を既に保持している media type に、あるいは、新しい権限（authority）を運ぶために具体的に指定された新しい media type に、権限（authority）を許容することを選好する。
誤った media type を提供するサーバと互換性を保つために、ユーザエージェントには、「コンテンツの嗅ぎ分け（sniffing）」を採用し、コンテンツを、そのサーバによって供給された media type とは異なる media type をもっていたかのように扱うものがある。注意深く行われない場合、「コンテンツの嗅ぎ分け」は、セキュリティ脆弱性をもたらす可能性がある。なぜならば、ユーザエージェントは、（画像のような）低権限（low-authority）の media type、（HTML ファイルの内容のような）高権限（high-authority）のmedia type の特権を許容する可能性がある [SNIFF] からである。
一般に、ユーザエージェントは、異なる源泉を分離し、源泉間のコントロールされた通信は許容するものである。「どのように、ユーザエージェントが、分離および通信を提供するか？」の詳細は、いくつかの要因に依存して多様となる。
ユーザエージェントによって露出される大部分の（「アプリケーション・プログラミング・インターフェイス」もしくは API としても知られる）オブジェクトは、同一源泉宛にのみ利用可能である。具体的には、ある URI から取得されたコンテンツは、そのふたつの URI が同一源泉に属する （例： 同一のスキーム、ホストおよびポートをもつ）場合、そしてこの場合のみ、別の URI から取得したコンテンツと関連するオブジェクトにアクセスできる。
この一般ルールに対するいくつかの例外がある。例えば、HTML の Location インターフェイスの部分には、（例えば、他のブラウザコンテキストを操縦（navigate）することを許容するために）源泉をまたいで利用可能なものがある。別の例として、HTML の postMessage インターフェイスは、他源泉（cross-origin）通信を容易にするために、源泉をまたいで明示的に（explicitly）に見ることができる。オブジェクトを外部の源泉にさらすことは危険であり、大いに注意を払うことを条件に行われる必要がある。なぜならば、そのようにすることは、これらのオブジェクトを潜在的な攻撃者にさらすからである。
ネットワークリソースへのアクセスは、「そのリソースが、それらにアクセスすることを試みているコンテンツと同一源泉にあるか否か？」に依存して多様となる。
一般に、別の源泉から情報を読み出すことは、禁止されている。しかし、ある源泉には、他の源泉から取得したある種のリソースを使うことが許容されている。例えば、ある源泉は、script を実行し、画像を描写し、あらゆる源泉からのスタイルシートを適用することが許容されている。同様に、ある源泉は、HTML フレーム中に HTML ファイルの内容のような別の源泉からのコンテンツを表示できる。ネットワークリソースは、例えば、Cross-Origin Resource Sharing [CORS] を使って、他の源泉にネットワークの情報を読ませる選択もできる。これらの場合、アクセスは、典型的には、源泉ごとに許容される。
情報を別の源泉宛に送ることは、許可されている。しかし、情報を任意のフォーマットでネットワーク越しに送ることは、危険である。したがって、ユーザエージェントは、document が （カスタムヘッダー無しの HTTP request 内のような）特定のプロトコルを使って情報を送ることを制約する。（例えば、WebSocket のサポートを追加することによって）許容されるプロトコルの集合を拡張することは、脆弱性を招くこと [RFC6455] を避けるために、注意深く行われなければならない。
ユーザエージェントが「ある源泉が別の源泉からのリソースと相互作用すること」を許容するときは常に、それらは、セキュリティ問題を招く。例えば、別の源泉からの画像を表示する能力は、それらの高さ（height）と幅（width）を漏らす。同様に、ネットワークリクエストを別の源泉宛に送る能力は、「リクエスト強要（cross-site request forgery）」という脆弱性 [CSRF] の懸念を高める。しかし、ユーザエージェント実装者は、しばしば、これらのリスクを、他源泉との相互作用を許容することの便益に対して均衡を図る。例えば、他源泉ネットワークリクエストをブロックした HTML ユーザエージェントは、そのユーザを（Web の核心的な機能である）ハイパーリンクに従うことから防ぐ。
新しい機能を Web プラットフォームに加えるとき、これは、あるリソースに対する特権を許容しつつ、同一源泉内の別のリソースからのその特権は保留することを試みているものでありうる。しかし、このやり方で特権を保留することは、非効率である。なぜならば、特権をもたないリソースは、通常、ユーザエージェントがひとつの源泉内のリソースを分離しないので、結局、特権を入手できるからである。代わりに、特権は、許容されるか、あるいは、（ある源泉内の個々のリソースを識別する（discriminating）のではなく）源泉からまるごと保留される必要がある [BOFGO]。
同一源泉ポリシーは、信頼関係を指定するために URI を使う。URI は、保護ドメインを表現する源泉にまとめられる。源泉中のリソース（例： 動的（active）コンテンツ）には、その源泉中の他のリソース（例： 待ち受ける（passive）コンテンツ）が、その源泉の権限（authority）を許容していないにもかかわらず、その源泉の全体の（full）権限（authority）を許容されるものがある。その源泉の権限（authority）を運ぶコンテンツは、自身の源泉内のオブジェクトやネットワークリソースに対するアクセスを許容される。このコンテンツは、他の源泉のオブジェクトやネットワーク リソースに対して制限されたアクセスも許容されているが、これらの他源泉特権は、セキュリティ脆弱性を避けるために、注意深く設計されなければならない。
与えられた URI の源泉は、下記のアルゴリズムによって計算される。：
- URI が命名機関（[RFC3986] の 3.2節を参照）として階層的要素を使わない場合、あるいは、その URI が絶対（absolute）URI でない場合、新鮮なグローバルに一意な識別子を生成し、その値を返す。
注： 同一の URI について、このアルゴリズムを複数回、走らせると、毎回、異なる値を創り出す可能性がある。典型的には、ユーザエージェントは、1 回のみ、例えば、ある HTML ファイルの内容の源泉を計算し、毎回、再計算することなく、以降のセキュリティチェックのために、その源泉を使う。
- uri スキームを小文字（lowercase）に変換された、その URI のスキームコンポーネントとなるようにする。
- その実装が uri スキームによって与えられるプロトコルをサポートしていない場合、新鮮なグローバルに一意な識別子を生成し、その値を返す。
- uri スキームが "file" である場合、その実装は、実装が定義した値を返すことができる（MAY）。
注： 経緯上、ユーザエージェントは、ファイルスキームからのコンテンツに対して、途方もない特権を許容してきた。しかし、すべてのローカルファイルに、そのような広い特権を許容することは、特権昇格（escalation）攻撃をもたらす懸念がある。ユーザエージェントには、ローカルファイルにディレクトリに基づく特権を許容することに成功したことがあるものがあるが、このアプローチは、広くは採用されていない。他のユーザエージェントは、各ファイル URI についてグローバルに一意な識別子を使う。これは、最もセキュアなオプションである。
- uri-host を URI の host コンポーネント、（[RFC4790] に定義されている「i;ascii-casemap collation」を使って）小文字に変換されたものにする。
注： 本書は、「ユーザエージェントは、URI を組み立てるとき、IDNA（Internationalizing Domain Names in Applications）の処理と検証（validation）を行う」と想定する。特に、本書は、「ユーザエージェントは、既に、あらゆる非 ASCII ラベルを、それらが対応する A-label （[RFC5890] 参照）に変換しているはずであるので、uri-host は、LDH ラベルのみを納めている」と想定する。したがって、源泉に基づくセキュリティポリシーは、ユーザエージェントによって採用された IDNA アルゴリズムに対して敏感である。さらなる検討詳細については 8.4 節を参照。
- URI の port コンポーネントが無い場合：
1. uri-port を uri-schime によって与えられたプロトコルについてのデフォルトポートとなるようにする。
さもなくば：
2. uri-port を、その URI のポートコンポーネントとなるようにする。
- 三種（uri-schime／uri-host／uri-port）を返す。
ふたつの源泉が同値である場合、そして、この場合に限って、それらは「同一」である。特に：
- ふたつの源泉がスキーム／ホスト／ポートの三種である場合、そのふたつの源泉は、それらが同一のスキーム、ホストおよびポートをもつ場合（かつ、この場合のみ）、同一である。
- グローバルに一意な識別子である源泉は、スキーム／ホスト／ポートの三種である源泉と同一ではありえない。
ふたつの URI は、それらの源泉が同一である場合、同一源泉である。
注： URI 自体は、必ずしも同一源泉ではない。例えば、data URI [RFC2397] 自体は、同一源泉ではない。なぜならば、data URI は、サーバに基づく命名機関を使わず、それゆえ、源泉としてグローバルに一意な識別子をもつからである。
本章では「どのように源泉を unicode [Unicode6] 文字列にシリアライズするか？」と、「どのように源泉を ASCII [RFC20] 文字列にシリアライズするか？」を定義する。
6.1. 源泉の Unicode シリアライズ English
源泉の Unicode シリアライズは、下記のアルゴリズムによって返される値である。：
- 源泉がスキーム／ホスト／ポートの 3つでない場合、下記の文字列を返す。
null
（すなわち、文字「U+006E, U+0075, U+006C, U+006C」）
そして、これらのステップを中止する。
- さもなくば、result をその源泉三種のスキーム部分となるようにする。
- 文字列 "://" を result に追記する。
- （下記のように変換される）源泉三種のホスト部分の各コンポーネントを、句点文字（"."：「U+002E」）によって区切られた result に追記する。：
- 源泉三種のポート部分が、その源泉三種のスキーム部分によって与えられたプロトコルについてのデフォルト（default）ポートと異なる場合：
- コロン文字（":"： U+003A）と、与えられポートを 10進数で result に追記する。
- result を返す。
源泉の ascii シリアライズは、下記のアルゴリズムによって返される値である。：
- 源泉がスキーム／ホスト／ポートの 3つでない場合、下記の文字列を返す。
null
（すなわち、文字「U+006E, U+0075, U+006C, U+006C」）
そして、これらのステップを中止する。
- さもなくば、result をその源泉三種のスキーム部分にする。
- 文字列 "://" を result に追記する。
- 源泉三種のホスト部分を result に追記する。
源泉三種のポート部分が、その源泉三種のスキーム部分によって与えられたプロトコルについてのデフォルト（default）ポートと異なる場合：
- コロン文字（":"： U+003A）と、与えられたポートを 10進数で result に追記する。
- result を返す。
7. HTTP Origin ヘッダーフィールド English
本章では HTTP Origin ヘッダーフィールドを定義する。
Origin ヘッダーフィールドは、下記の構文をもつ。：
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 ]
;, , from RFC 3986
HTTP request 中に含められるとき、Origin ヘッダーフィールドは、ユーザエージェントに（そのユーザエージェントが request を発行するように引き金を引いた API によって定義されているように、）その request を発行させた源泉を表示する。
例えば、源泉の代わりに script を実行するユーザエージェントを検討する。それらの script のひとつが、そのユーザエージェントに HTTP request を発行させる場合、ユーザエージェントは、そのサーバに、そのセキュリティコンテキストを知らせるために、Origin ヘッダーフィールドを使うことができる（MAY）。セキュリティコンテキストの中で、その script は、それがユーザエージェントに、その request の発行もたらしていたとき、実行していたものである。
場合によっては、数多くの源泉が、ユーザエージェントに HTTP request を発行させることに貢献する。それらの場合、ユーザエージェントは、Origin ヘッダーフィールド中にすべての源泉を掲げることができる（MAY）。例えば、HTTP request が当初、ある源泉によって発行されていたが、後で別の源泉によってリダイレクトされていた場合、そのユーザエージェントは、サーバに「ふたつの源泉が、そのユーザエージェントに request を発行させる際に巻き込まれていたこと」を知らせることができる（MAY）。
ユーザエージェントは、Origin ヘッダーフィールドを、あらゆる HTTP request 中に含めることができる（MAY）。
ユーザエージェントは、ひとつ以上の Origin ヘッダーフィールドを、あらゆる HTTP request 中に含めてはならない（MUST NOT）。
ユーザエージェントが "privacy-sensitive" コンテキストから HTTP request を発行するときはいつでも、ユーザエージェントは、値 "null" を Origin ヘッダーフィールド中に送らなければならない（MUST）。
注： 本書は、privacy-sensitive コンテキストの観念を定義しない。HTTP request を生成するアプリケーションは、「どのように、ユーザエージェントは、Origin ヘッダーフィールドを生成するか？」についての制約を提起する privacy-sensitive としてコンテキストを指定できる。
Origin ヘッダーフィールドを生成するとき、そのユーザエージェントは、下記の要件に適合しなければならない（MUST）。：
- 文法（grammar）におけるシリアライズされた源泉の生成結果（production）の各々は、源泉を ascii シリアライズしたものでなければならない（MUST）。
- 文法（grammar）における連続する（consecutive）ふたつのシリアライズされた源泉の生成結果（production）は、同一であってはならない。特に、ユーザエージェントが、ふたつの連続（consecutive）シリアライズされた源泉を生成する場合、ユーザエージェントは、2 番目のものを生成してはならない（MUST NOT）。
「同一源泉ポリシー」は、（Web ブラウザを含めた）多くのユーザエージェントについてのセキュリティの基礎（cornerstone）のひとつである。経緯上、ユーザエージェントには、taint 印追跡や、不正転送防止（exfiltration prevention）を含めて、他のセキュリティモデルを試みたものがある。それらのモデルは、（最近になって、これらのアイディアのいくつかを再現させる関心がもたれているが、）当時、実装するのが困難であると判明した。
「同一源泉ポリシー」のセキュリティを評価することは、困難である。なぜならば、「同一源泉ポリシー」自体が、セキュリティの観点として、コントロールする側の役割を果たすからである。観念的な「源泉」自体は、単なる分離の単位であり、多くの「ワンサイズ（one-size-fits-all）」な観念と同様に不完全である。とはいえ、以降で検討されるように、いくつかのシステム的（systemic）な弱点がある。
実践上、同一源泉ポリシーは、セキュリティのためには DNS（Domain Name System） に依存する。なぜならば、（http のような）多くの卑近に使われている URI スキームは、DNS に基づく命名機関を使うからである。その DNS が部分的に、あるいは完全に侵された場合、同一源泉ポリシーは、アプリケーションによって要求されたセキュリティプロパティを提供することに失敗する可能性がある。
（https のような）URI スキームには、DNS 侵害に対して、より耐性をもつものがある。なぜならば、ユーザエージェントは、これらの URI から取得したコンテンツの源泉を検証するために、証明書のような他のメカニズムを採用しているからである。「chrome 拡張 URI スキーム（[CRX] の 4.3 節を参照）」のような他の URI スキームは、公開鍵に基づく命名機関を使っており、DNS の侵害に対して完全にセキュアである。
「Web 源泉概念」は、異なる URI スキームから取得されたコンテンツを分離する。これは、DNS 侵害の影響を閉じ込めるために肝要である。
これまで、数多くの技術が、分離の便利な単位（unit）として、この Web 源泉概念に収斂してきた。
しかし、（cookie [RFC6265] のように）今日、使われている多くの技術は、現在の Web 源泉概念よりも前からあった。しばしば、これらの技術は、脆弱性につながる異なる分離の単位をもつ。
ひとつの代替案は、分離の単位として、完全修飾されたドメイン名ではなく、"registry-controlled" ドメインのみを使うことである（例： "www.example.com" の代わりに "example.com"）。この実践は、数多くの理由で問題があり、推奨されない（NOT RECOMMENDED）。：
- "registry-controlled" ドメインの観念は、DNS 自体のプロパティというよりは、DNS をとりまく人間の実践の役割である。例えば、日本にある多くの市町村は、公衆（public）レジストリを DNS 階層において極めて深い階層で運用されている。広く使われている "public suffix lists"があるが、これらのリストは、最新に保つのが困難であり、実装間で多様となる。
- この原則は、DNS に基づく命名機関を使わない URI スキームと互換性が無い。例えば、与えられた URI スキームが公開鍵を命名機関として使う場合、"registry-controlled" 公開鍵の観念は、いくぶん、一貫しないものである。さらに悪いものとして、（nntp のような）URI スキームには、DNS とは逆方向のドットで区切る委任関係（delegation）を使うもの(例： alt.usenet.kooks）があり、DNS を使うが 通常とは逆順にラベルを表現するもの（例： com.example.www）もある。
高々、"registry-controlled" ドメインの利用は、URI スキームであり、 実装固有である。最悪の場合、URI スキームと実装の間の相違は、脆弱性をもたらす懸念がある。
「同一源泉ポリシー」を使うとき、ユーザエージェントは、「どのオブジェクトを、そのコンテンツは、指定できるか？」に基づくのではなく、その URI に基づくコンテンツに対する権限（authority）を許容する。この権限（authority）からの指定の解放は、曖昧な権限（ambient authority）の一例であり、脆弱性につながりかねない。
例えば、HTML ファイルの内容へのスクリプト注入（cross-site scripting）について検討する。攻撃者が script コンテンツを HTML ファイルの内容中に注入できる場合、それらの script は、その内容の源泉の権限（authority）と共に動作し、おそらく、その script が（ユーザの医療記録のような）取扱注意の情報にアクセスできるようにする。しかし、その script の権限（authority）が、その script が指定できたそれらのオブジェクトに制限されていた場合、攻撃者は、その script を第三者によってホストされている HTML ファイルの内容に注入することによって、いかなる優位性も得ることはない。
「同一源泉ポリシー」のセキュリティプロパティは、ユーザエージェントによって採用されている IDNA アルゴリズムの詳細に重大に依存しうる。特に、ユーザエージェントは、何らかの国際化ドメイン名（例えば、U+00DF 文字を巻き込むもの）を「そのユーザエージェントが IDNA2003 [RFC3490] と IDNA2008 [RFC5890] のどちらを使っているか？」に依拠して、異なる ASCII 表現に対応づける可能性がある。
ある IDNA アルゴリズムから別のものに移行することは、数多くのセキュリティ境界を描き直す懸念があり、潜在的には新しいセキュリティ境界を建てる懸念がある。あるいは、より悪いことに、相互に信頼関係が無いふたつの主体間のセキュリティ境界を引き裂く（tearing down）懸念がある。セキュリティ境界を変更することは、リスクを伴う。なぜならば、ふたつの相互に信頼していない（distrusting）主体を同一源泉に結合することは、一方をして他方を攻撃することを許す懸念があるからである。
パーマネントメッセージヘッダーフィールドのレジストリ（[RFC3864] 参照）は、下記の登録内容に更新されている。：
Header field name: Origin
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document: this specification (7 章)
[RFC20] Cerf, V.,
"ASCII format for network interchange", RFC 20, 1969年10月.[RFC2119] Bradner, S.,
"Key words for use in RFCs to Indicate Requirement Levels", 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, 1999年 1月.[RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
"Registration Procedures for Message Header Fields", 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, 2005年 1月.[RFC4790] Newman, C., Duerst, M., and 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, 2008年 1月.[RFC5890] Klensin, J.,
"Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, 2010年 8月.[RFC5891] Klensin, J.,
"Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, 2010年 8月.[Unicode6] The Unicode Consortium,
"The Unicode Standard, Version 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>.[CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C Working Draft WD-cors-20100727, 2010年,
<http://www.w3.org/TR/2010/WD-cors-20100727/>.最新版がこちらで入手可能 <http://www.w3.org/TR/cors/>.
[CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman,"Protecting Browsers from Extension Vulnerabilities", 2010年,
<http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>.[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses for Cross-Site Request Forgery", 2008年,
<http://portal.acm.org/citation.cfm?id=1455770.1455782>.[HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525, 2011年 5月,
<http://www.w3.org/TR/2011/WD-html5-20110525/>.最新版がこちらで入手可能 <http://www.w3.org/TR/html5/>.
[RFC2397] Masinter, L.,
"The "data" URL scheme", RFC 2397, 1998年 8月.[RFC2817] Khare, R. and S. Lawrence,
"Upgrading to TLS Within HTTP/1.1", RFC 2817, 2000年 5月.[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", RFC 3490, 2003年 3月.[RFC5246] Dierks, T. and E. Rescorla,
"The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, 2008年 8月.[RFC6265] Barth, A.,
"HTTP State Management Mechanism", RFC 6265, 2011年 4月.
[RFC6455] Fette, I. and A. Melnikov,
"The WebSocket Protocol", RFC 6455, 2011年12月.
[SNIFF] Barth, A. and I. Hickson,
"Media Type Sniffing", 作業中, 2011年 5月.
我々は、本書について有用なフィードバックをしてくださった 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、Chris Weber に感謝する。
著者のアドレス
Adam Barth
Google, Inc.EMail： ietf＠adambarth.com
URI： http://www.adambarth.com/
翻訳者のアドレス
独立行政法人 情報処理推進機構
技術本部 セキュリティセンター
宮川 寧夫EMail： miyakawa＠ipa.go.jp