アカウント列挙.

アカウント列挙は、アカウントが存在する場合としない場合とでアプリの挙動が異なること(ログイン・登録・パスワードリセットの各フローでのエラー文言の違い、応答時間の差、HTTP ステータスコードの違いなど)を突きます。攻撃者は多数の候補識別子をプローブして、有効なアカウントの一覧を作り上げ、その後フィッシング、クレデンシャルスタッフィング、パスワードスプレーの標的にできます。

この脆弱性は、ログインフォーム(「ユーザーが存在しません」対「パスワードが違います」)、パスワードリセット(「メールを確認してください」対「アカウントが見つかりません」)、新規登録(「メールは既に登録済みです」)で多く見られます。これが最終目標であることは稀で、列挙は推測を排除して後続攻撃を鋭くする偵察ステップです。具体的かつ最近の例が Gitea の CVE-2025-69413(1.25.2 で修正)です。/api/v1/user エンドポイントが有効・無効なユーザー名に対して区別可能なレスポンスを返したため、攻撃者はクレデンシャルスタッフィングやスピアフィッシングの前に実在アカウントをマッピングできました。

エラー文言が統一されていても、時間が情報を漏らすことがあります。ユーザーが存在する場合にのみ送信されたパスワードをハッシュ化するシステムは、未知のアカウントに対して計測可能なほど速く応答します。そのため堅牢な防御は次を組み合わせます。汎用的で同一のメッセージ、定数時間のコードパス(常にダミーのハッシュを実行する)、汎用的なパスワードリセット・登録の通知、IP 単位とアカウント単位のレート制限、悪用時の CAPTCHA、後続攻撃を鈍らせる MFA です。OWASP の WSTG-IDNT-04 テストケースが、その確認方法を体系化しています。

flowchart TD
  A[攻撃者が候補識別子を送信] --> B{アカウントは存在するか?}
  B -->|はい| C["区別可能なシグナル:<br/>パスワード誤り / 遅いハッシュ / 200"]
  B -->|いいえ| D["区別可能なシグナル:<br/>ユーザー不明 / 速い応答 / 404"]
  C --> E[識別子を有効としてマーク]
  D --> F[識別子を無効としてマーク]
  E --> G[有効アカウント一覧を構築]
  G --> H[クレデンシャルスタッフィング / フィッシング / パスワードスプレー]
  C -.統一メッセージ + 定数時間.-> I[シグナルが同一:列挙をブロック]
  D -.統一メッセージ + 定数時間.-> I