|
Internet Engineering Task Force (IETF) Request for Comments： 6454 分類： スタンダードトラック ISSN: 2070-1721 |
A. Barth Google, Inc. 2011年12月 |
本書は、「源泉(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に記述されているように保証なしで提供されなければならない。
ユーザエージェント(UA；ブラウザ)は、 大勢の開発者によって制作されたコンテンツと相互作用を行う。 それらの開発者の多くは善意であるが、 開発者には悪者もいる懸念がある。 ユーザエージェントの実装者は、 ユーザエージェントが処理するコンテンツに基づく作用の範囲内で、 他のコンテンツ(もしくはサーバ)の守秘性もしくはインテグリティを損なうような悪意ある開発者の能力を制限することを望む可能性がある。
例として、多様なサーバから取得したHTMLコンテンツを表示するHTTPユーザエージェントを検討する。 ユーザエージェントが、 それらの文書内に格納されたスクリプトを実行する場合、 そのユーザエージェントの実装者は、 悪意あるサーバから取得したスクリプトが正直なサーバ上に保存されたファイルの内容を読むことを防ぐことを望む可能性がある。 この正直なサーバは、例えば、ファイアウォールの背後にある可能性がある。
従来、ユーザエージェントは、 コンテンツをその「源泉(origin)」の違いによって仕分けてきた。 より具体的に述べると、ユーザエージェントは、 ある源泉から取得したコンテンツには、 その源泉から取得された他のコンテンツと自由に相互作用することを許可するが、 ユーザエージェントは、「どのように、 そのコンテンツが他源泉からのコンテンツと相互作用できるか？」を制約する。
本書は、 源泉(のデータ)を比較してシリアライズすることについての基本的な事項のみならず、 いわゆる「同一源泉ポリシー(Same-Origin Policy)」の背後にある原則についてもも記述する。 本書は、「同一源泉ポリシー」のすべての側面の詳細までは記述していない。 これらは、(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 ユーザエージェントは、 遠隔サーバからの命令であるリダイレクトを伴い、 HTMLユーザエージェントは、リッチな DOM (Document Object Model)インターフェイスを遠隔サーバから取得したスクリプトに露出する。
セキュリティモデルがまったく搭載されていないとしたら、 ユーザエージェントは、 ユーザ(あるいは他の主体)に対して有害な作用を行う懸念がある。 時間の経過とともに、 多くのWeb関連技術が共通認識されるセキュリティモデルに収斂してきた。 いわゆる「同一源泉ポリシー」として知られているものである。 「同一源泉ポリシー」は大いに有機的に進展しているが、 このセキュリティモデルは「ひと握りの鍵となる概念」を通じて理解可能なものである。 本章は、それらの概念を提示し、「どのように、 これらの概念をセキュアに使うか？」についてのアドバイスを提供する。
「同一源泉ポリシー」は、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)を信頼すること」を宣言している。
「同一源泉ポリシー」を使う新しいプロトコルを設計するとき、 「重要な信頼度の区別がURI中に可視であること」を確保する。 例えば、TLS (Transport Layer Security)防護リソースと、 非TLS防護リソースの両方ともが、 ([RFC2817]にあるように) "http" URIスキームを使う場合、 documentが「TLS越しにのみ、 スクリプトを取得することを望むこと」を仕様として示さない。 "https" URIスキームを使うことによって、 documentは「積極的(active)なネットワーク攻撃者から保護されているリソースと相互作用することを望むこと」を示すことができる。
原則として、ユーザエージェントは、 すべての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)は、「どのように、 このセキュリティモデルが進展してきたか？」の経緯上の産物である。
下記のリソースのすべては、同一の源泉をもつ。：
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ファイルの内容(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)」として卑近に知られている脆弱性である。
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] からである。
一般に、ユーザエージェントは、異なる源泉同士を絶縁しつつ、 コントロールされた源泉間の通信は許容するものである。 「どのようにユーザエージェントが絶縁機能と通信機能を提供するか？」の詳細は、 いくつかの要因に起因して多様となる。
ユーザエージェントによって露出される大部分の(「API (Application Prognamming Interface)」として知られる)オブジェクトは、 同一源泉宛にのみ利用できる。 具体的には、あるURIから取得されたコンテンツは、 そのふたつのURIが同一源泉に属する(例：同一のスキーム、 ホストおよびポートをもつ)場合、そしてこの場合のみ、 別のURIから取得したコンテンツと関連するオブジェクトにアクセスできる。
この一般ルールに対するいくつかの例外がある。 例えば、HTMLのLocationインターフェイスの部分には、 (例えば、 他の閲覧コンテキストにページ遷移(navigate)することを許すために) 源泉を跨いで利用可能なものがある。 別の例として、HTMLのpostMessageインターフェイスは、 他源泉との(cross-origin)通信を容易にするために、 源泉を跨いで明示的に(explicitly)見ることができる。 オブジェクトを外部の源泉にさらすことは危険であり、 大いに注意を払うことを条件に行われる必要がある。 なぜならば、そのようにすることは、 これらのオブジェクトを潜在的な攻撃者にさらすからである。
ネットワークリソースへのアクセスは、「そのリソースが、 それらにアクセスすることを試みているコンテンツと同一源泉中にあるか否か？」に依存して多様となる。
一般に、別の源泉から情報を読み出すことは禁止されている。 しかし、ある源泉には、 他の源泉から取得したある種のリソースを使うことが許容されている。 例えば、ある源泉には、スクリプトを実行し、画像を描写し、 あらゆる源泉からのスタイルシートを適用することが許容されている。 同様に、ある源泉には、 HTMLフレーム中にHTMLファイルの内容のような別の源泉からのコンテンツを表示できる。 ネットワークリソースは、例えば、CORS (Cross-Origin Resource Sharing)[CORS] を使って、 他の源泉にネットワークの情報を読ませる選択もできる。 これらの場合、典型的には、アクセスは源泉ごとに許容される。
情報を別の源泉宛に送ることは、許可されている。 しかし、情報を任意のフォーマットでネットワーク越しに送ることは、 危険である。 したがって、ユーザエージェントは、 documentが(カスタムヘッダー無しのHTTP request内のような)特定のプロトコルを使って情報を送ることを制約する。 (例えば、WebSocketのサポートを追加することによって) 許容されるプロトコルの集合を拡張することは、 脆弱性を招くこと [RFC6455] を避けるために、注意深く行われなければならない。
ユーザエージェントが「ある源泉が別の源泉からのリソースと相互作用すること」を許可するときには常に、 それらはセキュリティ問題を招く。 例えば、別の源泉からの画像を表示する能力は、 それらの高さ(height)と幅(width)を漏らす。 同様に、ネットワークリクエストを別の源泉宛に送る能力は、 「リクエスト強要(CSRF)」攻撃に対する脆弱性 [CSRF] の懸念を高める。 しかし、ユーザエージェント実装者は、しばしば、 これらのリスクを他源泉との相互作用を許容することの便益に照らしてバランスをとる。 例えば、 他源泉ネットワークリクエストをブロックしたHTMLユーザエージェントは、 そのユーザが (Webの核心的な機能である) ハイパーリンクをたどることをできなくしてしまう。
新しい機能をWebプラットフォームに加えるとき、これが、 あるリソースに対する特権を与えつつ、 同一源泉内の別のリソースからのその特権は留保することを試みているものでありうる。 しかし、このやり方で特権を留保することは非効率である。 なぜならば、特権をもたないリソースは、通常、 ユーザエージェントがひとつの源泉内のリソースを絶縁しないので、結局、 特権を得ることができてしまうからである。 代わりに、特権は、許容されるか、あるいは、 (ある源泉内の個々のリソースを識別する(discriminating)のではなく) 源泉ごとまるごと留保される必要がある [BOFGO]。
「同一源泉ポリシー(Same-Origin Policy)」は、 信頼していることを指定するためにURIを使う。 URIは、保護ドメインを表現する「源泉(origin)」にまとめられる。 「源泉」中のリソース(例：動的(active)コンテンツ)には、 その源泉中の他のリソース(例：待ち受ける(passive)コンテンツ)が、 その源泉の権能(authority)を許容していないにもかかわらず、 その源泉の全権能(authority)を与えられるものがある。 その源泉の権能(authority)を運ぶコンテンツは、 自身の源泉内のオブジェクトやネットワークリソースに対するアクセス権能が与えられる。 このコンテンツは、 他の源泉のオブジェクトやネットワークリソースに対して制限されたアクセスも許容されているが、 セキュリティ脆弱性を避けるために、 そのような他源泉特権は注意深く設計されなければならない。
与えられたURIの源泉は、下記のアルゴリズムによって計算される。：
1. uri-portをuri-schimeによって与えられたプロトコルについてのデフォルトポートとなるようにする。
さもなくば：
2. uri-port を、その URI のポートコンポーネントとなるようにする。
ふたつの源泉が同値である場合、そして、この場合に限って、 それらは「同一」である。特に：
ふたつのURIは、それらの源泉が同一である場合、同一源泉である。
注：URI自体は、必ずしも同一源泉ではない。 例えば、data URI [RFC2397] 自体は、 同一源泉ではない。 なぜならば、data URIは、サーバに基づく命名機関を使わず、 それゆえ、源泉としてグローバルに一意な識別子をもつからである。
本章では「どのように源泉(データ)をunicode [Unicode6] 文字列にシリアライズするか？」と、 「どのように源泉(データ)をASCII [RFC20] 文字列にシリアライズするか？」を規定する。
源泉(データ)のUnicodeシリアライズは、 下記のアルゴリズムによって返される値である。：
源泉(データ)のasciiシリアライズは、 下記のアルゴリズムによって返される値である。：
本章では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を発行させた源泉を表示する。
例として、 源泉の代わりにスクリプトを実行するユーザエージェントを検討する。 それらのスクリプトのひとつが、そのユーザエージェントにHTTP requestを発行させる場合、ユーザエージェントは、そのサーバに、 そのセキュリティコンテキストを知らせるために、 Originヘッダーフィールドを使うことができる(MAY)。 セキュリティコンテキストの中で、そのスクリプトは、 それがユーザエージェントに、その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)。：
「同一源泉ポリシー」は、 (Web ブラウザを含めた)多くのユーザエージェントにとってはセキュリティの基礎(cornerstone)のひとつである。 経緯上、ユーザエージェントには、 「けがれ(taint)追跡」や「不正転送防止(exfiltration prevention)」を含めて、 他のセキュリティモデルを試みたものがある。 (最近になって、 これらのアイディアのいくつかを再現させる関心がもたれているが、)当時は、 それらのモデルを実装するのは困難と判定された。
「同一源泉ポリシー」のセキュリティを評価することは難しい。 なぜならば、 「同一源泉ポリシー」自体がセキュリティの観点としてコントロールする側の役割を果たすからである。 観念的な「源泉」自体は単なる絶縁するための括りであり、 多くの「ワンサイズお仕着せ」な観念と同様に完璧なものではない。 つまり、以降で検討されるように、 いくつかのシステム全体に影響する(systemic)弱点があるということである。
実際には、同一源泉ポリシーは、 セキュリティのためにDNS (Domain Name System)に依存する。 なぜならば、(httpのような)多くの卑近に使われているURIスキームは、 DNSに基づく命名機関を使うからである。 そのDNSが部分的に、あるいは完全に侵された場合、同一源泉ポリシーは、 アプリケーションによって要求されたセキュリティ特性を提供することに失敗する懸念がある。
(httpsのような) URIスキームには、DNS侵害に対して、 より耐性をもつものがある。 なぜならば、ユーザエージェントは、 これらのURIから取得したコンテンツの源泉を検証するために、 証明書のような他のメカニズムを採用しているからである。 「chrome拡張URIスキーム([CRX] の4.3節を参照)」のような他のURIスキームは、 公開鍵に基づく命名機関を使っており、 DNSの侵害に対して完全にセキュアである。
「The Webにおける源泉概念」は、 異なるURIスキームから取得されたコンテンツを絶縁する。 これは、DNS侵害の影響を封じ込めるために肝要である。
これまで、絶縁に都合の良い括り(unit)として、数多くの技術が、 この「The Web における源泉概念」に収斂してきた。
しかし、(cookie [RFC6265] のように)今日、 使われている多くの技術は、 現在の「The Webにおける源泉概念」よりも前からある。 しばしば、これらの技術は異なる絶縁の括りをもち、脆弱性をもたらす。
ひとつの代替案は、絶縁の括りとして完全修飾されたドメイン名ではなく、 "registry-controlled"ドメインのみを使うことである (例："www.example.com"の代わりに "example.com")。 この実践は、数多くの理由で問題があり、 推奨されない(NOT RECOMMENDED)。：
所詮、"registry-controlled"ドメインの利用はURIスキームであり、 実装固有である。 最悪の場合、URI スキームと実装の間の相違は脆弱性をもたらす懸念がある。
「同一源泉ポリシー」を使うとき、ユーザエージェントは、 「どのオブジェクトを、そのコンテンツが指定できるか？」に基づくのではなく、 そのURIに基づいてコンテンツに対する権能(authority)を与える。 このような権能(authority)を指定することからの解放は、 「ambientな権能」(アクセス制御用語：「場」が与える権能)の一例であり、 脆弱性につながりかねない。
例として、HTMLファイルの内容へのスクリプト注入(XSS)について検討する。 攻撃者がスクリプトをHTMLファイルのコンテンツに注入できる場合、 それらのスクリプトは、 そのコンテンツの源泉の権能(authority)で動作してしまい、 おそらく、そのスクリプトが(ユーザの医療記録のような)取扱に注意を要する情報にアクセスできるようにしてしまう。 しかし、もし、そのスクリプトの権能(authority)が、 そのスクリプトが指定できるオブジェクトに制限されていたら、 攻撃者がそのスクリプトを第三者によってホストされているHTMLファイルのコンテンツに注入したところで、 いかなる優位性も得ることはないであろう。
「同一源泉ポリシー」のセキュリティ特性は、 ユーザエージェントによって採用されているIDNAアルゴリズムの細部に重大に依存しうる。 特に、ユーザエージェントは、「そのユーザエージェントがIDNA2003 [RFC3490] とIDNA2008 [RFC5890] のどちらを使っているか？」に依拠して、 何らかの国際化ドメイン名 (例えば、U+00DF 文字を巻き込むもの) を異なるASCII表現に対応づける可能性がある。
あるIDNAアルゴリズムから別のものに移行することは、 数多くのセキュリティ境界を引き直す懸念があり、 潜在的には新しいセキュリティ境界を立ててしまう懸念がある。 あるいは、より悪いことに、 相互に信頼関係が無いふたつの主体間のセキュリティ境界を取り壊してしまう懸念がある。 セキュリティ境界を変更することはリスクを伴う。 なぜならば、 相互に信頼していないふたつの主体を同一源泉中に束ねることには、 一方をして他方を攻撃することを許す懸念があるからである。
パーマネントメッセージヘッダーフィールドのレジストリ ([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/>. |
| [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/>. |
| [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