攻撃者の影響
不適切な JWT 検証により、攻撃者はクレームを偽造したり、期限切れのトークン [S1] を再利用したりすることで認証メカニズムをバイパスできます。サーバーが有効な署名のないトークンを受け入れると、攻撃者はペイロードを変更して特権を昇格したり、任意のユーザー [S1] になりすますことができます。さらに、有効期限 (exp) 要求を強制しないと、攻撃者は侵害されたトークン [S1] を無期限に使用することができます。
根本原因
JSON Web トークン (JWT) は、デジタル署名または整合性が保護されたクレーム ([S1]) を表すために使用される JSON ベースの構造です。セキュリティ障害は通常、次の 2 つの主要な実装ギャップから発生します。
- 安全でない JWT の受け入れ: サービスが署名検証を厳密に強制しない場合、署名が存在せず、アルゴリズムが「なし」 [S1] に設定されている「安全でない JWT」を処理する可能性があります。このシナリオでは、サーバーはペイロード内のクレームの整合性を検証せずにそのクレームを信頼します ([S1])。
- クレーム検証の欠落:
exp(有効期限) クレームは、[S1] の処理のために JWT が受け入れられてはならない時間を識別します。aud(audience) クレームは、トークン [S1] の対象受信者を識別します。これらがチェックされていない場合、サーバーは期限切れのトークン、または別のアプリケーション [S1] を対象としたトークンを受け入れる可能性があります。
具体的な修正
- 暗号化署名の強制: 事前承認された強力な署名アルゴリズム (RS256 など) を使用しない JWT を拒否するようにアプリケーションを構成します。
- 有効期限の検証: 現在の日付と時刻が、
expクレーム [S1] で指定された時刻より前であることを確認する必須チェックを実装します。 - 対象ユーザーの確認:
audクレームにローカル サービスを識別する値が含まれていることを確認します。サービスがaudクレームで識別されない場合、トークンは [S1] で拒否される必要があります。 - リプレイの防止:
jti(JWT ID) クレームを使用して各トークンに一意の識別子を割り当て、サーバーがトークン [S1] を追跡して再利用できるようにします。
検出戦略
JWT 処理の脆弱性は、トークン構造とサーバー応答動作を分析することで特定できます。
- ヘッダー検査:
alg(アルゴリズム) ヘッダーをチェックして、ヘッダーが「なし」に設定されておらず、予期される暗号化標準 [S1] を使用していることを確認します。 - クレーム検証: JSON ペイロード [S1] 内の
exp(有効期限) およびaud(オーディエンス) クレームの存在と有効性を確認します。 - 検証テスト:
expクレームに従って期限切れになったトークン、またはaudクレーム [S1] によって定義された別の対象者を対象としたトークンをサーバーが正しく拒否するかどうかをテストします。