この質問は、クロスサイトリクエストフォージェリ攻撃のみに対する保護に関するものです。
具体的には、Originヘッダー(CORS)による保護はCSRFトークンによる保護と同等ですか?
例:
そう:
XHRではこれが不可能であることを知っています(たとえば クロスオリジンリソース共有のセキュリティ を参照)、少なくともすべての最新のブラウザーでW3C仕様が正しく実装されることを信頼する場合(できる私達?)
しかし、他の種類のリクエストについてはどうでしょう-例えばフォーム送信? script/img/...タグを読み込んでいますか?または、ページが(合法的に)リクエストを作成するために使用できる他の方法はありますか?または、既知のJSハックがありますか?
注:私は話していません
xHRではこれが不可能であることを知ってください(たとえば、クロスオリジンリソース共有のセキュリティを参照)。少なくとも、すべての最新のブラウザーでW3C仕様が正しく実装されていると信じている場合は可能です(できますか?)
結局のところ、ユーザーのデータを安全に保存し、セッションのクライアント側を保護するには、クライアントブラウザーを「信頼」する必要があります。クライアントブラウザーを信頼していない場合は、静的コンテンツ以外のWebの使用をまったく停止する必要があります。 CSRFトークンを使用している場合でも、クライアントブラウザが Same Origin Policy に正しく従うことを信頼しています。
IE 5.5/6. のような以前のブラウザの脆弱性がありましたが、攻撃者は同じオリジンポリシーをバイパスして攻撃を実行することができましたが、通常はすぐにパッチが適用されると期待できます発見され、ほとんどのブラウザが自動的に更新されるため、このリスクはほとんど軽減されます。
しかし、他の種類のリクエストについてはどうでしょう-例えばフォーム送信? script/img/...タグを読み込んでいますか?または、ページが(合法的に)リクエストを作成するために使用できる他の方法はありますか?または、既知のJSハックがありますか?
Origin
ヘッダーは通常、XHRクロスドメインリクエストに対してのみ送信されます。画像リクエストにはヘッダーが含まれていません。
注:私は話していません
ネイティブアプリケーション、
操作されたブラウザ、
example.comのページのクロスサイトスクリプティングのバグ、
これが操作されたブラウザに該当するかどうかはわかりませんが、 Flashの古いバージョン は、攻撃者が偽のreferer
ヘッダーでリクエストを送信できる任意のヘッダーを設定できました攻撃を実行するために被害者のマシンから。
Webコンテンツは、Originヘッダーを改ざんすることはできません。さらに、同じOriginポリシーでは、1つのOriginが他のオリジンにカスタムヘッダーを送信することさえできません。 [1]
したがって、Originヘッダーのチェックは、CSRFトークンを使用するのと同じくらいブロッキング攻撃に優れています。
これに依存する主な懸念は、それがすべての正当なリクエストを機能させるかどうかです。質問者はこの問題を知っており、主要なケース(古いブラウザはない、HTTPSのみ)を除外する質問を設定しました。
ブラウザベンダーはこれらのルールに従いますが、プラグインはどうですか?そうではないかもしれませんが、質問は「操作されたブラウザ」を無視します。攻撃者がOriginヘッダーを偽造できるブラウザーのバグはどうですか? CSRFトークンがオリジン間でリークすることを許可するバグが存在する可能性があるため、一方が他方より優れていると主張するには多くの作業が必要になります。