同一生成元ポリシー

コンピューティングにおいて、同一生成元ポリシー( SOP ) は、Web アプリのアプリケーション セキュリティ モデルの概念です。このポリシーでは、Web ブラウザーは、最初の Web ページに含まれるスクリプトが 2 番目の Web ページのデータにアクセスすることを許可しますが、両方の Web ページの生成元が同じである場合に限ります。生成元は、URI スキーム、ホスト名、およびポート番号の組み合わせとして定義されます。このポリシーは、あるページ上の悪意のあるスクリプトが、そのページの (DOM) を介して別の Web ページ上の機密データにアクセスすることを防止します。

このメカニズムは、認証されたユーザー セッションを維持するために HTTPS Cookie に大きく依存する最新の Web アプリケーションにとって特に重要です。サーバーは HTTP Cookie 情報に基づいて動作し、機密情報を公開したり、状態を変更するアクションを実行したりするためです。データの機密性や整合性が失われないようにするには、無関係なサイトによって提供されるコンテンツをクライアント側で厳密に分離する必要があります。

同一生成元ポリシーはスクリプトにのみ適用されます。つまり、画像、CSS、動的に読み込まれるスクリプトなどのリソースは、対応する HTML タグを介して生成元を越えてアクセスできます (フォントは例外です)。攻撃は、同一生成元ポリシーが HTML タグに適用されないという事実を利用します。

同一生成元ポリシーの概念は、Netscape 2.0でJavaScriptが導入された直後の1995年にNetscape Navigator 2.02で導入されました。[ ^{1 ] [2] [3]} JavaScriptにより、Webページでのスクリプト、特にドキュメントオブジェクトモデル(DOM)へのプログラムによるアクセスが可能になりました。

このポリシーはもともと DOM へのアクセスを保護するために設計されましたが、その後、グローバル JavaScript オブジェクトの機密部分を保護するように拡張されました。

現代のブラウザはすべて、セキュリティの重要な基礎となる同一生成元ポリシーを何らかの形で実装しています。^[4]ポリシーは仕様に厳密に一致する必要はありませんが^{[5] 、} Microsoft Silverlight、Adobe Flash、Adobe Acrobatなどの他のウェブ技術や、 XMLHttpRequestなどの直接的な DOM 操作以外のメカニズムと互換性のあるセキュリティ境界を定義するために拡張されることがよくあります。

URI の「オリジン」を計算するために使用されるアルゴリズムは、RFC 6454 のセクション 4 で指定されています。絶対 URI の場合、オリジンは 3 つの {スキーム、ホスト、ポート} です。URI が命名機関として階層要素を使用していない場合 (RFC 3986 のセクション 3.2 を参照)、または URI が絶対 URI でない場合は、グローバルに一意の識別子が使用されます。これらの値がすべて完全に同じである場合にのみ、2 つのリソースは同じオリジンであると見なされます。

たとえば、次の表は、URL「http://www.example.com/dir/page.html」に対するチェックの一般的な結果の概要を示しています。

他のブラウザとは異なり、Internet Explorerはオリジンの計算にポートを含めず、代わりにセキュリティゾーンを使用します。^[8]

同一オリジン ポリシーは、オリジン間で認証されたセッションを再利用することを防ぎます。次の例は、同一オリジン ポリシーがない場合に発生する可能性のあるセキュリティ リスクを示しています。ユーザーが銀行の Web サイトにアクセスしていて、ログアウトしていないとします。次に、ユーザーは、銀行のサイトからデータを要求する悪意のある JavaScript コードのある別のサイトに移動します。ユーザーは銀行のサイトにまだログインしているため、悪意のあるコードは、ユーザーが銀行のサイトで実行できることをすべて実行できます。たとえば、ユーザーの最後のトランザクションの一覧を取得したり、新しいトランザクションを作成したりできます。これは、World Wide Web の本来の精神に従い、ブラウザーは、銀行サイトのドメインに基づいて、セッション Cookie やプラットフォーム レベルの種類の Authorization 要求ヘッダーなどの認証の詳細を銀行サイトにタグ付けする必要があるためです。

