開発者ツール · JWT デコーダー
alg:none 攻撃と主要な混乱: 検証者がアルゴリズムを固定する必要がある理由
· なぜそれが重要なのか
jwt セキュリティ 暗号化
検証者がトークンに独自のアルゴリズムを選択させた場合、攻撃者は何も選択しないか、RSA を HMAC に交換する可能性があります。この投稿では、両方の攻撃とそれを防ぐルールについて説明します。
自身を検証したトークン — ヘッダーフィールドがどのようにして攻撃対象領域になったか
アルゴリズム ラベルは、攻撃者が制御するトークン入力内に存在します。検証者がそのラベルを利用可能な検証モードを選択する許可として扱う場合、トークンはそれ自体を判断するために使用されるルールに影響を与え始めます。 ToolAcre は、レビュー担当者がラベルを確認できるようにラベルを正確に公開しますが、ラベルを暗号化して操作することはありません。
安全な方向はその逆です。信頼できるサービス構成では、許容可能なアルゴリズム ファミリと関連キーが定義されており、受信ヘッダーはそのポリシーに一致する必要があります。デコード パネルはそのポリシーを提供できないため、疑わしい値を強調表示するという理由だけで保護されていると誤解してはなりません。
リポジトリは alg:none にフラグを立てますが、セキュリティで保護されていない JWT の背後にある仕様履歴を確立しません。
実装は `alg: none` を署名されていない宣言として扱い、これを受け入れると任意のコンテンツを受け入れることになると警告します。また、空の 3 番目のセグメントも個別にレポートします。リポジトリの証拠は、認証されたワークフローでのそのような入力の拒否をサポートしています。セキュリティで保護されていない JWT が最初に仕様に含まれていた理由については文書化されていません。
したがって、その歴史的な文言は創作されたものではなく、修正されたものです。運用上重要なことは明らかです。署名された資格情報を期待するサービスでは、トークン ヘッダーで署名チェックを無効にすることを許可してはなりません。 ToolAcre 自体は検証を実行しないため、`none` を表示する機能は検査のみを目的とした検出です。
alg:none 攻撃 - 署名を剥ぎ取り、検証者に空の署名を受け入れるよう要求する
署名されていない攻撃は、ヘッダーを変更して `none` を要求し、必要に応じてクレームを変更し、署名バイトを提供しません。すべてのセグメントは依然として構文的に有効であり、最初の 2 つは洗練された JSON にデコードされます。寛容な検証者は、攻撃者の好みを認証バイパスに変換します。
厳密な検証ツールには、署名付きトークンが必要な場合にこの入力を信頼できるステータスにアップグレードするブランチがありません。 ToolAcre の警告はデバッグ中に形状を識別するのに役立ちますが、`none` という単語を読んでもバックエンドによる誤った決定は阻止されません。資格情報が使用される場所に強制が適用されます。
鍵の混乱 - RS256 トークンが HS256 として検証されるように、公開鍵を HMAC シークレットとして提示する
鍵の混乱は、検証者が互換性のない鍵の役割を持つアルゴリズム ファミリを許可し、各選択を正しい鍵タイプにバインドできない場合に発生します。公開 RSA 検証キーは HMAC シークレットではありません。攻撃者がアルゴリズム ラベルを変更した後にそのバイトを 1 つとして扱うと、意図した public/private 分離が崩壊します。
この種のエラーを防ぐには、署名の形をしたセグメントをチェックするだけでは不十分です。サービスは、信頼できる構成を通じて、期待されるアルゴリズム、キーの種類、発行者、およびトークン プロファイルをペアにする必要があります。 RS256 または HS256 を示すデコーダーは、バックエンドがそれらのバインディングを維持しているかどうかを判断できません。
修正 — 受け入れられたアルゴリズムを検証器に固定し、トークンから派生させない
検証者構成で受け入れられたアルゴリズムを固定し、発行者の契約が許可する限りリストを狭く保ちます。別のアルゴリズムを試行するのではなく、署名された資格情報フローの `none` を拒否し、不一致を拒否します。未検証のヘッダーまたはペイロード要求からホワイトリストを導出しないでください。
キーの検索も同じ原則に従います。 `kid` は、すでに信頼されている候補の中から選択できますが、新しい信頼ソースを作成してはなりません。ヘッダー URL や埋め込みキーは、単にトークンが要求するという理由だけで従うべきではありません。検証者はそのソースを独自に決定します。
うまくいった例 — ToolAcre JWT デコーダーのヘッダーを読み取って alg:none を検出する、およびそれを検出することが保護されることと同じではない理由
`none` を宣言する無害なトークン ヘッダーを作成し、3 番目のセグメントを空のままにします。 ToolAcre は JSON をデコードし、宣言されたアルゴリズムを報告し、署名されていないことを警告し、署名が存在しないことに注意します。これはまさに検査ツールに期待される動作です。
この演習では、API がトークンを拒否することは証明されません。実際の検証ツールと構成に対して制御された陰性テストを使用して、それを個別に確認します。 API がそれを受け入れる場合、修正はその検証境界内に属します。デコーダに大音量の警告を追加しても、リクエストは保護されません。
これでカバーされないもの — 多くのライブラリ固有の修正。 RFC 8725 とライブラリの変更ログを参照してください。
ライブラリ API、デフォルト、および過去の修正は、製品およびバージョンによって異なります。このモジュールは、どのオプション名がスタック内のアルゴリズムを固定するかを確立するものではなく、この記事では意図的に何も考え出しません。選択したライブラリの現在のドキュメントと変更ログを読み、独自のテスト スイートで拒否のケースを実行します。
間違ったキー タイプ、不明な `kid` 値、不足している署名、および予期しないトークン プロファイルもテストします。目標は、構成がトークンの提案よりも優先されることを示すことです。構文の成功はあらゆる悪意のある例と互換性があるため、デコードの成功はこれらの受け入れアサーションのどこにも属しません。
要点: トークンではなく検証者が決定します。デコーダーはヘッダーを確認するのに役立ちますが、固定された検証のみが保護します
検証者が決定します。トークンはそうではありません。 ToolAcre は、`none` というヘッダー、見慣れないアルゴリズム、または驚くべきキー識別子を明らかにする可能性があります。この可視性は優先順位付けに役立ちますが、受け入れを妨げるのは固定されたアルゴリズム ポリシーと正しくバインドされた信頼できるキーのみです。
`none` を有効にしたり、信頼できないヘッダーから検証キーを選択したり、表示された署名の長さを検証として扱ったりすることは決して推奨しません。検査のためにデコードし、制御されたテストを使用して、実際の暗号境界での拒否および受け入れの動作を証明します。