Authentication Bypass (認証の迂回)¶
概要¶
認証を要求する API エンドポイントが無効な認証情報を使用したリクエストに対して 正常なレスポンスを返しました。 保護されたエンドポイントは、クライアント エラーを示す 4xx ステータス コードを 返すことが期待されます。 認証情報がないか無効な場合、通常、サーバーは "403 Forbidden" または "HTTP 401 Unauthorized" を返します。
正常なレスポンスは、未認可のユーザーが機密性の高いエンドポイントにアクセスでき、 情報漏洩が発生したり、未認可の操作が実行されたりする可能性があることを 意味します。認証の迂回はセキュリティ脆弱性です。
推奨事項¶
エンドポイントのコードをレビューし、すべてのケースで必要な認証コードが 実行されていることを確認します。 エンドポイントが認証を要求しない場合、仕様を更新してそのように指定します。 エンドポイントで認証チェックが実行されている場合、指定された認証情報をチェックする コードが有効かどうかをレビューします。 認証チェックが行われる前に、ユーザー入力データが徹底的に検証されていることを 確認します。 バグ レポートの一部とし て Mayhem for API によって提示されたサンプル レスポンスは、問題のデバッグを試みる際の正しい方向性を示している可能性が あります。 妥当性チェックに使用しているライブラリがある場合、ライブラリに問題がある可能性があります。
サンプル¶
認証の迂回は、アノテーションが不足しているといった単純な問題である場合も あります。たとえば、Java Spring Boot のコンテキストでは、次を変更して
@RequestMapping("/super-secret")
public String protectedEndpoint() {
...
}
次のように認証されたユーザーを要求するエンドポイントにする必要がある場合があります。
@RequestMapping("/super-secret")
public String protectedEndpoint(@AuthenticationPrincipal User user) {
... // do stuff with user
}
行う必要がある変更は、アプリケーションでどのように認証をセットアップしたかに よって異なります。 詳細については Spring Security Architecture を 参照してください。
JSON Web Token (JWT) は、API 認証情報の作成に広く使われています。 JWT はクライアントとサーバーの間で JSON オブジェクトとして安全に情報を 伝送する自己完結的な方法です。 トークンは署名され、受信者が JSON の完全性を検証することが可能です。 秘密性を確保するため、トークンを暗号化することもできます。
JWT の形式はコンパクトであり、ドット (.) で区切られた次の 3 つのパートで構成されます。 - ヘッダー - ペイロード - 署名
したがって、典型的な JWT は次のようになります。xxxxx.yyyyy.zzzzz
重要な点として、ヘッダーにはペイロードの検証に使用される署名アルゴリズム
が含まれます。
受信者は、該当アルゴリズムを使用してメッセージの完全性を検証できます。
すぐにわかるとおり、これには鶏が先か卵が先かという問題があります。
受信者は JWT の完全性を検証するために JWT の未検証の情報に依存しているのです。
多くの JWT ライブラリには次のような API があります。
verify(user_provided_jwt, verification_key)
攻撃者はこれを悪用できます。数年前まで、多くの JWT ライブラリはアルゴリズムが 'none' に変更された JWT を有効とし、完全性チェックを完全に無効化して いました。 アルゴリズムを RSA から HMAC に切り替えることによる、より手の込んだ攻撃もありました。
最近では、多くの JWT ライブラリは、JWT ヘッダーで指定されたアルゴリズムを 無視してハードコーディングされたアルゴリズムを使用できるよう API を変更しました。
verify(user_provided_jwt, algorithm, verification_key)