2026.04.26

【新規登録フォームの裏側】サインアップから漏れる情報と防御策｜CTF思考フレームワーク #02

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Webフォーム編　#02 / 公開中 7記事　→　シリーズ一覧を見る →

新規登録フォームは「誰でも触れる入口」。攻撃者にとって偵察と乗っ取りの入口になりやすい場所です🚪

難易度：★☆☆（入門）

会員登録時のレスポンス差・既存ユーザー判定が主なネタ。HTTPの基本でOK👌

「メールアドレスはすでに登録されています」って親切メッセージ、実は攻撃者にとって便利な情報源だったりします。観察→仮説→検証の流れで見ていきましょう✨

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者ならどう考える？
🔬 検証フェーズ：実際に試す手順
⚔️ 攻撃フェーズ：攻撃者ならこう攻める
🛡️ 防御フェーズ：どう守る？
🛡️ 今日からできる対策ツール
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
📚 次に読みたい

👀 観察フェーズ：まず何を見る？

登録フォームって、入力前後の反応に攻撃ヒントがいっぱい埋まってるんだ。

登録フォームを開いて、まずは何も入力せずじっくり観察。次に意図的にダメな値を入れて反応の差を比較します🔍

メアド／ユーザー名フィールドの重複チェックが「リアルタイム」か「送信後」か
パスワード強度ポリシー（最低文字数、複雑さ要件）
reCAPTCHA・hCaptchaの有無、自動化耐性
「すでに登録されています」と「登録できました」のレスポンス差
招待コード／紹介コード欄の有無（権限昇格のヒント）
メール認証フローの有無（後で重要）

Networkタブで重複チェックAPIが叩かれてるか見てみると、隠れたエンドポイントが見つかること多めです。F12で開発者ツール起動👀

えっ、登録するだけでメアドの存在確認に使われちゃうの…？

🤔 仮説フェーズ：攻撃者ならどう考える？

“誰でも触れる”フォームほど、攻撃の起点にされやすいんだよ。

観察したら、攻撃者の頭の中をシミュレーションしてみましょう。新規登録フォームには4つの大きな落とし穴があります。

🎣 仮説①：メアド重複チェックでアカウント列挙

メアド入力時の「すでに登録されています」メッセージは、攻撃者にとってアカウント列挙の格好のヒント。リアルタイムチェックAPIならさらに高速で総当たりされます。

えっ、親切なメッセージがそんな攻撃に使われるの…？

🔓 仮説②：アカウント先取り（Pre-hijack）

攻撃者が先に他人のメアドで仮登録しておき、後から本人が登録しようとすると「すでに登録済み」。本人がパスワードリセットせずアカウントを使うと、攻撃者が裏で同じアカウントを共有できる手口です。

うわ、先回りされるってこと！？気づかないよこんなの…💧

✉️ 仮説③：メール認証なし＝なりすまし放題

メアド認証なしで登録できると、他人のメアドで勝手にアカウントを作られる可能性。被害者は身に覚えのないサービスからメールを受け取って混乱します。

他人のメアドで勝手に登録できちゃうって、フィッシングの温床じゃん…

💣 仮説④：パスワードポリシーが甘い

最低8文字・記号必須などのポリシーがないと、passwordや123456のような弱いパスワードで大量のbotアカウントが作られます。スパム拠点化のリスク大。

え、大量のbotアカウントが作られて何に使われるの…

これら4つを順番にチェックするのが、攻撃者の典型的な思考パターン。次は実際に試す検証フェーズへ💡

🔬 検証フェーズ：実際に試す手順

仮説のままじゃ意味がないから、小さく試して反応を見る。これが検証の基本。

仮説を実際に試して確認します。必ず自分の環境か、許可された環境でやってください。

STEP 1

メアド列挙の検証

存在するメアド（自分のもの）と存在しないメアドで、レスポンス（メッセージ・ステータス・時間）を比較。差があれば列挙可能。

STEP 2

重複チェックAPI叩き

リアルタイムバリデーションのエンドポイントをBurp/curlで直接叩く。レート制限がなければ、メアド辞書で総当たり可能か確認。

STEP 3

招待コードの予測

