この質問は、クロスサイトリクエストフォージェリ攻撃からの保護のみに関するものです。
具体的には、Origin ヘッダー (CORS) による保護は、CSRF トークンによる保護と同じくらい優れているかということです。
例：
- Alice はブラウザで (Cookie を使用して) にログインしています
https://example.com。彼女は最新のブラウザを使用していると想定しています。 - Alice が を訪問し
https://evil.example、evil.example のクライアント側コードが に何らかのリクエストを実行しますhttps://example.com(典型的な CSRF シナリオ)。
それで：
- Origin ヘッダー (サーバー側) をチェックせず、CSRF トークンもない場合は、CSRF セキュリティ ホールが発生します。
- CSRF トークンをチェックすれば安全です (ただし、少し面倒です)。
- Origin ヘッダーをチェックすると、evil.example のクライアント側コードからのリクエストは、CSRF トークンを使用する場合と同じようにブロックされるはずです。ただし、evil.example のコードが何らかの方法で Origin ヘッダーを設定できる場合は除きます。
これはXHRでは不可能だということは分かっています（例えばクロスオリジンリソース共有のセキュリティ)、少なくとも、W3C 仕様がすべての最新ブラウザで正しく実装されていると信頼できるのであれば、そうではありません (できるでしょうか?)
しかし、他の種類のリクエストはどうでしょうか。たとえば、フォームの送信でしょうか。script/img/... タグの読み込みでしょうか。あるいは、ページが (合法的に) リクエストを作成するために使用できる他の方法でしょうか。あるいは、既知の JS ハックでしょうか。
注: 私が話しているのは
- ネイティブアプリケーション、
- 操作されたブラウザ、
- example.com のページのクロスサイトスクリプティングバグ、
- ...
ベストアンサー1
これは XHR では不可能であるはずです (例: クロスオリジン リソース共有のセキュリティを参照)。少なくとも、W3C 仕様がすべての最新ブラウザーで正しく実装されていると信頼できる場合は不可能です (信頼できるでしょうか?)。
結局のところ、クライアントブラウザがユーザーのデータを安全に保存し、クライアント側のセッションを保護することを「信頼」する必要があります。クライアントブラウザを信頼できない場合は、静的コンテンツ以外のWebの使用を一切やめてください。CSRFトークンを使用しても、クライアントブラウザがCSRFトークンに正しく従うことを信頼していることになります。同一起源ポリシー。
これまでにもブラウザの脆弱性は存在していたが、IE5.5/6.0 の場合攻撃者が同一生成元ポリシーを回避して攻撃を実行できる場合、通常は発見次第パッチが適用され、ほとんどのブラウザが自動的に更新されるため、このリスクはほぼ軽減されます。
しかし、他の種類のリクエストはどうでしょうか。たとえば、フォームの送信でしょうか。script/img/... タグの読み込みでしょうか。あるいは、ページが (合法的に) リクエストを作成するために使用できる他の方法でしょうか。あるいは、既知の JS ハックでしょうか。
ヘッダーOriginは通常、XHR クロスドメイン リクエストに対してのみ送信されます。イメージ リクエストにはヘッダーは含まれません。
注: 私が話しているのは
ネイティブアプリケーション、
操作されたブラウザ、
example.com のページのクロスサイトスクリプティングバグ、
これがブラウザ操作に該当するかどうかは分かりませんが、古いバージョンのFlash任意のヘッダーを設定できるようになり、攻撃者がreferer被害者のマシンから偽装したヘッダーを含むリクエストを送信して攻撃を実行できるようになりました。