[解決済み] CORS OriginヘッダーとCSRFトークンによるCSRF保護

質問

この質問は、クロスサイトリクエストフォージェリ攻撃からの保護についてのみです。

具体的には、次のようなことです。Originヘッダ（CORS）による保護は、CSRFトークンによる保護と同じくらい良いのでしょうか？

例です。

• アリスはブラウザで"に(クッキーを使って)ログインしている。 https://example.com にログインしています。私は、彼女が最新のブラウザを使用していると仮定しています。
• アリスは " を訪問します。 https://evil.com にアクセスし、evil.com のクライアント側のコードが " への何らかのリクエストを実行します。 https://example.com への何らかのリクエストを実行します (古典的な CSRF シナリオ)。

では

• Originヘッダ（サーバー側）をチェックせず、CSRFトークンもなければ、CSRFのセキュリティホールがあることになります。
• CSRF トークンをチェックすれば安全です (ただし、少し面倒です)。
• Originヘッダーをチェックする場合、evil.comのクライアント側のコードからのリクエストは、CSRFトークンを使用するときと同様にブロックされるはずです - ただし、evil.comのコードがOriginヘッダーを設定することが何らかの形で可能である場合は除きます。

私は、これがXHRで可能であってはならないことを知っています(例えば、次のようなものです。 クロスオリジンリソース共有のためのセキュリティ を参照)、少なくとも、W3C仕様がすべてのモダンブラウザで正しく実装されていることを信じるなら、それはできません(できるでしょうか?)。

しかし、他の種類のリクエストについてはどうでしょうか - たとえば、フォームの送信？script/img/... タグを読み込む？または、ページが (合法的に) リクエストを作成するために使用できる他の方法は何ですか? あるいは、既知のJSハック？

注：私は

• ネイティブ アプリケーションのことです。
• 操作されたブラウザー
• example.com のページにクロス サイト スクリプティングのバグがあります。
• ...

どのように解決するのですか？

これはXHRで可能であってはならないこと（例えば、Security for cross-origin resource sharingを参照）、少なくとも、W3C仕様がすべてのモダンブラウザで正しく実装されていると信じるなら（そうでしょうか）、可能ではないことを知っておいてください。

結局のところ、ユーザーのデータを安全に保存し、セッションのクライアント側を保護するために、クライアント ブラウザを信頼しなければなりません。クライアント ブラウザを信頼できないのであれば、静的なコンテンツ以外では Web を一切使用しないようにすべきです。CSRF トークンを使用する場合でも、クライアント ブラウザが正しく 同一生成元ポリシー .

のようなブラウザの脆弱性は以前からありましたが、今回のような IE 5.5/6.0 などの以前の脆弱性では、攻撃者が同一生成元ポリシーをバイパスして攻撃を実行することが可能でしたが、通常、発見されるとすぐにパッチが適用され、ほとんどのブラウザが自動的に更新されるため、このリスクはほとんど軽減されると予想されます。

しかし、他の種類のリクエストについてはどうでしょうか - たとえば、フォームの送信など? script/img/... タグを読み込むことはできますか? あるいは、ページが (合法的に) リクエストを作成するために使用できる他の方法は? あるいは、既知のJSハック？

その Origin ヘッダは通常 XHR のクロスドメインリクエストに対してのみ送信されます。画像リクエストにはこのヘッダは含まれません。

注意: 私が話しているのは

• ネイティブアプリケーションのことです。

• 操作されたブラウザー。

• example.com のページにクロスサイトスクリプティングのバグがあります。

これが操作されたブラウザに該当するかどうかは分かりませんが 旧バージョンのFlash では任意のヘッダを設定することができ、これにより攻撃者はなりすました referer ヘッダーのリクエストを送信できるようになります。