CSRF は PUT または DELETE メソッドで可能ですか? または、PUT または DELETE を使用すると CSRF が防止されますか?
5 に答える
素晴らしい質問です。
完璧な世界では、CSRF 攻撃を実行する方法を思いつきません。
- HTML フォームを使用して PUT または DELETE 要求を行うことはできません。
- 画像、スクリプト タグ、CSS リンクなどはすべて GET リクエストをサーバーに送信します。
- XmlHttpRequest と、Flash/Silverlight/Applets などのブラウザ プラグインは、クロスドメイン リクエストをブロックします。
したがって、一般に、PUT/DELETE 動詞をサポートするリソースに対して CSRF 攻撃を行うことはできないはずです。
とは言え、世界は完璧ではありません。このような攻撃を可能にする方法はいくつかあります。
Rails などの Web フレームワークは、「疑似メソッド」をサポートしています。という隠しフィールドを配置し、
_method
その値を PUT または DELETE に設定してから、GET または POST 要求を送信すると、HTTP 動詞がオーバーライドされます。これは、ブラウザ フォームからの PUT または DELETE をサポートする方法です。このようなフレームワークを使用している場合は、標準的な手法を使用して CSRF から身を守る必要があります。サーバー上でCORSの緩い応答ヘッダーを誤って設定する可能性があります。これにより、任意の Web サイトが PUT および DELETE 要求を行うことができます。
ある時点で、HTML5 は HTML フォームに PUT と DELETE のサポートを含めることを計画していました。しかし、その後、彼らはそのサポートを削除しました。後で追加されないという保証はありません。一部のブラウザは実際にこれらの動詞をサポートしている場合があり、それがあなたに不利に働く可能性があります.
一部のブラウザ プラグインには、攻撃者が PUT/DELETE リクエストを作成できるバグが存在する可能性があります。
つまり、リソースが PUT メソッドと DELETE メソッドしかサポートしていない場合でも、リソースを保護することをお勧めします。
いいえ。HTTP 動詞に依存することは、CSRF 攻撃を防ぐ方法ではありません。それはすべて、サイトの作成方法にあります。PUT を POST として、DELETE を GET として使用できますが、実際には問題ではありません。
CSRF を防ぐには、次の手順を実行します。
Web サイトには、さまざまな CSRF 対策が用意されています。
- すべてのフォーム送信と副作用 URL で秘密のユーザー固有のトークンを要求すると、CSRF が防止されます。攻撃者のサイトは
、提出物に正しいトークンを入れることができません1- セキュリティに関係する操作 (送金など) を実行するために使用されるのと同じ HTTP 要求で認証データを提供するようにクライアントに要求する。
- セッション Cookie の有効期間を制限する HTTP リファラー ヘッダーまたは (および) をチェックする
- HTTP Origin ヘッダーの確認[16]
- Silverlight コントロールへの意図しないアクセスを許可する clientaccesspolicy.xml ファイルがないことを確認する[17]
- Flash ムービーへの意図しないアクセスを許可する crossdomain.xml ファイルがないことを確認する[18]
- リクエストのヘッダーに X-Requested-With が含まれていることを確認します。Ruby on Rails (v2.0 より前) と Django (v1.2.5 より前) で使用されます。この保護は、ブラウザー プラグインとリダイレクトの組み合わせの下では安全ではないことが証明されています[19]。これにより、攻撃者は任意の Web サイトへの要求にカスタム HTTP ヘッダーを提供できるため、偽造された要求が可能になります。
クロスドメインの PUT または DELETE リクエストを開始する方法がないため、理論的には不可能です (CORS を除きますが、プリフライト リクエストとターゲット サイトの協力が必要です)。実際には、私はそれに頼りません - 多くのシステムは、たとえば、CSRF ファイルのアップロード攻撃が不可能であると仮定して噛まれてきました (そうあるべきではありませんが、特定のブラウザーのバグにより可能になりました)。