銀行サイトの所有者は、悪意のあるサイトを訪問するユーザーの通常のブラウザが、悪意のあるサイトから読み込まれたコードが銀行のセッション Cookie またはプラットフォーム レベルの認証にアクセスすることを許可しないことを期待します。JavaScript が銀行のセッション Cookie に直接アクセスできないのは事実ですが、銀行サイトのセッション Cookie を使用して銀行サイトへのリクエストを送受信することはできます。同一生成元ポリシーは、セキュリティを重視するブラウザが、生成元全体からの応答への読み取りアクセスを拒否するための要件として導入されました。これは、大多数のユーザーが準拠したブラウザを使用することを前提としています。このポリシーは書き込みを拒否しません。書き込み権限の悪用に対抗するには、ターゲット サイトによる 追加のCSRF保護が必要です。

状況によっては、同一生成元ポリシーの制限が厳しすぎるため、複数のサブドメインを使用する大規模な Web サイトで問題が発生することがあります。最初は、異なるドメインにあるドキュメント間でデータを渡すために、フラグメント識別子やwindow.nameプロパティを使用するなど、いくつかの回避策が使用されていました。最新のブラウザは、制御された方法で同一生成元ポリシーを緩和するための複数の手法をサポートしています。

Netscape Navigator には、汚染チェック機能が短期間含まれていました。この機能は、1997 年に Netscape 3 の一部として試験的に導入されました。^{[9]この機能はデフォルトではオフになっていますが、ユーザーが有効にすると、Web サイトは別のドメインに属するウィンドウや}フレームの JavaScript プロパティを読み取ろうとします。ブラウザは、ユーザーに問題のアクセスを許可するかどうかを尋ねます。^{[10] [11]}

2 つのウィンドウ (またはフレーム) に、ドメインを同じ値に設定するスクリプトが含まれている場合、これら 2 つのウィンドウの同一生成元ポリシーは緩和され、各ウィンドウは相互にやり取りできます。たとえば、orders.example.com と catalog.example.com から読み込まれたドキュメント内の連携スクリプトは、document.domainプロパティを「example.com」に設定し、ドキュメントが同じ生成元を持つように見せかけ、各ドキュメントが他のドキュメントのプロパティを読み取ることができるようにします。このプロパティを設定すると、ポートが暗黙的に null に設定され、ほとんどのブラウザーはポート 80 や指定されていないポートとは異なる解釈をします。ブラウザーによるアクセスを許可するには、両方のページの document.domain プロパティを設定します。^[12]

このコンセプトは1996年にリリースされたNetscape Navigator 3 ^[13]document.domainの一部として導入されました。^[9]

同一生成元ポリシーを緩和するもう 1 つの手法は、Cross-Origin Resource Sharing (CORS) という名前で標準化されています。この標準は、新しい Origin リクエスト ヘッダーと新しい Access-Control-Allow-Origin レスポンス ヘッダーを使用して HTTP を拡張します。^[14]これにより、サーバーはヘッダーを使用して、ファイルを要求する可能性のある生成元を明示的にリストしたり、ワイルドカードを使用して任意のサイトからファイルを要求できるようにしたりできます。Firefox 3.5、Safari 4、Internet Explorer 10 などのブラウザーは、このヘッダーを使用して、同一生成元ポリシーによって禁止されていた XMLHttpRequest によるクロス オリジン HTTP 要求を許可します。

もう 1 つのテクニックであるクロスドキュメント メッセージングでは、スクリプトの出所に関係なく、あるページのスクリプトから別のページのスクリプトにテキスト メッセージを渡すことができます。Window オブジェクトで postMessage() メソッドを呼び出すと、そのウィンドウで「onmessage」イベントが非同期的に発生し、ユーザー定義のイベント ハンドラーがトリガーされます。1 つのページのスクリプトは、他のページのメソッドや変数に直接アクセスすることはできませんが、このメッセージ パッシング テクニックを通じて安全に通信できます。

HTML 要素は他のドメインからコンテンツを取得して実行できるため <script>、ページは JSONP ペイロードを返すリソースを読み込むことで、同一オリジン ポリシーを回避し、別のドメインから JSON データを受け取ることができます。JSONP ペイロードは、事前定義された関数呼び出しでラップされた内部 JSON ペイロードで構成されます。スクリプト リソースがブラウザーによって読み込まれると、指定されたコールバック関数が呼び出され、ラップされた JSON ペイロードが処理されます。

