【ログイン画面の攻撃者目線】何を狙う?どう守る?|CTF思考フレームワーク #01
こんにちは、アンペンです!「はじめてのWebセキュリティ」シリーズの第1回はログイン画面編。CTF(シーティーエフ)という安全な演習環境を題材に、攻撃者がログイン画面の『どこを見るか』、そしてなぜ失敗メッセージのひと言が手がかりになるのかを、守る側の対策とセットで学びます。
「ログインに失敗しただけで、いったい何が漏れるの?」——そう思った人ほど、今日の話はきっと面白いはずです。むずかしい専門用語はできるだけ使いません。大切なのは、画面の“ちょっとした違い”に気づく目を持つこと。その目はそのまま、攻撃を見抜く力にも、安全な画面を作る力にもつながっていきます。気楽に読み進めてくださいね。

ログインに失敗しただけなら、情報は何も漏れてないよね?中に入れてないんだし。

それがね、失敗したときのメッセージだけで「そのIDは使われているかも」と分かってしまうことがあるんだ。中に入れなくても、『誰がいるか』が漏れる。これをユーザー名列挙と呼ぶよ。今日はその仕組みと、守り方を一緒に見ていこう。
ユーザー名列挙(User Enumeration)とは「ログイン画面などの反応の違いから、登録済みのIDやメールアドレスを推測されること」。たとえば失敗時に『パスワードが違います』と『ユーザーが見つかりません』を出し分けると、存在するIDが分かってしまいます。手がかりは文言だけでなく、HTTPステータス・移動先・応答時間にも出ます。守る側は『失敗時の応答をそろえる+総当たりを抑える(レート制限・ロック)+MFA+ログ監視』が基本です。
この記事で分かること
- ログイン画面で、攻撃者が最初に見るポイント
- 失敗メッセージの違いが、なぜ問題になるのか
- 文言以外(ステータス・時間)にも差が出ること
- 演習環境での確認手順(応答の差を観察する)
- 守る側の「手がかりを減らす」チェックリスト
📖 はじめてのWebセキュリティ #01|ログイン画面編
難しい攻撃手順を覚えるのではなく、「画面のどこを見るか」「なぜ危ないか」「どう守るか」を1つずつ身につけます。 シリーズ一覧を見る →
⚠️ 大事なお約束
この記事の確認は、CTF・公式ラボ・自分で作った検証環境だけで行ってください。実在するサイトで他人のIDを入力して試すことは、不正アクセス禁止法に触れるおそれがあります。本記事の目的は守る側の理解です。「できる」と「やってよい」は全く別です。
ログイン画面は「入れるか」だけを見る場所ではない
ログイン画面は、IDとパスワードが正しければ中に入り、間違っていれば入れない画面です。だから普通は「成功したか、失敗したか」だけを気にします。でもセキュリティを学ぶときは、もう一つ見ます。それが失敗したときに画面が何を教えているかです。攻撃者がログイン画面で最初に観察するのは、次のような『反応の差』です。
- 失敗メッセージの文言:「パスワードが違います」と「ユーザーが見つかりません」を出し分けていないか
- HTTPステータス・移動先:存在するIDと存在しないIDで、応答コードやリダイレクト先が違わないか
- 応答時間:存在するIDだけパスワード照合で時間がかかり、時間差で判別できないか
- 他の入口との一貫性:新規登録・パスワードリセットでも同じ手がかりが出ていないか

ここで『そんな細かい言葉の違い、気にする人なんている?』と思うかもしれません。ところが攻撃者にとっては、この一文字レベルの差が“宝の地図”になります。彼らが本当に知りたいのは「どのIDが実在するか」だからです。ログイン画面は、中に入る前から“住人名簿”をチラ見せしてしまうことがある——まずはこの感覚をつかんでおきましょう。逆に言えば、ここさえ塞げば攻撃の出発点を一つ潰せる、ということでもあります。
ここで覚える用語:ユーザー名列挙(User Enumeration)
意味:ログイン画面などの反応の違いから、「存在するユーザー名やID」を推測すること。まずは「失敗メッセージの違いから利用者を探られること」と覚えれば大丈夫です。
例:aliceには『パスワードが違います』、no-such-userには『ユーザーが見つかりません』と返す→aliceは存在するIDだと分かる。
使いどころ:守る側は失敗時の応答をそろえ、存在の有無が外から区別できないようにします。OWASPのテストガイドでも確認項目として扱われています。
なぜIDが分かるだけで危ないのか
訪ねてきた人に、受付が「田中さんは住んでいません」と「田中さんはいますが、暗証番号が違います」を使い分けたらどうでしょう。部屋には入れなくても、誰が住んでいるかはハッキリ分かってしまいます。攻撃者にとって、存在するIDが分かるのは大きな一歩です。存在しないIDに時間を使わず、実際に使われているIDだけに狙いを絞れるからです。さらに、他のサイトから漏れたパスワードの使い回しを試したり、「あなたのアカウントに異常が…」という偽の連絡の材料にしたりできます。だから受付は、住人の有無が分からないよう『いつも同じ対応』をするのが正解。ログイン画面もまったく同じで、失敗時の応答をそろえることが守りの第一歩になります。

