Internet Engineering Task Force (IETF)
Request for Comments: 6454
分類: スタンダードトラック
ISSN: 2070-1721
A. Barth
Google, Inc.
2011年12月

English

The Web における源泉概念
(The Web Origin Concept)

要旨

本書は、「源泉(origin)」の概念を定義する。この概念は、しばしばブラウザ(UA)によって、その権能もしくは特権の範囲として使われる。典型的には、ブラウザは、悪意ある Web サイト運用者から健全な Web サイトの運用が妨げられないようにするために、他の「源泉」から取得されたコンテンツを絶縁する。本書は、「源泉」の概念の背後にある原則的な事項を概説し、「どのように(提示された)URI の『源泉』を判定するか?」と「どのように『源泉』(データ)を文字列にシリアライズするか?」についても詳説する。本書は、Origin と命名された HTTP ヘッダーフィールドも規定する。これは、「どの『源泉』が(提示された)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. はじめに

2. 慣行

2.1. 準拠性クライテリア
2.2. 構文の表記法
2.3. 用語法

3. 「同一源泉ポリシー」の原則

3.1. 信頼度(trust)
3.1.1. 思わぬ脆弱性

3.2. 源泉(origin)
3.2.1. 例

3.3. 権能(authority)

3.3.1. 思わぬ脆弱性

3.4. ポリシー(policy)

3.4.1. オブジェクトアクセス
3.4.2. ネットワークアクセス
3.4.3. 思わぬ脆弱性

3.5. 結論

4. ある URI の源泉(データ)

5. 源泉(データ)を比較する

6. 源泉(データ)をシリアライズする

6.1. 源泉(データ)の Unicode シリアライズ
6.2. 源泉(データ)の ASCII シリアライズ

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

7.1. 構文
7.2. 意味論
7.3. ユーザエージェントの要件

8. セキュリティについての考慮事項

8.1. DNS への依存
8.2. 絶縁する分岐の括り
8.3. 場が与える権能
8.4. IDNA 依存性と移行

9. IANA に関する考慮事項

10. 参考文献

10.1. 規範的参考文献
10.2. 参考資料

補遺 A. 謝辞

1. はじめに English

ユーザエージェント(UA; ブラウザ)は、大勢の開発者によって制作されたコンテンツと相互作用を行う。それらの開発者の多くは善意であるが、開発者には悪者もいる懸念がある。ユーザエージェントの実装者は、ユーザエージェントが処理するコンテンツに基づく作用の範囲内で、他のコンテンツ(もしくはサーバ)の守秘性もしくはインテグリティを損なうような悪意ある開発者の能力を制限することを望む可能性がある。

例として、多様なサーバから取得した HTML コンテンツを表示する HTTP ユーザエージェントを検討する。ユーザエージェントが、それらの文書内に格納されたスクリプトを実行する場合、そのユーザエージェントの実装者は、悪意あるサーバから取得したスクリプトが正直なサーバ上に保存されたファイルの内容を読むことを防ぐことを望む可能性がある。この正直なサーバは、例えば、ファイアウォールの背後にある可能性がある。

従来、ユーザエージェントは、コンテンツをその「源泉(origin)」の違いによって仕分けてきた。より具体的に述べると、ユーザエージェントは、ある源泉から取得したコンテンツには、その源泉から取得された他のコンテンツと自由に相互作用することを許可するが、ユーザエージェントは、「どのように、そのコンテンツが他源泉からのコンテンツと相互作用できるか?」を制約する。

本書は、源泉(のデータ)を比較してシリアライズすることについての基本的な事項のみならず、いわゆる「同一源泉ポリシー(Same-Origin Policy)」の背後にある原則についてもも記述する。本書は、「同一源泉ポリシー」のすべての側面の詳細までは記述していない。これらは、(HTML [HTML] や WebSockets [RFC6455] のような)他の仕様に委ねられる。なぜならば、しばしば詳細はアプリケーション固有であるからである。

2. 慣行 English

2.1. 準拠性クライテリア English

本書中の MUSTMUST NOTREQUIREDSHALLSHALL NOTSHOULDSHOULD NOTRECOMMENDEDMAYOPTIONAL は、BCP 14, RFC 2119 [RFC2119] に記述されたように解釈されるべきものである。

("strip any leading space characters" や "return false and abort these steps" のような)アルゴリズムの記述の一部分をなす命令法で表現された要件は、そのアルゴリズムを紹介する際に使われているキーワード(MUSTSHOULDMAY 等)の意味で解釈されるべきものである。

