何が起きるか

認証の不備は、本人確認を完了していない攻撃者のリクエストを、サーバーが被害者本人の操作として受け付ける問題です。説明用の例として、パスワードの後に追加の確認コードを求めるサイトを考えます。

攻撃者が被害者のパスワードだけを知っていても、本来は確認コードなしで注文履歴を取得できません。ところが、パスワード確認直後に利用者とセッションIDを対応付け、追加確認も完了扱いにする不備があるとします。サーバーはSet-CookieヘッダーでそのIDを攻撃者のブラウザへ保存させます。攻撃者が確認コードの画面を操作せず、注文履歴APIのURLへHTTPリクエストを直接送ると、ブラウザは対象サイトのCookieをそのリクエストへ付けます。APIも追加確認の状態を検査しなければ、被害者の住所や購入履歴を攻撃者の端末へ返してしまいます。

問題は確認コードの画面を表示するかどうかではなく、APIがデータを返す前にサーバー上の本人確認の完了を検査するかです。ログイン以外にも、パスワード再設定やAPIキーで同じアカウントを操作できる経路があるため、それぞれの本人確認と失効条件を調べます。

正常ならどう動くか

Cookieでログイン状態を管理するサイトを例にします。サーバーはパスワードと必要な多要素認証を確認してから、ランダムなセッションIDに利用者と認証完了の状態を対応付けて保存します。HTTPレスポンスのSet-Cookieヘッダーで、そのIDを含むCookieをブラウザへ保存させます。

ブラウザは、Cookieの対象ホスト・パス・HTTPSやSameSiteなどの条件に合うサイト宛てのHTTPリクエストに、保存したCookieを付けます。サーバーはCookie内のIDで保存情報を探し、利用者と必要な認証段階の完了を確認してからAPIの応答を返します。ログアウトで保存情報を無効にしたり期限を過ぎたりしたIDは、再送されてもログイン状態として受け付けません。

不備と攻撃が成立する流れ

多要素認証を飛ばす説明用の例です。攻撃者が知っているのは被害者のパスワードで、追加の確認コードは知りません。サーバーがパスワード確認直後に完全なログイン権限を持つセッションを発行するとします。攻撃者は確認コードの画面を通らず、そのセッションのCookieで保護対象のAPIへ直接HTTPリクエストを送れます。APIも追加確認の状態を検査しなければ、被害者本人向けの応答を攻撃者へ返します。

盗まれたセッションを再利用する経路は別です。攻撃者が有効なセッションIDを入手し、自分の端末から送るリクエストのCookieヘッダーへ入れると、サーバーが保存したIDとの一致で被害者と判断する場合があります。この説明はIDを入手した後の処理で、どのように盗めたかまで実証したものではありません。APIキーも、漏れた値をAPIの認証用ヘッダーなどに入れて送れば、そのキーが許す機能を呼べる構成があります。 APIキーを利用者へ発行する構成では、サイトが本人確認後にキーを作り、利用者と許可機能をサーバーへ対応付けて保存します。以後は受け取ったキーを保存情報と照合して処理するため、リクエストごとにパスワードや確認コードを再入力しない場合があります。

起こり得る被害と条件

情報取得の例では、攻撃者が本人として受け付けられたセッションを使い、注文履歴APIへHTTPリクエストを送ります。APIが住所や購入履歴をレスポンスに含めると、攻撃者は自分の端末で他人の個人情報を入手できます。

設定変更の例では、攻撃者が同じログイン状態で登録メールアドレスの変更を要求します。追加の本人確認なしで変更できれば、そのアカウントの通知を攻撃者のアドレスで受け取れるようになります。重要操作に再認証が必要なら、その条件も満たさなければ変更できません。

本人としてログインできることと、管理者として全利用者を操作できることは別です。取得できる情報や変更できる設定は、侵害されたアカウントの権限とAPIごとの認可で決まります。

防ぎ方と、防げる理由

認証の途中段階と完了状態をサーバーに保存し、保護対象の各APIが必要な段階を満たすか検査します。パスワードだけ確認したセッションでは注文履歴を返さず、確認コードの照合が成功した後にだけ許可します。画面の移動を省略してAPIを直接呼ばれても、保存された状態が未完了なので拒否できます。

パスワードや確認コードの試行回数を制限すると、候補を繰り返し送って正解を探す機会を減らせます。パスワード再設定では、サーバーが予測困難なトークンを作り、登録済みメールアドレスへその値を含むリンクを送ります。リンクを開いた利用者が新しいパスワードとトークンを送ると、サーバーは保存した値と照合して、対応する利用者のパスワード変更を許可します。この再設定トークンは、サーバーに利用者・期限・使用済み状態を対応付け、一度変更に使った値の再送を拒否します。漏えいしたセッションIDやAPIキーは、それぞれの照合処理で無効と判断するよう失効させます。パスワードだけを変更しても、別に管理する有効なキーまで無効になるとは限りません。

よくある誤解

多要素認証は、すでに盗まれた有効なセッションを自動で無効にはしません。通常のパスワードを変更しても、別のAPIキーやアプリ用パスワードが残ればアクセスが続く場合があります。どの資格情報を失効させるかも確認が必要です。

実装の確認点

ログイン、登録、回復、多要素認証、APIキー、ログアウトの各処理について、HTTPリクエストに含まれる資格情報とサーバーが確認する認証状態を対応付けます。許可されたテスト環境で、追加確認を飛ばしたリクエスト、失効済みセッション、使用済みパスワード再設定トークンが保護対象のAPIで拒否されるか確認します。

出典・確認範囲

  1. [1] Web Security Academy: 認証の不備PortSwigger / 確認日 2026-11-01
  2. [2] Vulnerabilities in other authentication mechanismsPortSwigger / 確認日 2026-11-01