Hello there, ('ω')ノ
✅ 攻撃が成立する具体的なシナリオ
CSRFの仕組みをよりリアルな例で見てみましょう。 ここでは「ユーザーのメールアドレスを変更する機能」があるWebアプリが対象です。
📋 通常のリクエスト（正規ユーザーによる操作）
POST /email/change HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE email=wiener@normal-user.com
✅ 攻撃者がこの構造を悪用する
このアクションはCSRFに非常に適しているため、次のように悪用されます。
✅ なぜこのケースがCSRFに弱いのか？
🔑 条件①：価値のある操作（メールアドレスの変更）
- メールアドレス変更 → 攻撃者のアドレスに上書き
- → その後パスワードリセットを実行 → アカウントを完全乗っ取り可能
🔑 条件②：セッションはCookieで管理されている
Cookie: session=xxxが自動的に付与される- 攻撃者が作ったリクエストにも被害者のセッション情報が付いて送信される
🔑 条件③：リクエストパラメータが予測可能
emailの値だけ知っていれば実行可能current_passwordやCSRFトークンなどの攻撃者が知らない情報は不要
🎯 攻撃者が仕掛ける偽装フォームの例
<html> <body> <form action="https://vulnerable-website.com/email/change" method="POST"> <input type="hidden" name="email" value="attacker@example.com" /> <input type="submit" value="Click me" /> </form> <script> document.forms[0].submit(); // 自動送信 </script> </body> </html>
💥 結果：
- 被害者がこのページにアクセスした瞬間にリクエストが送られる
- 攻撃者のアドレスにメールが変更される
- 攻撃者はその後「パスワードを忘れた場合」機能を使って乗っ取り
✅ 防御すべき理由
- 一見シンプルなリクエストに見えるが、CSRF脆弱性があると致命的
- ユーザーの個人情報の書き換え、資金移動、設定変更などに直結
- アカウント乗っ取りや管理者操作まで拡大される危険性
✅ このような機能に必要な防御策
| 対策 | 内容 |
|---|---|
| CSRFトークンを導入 | フォームごとにユニークな値を含め、サーバー側で検証 |
SameSite=Lax or Strict Cookie設定 |
第三者サイトからのリクエスト時にCookieを送らせない |
| メール変更時に元パスワードを入力させる | 攻撃者は元パスワードを知らないので実行不可 |
| RefererヘッダーやOriginヘッダーの検証 | 外部ドメインからのPOSTを拒否する手段として有効 |
✅ まとめ
このような単純なアクションこそ、CSRFの標的にされやすい なぜなら：
- 攻撃者にとっての価値が高い
- 実行がシンプル
- 被害者が気づきにくい
「被害者が自分で操作したように見える」のがCSRF最大の怖さです。
Best regards, (^^ゞ