アルゴリズム、もしくは、特定のステップとして表現された準拠性要件は、その最終結果(end result)が等価である限り、あらゆる作法で実装されうる。特に、この仕様中に規定されたアルゴリズムは、理解し易いことを意図されており、効率的(performant)であることは意図されていない。

2.2. 構文の表記法 English

この仕様は、[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

2.3. 用語法 English

用語「ユーザエージェント」、「クライアント」、「サーバ」、「プロキシ」および「源泉サーバ(origin server)」は、HTTP/1.1 仕様([RFC2616] 1.3節)のものと同一の意味をもつ。

グローバルに一意な識別子は、他の以前から存在しているすべての値とは異なる値である。例えば、十分に長く乱雑な(random)文字列は、グローバルに一意な識別子である傾向がある。その源泉の値がユーザエージェントから決して離れることがない場合、そのユーザエージェントにとってローカルな単調増加するカウンタは、グローバルに一意な識別子としても働く。

3. 「同一源泉ポリシー」の原則 English

多くのユーザエージェントは、遠隔の主体の代わりにふるまう。例えば、HTTP ユーザエージェントは、遠隔サーバからの命令であるリダイレクトを伴い、HTML ユーザエージェントは、リッチな DOM(Document Object Model)インターフェイスを遠隔サーバから取得したスクリプトに露出する。

セキュリティモデルがまったく搭載されていないとしたら、ユーザエージェントは、ユーザ(あるいは他の主体)に対して有害な作用を行う懸念がある。時間の経過とともに、多くの Web 関連技術が共通認識されるセキュリティモデルに収斂してきた。いわゆる「同一源泉ポリシー」として知られているものである。「同一源泉ポリシー」は大いに有機的に進展しているが、このセキュリティモデルは「ひと握りの鍵となる概念」を通じて理解可能なものである。本章は、それらの概念を提示し、「どのように、これらの概念をセキュアに使うか?」についてのアドバイスを提供する。

3.1. 信頼度(trust) English

「同一源泉ポリシー」は、URI によって信頼していることを規定する。例えば、HTML ファイルの内容は、どのスクリプトを動作させるかを URI で指定する。:

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

あるユーザエージェントが、この要素を処理するとき、そのユーザエージェントは、そのスクリプトを指定された URI に取りにいき、そのスクリプトを、その 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)を信頼すること」を宣言している。

3.1.1. 思わぬ脆弱性 English

「同一源泉ポリシー」を使う新しいプロトコルを設計するとき、「重要な信頼度の区別が URI 中に可視であること」を確保する。例えば、TLS(Transport Layer Security)防護リソースと、非 TLS 防護リソースの両方ともが、([RFC2817]にあるように) "http" URI スキームを使う場合、document が「TLS 越しにのみ、スクリプトを取得することを望むこと」を仕様として示さない。"https" URI スキームを使うことによって、document は「積極的(active)なネットワーク攻撃者から保護されているリソースと相互作用することを望むこと」を示すことができる。

3.2. 源泉(origin) English

原則として、ユーザエージェントは、すべての URI を絶縁された保護ドメインとして扱うことができ、ある URI から別の URI と相互作用するために取得したコンテンツについて、明示的な承諾(consent)を要求する。残念ながら、この設計は開発者にとっては厄介である。なぜならば、Web アプリケーションは、しばしば協調してふるまう数多くのリソースから成るからである。

代わりに、ユーザエージェントは、URI を「源泉(origin)」と呼ばれる保護ドメインにまとめる。大雑把に言うと、ふたつの URI は、それらが同一スキーム、同一ホストおよび同一ポートをもつ場合(すなわち、同一の主役(principal)を表現する場合)、同一源泉の部分となる。(詳細については 4 章を参照。)

Q: なぜ、単純に「ホスト(host)」を使わないのか?

A: 源泉の組の中に「スキーム」を含めることは、セキュリティのために肝要である。ユーザエージェントが、その「スキーム」を含めなかった場合、http://example.com と https://example.com の間は絶縁されない。なぜならば、これらふたつは同一の「ホスト(host)」をもつからである。しかし、この絶縁がなさえれない場合、活動的なネットワーク攻撃者が、http://example.com から取得したコンテンツを壊し、そのコンテンツが、そのユーザエージェントに TLS [RFC5246] によって与えられている防護を迂回して、https://example.com から取得したコンテンツの守秘性とインテグリティを侵すことを指図するようにしてしまう懸念がある。

