Hello there, ('ω')ノ
✅ 被害者が攻撃者のページを訪れるとどうなるか？
攻撃者が作成したHTMLを仕込んだページに、被害者がアクセスすると：
1️⃣ 攻撃ページがHTTPリクエストを発動
<form action="https://vulnerable-website.com/email/change" method="POST"> <input type="hidden" name="email" value="pwned@evil-user.net" /> </form> <script> document.forms[0].submit(); </script>
→ JavaScriptでフォームが自動送信される
2️⃣ セッションクッキーが自動付与される
- 被害者がログイン済みであれば、ブラウザがそのサイトのクッキー（
session=xxx）を自動送信 - このとき、アプリ側が
SameSite=LaxやStrictを設定していなければ、外部サイトからでもクッキーが送信されてしまう
3️⃣ 脆弱なWebアプリがリクエストを正規ユーザーからの操作と認識
- 攻撃リクエストに ユーザーのセッションクッキーが添付されているため
- Webアプリは「このユーザー本人がメールを変更した」と認識し、処理を実行してしまう
✅ 攻撃成功 → メール変更 → パスワードリセット → アカウント乗っ取り
- その後、攻撃者は「パスワード忘れた」機能を使い、自分のメールにリセットリンクを受け取る
- 新パスワードを設定し、完全にユーザーアカウントを奪う
📌 注目ポイント：CSRFはCookie以外の認証方式でも成立する
通常、CSRFは セッションクッキー（session cookie） を前提としていますが、 次のような他の認証方式でも成立することがあります：
| 認証方式 | CSRFが成立する理由 |
|---|---|
| ✅ HTTP Basic認証 | ブラウザが一度認証すると、自動でAuthorizationヘッダーを送信 |
| ✅ クライアント証明書認証 | 一度証明書でログインすると、リクエストに自動で証明書が添付される |
| ✅ ブラウザ内に保存されたBearerトークンなど | JavaScriptでなく自動的に添付される認証情報はすべて対象になり得る |
✅ まとめ：CSRFの仕組みと本質
| 流れ | 内容 |
|---|---|
| 攻撃ページがリクエストを送信 | 自動でフォームや画像タグなどを使う |
| ブラウザがユーザー認証情報を添付 | セッションクッキーや証明書など |
| サーバーが正規リクエストと判断して処理 | 結果、攻撃が成功する |
💡 教訓
- CSRFはセッションIDの流出を必要としない → より気づかれにくい
- 「自動的に送信される認証情報」すべてがCSRFの入り口になり得る
Best regards, (^^ゞ
