Confusão de Claims JWT em Competições

Use esta habilidade apenas como uma especialização downstream, depois que $ctf-sandbox-orchestrator já estiver ativo e tiver estabelecido suposições de sandbox, propriedade de nós e prioridades de evidências. Se isso ainda não aconteceu, retorne primeiro para $ctf-sandbox-orchestrator.

Use esta habilidade quando o bug decisivo não for apenas "existe um JWT", mas como cabeçalhos, claims e seleção de chaves se transformam em identidade aceita.

Responda em português do Brasil, a menos que o usuário solicite explicitamente o inglês.

Início Rápido

1. Divida o caminho do token em análise, busca de chave, assinatura ou descriptografia, validação de claims e aceitação final.
2. Registre os campos do cabeçalho, claims, origem da chave, emissor, público e mapeamento de função antes de modificar qualquer coisa.
3. Separe a posse de um token do serviço exato que o aceita.
4. Mantenha o comportamento do parser, a política de confiança e a sessão de aplicativo ou privilégio resultante em uma única cadeia.
5. Reproduza o menor fluxo de token para aceitação que comprove a confusão decisiva.

Fluxo de Trabalho

1. Mapear Cabeçalho e Seleção de Chave

• Registre campos do cabeçalho como alg, kid, typ, cty, jku ou material de chave incorporado quando presente.
• Observe de onde vêm as chaves: configuração estática, JWKS, arquivo local, cache ou busca dinâmica.
• Mantenha o parser de token, o caminho de seleção de chave e o modo de validação interligados.

2. Provar Aceitação de Claim para Privilégio

• Mostre como subject, audience, issuer, tenant, scope, role ou claims personalizados se tornam sessão de aplicativo, acesso a rotas ou privilégio de backend.
• Registre expiração, not-before, desvio de relógio, correspondência de emissor, correspondência de público e comportamento de normalização de claims.
• Distinga o sucesso da análise do token do sucesso real da autorização.

3. Reduzir ao Caminho JWT Decisivo

• Comprima o resultado para a menor sequência: token fornecido -> caminho do parser ou chave tomado -> claim aceito -> capacidade resultante.
• Mantenha um caminho de token aceito canônico e um caminho de token modificado se a confusão ou bypass depender de uma diferença.
• Se a tarefa se expandir para uma cadeia de redirecionamento OAuth maior, retorne para a habilidade OAuth mais específica.

Leia esta Referência

• Carregue references/jwt-claim-confusion.md para a lista de verificação de cabeçalho, lista de verificação de claims e empacotamento de evidências.

O Que Preservar

• Cabeçalhos brutos, claims, origem da chave, JWKS ou caminho de chave local e o serviço aceitador
• A etapa exata de validação ou normalização que transforma o token em identidade aceita
• Uma sequência mínima reproduzível de token para aceitação