Q: なぜ、単なる「トップレベル」ドメインの代わりに完全に修飾されたホスト名を使うのか?

A: DNS は階層的な委任関係(delegation)をもっているが、ホスト名の信頼関係は、配備(シナリオ)に応じて多様となる。例えば多くの教育機関において、学生は https://example.edu/~student/ にコンテンツを置くことができる。しかし、これは「学生によって書かれた document は、https://grades.example.edu/ に置かれている学年を管理するための Web アプリケーションと同一源泉の部分(すなわち、同一の保護ドメインに存在する)になければならないこと」を意味するものではない。

example.edu の配備例は、「リソースを源泉によってまとめることは、すべての配備シナリオに完璧に沿えるとは限らないこと」を描写している。この配備例において、すべての学生の Web サイトは同一源泉中に在るが、このようなものが欲しいのではないかもしれない。同様に源泉の粒度(granularity)は、「どのように、このセキュリティモデルが進展してきたか?」の経緯上の産物である。

3.2.1. 例 English

下記のリソースのすべては、同一の源泉をもつ。:

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/

各事例において、少なくともそのスキーム、ホスト、ポートのコンポーネントの内のひとつが、リスト中の他のものとは異なる。

3.3. 権能(authority) English

ユーザエージェントは、URI を源泉にまとめるが、必ずしもひとつの源泉中のすべてのリソースが同一の権能(authority: セキュリティセンスの単語であり、[RFC3986] のセンスの用語ではない)を運ぶとは限らない。例えば、画像は受け身(passive)なコンテンツであり、それゆえ権能(authority)を運んだりはしない。これは、「その画像は、その源泉が利用可能なオブジェクトやリソースにアクセスできないこと」を意味する。一方、HTML ファイルの内容(document)は、その源泉の全権能(authority)を運び、その document 中の(あるいはインポートされた)スクリプトは、その源泉中のすべてのリソースにアクセスできる。

ユーザエージェントは、「その media type を吟味することによって、あるリソースに対して、どれだけ多くの権能(authority)を許容するか?」を判定する。例えば、media type として image/png をもつリソースは画像として扱われ、media type として text/html をもつリソースは HTML ファイルの内容として扱われる。

(ユーザによって生成されたコンテンツのような)信頼されていないコンテンツをホストするとき、Web アプリケーションは、その media type を制約することによって、そのコンテンツの権能(authority)を制限できる。例えば、ユーザによって生成されたコンテンツを image/png として提供することは、ユーザが生成した(user-generated)コンテンツを text/html として提供するよりもリスクが低い。当然、多くの Web アプリケーションは、信頼できないコンテンツを、その HTML ファイルの内容の中に組み入れる。注意深く行われない場合、Web アプリケーションは、それらの源泉の権能(authority)を信頼できないコンテンツに与えてしまうというリスクにさらされる。「スクリプト注入(XSS)」として卑近に知られている脆弱性である。

3.3.1. 思わぬ脆弱性 English

Web プラットフォームの新しいソフトウェア(pieces)を設計するとき、リソースに media type と関連づけずに権能(authority)を与えてしまわないように注意せよ。多くの Web アプリケーションは、信頼されない(untrusted)コンテンツを制約された media type で提供している。これらのコンテンツに対して権能(authority)を与える新しい Web プラットフォームの機能は、既存のアプリケーションに脆弱性を招く事態になる。代わりに、その源泉の全権能(authority)を既に保持している media type に権能(authority)を与える、あるいは、新しい権能(authority)を運ぶために具体的に指定された新しい media type に権能(authority)を与えることが望ましい。

ユーザエージェントには、誤った media type を提供するサーバと互換性を保つために「コンテンツの嗅ぎ分け(sniffing)」を採用し、コンテンツを、そのサーバによって供給された media type とは異なる media type をもっていたかのように扱うものがある。「コンテンツの嗅ぎ分け(sniffing)」は、注意深く行われない場合、セキュリティ脆弱性をもたらす懸念がある。なぜならば、ユーザエージェントが(画像のような)低権能(low-authority)の media type に(HTML ファイルのコンテンツのような)高権能(high-authority)の media type の特権を与えてしまう懸念がある [SNIFF] からである。

3.4. ポリシー(policy) English

