AntiForgeryToken を使用するには、各要求が有効なトークンを渡す必要があるため、Web アプリケーションにデータを投稿する単純なスクリプトを含む悪意のある Web ページは成功しません。
しかし、悪意のあるスクリプトが最初に単純な GET リクエスト ( Ajaxによる) を作成して、隠し入力フィールドに偽造防止トークンを含むページをダウンロードし、それを抽出し、それを使用して有効なPOSTを作成した場合はどうなるでしょうか?
それは可能ですか、それとも何か不足していますか?
5568 次
2 に答える
13
はい、これがあなたがする必要があるすべてです。
保護された各ページで新しいトークンを生成する限り、<%= Html.AntiForgeryToken() %>
保護されたアクションで常にチェックされていることを確認してください。[ValidateAntiForgeryToken]
これにより、OWASPのCSRF防止に関するチートシートで説明されているシンクロナイザートークンパターンが実装されます。
スクリプトが受け入れ可能な要求を行うのに成功するには、最初にフォームを取得してトークンを読み取り、次にトークンを投稿する必要があります。同一生成元ポリシーは、これがブラウザで許可されないようにします。サイトは別のサイトにAJAXスタイルのhttpリクエストを行うことはできません。それ自体にのみ。何らかの理由で同一生成元ポリシーに違反する可能性がある場合は、脆弱になります。
クロスサイトスクリプティングの脆弱性がある場合、攻撃者はxssの脆弱性を悪用して、同一生成元ポリシーによって提供される保護を回避する可能性があることに注意してください（スクリプトは現在自分のサイトから実行されているため、SOPは成功します）。挿入されたスクリプトは、トークンを喜んで読み取って再送信できます。XSSを介してCSRF保護を通過するこの手法は、最近一部のワームで一般的になっています。基本的に、XSSを使用している場合、CSRF保護は時間の無駄なので、どちらにも脆弱でないことを確認してください。
注意すべきもう1つのことは、FlashとSilverlightです。これらのテクノロジーはどちらも同一生成元ポリシーにサブスクライブせず、代わりにクロスドメインポリシーファイルを使用してリモートリソースへのアクセスを制限します。Flash / Silverlightスクリプトは、自分のサイトでクロスドメインポリシーxmlファイルを公開した場合にのみ、サイトのリソースにアクセスできます。このファイルを公開する場合は、信頼できるサードパーティサーバーのホワイトリストのみを許可し、*は許可しないでください。
OWASPでCSRFの詳細を読む 参照：XSS防止に関するチートシート
于 2009-11-26T13:41:37.840 に答える
3
しかし、悪意のあるスクリプトが最初に (AJAX による) 単純な GET リクエストを作成して、非表示の入力フィールドに偽造防止トークンを含むページをダウンロードし、それを抽出し、それを使用して有効な POST を作成した場合はどうなるでしょうか?
はい、これは本当ですが、ブラウザーで終わらない場合、これは CSRF 攻撃ではありません。
ブラウザーで終了した場合 (たとえば、サーバー側コードの HTTP 要求を介してスクレイピング)、スクレイプ コードは CSRF トークンを取得します。ただし、正当な認証されたユーザーは、マシンに別のトークンが置かれます。スクレーパーがリフトするトークンはユーザーに発行されたものとは異なるため、POST は失敗します。
ブラウザ以外のスクリプトによる投稿を停止したい場合は、それが人間であることを検証する別のアプローチを取る必要があります。
于 2009-11-27T12:46:44.647 に答える