2009-11-26 25 views
18

AntiForgeryTokenを使用すると、各リクエストに有効なトークンを渡す必要があります。そのため、簡単なスクリプトでデータをWebアプリケーションに送信する悪意のあるWebページは成功しません。ASP.NET MVCのAntiForgeryTokenはすべてのCSRF攻撃を防ぎますか?

しかし、どのような悪質なスクリプトが最初の隠し入力フィールドにantiforgeryトークンを含むページをダウンロードするために、(Ajaxによって)いくつかの単純なGETリクエストを作れば、それを抽出し、有効なPOSTを作ってそれを使うのか?

これは可能ですか、それとも不足していますか?

答えて

12

はい、これだけです。限り、あなたは<%= Html.AntiForgeryToken() %> で、保護された各ページに新しいトークンを生成し、常にそれがOWASPでCSRF Prevention Cheat Sheetで説明したようにこれは、シンクロナイザトークンパターンを実装し[ValidateAntiForgeryToken]

を使用して、任意の保護されたアクションでチェックされていることを確認して

スクリプトが受け入れ可能なリクエストを作成するには、まずフォームを取得してトークンを読み取ってからトークンを送信する必要があります。 Same Origin Policyは、これがブラウザで許可されないようにします。サイトカノットはAJAXスタイルのHTTPリクエストを別のサイトに作成します。それ自身にのみ。何らかの理由で同じ発信元ポリシーが破られた場合、脆弱になります。

クロスサイトスクリプティングの脆弱性が存在する場合、攻撃者はxssの脆弱性を悪用して、同じ発信元ポリシーによって保護されないようにすることができます(スクリプトは自分のサイトから実行されているため、SOPは成功します) 。注入されたスクリプトは、喜んで読んで、トークンを再提出することができます。最近、いくつかのワームでは、XSS経由でCSRF保護機能を使用するこの手法が一般的でした。基本的に、XSSをお持ちの場合、CSRF保護は時間の無駄ですので、どちらにも脆弱でないようにしてください。

注意すべき点として、FlashとSilverlightがあります。これらのテクノロジはどちらも同じ発信元ポリシーに登録せず、クロスドメインポリシーファイルを使用してリモートリソースへのアクセスを制限します。 Flash/Silverlightスクリプトは、自分のサイトにクロスドメインポリシーXMLファイルを公開する場合にのみ、サイトのリソースにアクセスできます。このファイルを公開する場合は、信頼できるサードパーティ製サーバーのホワイトリストを許可し、*を許可しないでください。

読むよりおよそCSRF at OWASP も参照してください:XSS Prevention Cheat Sheet

+1

トークンの検証とは別に、crossdomain.xmlに注意する必要があります。私が正しく理解していれば、crossdomain.xmlのdomain = "*"からallow-http-request-headers(無制限クロスドメインリクエスト)をWebアプリケーションに公開すると、AntiForgeryTokensの目的を破り、サイトCSRFが脆弱になります。 – PanJanek

+0

はい。サーバー上にcrossdomain.xmlポリシーファイルを公開すると、リモートフラッシュムービーでActionScript経由でCSRF攻撃を再開することができます。このファイルを公開すると、信頼できる第三者のみがホワイトリストに登録され、決して*は公開されません。 – Cheekysoft

+1

「サイトはAJAXスタイルのHTTPリクエストを別のサイトに作成できますが、自分自身にのみ」 Googleアナリティクスはどのように機能しますか? 私は、Same-Origin-Policyが別のサイトのクッキーを読んだり変更したりすることができないと考えています。 –

3

しかし、どのような悪質なスクリプトが非表示の入力フィールドにantiforgeryトークンを含むページをダウンロードするために、(AJAXによって)最初のいくつかの単純なGETリクエストを作れば、それを抽出し、有効なPOSTを行うために使用しますか?

はい、これは当てはまりますが、ブラウザで終わっていない場合、これはCSRF攻撃ではありません。

ブラウザを終了させると(たとえば、サーバー側のコードでHTTPリクエストを使用してスクラップするなど)、スクレイプコードはCSRFトークンを取得します。しかし、正規の認証済みユーザーは、自分のマシンに置かれた別のトークンを取得します。スクレーパーが持ち上げるトークンがユーザーに発行されたトークンと異なるため、POSTは失敗します。

投稿を作成しているブラウザ以外のスクリプトを停止したい場合は、それを人間であることを検証する別の方法をとる必要があります。

+0

AJAXでGETリクエストを行うことで、あるページに埋め込まれた悪意のあるスクリプトによってGETが実行され、何らかの形でそのようなページを開こうとしたユーザーがブラウザに開くことを意味しました。この方法で、スクリプトはユーザーのコンテキストで実行されます。だから私はまだCSRFだと思います。 – PanJanek

+0

ああ、私は参照してください。さて、同じオリジナルのポリシーのため、何か厄介なことをしない限り、それは動作しません。その場合、クッキーはとにかく流れないので、トークンは異なります – blowdart

関連する問題