一般に、ユーザエージェントは、異なる源泉同士を絶縁しつつ、コントロールされた源泉間の通信は許容するものである。「どのようにユーザエージェントが絶縁機能と通信機能を提供するか?」の詳細は、いくつかの要因に起因して多様となる。

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

ユーザエージェントによって露出される大部分の(「API(Application Prognamming Interface) 」として知られる)オブジェクトは、同一源泉宛にのみ利用できる。具体的には、ある URI から取得されたコンテンツは、そのふたつの URI が同一源泉に属する(例: 同一のスキーム、ホストおよびポートをもつ)場合、そしてこの場合のみ、別の URI から取得したコンテンツと関連するオブジェクトにアクセスできる。

この一般ルールに対するいくつかの例外がある。例えば、HTML の Location インターフェイスの部分には、(例えば、他の閲覧コンテキストにページ遷移(navigate)することを許すために)源泉を跨いで利用可能なものがある。別の例として、HTML の postMessage インターフェイスは、他源泉との(cross-origin)通信を容易にするために、源泉を跨いで明示的に(explicitly)見ることができる。オブジェクトを外部の源泉にさらすことは危険であり、大いに注意を払うことを条件に行われる必要がある。なぜならば、そのようにすることは、これらのオブジェクトを潜在的な攻撃者にさらすからである。

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

ネットワークリソースへのアクセスは、「そのリソースが、それらにアクセスすることを試みているコンテンツと同一源泉中にあるか否か?」に依存して多様となる。

一般に、別の源泉から情報を読み出すことは禁止されている。しかし、ある源泉には、他の源泉から取得したある種のリソースを使うことが許容されている。例えば、ある源泉には、スクリプトを実行し、画像を描写し、あらゆる源泉からのスタイルシートを適用することが許容されている。同様に、ある源泉には、HTML フレーム中に HTML ファイルの内容のような別の源泉からのコンテンツを表示できる。ネットワークリソースは、例えば、CORS(Cross-Origin Resource Sharing)[CORS] を使って、他の源泉にネットワークの情報を読ませる選択もできる。これらの場合、典型的には、アクセスは源泉ごとに許容される。

情報を別の源泉宛に送ることは、許可されている。しかし、情報を任意のフォーマットでネットワーク越しに送ることは、危険である。したがって、ユーザエージェントは、document が (カスタムヘッダー無しの HTTP request 内のような)特定のプロトコルを使って情報を送ることを制約する。(例えば、WebSocket のサポートを追加することによって)許容されるプロトコルの集合を拡張することは、脆弱性を招くこと [RFC6455] を避けるために、注意深く行われなければならない。

3.4.3. 思わぬ脆弱性 English

ユーザエージェントが「ある源泉が別の源泉からのリソースと相互作用すること」を許可するときには常に、それらはセキュリティ問題を招く。例えば、別の源泉からの画像を表示する能力は、それらの高さ(height)と幅(width)を漏らす。同様に、ネットワークリクエストを別の源泉宛に送る能力は、「リクエスト強要(CSRF)」攻撃に対する脆弱性 [CSRF] の懸念を高める。しかし、ユーザエージェント実装者は、しばしば、これらのリスクを他源泉との相互作用を許容することの便益に照らしてバランスをとる。例えば、他源泉ネットワークリクエストをブロックした HTML ユーザエージェントは、そのユーザが(Web の核心的な機能である)ハイパーリンクをたどることをできなくしてしまう。

新しい機能を Web プラットフォームに加えるとき、これが、あるリソースに対する特権を与えつつ、同一源泉内の別のリソースからのその特権は留保することを試みているものでありうる。しかし、このやり方で特権を留保することは非効率である。なぜならば、特権をもたないリソースは、通常、ユーザエージェントがひとつの源泉内のリソースを絶縁しないので、結局、特権を得ることができてしまうからである。代わりに、特権は、許容されるか、あるいは、(ある源泉内の個々のリソースを識別する(discriminating)のではなく)源泉ごとまるごと留保される必要がある [BOFGO]。

3.5. 結論 English

