8. Security Considerations (セキュリティに関する考察)

同一生成元ポリシー (same-origin policy) は, Webブラウザを含む多くのユーザーエージェントのセキュリティの基礎の1つです。歴史的に, 一部のユーザーエージェントは, 汚染追跡 (taint tracking) や流出防止 (exfiltration prevention) を含む他のセキュリティモデルを試みましたが, これらのモデルは当時実装が困難であることが証明されました (ただし, 最近これらのアイデアの一部を復活させることに関心が再び高まっています)。

同一生成元ポリシーのセキュリティを評価することは困難です。なぜなら, 生成元 (origin) 概念自体がセキュリティ環境において非常に中心的な役割を果たしているからです。概念的な生成元自体は単なる分離単位 (unit of isolation) であり, ほとんどの「万能 (one-size-fits-all)」概念と同様に不完全です。とはいえ, 以下で説明するいくつかの体系的な弱点があります。

8.1 Reliance on DNS (DNSへの依存)

実際には, 同一生成元ポリシーはセキュリティのためにドメインネームシステム (Domain Name System, DNS) に依存しています。なぜなら, httpなどの一般的に使用されるURIスキーム (scheme) は, DNSベースの命名権限 (naming authority) を使用するからです。DNSが部分的または完全に侵害された場合, 同一生成元ポリシーはアプリケーションが必要とするセキュリティプロパティを提供できない可能性があります。

httpsなどの一部のURIスキームは, ユーザーエージェントが証明書 (certificate) などの他のメカニズムを使用してこれらのURIから取得されたコンテンツのソースを検証するため, DNS侵害に対してより耐性があります。chrome-extension URIスキーム ([CRX]のセクション4.3を参照) などの他のURIスキームは, 公開鍵ベースの命名権限を使用し, DNS侵害に対して完全に安全です。

Web生成元 (web origin) 概念は, 異なるURIスキームから取得されたコンテンツを分離します; これはDNS侵害の影響を封じ込めるために不可欠です。

8.2 Divergent Units of Isolation (異なる分離単位)

時間の経過とともに, 多くの技術がWeb生成元概念を便利な分離単位として収束してきました。しかし, Cookie [RFC6265] など今日使用されている多くの技術は, 現代のWeb生成元概念よりも前のものです。これらの技術は多くの場合異なる分離単位を持ち, 脆弱性につながります。

1つの代替案は, 完全修飾ドメイン名 (fully qualified domain name) ではなく「レジストリ制御 (registry-controlled)」ドメインのみを分離単位として使用することです (例えば, "www.example.com" ではなく "example.com")。この慣行はいくつかの理由で問題があり, 推奨されません (NOT RECOMMENDED):

「レジストリ制御」ドメインの概念は, DNS自体のプロパティではなく, DNSを取り巻く人間の実践の関数です。例えば, 日本の多くの自治体は, DNS階層の非常に深いところで公共レジストリを運営しています。広く使用されている「公開サフィックスリスト (public suffix list)」がありますが, これらのリストは最新に保つことが困難であり, 実装間で異なります。
この慣行は, DNSベースの命名権限を使用しないURIスキームと互換性がありません。例えば, 特定のURIスキームが命名権限として公開鍵を使用する場合, 「レジストリ制御」公開鍵の概念は多少一貫性がありません。さらに悪いことに, nntpなどの一部のURIスキームは, DNSとは逆方向のドット区切り委譲 (dotted delegation) を使用し (例えば, alt.usenet.kooks), 他のスキームはDNSを使用しますが, 通常とは逆の順序でラベルを提示します (例えば, com.example.www)。

せいぜい, 「レジストリ制御」ドメインの使用は, URIスキームと実装固有です。最悪の場合, URIスキームと実装の違いが脆弱性につながる可能性があります。

8.3 Ambient Authority (環境権限)

同一生成元ポリシーを使用する場合, ユーザーエージェントは, コンテンツが指定できるオブジェクトに基づいてではなく, コンテンツのURIに基づいてコンテンツに権限 (authority) を付与します。この指定 (designation) と権限の分離は, 環境権限 (ambient authority) の例であり, 脆弱性につながる可能性があります。

例えば, HTMLドキュメントでのクロスサイトスクリプティング (cross-site scripting) を考えてみましょう。攻撃者がスクリプトコンテンツをHTMLドキュメントに注入できる場合, これらのスクリプトはドキュメントの生成元 (origin) の権限で実行され, おそらくスクリプトがユーザーの医療記録などの機密情報にアクセスできるようになります。ただし, スクリプトの権限がスクリプトが指定できるオブジェクトのみに制限されている場合, 攻撃者は第三者がホストするHTMLドキュメントにスクリプトを注入しても利点を得られません。

8.4 IDNA Dependency and Migration (IDNA依存と移行)

同一生成元ポリシーのセキュリティプロパティは, ユーザーエージェントが採用するIDNAアルゴリズムの詳細に決定的に依存する可能性があります。特に, ユーザーエージェントは, ユーザーエージェントがIDNA2003 [RFC3490] を使用するかIDNA2008 [RFC5890] を使用するかによって, 一部の国際化ドメイン名 (international domain name) (例えば, U+00DF文字を含むもの) を異なるASCII表現にマップする可能性があります。

あるIDNAアルゴリズムから別のアルゴリズムに移行すると, 多くのセキュリティ境界が再描画される可能性があり, 新しいセキュリティ境界が構築されるか, さらに悪いことに, 相互に信頼していない2つのエンティティ間のセキュリティ境界が取り壊される可能性があります。セキュリティ境界を変更することは危険です。なぜなら, 相互に信頼していない2つのエンティティを同じ生成元に結合すると, 一方が他方を攻撃できるようになる可能性があるからです。