認証の欠如（Broken Authentication）
| 脅威エージェント/攻撃ベクトル | セキュリティの弱点 | 影響 |
|---|---|---|
| API特有：悪用の容易さ 簡単 | 普及度 一般的：検出容易度 簡単 | 技術的影響 重大：ビジネス特有 |
| 認証機構はすべての人に公開されているため、攻撃者にとって容易な標的となります。いくつかの認証問題を悪用するには高度な技術スキルが必要かもしれませんが、悪用ツールは一般的に利用可能です。 | ソフトウェアおよびセキュリティエンジニアの認証境界に関する誤解や、認証の実装の複雑さから、認証問題が広まっています。認証の欠如を検出する手法は利用可能であり、作成も容易です。 | 攻撃者はシステム内の他のユーザーのアカウントを完全に制御し、個人データを読み取り、代理で機密操作を実行できます。システムは攻撃者の操作と正当なユーザーの操作を区別できない可能性があります。 |
APIは脆弱ですか？
認証エンドポイントとフローは保護する必要がある資産です。さらに、「パスワードの忘れ/リセット」も認証機構と同様に扱うべきです。
以下の場合、APIは脆弱です：
- 攻撃者が有効なユーザー名とパスワードのリストを使用してブルートフォース攻撃（クレデンシャルスタッフィング）を行うことができる。
- 攻撃者が同一ユーザーアカウントに対してブルートフォース攻撃を行うことができ、キャプチャ/アカウントロックアウトメカニズムが存在しない。
- 弱いパスワードを許可する。
- 認証トークンやパスワードなどの機密認証情報をURLに送信する。
- ユーザーがメールアドレス、現在のパスワードを変更する、または他の機密操作を行う際にパスワード確認を要求しない。
- トークンの真正性を検証しない。
- 署名されていない/弱い署名のJWTトークン（
{"alg":"none"}）を受け入れる。 - JWTの有効期限を検証しない。
- プレーンテキスト、非暗号化、または弱いハッシュ化されたパスワードを使用する。
- 弱い暗号鍵を使用する。
さらに、マイクロサービスが脆弱である場合：
- 他のマイクロサービスが認証なしでアクセスできる。
- 認証を強制するために弱いまたは予測可能なトークンを使用する。
攻撃シナリオの例
シナリオ #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が現在のパスワードを提供してユーザーの身元を確認することを要求しないため、悪意のある者が認証トークンを盗むことができれば、被害者のアカウントのメールアドレスを更新した後、パスワードリセットのワークフローを開始して被害者のアカウントを乗っ取ることができます。
防止方法
- APIへの認証フロー（モバイル/ウェブ/ワンクリック認証を実装するディープリンクなど）をすべて把握していることを確認してください。エンジニアに、見逃したフローがないか尋ねてください。
- 認証機構について学んでください。それらが何であり、どのように使用されるかを理解してください。OAuthは認証ではなく、APIキーも認証ではありません。
- 認証、トークン生成、パスワード保存で車輪の再発明をしないでください。標準を使用してください。
- クレデンシャルリカバリー/パスワード忘れのエンドポイントは、ブルートフォース、レート制限、およびロックアウト保護に関してログインエンドポイントと同様に扱うべきです。
- 機密操作（例：アカウント所有者のメールアドレス/2FA電話番号の変更）に対して再認証を要求してください。
- OWASP Authentication Cheatsheetを使用してください。
- 可能な場合は、多要素認証を実装してください。
- 認証エンドポイントに対するクレデンシャルスタッフィング、辞書攻撃、およびブルートフォース攻撃を軽減するために、アンチブルートフォースメカニズムを実装してください。このメカニズムは、APIの通常のレート制限メカニズムよりも厳格であるべきです。
- 特定のユーザーに対するブルートフォース攻撃を防ぐために、アカウントロックアウト/キャプチャメカニズムを実装してください。弱いパスワードチェックを実装してください。
- APIキーはユーザー認証に使用すべきではありません。それらはAPI