「同一源泉ポリシー(Same-Origin Policy)」は、信頼していることを指定するために URI を使う。URI は、保護ドメインを表現する「源泉(origin)」にまとめられる。「源泉」中のリソース(例: 動的(active)コンテンツ)には、その源泉中の他のリソース(例: 待ち受ける(passive)コンテンツ)が、その源泉の権能(authority)を許容していないにもかかわらず、その源泉の全権能(authority)を与えられるものがある。その源泉の権能(authority)を運ぶコンテンツは、自身の源泉内のオブジェクトやネットワークリソースに対するアクセス権能が与えられる。このコンテンツは、他の源泉のオブジェクトやネットワークリソースに対して制限されたアクセスも許容されているが、セキュリティ脆弱性を避けるために、そのような他源泉特権は注意深く設計されなければならない。

4. ある URI の源泉(データ) English

与えられた URI の源泉は、下記のアルゴリズムによって計算される。:

  1. URI が命名機関([RFC3986] の 3.2 節を参照)として階層的要素を使わない場合、あるいは、その URI が絶対(absolute)URI でない場合、新鮮なグローバルに一意な識別子を生成し、その値を返す。

    注: 同一の URI について、このアルゴリズムを複数回、走らせると、毎回、異なる値を創り出す可能性がある。典型的には、ユーザエージェントは、1 回のみ、例えば、ある HTML ファイルの内容の源泉を計算し、毎回、再計算することなく、以降のセキュリティチェックのために、その源泉を使う。

  2. uri スキームを小文字(lowercase)に変換された、その URI のスキームコンポーネントとなるようにする。

  3. その実装が uri スキームによって与えられるプロトコルをサポートしていない場合、新鮮なグローバルに一意な識別子を生成し、その値を返す。

  4. uri スキームが "file" である場合、その実装は、実装が定義した値を返すことができる(MAY)

    注: 経緯上、ユーザエージェントは、file スキームからのコンテンツに対して、途方もない特権を許容してきた。しかし、すべてのローカルファイルに、そのような広い特権を許容することは、特権昇格(escalation)攻撃をもたらす懸念がある。ユーザエージェントには、ローカルファイルにディレクトリに基づく特権を許容することに成功したことがあるものがあるが、このアプローチは、広くは採用されていない。他のユーザエージェントは、各 file URI についてグローバルに一意な識別子を使う。これは、最もセキュアなオプションである。

  5. 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 節を参照。

  6. URI の port コンポーネントが無い場合:

  7. 1. uri-port を uri-schime によって与えられたプロトコルについてのデフォルトポートとなるようにする。

    さもなくば:

    2. uri-port を、その URI のポートコンポーネントとなるようにする。

  8. トリプル(triple: uri-schime と uri-host と uri-port)を返す。

5. 源泉(データ)を比較する English

ふたつの源泉が同値である場合、そして、この場合に限って、それらは「同一」である。特に:

ふたつの URI は、それらの源泉が同一である場合、同一源泉である。

注: URI 自体は、必ずしも同一源泉ではない。例えば、data URI [RFC2397] 自体は、同一源泉ではない。なぜならば、data URI は、サーバに基づく命名機関を使わず、それゆえ、源泉としてグローバルに一意な識別子をもつからである。

6. 源泉(データ)をシリアライズする English

本章では「どのように源泉(データ)を unicode [Unicode6] 文字列にシリアライズするか?」と、「どのように源泉(データ)を ASCII [RFC20] 文字列にシリアライズするか?」を規定する。

6.1. 源泉(データ)の Unicode シリアライズ English

源泉(データ)の Unicode シリアライズは、下記のアルゴリズムによって返される値である。:

  1. 源泉が「スキーム・ホスト・ポート」のトリプルでない場合、下記の文字列を返す。

      null

    (すなわち、文字「U+006E, U+0075, U+006C, U+006C」)
    そして、これらのステップを中止する。

  2. さもなくば、result をその源泉トリプルのスキーム部分となるようにする。

  3. 文字列 "://" を result に追記する。

  4. (下記のように変換される)源泉トリプルのホスト部分の各コンポーネントを、句点文字(".":「U+002E」)によって区切られた result に追記する。:

    1. そのコンポーネントが A-label である場合、代わりに対応する U-label ([RFC5890] および [RFC5891] を参照)を使う。

    2. さもなくば、コンポーネント verbatim を使う。

  5. 源泉トリプルのポート部分が、その源泉トリプルのスキーム部分によって与えられたプロトコルについてのデフォルト(default)ポートと異なる場合:

    1. コロン文字(":": U+003A)と、与えられポートを 10進数で result に追記する。

  6. result を返す。

6.2. 源泉(データ)の ASCII シリアライズ English