最新のブラウザでは、同一生成元ポリシーを適用せずにスクリプトが WebSocket アドレスに接続することを許可します。ただし、WebSocket URI が使用されていることを認識し、接続を要求しているスクリプトの生成元を示すOrigin:ヘッダーをリクエストに挿入します。クロスサイト セキュリティを確保するため、WebSocket サーバーは、応答の受信が許可されている生成元のホワイトリストとヘッダー データを比較する必要があります。

同一生成元チェックおよび関連メカニズムの動作は、URL ( file:、 data: など) に関連付けられたホスト名またはポートが明確に定義されていない疑似プロトコルなどのいくつかの特殊なケースでは明確に定義されていません。これは歴史的に、ローカルに保存された HTML ファイルがディスク上の他のすべてのファイルにアクセスしたり、インターネット上の任意のサイトと通信したりするといった、一般的に望ましくない機能など、かなりの数のセキュリティ問題を引き起こしてきました。

最後に、DNS 再バインディングやサーバー側プロキシなどの特定の種類の攻撃では、ホスト名のチェックが部分的に破壊され、不正な Web ページが「真の」正規の発信元以外のアドレスを通じてサイトと直接やり取りできるようになります。このような攻撃の影響は、非常に特殊なシナリオに限定されます。ブラウザーは攻撃者のサイトとやり取りしていると認識しているため、サードパーティの Cookie やその他の機密情報を攻撃者に開示しません。

同一オリジンポリシーが有効な場合でも（クロスオリジンリソース共有によって緩和されていない場合）、特定のクロスオリジン攻撃が実行される可能性があります。WebRTCを使用すると、被害者の内部IPアドレスを見つけることができます^[15]。クロスオリジンポートに接続しようとすると、同一オリジンポリシーがあるため応答を読み取ることはできませんが、JavaScriptはonload/onerrorイベントが発生したかどうか、またはタイムアウトが発生したかどうかをチェックすることで、ポートが開いているか閉じているかを推測できます。これにより、クロスオリジンポートスキャンの機会が生まれます。

さらに、JavaScriptスニペットはクロスサイトリーク^[16]などの技術を使用して、ブラウザで長年続いている情報漏洩を悪用し、クロスオリジンの情報を推測することができます。これらの攻撃は、クロスオリジンリソースポリシー（CORP）ヘッダーを実装することで対抗できます。これにより、Webサイトの所有者は、画像、ビデオ、スタイルシートなどのクロスオリジンまたはクロスサイトのリソースをブロックできます。CORPはJavaScriptによって開始されたリクエストもブロックできますが、 ^[17]fetchリクエストモードで送信された場合のみです。^[18]no-cors

同一生成元ポリシーは、ブラウザが GET、OPTIONS、TRACE リクエストを行うことを妨げるものではなく、応答がユーザー コードによって読み取られることを防ぐだけです。したがって、エンドポイントがこれらの「安全な」リクエスト メソッドのいずれかを使用して情報を書き込んだり、ユーザーに代わってアクションを実行したりする場合、攻撃者に悪用される可能性があります。

同一生成元ポリシーは歴史的な理由によりクッキーには適用されないことに注意する必要がある^[19]。SOPに反して、複数の敵対サイトが同じホスト名で異なるポート番号で展開されている場合、いずれかのサイトによって設定されたすべてのクッキーが共有されます。これを利用して、ユーザーのセッショントークンを漏らし、アカウント情報を盗むことができます。したがって、Webサービスはポート番号ではなく サブドメインを区別して分離する必要があります。

• クロスオリジンリソース共有
• クロスサイトスクリプティング
• クロスサイトリクエストフォージェリ
• サイトの分離
• コンテンツセキュリティポリシー

• 500 行以内の同一生成元ポリシー。

• 同一生成元ポリシーのいくつかの種類の詳細な比較
• Wayback Machineにおける同一生成元ポリシーの欠陥と Web セキュリティへの影響に関するレビュー(2007 年 2 月 11 日アーカイブ)
• ベンダー提供の同一生成元ポリシー仕様のサンプル
• HTML5仕様のOriginの定義
• 同一生成元ポリシーに関する W3C の記事
• ウェブオリジンコンセプトに関するRFC 6454
• ブログ投稿: Cookie 同一生成元ポリシー
• コンテンツ セキュリティ ポリシーの wordpress.org プラグイン