API2:2023 認証の不備（Broken Authentication）
| Threat agents / Attack vectors（脅威エージェント／攻撃ベクター） | Security Weakness（セキュリティの弱点） | Impacts（影響） |
|---|---|---|
| API 固有：悪用難易度（Exploitability） 容易 認証メカニズムは誰にでも公開されているため、攻撃者にとって狙いやすい標的です。いくつかの認証問題を悪用するには高度なスキルが必要な場合もありますが、一般に悪用ツールが入手可能です。 |
蔓延度（Prevalence） 一般的 ： 検出可能性（Detectability） 容易 認証の境界に関するソフトウェア／セキュリティエンジニアの誤解や、実装の複雑さが、認証の不備を広く発生させます。破られた認証を検出する手法は利用可能で、容易に作成できます。 |
技術的影響（Technical） 重大 ： ビジネス影響（Business） ケース依存 攻撃者は他ユーザーのアカウントを完全に掌握し、個人データを読み取り、代理で機微な操作を実行できます。システムは攻撃者の行為を正当なユーザーの行為と区別できない可能性があります。 |
API は脆弱か？
認証エンドポイントやフローは保護すべき資産です。加えて、「パスワードを忘れた／パスワードリセット」も認証メカニズムと同様に扱うべきです。
次のような場合、API は脆弱です：
- 資格情報スタッフィング（有効なユーザー名とパスワードのリストを使った総当たり）を許してしまう。
- 特定のユーザーアカウントに対する総当たり攻撃を、CAPTCHA／アカウントロックアウトなしで許す。
- 弱いパスワードを許容している。
- 認証トークンやパスワードなどの機微な認証情報を URL に載せて送信している。
- ユーザーがメールアドレスや現在のパスワードの変更、その他の機微な操作を行う際に、パスワード再入力による本人確認を求めない。
- トークンの正当性を検証していない。
- 署名なし／脆弱な署名の JWT（例：
{"alg":"none"}）を受け入れてしまう。 - JWT の有効期限（exp）を検証しない。
- 平文や暗号化なし、弱いハッシュでパスワードを保存している。
- 弱い暗号鍵を使用している。
さらに、マイクロサービスの場合、以下に当てはまると脆弱です：
- 他のマイクロサービスが認証なしでアクセスできる。
- 認証を強制するためのトークンが弱い、または予測可能である。
攻撃シナリオ例
シナリオ #1
ユーザー認証を行うため、クライアントは以下のようにユーザー資格情報を含む API リクエストを発行する：
POST /graphql
{
"query":"mutation {
login (username:\"<username>\",password:\"<password>\") {
token
}
}"
}
資格情報が正しければ、後続リクエストでユーザー識別に使用する認証トークンが返される。ログイン試行には厳しめのレート制限（1 分間に 3 リクエストのみ）が適用される。
被害者アカウントで総当たりログインを行うために、攻撃者は GraphQL のクエリ・バッチング を悪用してリクエストのレート制限を回避し、攻撃を加速させる：
POST /graphql
[
{"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"},
{"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"},
{"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"},
...
{"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"},
]
シナリオ #2
ユーザーアカウントに紐づくメールアドレスを更新するため、クライアントは次のような API リクエストを送る：
PUT /account
Authorization: Bearer <token>
{ "email": "<new_email_address>" }
API が、現在のパスワードの提示による本人確認を要求しないため、認証トークンを盗む立場にある攻撃者は、被害者アカウントのメールアドレスを更新した後にパスワードリセットのワークフローを開始することで、そのアカウントを乗っ取れる可能性がある。
防止方法（How To Prevent）
- モバイル／Web／ワンクリック認証を実装するディープリンク等、API への すべての認証フロー を把握する。見落としているフローがないかエンジニアに確認する。
- 自組織の認証メカニズムを学び、何をどう使っているか理解する。OAuth は認証ではなく、API キーも認証ではない。
- 認証・トークン生成・パスワード保管で独自方式を発明しない。標準 を用いる。
- 資格情報の回復／パスワード忘れエンドポイントは、総当たり対策、レート制限、ロックアウト保護の観点でログインと同等に扱う。
- 機微な操作（例：アカウント所有者のメールアドレス／2FA の電話番号の変更）には 再認証 を要求する。
- OWASP Authentication Cheat Sheet を参照する。
- 可能な限り 多要素認証（MFA） を実装する。
- 認証エンドポイントに対して、資格情報スタッフィング／辞書攻撃／総当たり攻撃を緩和する アンチブルートフォース機構 を実装する（通常の API レート制限より厳格に）。
- 特定ユーザーへの総当たりを防ぐために、アカウントロックアウト／CAPTCHA を実装する。弱いパスワードの拒否チェックも実装する。
- API キーをユーザー認証に使わない。 API キーは API クライアント の認証にのみ使用する。