招待コードをinvalid/空/数字連番で送信。エラーメッセージや権限の差を観察。

STEP 4

メール認証なしでの登録

メアドを入れてメール認証前にログイン試行。認証なしでも入れたら設計上の問題あり。

STEP 5

パスワードポリシー回避

「password」「12345678」など弱いパスワードで登録できるか試す。要件が甘ければ攻撃しやすい。

うわ、エラーメッセージの差とレスポンス時間の差でそんなに分かるの…！？

そう、守る側はこの“差”を消すのが鉄則。文言・コード・時間まで揃えるのがポイントだよ。

⚔️ 攻撃フェーズ：攻撃者ならこう攻める

“なぜ通るか”を理解するのがゴール。攻撃の流れが分かれば対策も見える。

検証で「ここ弱いな」と判断したら、いよいよ実際の攻撃手法に移ります。新規登録フォームでよくある攻撃はこの3パターン。

① メアド列挙→ターゲット情報収集

「すでに登録されています」レスポンスで、対象組織の社員メアドを大量特定。後続のフィッシングや認証情報攻撃の下準備に💥

② アカウント先取り（Pre-hijack）

相手のメアドを先に登録して、認証メールが来たタイミングで奪取。SSOと組み合わせると怖い⚠️

③ 大量自動登録→スパム拠点化

CAPTCHAなしの登録APIをスクリプトで叩き、捨てアカウントを大量作成→スパム送信・ボット運用に悪用🤖

えっ、先取りとかスパム拠点化とか…登録フォームってこんなに狙われるの…💧

結果として、こんな”フラグ”を取られちゃうイメージ：

POST /api/check-email
{"email":"victim@example.com"}
→ {"exists":true}
→ ターゲットメアド列挙完了
FLAG{user_enumeration_via_signup}

攻撃の意図は「情報収集」と「先取り」が中心。手数が少なくても被害は連鎖します。

🛡️ 防御フェーズ：どう守る？

やっとお待ちかね、守る側の打ち手。攻撃を見たあとだとスッと入ってくるよ。

攻撃側を理解したら、守る側の打ち手も見えてきます。設計・実装・運用の3レイヤーで考えるのがコツ🛡️

🏗️ 設計レベル

重複チェックは「メールを送りました」で一律応答（存在を露呈しない）
本人確認はメール認証＋有効期限つきトークン必須
招待コードはランダム＋ワンタイム＋有効期限

⚙️ 実装レベル

reCAPTCHA v3 / hCaptchaで自動登録ブロック
IP・端末単位のレート制限
パスワードポリシー（12文字以上、漏洩リスト除外）
パスキー（WebAuthn）登録の動線を初期から提供（パスワードレス化で長期的に強い）

🔐 運用レベル

異常な登録パターンを監視（同IPから大量登録など）
使い捨てメールドメインのブラックリスト運用
アカウント先取り対策：未認証メアド宛にも警告メール送信

なるほど…設計・実装・運用の3層で重ねるんだね。1個壊れても他で守れるってわけか！

その通り。多層防御がセキュリティの基本だよ🛡️

🛡️ 今日からできる対策ツール

パスワードの使い回しや手動管理はどんなに気をつけても限界があります。🔑 パスワード管理ツール「ワンパス」なら、複雑なパスワードを安全に保管して「1つのマスターパスワード」だけ覚えられるので、今日から始める防御策としてしっくりきます。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

リアルタイム重複チェックを「UX向上」のためだけに残しがち（列挙経路に）
メール認証だけで満足し、パスワード強度を疎かにする
CAPTCHAをreCAPTCHA v2（チェック型・画像選択型）だけに頼る（機械学習で突破されやすい。v3スコア型やhCaptcha併用が必須）

🧰 ツール早見表

ツール	何ができる	使いどころ
Burp Suite	登録APIのレスポンス差検出	観察〜検証
ffuf	メアド列挙の自動化	差分レスポンス検出
Have I Been Pwned API	漏洩パスワードチェック	実装レベル防御
mailcheck	使い捨てメールドメイン判定	運用レベル防御
Burp Intruder	メアド・招待コードの自動列挙	攻撃フェーズ（演習環境のみ）