開発者ツール · JWT デコーダー
RFC 8725 の説明: JWT 検証者のための現在のベスト プラクティス
· 背景
jwt セキュリティ 認証
IETF は、既知の JWT の落とし穴を 1 つの現在のベスト プラクティス文書にまとめました。この投稿では、その推奨事項を詳しく説明し、各推奨事項を防止するインシデントのクラスに関連付けます。
JWT の失敗が繰り返されると、検証者のチェックリストが作成されます。リポジトリ ソースが公開履歴を確立しない
柔軟なトークン形式により、検証者が制限する必要がある組み合わせが許可されます。繰り返される間違いには、アルゴリズムのラベルを信頼すること、間違った発行者または対象者のもとでトークンを受け入れること、攻撃者が選択した鍵マテリアルに従うことなどが含まれます。チェックリストは、これらの広範なリスクを実際の許容境界での不合格テストに変換します。
概要では出版履歴を特定の年に帰属させていますが、リポジトリのソースはその履歴を検証していないため、このセクションでは省略しています。実用的な区別はローカルで確立されます。ToolAcre はデコードのみですが、すべてのベスト プラクティスの決定は構成された検証者に属します。
アルゴリズムを固定し、何も拒否しない - alg:none とキーの混乱に対処する推奨事項
許可されたアルゴリズムをヘッダーとは独立してピン留めし、署名が必要なフローでの署名のない入力を拒否します。受け入れられた各アルゴリズム ファミリを正しいキー タイプにバインドします。トークンによってベリファイアが非対称チェックから HMAC に切り替わったり、チェックを無効にしたりしないでください。`none`.
ToolAcre は `none` にフラグを立て、認識されたラベルについて説明しますが、これらの警告は何も強制しません。バックエンドに対するネガティブ テストで実際のポリシーを証明します。予期しないアルゴリズム、空の署名、および間違ったキー タイプは、最初の 2 つのセグメントがデコード可能なままであっても失敗する必要があります。
対象者と発行者を検証する - サービス間のリプレイに対する推奨事項
信頼できるキー構成で発行者を認証し、対象となるユーザーと使用するサービスを比較します。文脈上の要求チェックを行わない有効な署名でも、間違った場所でトークンが承認される可能性があります。コピーされた発行者文字列自体はキー バインドではありません。
デコーダは、予想される構成を認識せずに、`iss` および `aud` の値を表示します。その可視性は、判定を下すためではなく、テスト ケースを特定するために使用します。受け入れテストでは、間違った発行者、間違った対象者、署名の失敗を区別して、運用ログが有用なままになるようにする必要があります。
明示的な型指定を使用します。トークン置換に対する防御として typ ヘッダーを使用します。
明示的なトークンの型指定により、同様のクレーム形状を再利用するプロファイルを分離できます。検証者は、署名された JWT をすべて交換可能として扱うのではなく、特定のエンドポイントにどのようなタイプが期待されるかを認識し、互換性のないプロファイルを拒否する必要があります。
`typ` ヘッダーは検証されるまで信頼されず、ToolAcre はその文字列が `JWT` と異なる場合にのみ警告します。アクセス トークン プロファイル、ネストされたコンテンツ、プロバイダー規則は検証されません。アプリケーションで型ルールを定義し、置換の試行をテストします。
jku、x5u、または埋め込みキーを信頼しないでください - キーソースの推奨事項
`jku`、`x5u`、埋め込み JWK データ、または証明書配列が保護されたヘッダーに表示されるという理由だけでキー ソースを確立させないでください。独立して信頼できる発行者関係と制約付き取得ポリシーを通じてキーを解決します。 `kid` は、その境界内のセレクターとしてのみ扱ってください。
ToolAcre はヘッダー値からのネットワーク ルックアップを実行しません。これは、汎用インスペクターの正しい動作です。監査中に、ヘッダーのメタデータからファイル システム、キャッシュ、データベース、ネットワーク操作までのすべてのパスを追跡し、トークン制御された入力から信頼を生み出すパスをすべて拒否します。
暗号入力と暗号化されたコンテンツのガイダンスは、選択したライブラリとプロファイルでチェックする必要があります
暗号化実装は入力を検証し、選択されたプロファイルのルールに従う必要があります。暗号化設計では、圧縮と観察可能なデータにも注意が必要です。正確な API とデフォルトはライブラリ固有であり、このリポジトリには存在しないため、この記事はスイッチを発明したり、ユニバーサル サポートを主張したりするものではありません。
デプロイされたライブラリとバージョンに関する現在のドキュメントを読み、不正な入力テストとポリシー不一致テストを構築します。デコーダーのクリーンな INVALID_JWT エラーは、検査の人間工学が優れていることを示していますが、別の検証ツールが暗号化のエッジ ケースを正しく処理していることを示す証拠ではありません。
実用的な例 — チェックリストに対する検証ルーチンの監査
信頼できる発行者の構成、承認されたアルゴリズム、キー ソース、対象者、トークン タイプ、時間ポリシー、およびアプリケーション クレームをリストすることにより、検証ルーチンを監査します。項目ごとに、構文的には読み取り可能だが、期待値を 1 つだけ破る否定トークンを追加します。実際の境界での拒否を確認します。
ToolAcre は、各フィクスチャの主張を検査し、意図した突然変異が存在することを確認する場合にのみ使用してください。その出力をフィクスチャが無効であるというアサーションとして使用しないでください。検証者の応答とログはその証拠を提供しますが、デコーダーは受け入れられた例と拒否された例にわたって一定のままです。
要点: ライブラリではなくチェックリスト — ToolAcre JWT デコーダーは、監査中にトークンを検査するのに役立ちます。プラクティスは作成した検証者に適用されます
ベスト プラクティス文書はチェックリストであり、検証ライブラリではありません。その価値は、チームが推奨事項を明示的な構成、狭い信頼関係、およびフェールクローズされたテストに変換するときに現れます。デコーダは、その作業中にトークン入力を判読できるようにすることはできますが、コントロールを実装することはできません。
ドキュメントと UI の境界を維持します。デコードされたとは、読み取り可能である、本物ではない、変更されていない、承認されている、または受け入れられることを意味します。トークンの外側にポリシーを固定し、最初に検証して、次にクレームを適用します。 ToolAcre は、これらすべての決定の前に意図的に停止します。