【パスワード再設定の罠】リセットリンクから乗っ取る手口と対策｜CTF思考フレームワーク #03

「パスワードを忘れた」リンク、何気なく使ってますよね。でもここ、実はアカウント乗っ取りの黄金ルートとして攻撃者に大人気のフィーチャーです🔑

パスワードリセットは「メール送信→トークン付きURLでリセット」という単純フローに見えて、攻撃面が想像以上に多いです。攻撃者の思考を追っていきましょう✨

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

リセット機能って“裏口”になりやすいから、観察ポイント多めだよ。

パスワード再設定機能は、ログインを正面突破できないときの“裏口”になりやすい場所。攻撃者は「リセット要求→メール受信→新パスワード設定→ログイン」の一連の流れを観察して、トークンの作り方やURLの組み立て方の中に弱点を探します。下のチェックリストは、観察フェーズで見るべき6つのポイントです👌

受け取ったメールの生ソース表示（Gmailなら「メッセージのソースを表示」）からURLをコピーして、トークン部分をBase64デコード（jwt.ioなどで貼り付けると一発）してみるのがおすすめ。中にユーザーIDや有効期限が平文で入っていれば、それだけで設計の弱点が見えてきます👀

トークンの形式って攻撃の鍵になるんだ…意識したことなかった💧

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

リセットは本人確認の代わりになる機能。だから狙われやすいんだ。

パスワード再設定機能は本人確認の代わりを果たす場所。だからこそ攻撃者は「トークンを盗む／推測する／迂回する」の3方向から狙ってきます。代表的な4つの仮説を紹介しますが、全部覚える必要はなくて「こういう見方をするんだ」と眺めてもらえればOK。守る側にとっては、この4つに当てはまらない設計＝攻撃者に取り付く島がないというヒントになります。

🎯 仮説①：トークンが連番・タイムスタンプ＝予測可能

トークンを連番やタイムスタンプ＋ユーザーIDから生成している実装は、被害者がリセット要求した瞬間に攻撃者が「だいたいこの時刻にこのIDで作られたはず」と推測できてしまいます。UUID v4（バージョン4：完全ランダム生成のID形式）や暗号学的に安全な乱数（CSPRNG）を使うのが鉄則です。

え、時刻＋IDで作るとそんなに簡単にバレるの…！？

🪤 仮説②：HostヘッダーがリセットURLに使われる

メール本文のリセットURLが、リクエストの Host ヘッダ（ブラウザがアクセスしたドメイン情報）をそのまま信頼して組み立てていると、攻撃者が Host: attacker.com に偽装したリクエストを送れば、被害者宛のメールに attacker.com 経由のリセットURLが入って届きます。被害者がクリックした瞬間にトークンが攻撃者のサーバーに渡り、即座に乗っ取り完了です。

えっ、メールに届くURLが攻撃者のドメインに書き換わるの…？怖すぎ💧

🔓 仮説③：リセット完了APIにIDORがある

パスワード変更APIに userId パラメータが露出していて、自分のトークンで他人のIDを指定してもサーバーが通してしまう実装だと、他人のパスワードを自由に書き換えられます。これをIDOR（Insecure Direct Object Reference：認可漏れによる直接オブジェクト参照）と呼びます。トークンとユーザーIDの紐付けをサーバー側で必ず検証する必要があります。

うわ、userIdを変えるだけで他人のパスワード変えられるの…？致命的すぎる💧

⏰ 仮説④：トークンに有効期限がない／再利用できる

トークンに有効期限がない、または1度使った後も再度使える実装だと、メール窃盗・SSRF（サーバ側からの内部リクエスト悪用）・ログイン履歴漏洩などで一度漏れたトークンがいつまでも有効に。15〜60分の有効期限＋使い切り（1回使ったら無効化）が原則です。

昔のメールに残ってるリンクでいまだに侵入できるのか…ヤバい

これら4つを順番にチェックしていくのが、攻撃者の典型的な思考パターン。リセット機能はログイン画面と同じくらい狙われる場所なので、観察→仮説までしっかり押さえたら、次は実際にどう確かめるか——検証フェーズに進みます💡

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

リセットの検証はトークン形式と有効期限が中心になるよ。

