0

CSRF 攻撃を防ぐための OWASP の推奨事項を調べています ( https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet )。

さて、私が理解していないのは、これが XSS と CSRF 攻撃の組み合わせである攻撃をどのように防ぐかということです。次の攻撃シナリオがあるとします。


  1. 攻撃者はストアド XSS 攻撃を実行できるため、攻撃者が Web サイトに挿入したスクリプトは、ユーザーがそのページにアクセスするたびに実行されます。

  2. このスクリプトは DOM を完全に再設計します。たとえば、ユーザーが関係のない情報を入力する必要がある元のフォームの代わりに、攻撃者のスクリプトが DOM を再設計して、このフォームが管理者権限を持つユーザーが追加されたフォームに再設計されるようにします。フィールドのラベルは同じままであるため、ユーザーには表示されないことに注意してください。POSTのみが異なります。

  3. 攻撃者は、この Web サイトがアンチ CSRF トークンを使用していることを知っています。OWASP の推奨事項: 「(..)application should include a hidden input parameter with a common name such as "CSRFToken"」を見ると、攻撃者はほとんどの Web サイトがこの ID を持つ隠しフィールドをページのどこかに持っていることを知っています。

  4. 攻撃者は、このフィールドの値が偽の POST でも送信されるようにします。攻撃者はこの非表示フィールドの値を知りませんが、POST でこの値をリクエストと共に送信するように指定できます。これは可能です。ユーザーの DOM が変更されているため、リクエストはユーザーのブラウザーから送信され、ユーザーの Cookie もリクエストと共に送信されます。

  5. ユーザーがフォームを送信すると、偽のユーザーが作成されます。


CSRFトークンを使用するだけではこれを防ぐことはできないようです。それとも、XSS 攻撃が無力化されたというシンクロナイザー パターンの暗黙の前提ですか?

4

1 に答える 1

4

それとも、XSS 攻撃が無力化されたというシンクロナイザー パターンの暗黙の前提ですか?

はい。Web サイトがこの方法で攻撃された場合、それは CSRF ではなく XSS 攻撃です。CSRF は単にリクエストが「クロスサイト」で行われることを意味しますが、あなたの例ではリクエストは同じサイトにあります - 「クロスサイト」であるスクリプトだけです。

于 2013-09-23T10:29:47.040 に答える