CORS OriginヘッダーとCSRFトークンによるCSRF保護


103

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

具体的には:Originヘッダー(CORS)による保護は、CSRFトークンによる保護と同じくらい優れていますか?

例:

そう:

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

私は、W3C仕様がすべての最新のブラウザーで正しく実装されていると信頼できる場合(少なくとも、クロスオリジンリソースシェアリングのセキュリティを参照)、これはXHRでは不可能であることを知っています(できるでしょうか?)

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

注:私は話していません

  • ネイティブアプリケーション
  • 操作されたブラウザ、
  • example.comのページのクロスサイトスクリプティングのバグ
  • ...

1
多くのプロキシがoriginヘッダーを取り除いていると思います。
thefourtheye 14

また、フォーム送信タグとimg / scriptタグについては、古いブラウザーについては不明ですが、CSPに依存する必要があります。
thefourtheye 14

3
@thefourtheye:TLS経由で接続が開始されるため、プロキシが中間者である場合、ユーザーはCSRFよりもはるかに差し迫った問題を抱えています。
Perseids 14

2
@thefourtheye、なぜ彼らはストリップするのOriginですか?CORS保護が無効になります。
Paul Draper 14

1
この質問とその回答は、特定の問題に関するものなので気に入っていますが、CSRFとCORSの違いを思い出させてくれます。(私はそれらが簡単に混同されやすい概念ではないことを認めます...しかし、私はまだそれらを混乱させることができます。)
Red Pea

回答:


41

これは、XHR(たとえば、クロスオリジンリソースシェアリングのセキュリティを参照)では不可能であることがわかっています。少なくとも、最新のすべてのブラウザーでW3C仕様が正しく実装されていると信頼できる場合は(そうでしょうか?)

結局のところ、ユーザーのデータを安全に保存し、セッションのクライアント側を保護するには、クライアントブラウザを「信頼」する必要があります。クライアントブラウザを信頼しない場合は、静的コンテンツ以外の目的でWebを使用するのをやめてください。CSRFトークンを使用している場合でも、クライアントブラウザが同じ発生元ポリシーに正しく従うことを信頼しています。

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

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

Originヘッダは、通常のみXHRクロスドメインリクエストのために送られます。画像リクエストにはヘッダーが含まれていません。

注:私は話していません

  • ネイティブアプリケーション

  • 操作されたブラウザ、

  • example.comのページのクロスサイトスクリプティングのバグ

これが操作されたブラウザに該当するかどうかはわかりませんが、古いバージョンのFlashでは、攻撃者がreferer被害者のマシンからスプーフィングされたヘッダーを含むリクエストを送信して攻撃を実行できる任意のヘッダーを設定できました。


Flashの例は良い例です。他のプラグインにも同様の脆弱性があるかもしれません。(残念ながら)アリスをCSRFから保護することしかできません。彼女が最新のブラウザーなどを使用している場合、それは明らかです。しかし、セキュリティを意識したユーザーであっても、サードパーティのプラグインをインストールした可能性があることは不合理ではありません。彼らが安全なプラグインを作成しているとしても、CSRFについても考えれば、私は100%確信していません。したがって、ブラウザーのサンドボックスがプラグインのSOP違反を制限しない限り(おそらくそうですか?)、CSRFトークンを使用することをお勧めします。
Chris Lercher、2014

@ChrisLercher:はい、現代のプラグインはもう少し堅牢に見えます。ただし、攻撃者がブラウザ保護をバイパスするような方法でそれを利用できる新しいバージョンがいつでもリリースされる可能性があります。それを処理する最良の方法(例えば、トークン/ヘッダー)は、データの機密性と、そのようなリスクが許容できるかどうかによって異なります。FlashはSOPに従いますが、Flashプラグインの起源は、JavaScriptのような呼び出しサイトではなく、ロード元のサイトです。あるcrossdomain.xmlクロスドメイン通信を可能にすることができます。
SilverlightFox

27

WebコンテンツはOriginヘッダーを改ざんできません。さらに、同じオリジンポリシーでは、1つのオリジンがカスタムヘッダーを他のオリジンに送信することさえできません。[1]

したがって、Originヘッダーをチェックすることは、CSRFトークンを使用するのと同じくらい攻撃のブロックに優れています。

これに依存することの主な懸念は、それがすべての正当な要求を機能させるかどうかです。質問者はこの問題を知っており、主要なケースを除外するための質問を設定しました(古いブラウザではなく、HTTPSのみ)。

ブラウザベンダーはこれらのルールに従いますが、プラグインはどうですか?彼らはそうしないかもしれませんが、質問は「操作されたブラウザ」を無視します。攻撃者がOriginヘッダーを偽造できるブラウザのバグはどうですか?CSRFトークンがオリジン全体に漏洩するバグも存在する可能性があるため、一方が他方よりも優れていると主張するには、より多くの作業が必要になります。


5
私はFirefox 47をテストしたばかりで、クロスオリジンフォームポストのオリジンヘッダーを送信しないので(XHRでCORSを有効にしないRESTサービスを攻撃する一般的な方法)、オリジンヘッダーチェックを考えていませんユーザーがFirefoxを使用している場合に効果的です。
アンディ

3
参考までに、Firefoxで「Origin」ヘッダーが送信されない問題は、Bugzillaで追跡されています:bugzilla.mozilla.org/show_bug.cgi ? id=446344 Firefoxユーザーは、プライバシーの問題のため、「Referer」ヘッダーをブロックします(ただし、パスとクエリを削除するだけで十分です)。
Steffen
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.