仮説が立ったら検証フェーズです。検証は“答え合わせ”の時間。1つずつ小さく試して反応を確かめます。必ず自分で立てた検証環境か、許可されたCTF用サイトでやってください。本番サイトに対して試すのは法律違反になります（最後のお約束で詳しく書きます）。

うわ、トークンの長さや文字種を見ただけで生成方法が推測できちゃうの！？

そう。UUID v4で十分長く、毎回新しいもの。これが鉄則。

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

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

検証で「ここ弱いな」と判断したら、いよいよ実際の攻撃に移ります。リセット機能でよくある攻撃はこの3パターン。“なぜ通るのか”を理解できれば、守る側の打ち手も見えてきます。

えっ、Hostヘッダーを書き換えるだけでメールのURLが攻撃者ドメインに…ホラーじゃん💧

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

POST /api/reset-password
{"token":"my-token","userId":42,"newPassword":"hacked"}
→ 200 OK
CTF{idor_in_password_reset}

パスワードリセットの脆弱性は、「他人のアカウント完全乗っ取り」に直結する最重要ポイント。攻撃のインパクトが極大なので、バグ報奨金プログラムでも高額査定の対象になります🚨 許可されていない実環境への攻撃は不正アクセス禁止法違反です。試すなら必ず自分の検証環境かCTF用サイトで🚫

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

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

攻撃側を理解できれば、守る側の打ち手も自然と見えてきます。設計／実装／運用の3レイヤーで重ねて考えるのがコツ。リセット機能は乗っ取りに直結するので、「トークンが漏れても被害が広がらない」設計を意識するのがポイントです🛡️

なるほど…UUID + 短い有効期限 + 使い切りがリセットの基本セットなんだね！

その通り。トークン管理がリセット機能のキモだよ🛡️

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

記事中で出てきた「強いパスワード」「使い回さない」を全部自力でやろうとすると、現実的にはすぐ限界がきます。パスワード管理ツールを1つ入れておけば、複雑なパスワードを各サイトごとに自動生成・自動入力できて、覚えるのは「マスターパスワード1つだけ」。今日から始められる現実的な防御策として、🔑「ワンパス」がおすすめです。

PR / 広告

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

⚠️ よくある落とし穴

1. トークンにユーザーIDをそのまま含めてしまう　token=user42-abc...のような形だと、攻撃者がID部分を書き換えて他人のリセットを試せます。トークンとユーザーの紐付けはサーバー側のDBで管理するのが鉄則
2. メール送信遅延で複数トークンが同時有効に　ユーザーが「メール来ない」と2回押すと2通届き、両方が有効になっている実装が意外と多い。新しいトークン発行時に古い方を必ず無効化
3. リセットリンクがログやRefererに残る　Webサーバーのアクセスログ、Refererヘッダ（リンクの遷移元情報）、ブラウザ履歴などにトークン付きURLが平文で残ると、内部関係者やプロキシ経由で漏洩する経路に。クエリ文字列ではなくPOSTで送るなどの工夫を

🧰 ツール早見表

🎓 本気で学びたい人へ

「Webセキュリティを趣味から仕事に変えたい」「インフラ寄りで体系的に学びたい」という方へ。🎓 ササエルはインフラエンジニアに特化したオンラインスクールで、セキュリティ設計の基礎から実務スキルまで段階的に学べます。

PR / 広告

📚 もっと深く学びたい人へ

攻撃と防御の両方を1冊で学びたいなら、『ホワイトハッカー入門 第2版』が分かりやすい入口です。本記事の「観察→仮説→検証」の流れを、より幅広いテーマで体系的に追えます📚

ホワイトハッカー入門 第2版

Amazon

＼楽天ポイント4倍セール！／

楽天市場

Yahooショッピング

ポチップ

🤝 大事なお約束

📚 次に読みたい

• ログイン画面の攻撃者目線│CTF思考フレームワーク #01
• 新規登録フォームの裏側│CTF思考フレームワーク #02
• お問い合わせフォームの危険│CTF思考フレームワーク #05
• セッション・Cookie編｜CTF思考フレームワーク #08
• API・GraphQL編｜CTF思考フレームワーク #09
• CORS・SOP編｜CTF思考フレームワーク #10