CSRF は、「脆弱」または「脆弱ではない」タイプの脆弱性ではありません。「何かが悪用される可能性はありますか?」というより。詳しく説明しましょう。
CSRF の背後にある全体的な考え方は、ユーザーに (利用可能なあらゆる手段を介して) プログラムで (できればユーザーの同意なしに) 自分自身として変更を実行させることです。これを行う方法は、次のいずれかの重要なリクエストがある、攻撃しようとしているサイトの一部を見つけることです。
- パラメータを使用して完全に完了し
GET
ます (この時点でimg
タグを使用して、ユーザーのブラウザをだましてトリガーさせることができます)
- リクエストに一意の CSRF トークンがありませんが、この場合、次のいずれかが必要になります。
- AJAX を利用してリクエストを実行するための XSS 脆弱性を持つサイトのページ
- サーバーの構成ミスにより、CORS ヘッダーが一括送信されました。これはまれです。
CSRF 自体はめったにありません (ほとんどの Web サイトPOST
はさまざまなことに使用します。イメージ タグに頼らなければならないことはめったにありません)。より可能性の高い組み合わせは CSRF+XSS ですが、亜種が見つかります。
CSRF を防御するための鍵は、「私のリンクがハッキングされる可能性がある!!!」ということではありません。さらに、使用してリプレイできるリクエストがべき等であることGET
(つまり、状態の変更を引き起こさないこと) を確認し、それ以外は自動リプレイを防ぐためにワンタイム トークンを使用するようにしてください。