ちょっとだけ攻撃者の頭の中をのぞいてみましょう。彼らはいきなりパスワードを破ろうとはしません。まず大量のメールアドレスやIDを用意して、ログイン画面に次々と入れていきます。そして返ってきた反応を「存在する」「存在しない」の2つに仕分けるんです。この“仕分け”が終わった時点で、狙う相手はぐっと絞り込まれます。あとは存在すると分かったIDにだけ、どこかで流出したパスワードを片っ端から試す——という流れ。つまり最初のひと言の差が、その後の攻撃の効率を何倍にも変えてしまうわけですね。だからこそ、入口で「存在する/しない」を悟らせない設計が効いてきます。
差は「言葉」だけに出るとは限らない
メッセージを同じ文言にそろえても、別のところで差が出ることがあります。たとえば、存在するIDだけパスワード照合の処理が走って応答が少し遅い、あるいは成功・失敗でリダイレクト先がわずかに違う、といったケースです。攻撃者はこうした小さな差も手がかりにします。だから守る側は『見える文言』だけでなく、裏側の応答もそろえる意識が必要です。
ここで覚える用語:応答の差(オラクル)
意味:入力に対してシステムが返すあらゆる反応の違いのこと。文言・HTTPステータス・リダイレクト先・応答時間などが含まれます。差があると、それ自体が情報を「教えてくれる窓口(オラクル)」になってしまいます。
例:存在するIDは照合に20ミリ秒、存在しないIDは即エラーで5ミリ秒→時間差で存在を見分けられる。
使いどころ:守る側は文言・ステータス・処理時間まで均一化し、差という名の手がかりを消します。
『オラクル』なんて言葉が出てくると、急にむずかしく感じるかもしれませんね。でも身構えなくて大丈夫。次の会話くらいのイメージで十分です。

「オラクル」って神様のお告げみたいでカッコいいけど、セキュリティだと結局なんのこと?

語源はまさに古代の『お告げ』なんだ。ここでは『質問を投げると、つい答えのヒントを漏らしてしまう窓口』のことだよ。ログイン画面が「そのIDはいません」と正直に答えてしまうのは、小さなお告げをしているのと同じ。だから守る側は、何を聞かれても“同じ顔”で返すのが大事なんだ。
CTFでやってみよう:表示と応答の差を見つける
登録済みIDと未登録IDで、失敗時の「差」を比べてみよう
この演習の目的は、ログインを突破することではありません。画面が返す『情報の差』に気づくことです。対象は必ず自分の検証環境かCTFにしてください。各ステップに「なぜやるか」を添えました。
- 演習環境で登録済みのテスト用IDを1つ確認 → なぜ:比較の基準を作るため
- 存在しないテスト用IDを1つ用意 → なぜ:対照を作るため
- 両方に同じ誤ったパスワードを入力 → なぜ:条件をそろえ差だけを見るため
- 表示メッセージの文言を記録 → なぜ:文言の差を確認するため
- ブラウザの開発者ツールでHTTPステータス・移動先を確認 → なぜ:文言以外の差を見るため
- 応答時間(処理の速さ)の違いを観察 → なぜ:時間差の手がかりを見るため
- 「第三者には何が分かるか」を書き出す → なぜ:リスクを言葉にするため
- 失敗時の応答をそろえる修正を入れて再確認 → なぜ:守りを手で検証するため
この演習を実際にやってみると、たぶん『えっ、こんなにあっさり分かっちゃうの?』と驚くはずです。その驚きこそが大事。攻撃者目線を一度でも体験しておくと、守る側に回ったとき「どこを直せばいいか」が自然と見えてきます。では、その“直し方”を次にまとめておきましょう。
守る側:失敗時の応答をそろえる
- 失敗メッセージを統一:「IDまたはパスワードが正しくありません」に一本化する
- ステータス・移動先も同一に:HTTP応答コードやリダイレクト先を存在/非存在で揃える
- 応答時間を均一化:存在しないIDでもダミー照合を行い処理時間をそろえる
- レート制限・アカウントロック:短時間の失敗集中を抑え総当たりを困難にする
- 他の入口も統一:新規登録・パスワードリセットでも存在を漏らさない応答にする
- MFA・パスキー:万一IDが知られても突破されにくくする
- ログ監視:失敗の集中や列挙の兆候を検知してアラートする
- 自動化対策:CAPTCHA等で機械的な大量試行を抑える


「親切に詳しく教える」が、ログイン画面では逆効果になることもあるんだね。文言だけじゃなく時間までそろえるとは…!

そう、便利さと安全性のバランスを取るのが守る側の仕事なんだ。次回#02は新規登録フォーム編。「このメールアドレスは登録済みです」という親切な表示が、なぜ手がかりになるのかを一緒に見ていくよ。
まとめ:ログイン失敗時の「ひと言」に注目しよう
- ログイン画面では、成功・失敗だけでなく失敗時に何を表示するかが大切
- 表示の違いから存在するIDを推測されるのがユーザー名列挙
- 差は文言だけでなくステータス・移動先・応答時間にも出る
- CTFでは2つのテスト用IDを比べ、反応の差に気づく練習をする
- 守る側は応答をそろえ、レート制限・MFA・監視を組み合わせる
最後に、今日いちばん覚えてほしいことを。それは『親切すぎる画面は、ときに危ない』ということです。利用者にとっては分かりやすいエラーが理想ですが、こと“アカウントの存在”に関しては、わざとそっけなく「IDまたはパスワードが正しくありません」とだけ返すのが正解。これは不親切なのではなく、利用者みんなのアカウントを守るための“やさしい無口”なんですね。
ログイン画面は、ただ入力するだけの場所ではありません。ほんの少し表示や応答が違うだけでも、外から見える情報は変わります。次回は、ログインする前に使う新規登録フォームを見ていきましょう。
