competition-jwt-claim-confusion

競技 JWT クレーム混同

このスキルは、$ctf-sandbox-orchestrator がすでに有効であり、サンドボックスの前提、ノードの所有権、および証拠の優先順位を確立した後にのみ、下流の特殊化として使用してください。まだそれが行われていない場合は、まず $ctf-sandbox-orchestrator に戻ってください。

このスキルは、決定的なバグが単に「JWT がある」ことではなく、ヘッダー、クレーム、およびキー選択がどのようにして受け入れられるアイデンティティに変わるかである場合に使用してください。

ユーザーが明示的に英語を要求しない限り、簡体字中国語で回答してください。

クイックスタート

1. トークンのパスを、パース、キー検索、署名または復号、クレーム検証、および最終的な受け入れに分割します。
2. 何かを変更する前に、ヘッダーフィールド、クレーム、キーソース、発行者、対象者、およびロールマッピングを記録します。
3. トークンの所持と、それを正確に受け入れるサービスを分離します。
4. パーサーの動作、信頼ポリシー、および結果として生じるアプリのセッションまたは権限を 1 つのチェーンにまとめます。
5. 決定的な混同を証明する、最小のトークンから受け入れまでのフローを再現します。

ワークフロー

1. ヘッダーとキー選択をマッピングする

• 存在する場合は、alg、kid、typ、cty、jku、または埋め込みキーマテリアルなどのヘッダーフィールドを記録します。
• キーの出所を記録します: 静的設定、JWKS、ローカルファイル、キャッシュ、または動的検索。
• トークンパーサー、キー選択パス、および検証モードを結び付けたままにします。

2. クレームから権限への受け入れを証明する

• サブジェクト、対象者、発行者、テナント、スコープ、ロール、またはカスタムクレームが、どのようにしてアプリのセッション、ルートアクセス、またはバックエンドの権限になるかを示します。
• 有効期限、not-before、クロックスキュー、発行者の照合、対象者の照合、およびクレーム正規化の動作を記録します。
• トークンのパース成功と、実際の認可成功を区別します。

3. 決定的な JWT パスに還元する

• 結果を最小のシーケンスに圧縮します: トークンが提供される -> パーサーまたはキーパスが取られる -> クレームが受け入れられる -> 結果として得られる権限。
• 混同またはバイパスが差分に依存する場合は、1 つの正規の受け入れられたトークンパスと、1 つの改変されたトークンパスを保持します。
• タスクがより大きな OAuth リダイレクトチェーンに広がる場合は、より厳密な OAuth スキルに引き継ぎます。

このリファレンスを読む

• ヘッダーチェックリスト、クレームチェックリスト、および証拠のパッケージ化については、references/jwt-claim-confusion.md を読み込んでください。

保持すべきもの

• 生のヘッダー、クレーム、キーソース、JWKS またはローカルキーパス、および受け入れるサービス
• トークンを受け入れられたアイデンティティに変える、正確な検証または正規化のステップ
• 1 つの最小限で再生可能なトークンから受け入れまでのシーケンス