源泉(データ)の ascii シリアライズは、下記のアルゴリズムによって返される値である。:

  1. 源泉が「スキーム・ホスト・ポート」のトリプルでない場合、下記の文字列を返す。

     null

    (すなわち、文字「U+006E, U+0075, U+006C, U+006C」)
    そして、これらのステップを中止する。

  2. さもなくば、result をその源泉トリプルのスキーム部分にする。

  3. 文字列 "://" を result に追記する。

  4. 源泉トリプルのホスト部分を result に追記する。

    源泉トリプルのポート部分が、その源泉トリプルのスキーム部分によって与えられたプロトコルについてのデフォルト(default)ポートと異なる場合:

    1. コロン文字(":": U+003A)と、与えられたポートを 10進数で result に追記する。

  5. result を返す。

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

本章では HTTP Origin ヘッダーフィールドを規定する。

7.1. 構文 English

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

7.2. 意味論 English

HTTP request 中に含められるとき、Origin ヘッダーフィールドは、ユーザエージェントに(そのユーザエージェントが request を発行するように引き金を引いた API によって定義されているように、)その request を発行させた源泉を表示する。

例として、源泉の代わりにスクリプトを実行するユーザエージェントを検討する。それらのスクリプトのひとつが、そのユーザエージェントに HTTP request を発行させる場合、ユーザエージェントは、そのサーバに、そのセキュリティコンテキストを知らせるために、Origin ヘッダーフィールドを使うことができる(MAY)。セキュリティコンテキストの中で、そのスクリプトは、それがユーザエージェントに、その request の発行もたらしていたとき、実行していたものである。

場合によっては、数多くの源泉が、ユーザエージェントに HTTP request を発行させることに貢献する。それらの場合、ユーザエージェントは、Origin ヘッダーフィールド中にすべての源泉を掲げることができる(MAY)。例えば、HTTP request が当初、ある源泉によって発行されていたが、後で別の源泉によってリダイレクトされていた場合、そのユーザエージェントは、サーバに「ふたつの源泉が、そのユーザエージェントに request を発行させる際に巻き込まれていたこと」を知らせることができる(MAY)

7.3. ユーザエージェントの要件 English

ユーザエージェントは、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)。:

8. セキュリティについての考慮事項 English

「同一源泉ポリシー」は、(Web ブラウザを含めた)多くのユーザエージェントにとってはセキュリティの基礎(cornerstone)のひとつである。経緯上、ユーザエージェントには、「けがれ(taint)追跡」や「不正転送防止(exfiltration prevention)」を含めて、他のセキュリティモデルを試みたものがある。(最近になって、これらのアイディアのいくつかを再現させる関心がもたれているが、)当時は、それらのモデルを実装するのは困難と判定された。

「同一源泉ポリシー」のセキュリティを評価することは難しい。なぜならば、「同一源泉ポリシー」自体がセキュリティの観点としてコントロールする側の役割を果たすからである。観念的な「源泉」自体は単なる絶縁するための括りであり、多くの「ワンサイズお仕着せ」な観念と同様に完璧なものではない。つまり、以降で検討されるように、いくつかのシステム全体に影響する(systemic)弱点があるということである。

8.1. DNS への依存 English

実際には、同一源泉ポリシーは、セキュリティのために DNS(Domain Name System)に依存する。なぜならば、(http のような)多くの卑近に使われている URI スキームは、DNS に基づく命名機関を使うからである。その DNS が部分的に、あるいは完全に侵された場合、同一源泉ポリシーは、アプリケーションによって要求されたセキュリティ特性を提供することに失敗する懸念がある。

(https のような)URI スキームには、DNS 侵害に対して、より耐性をもつものがある。なぜならば、ユーザエージェントは、これらの URI から取得したコンテンツの源泉を検証するために、証明書のような他のメカニズムを採用しているからである。「chrome 拡張 URI スキーム([CRX] の 4.3 節を参照)」のような他の URI スキームは、公開鍵に基づく命名機関を使っており、DNS の侵害に対して完全にセキュアである。

「The Web における源泉概念」は、異なる URI スキームから取得されたコンテンツを絶縁する。これは、DNS 侵害の影響を封じ込めるために肝要である。

8.2. 絶縁する分岐の括り English

これまで、絶縁に都合の良い括り(unit)として、数多くの技術が、この「The Web における源泉概念」に収斂してきた。

しかし、(cookie [RFC6265] のように)今日、使われている多くの技術は、現在の「The Web における源泉概念」よりも前からある。しばしば、これらの技術は異なる絶縁の括りをもち、脆弱性をもたらす。

