Forjando a Claim de Grupo: Escalando para Admin via cognito:groups
O desafio
Este app na nuvem autoriza ações de admin a partir de uma claim de grupo aninhada no seu JWT, o array cognito:groups no estilo Cognito. Você está no grupo users, mas o backend lê esse array direto do token e nunca verifica a assinatura. Na bancada, edite o payload para que cognito:groups vire ["admins"]. Cuidado com o JSON: é um array de strings, então mantenha os colchetes e as aspas intactos. Copie o token forjado inteiro e envie.
O que você vai aprender
- Entender como provedores de nuvem embutem a participação em grupos em claims de JWT
- Editar uma claim de array aninhado mantendo o JSON estruturalmente válido
- Forjar acesso de admin mudando cognito:groups de users para admins
- Reconhecer claims de grupo não verificadas como uma falha crítica de autorização
- Saber que a autorização deve derivar de um token com assinatura verificada
Habilidades testadas
Pré-requisitos
- Um JWT tem três partes em base64url: header, payload, signature
- Claims podem ser aninhadas, incluindo arrays de strings
- Edição básica de JSON
Como funciona
Sistemas de identidade na nuvem como o Amazon Cognito anexam os grupos de um usuário ao token como uma claim aninhada, convencionalmente cognito:groups, cujo valor é um array de nomes de grupo. As aplicações então mapeiam esses grupos para permissões: se o array contém admins, concede acesso de admin. Isso só funciona quando a assinatura do token foi verificada com a chave do provedor de identidade, porque essa verificação é o que prova que a lista de grupos veio do provedor e não foi editada por quem detém o token.
Este backend lê o array mas nunca verifica a assinatura, então o JWT é apenas JSON editável. O desafio em relação a uma claim plana é que o alvo aqui é aninhado e estruturado: {"cognito:groups":["users"]}. Você precisa mudar ["users"] para ["admins"] mantendo um array JSON válido de strings - os colchetes e as aspas duplas em volta da string precisam permanecer, ou o payload não será interpretado. A bancada recodifica o payload corrigido e reconstrói o token, carregando a assinatura original (agora inválida), que o servidor ignora.
O resultado é um token que afirma participação em admins e é aceito como tal. A falha é idêntica em espírito a uma forja de role plana - a única dificuldade adicionada é editar a estrutura aninhada corretamente.
Erros comuns
- Quebrar a estrutura do JSON.
cognito:groupsé um array de strings; mantenha os colchetes e as aspas, por exemplo["admins"], e nãoadminssozinho. - Editar a claim errada. A autorização depende do array de grupo, não de
subouemail. - Tentar corrigir a assinatura. Nenhuma assinatura válida é necessária aqui; o servidor nunca a verifica.
- Enviar o JSON decodificado. Envie o token reconstruído e recodificado (ou seu segmento de payload), não as claims legíveis por humanos.
Como se proteger
A autorização baseada em grupo só é tão forte quanto a verificação do token por trás dela. Verifique primeiro, depois confie na claim.
- Verifique a assinatura do JWT com a chave publicada pelo provedor de identidade (JWKS) antes de ler qualquer claim de grupo, e rejeite
alg:none. - Confirme se o issuer e o audience do token correspondem à sua aplicação, para que um token emitido em outro lugar não possa ser reutilizado.
- Reverifique a participação em grupos junto ao provedor para ações sensíveis de admin, em vez de confiar em uma claim em cache de longa duração.
- Mantenha os tokens de curta duração e registre ações sensíveis a privilégio para que um grupo forjado seja detectável.