ひとつの代替案は、絶縁の括りとして完全修飾されたドメイン名ではなく、"registry-controlled" ドメインのみを使うことである(例: "www.example.com" の代わりに "example.com")。この実践は、数多くの理由で問題があり、推奨されない(NOT RECOMMENDED)。:

  1. "registry-controlled" ドメインの観念は、DNS 自体のプロパティというよりは、DNS をとりまく人間の実践の役割である。例えば、日本にある多くの市町村は、公衆(public)レジストリを DNS 階層において極めて深い階層で運用されている。広く使われている "public suffix lists"があるが、これらのリストは、最新に保つのが困難であり、実装間で多様となってしまう。

  2. この原則は、DNS に基づく命名機関を使わない URI スキームと互換性が無い。例えば、与えられた URI スキームが公開鍵を命名機関として使う場合、"registry-controlled" 公開鍵の観念は、あまり一貫性がないものである。さらに悪いものとして、(nntp のような)URI スキームには、DNS とは逆方向のドットで区切る委任関係(delegation)を使うもの(例: alt.usenet.kooks)があり、DNS を使うが 通常とは逆順にラベルを表現するもの(例: com.example.www)もある。

所詮、"registry-controlled" ドメインの利用は URI スキームであり、 実装固有である。最悪の場合、URI スキームと実装の間の相違は脆弱性をもたらす懸念がある。

8.3. 場が与える権能 English

「同一源泉ポリシー」を使うとき、ユーザエージェントは、「どのオブジェクトを、そのコンテンツが指定できるか?」に基づくのではなく、その URI に基づいてコンテンツに対する権能(authority)を与える。このような権能(authority)を指定することからの解放は、「ambient な権能」(アクセス制御用語:「場」が与える権能)の一例であり、脆弱性につながりかねない。

例として、HTML ファイルの内容へのスクリプト注入(XSS)について検討する。攻撃者がスクリプトを HTML ファイルのコンテンツに注入できる場合、それらのスクリプトは、そのコンテンツの源泉の権能(authority)で動作してしまい、おそらく、そのスクリプトが(ユーザの医療記録のような)取扱に注意を要する情報にアクセスできるようにしてしまう。しかし、もし、そのスクリプトの権能(authority)が、そのスクリプトが指定できるオブジェクトに制限されていたら、攻撃者がそのスクリプトを第三者によってホストされている HTML ファイルのコンテンツに注入したところで、いかなる優位性も得ることはないであろう。

8.4. IDNA 依存性と移行 English

「同一源泉ポリシー」のセキュリティ特性は、ユーザエージェントによって採用されている IDNA アルゴリズムの細部に重大に依存しうる。特に、ユーザエージェントは、「そのユーザエージェントが IDNA2003 [RFC3490] と IDNA2008 [RFC5890] のどちらを使っているか?」に依拠して、何らかの国際化ドメイン名(例えば、U+00DF 文字を巻き込むもの)を異なる ASCII 表現に対応づける可能性がある。

ある IDNA アルゴリズムから別のものに移行することは、数多くのセキュリティ境界を引き直す懸念があり、潜在的には新しいセキュリティ境界を立ててしまう懸念がある。あるいは、より悪いことに、相互に信頼関係が無いふたつの主体間のセキュリティ境界を取り壊してしまう懸念がある。セキュリティ境界を変更することはリスクを伴う。なぜならば、相互に信頼していないふたつの主体を同一源泉中に束ねることには、一方をして他方を攻撃することを許す懸念があるからである。

 

9. IANA に関する考慮事項 English

パーマネントメッセージヘッダーフィールドのレジストリ([RFC3864] 参照)は、下記の登録内容に更新されている。:

Header field name: Origin

Applicable protocol: http

Status: standard

Author/Change controller: IETF

Specification document: this specification (7 章)

10. 参考文献

10.1. 規範的参考文献

[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/>.

10.2. 参考資料

[BOFGO] Jackson, C. and A. Barth, "Beware of Finer-Grained Origins", 2008年,
<http://w2spconf.com/2008/papers/s2p1.pdf>.
[CORS]

van Kesteren, A., "Cross-Origin Resource Sharing", W3C Working Draft WD-cors-20100727, 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月.
(訳注: その後、中止された。)

 

補遺 A. 謝辞

我々は、本書について有用なフィードバックをしてくださった 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