Forjando o Tier: Escalando Privilégios com uma Claim JWT Não Verificada
O desafio
Esta plataforma de IA escolhe qual modelo você pode chamar a partir da claim tier dentro do seu JWT. Você está no tier gratuito, mas o backend confia nessa claim sem nunca verificar a assinatura do token. Na bancada, edite o payload para que tier vire enterprise. O token se reconstrói ao vivo. Copie o token forjado inteiro e envie.
O que você vai aprender
- Entender que claims de tier e plan só controlam recursos se o token for verificado
- Adulterar uma claim do payload e ver o token ser recodificado em tempo real
- Forjar um token com privilégios escalados definindo tier como enterprise
- Reconhecer claims confiadas pelo cliente como uma falha de cobrança e autorização
- Saber que direitos devem ser verificados no servidor, não lidos de um token do cliente
Habilidades testadas
Pré-requisitos
- Um JWT tem três partes em base64url: header, payload e signature
- Claims de direitos como tier e plan ficam no payload
- Edição básica de JSON
Como funciona
Muitos produtos mapeiam um tier de cobrança para recursos: leem a claim tier do token do usuário e decidem qual modelo, limite de taxa ou capacidade conceder. Isso só é seguro quando a assinatura do token foi verificada, porque a assinatura é a única coisa que prova que a claim foi emitida pelo servidor e não editada pelo portador. Este backend pula a verificação, então a prova está ausente.
Sem verificação de assinatura, o JWT é apenas uma lista de claims codificada em base64url que você pode reescrever à vontade. O controle de recurso se baseia em tier, então você muda "tier":"free" para "tier":"enterprise". A bancada recodifica o payload e reconstrói o token; a assinatura original é mantida sem alteração e agora está matematicamente errada, mas como o servidor nunca a verifica, o token forjado é aceito e o modelo enterprise é liberado.
O problema mais profundo é confiar em um valor mantido pelo cliente para uma decisão de autorização ou cobrança. Mesmo um token perfeitamente assinado pode divergir do estado real da conta, por isso os direitos sensíveis devem ser confirmados com registros do lado do servidor.
Erros comuns
- Apenas decodificar o token. Ler
tiernão prova nada - o problema é que você pode mudá-lo e ainda assim ser confiado. - Editar o campo errado. O controle lê
tier; defina-o comoenterprise, nãomodelouuser. - Tentar corrigir a assinatura. Você não precisa de uma assinatura válida aqui; o servidor nunca a verifica.
- Enviar o JSON decodificado. Envie o token reconstruído (ou seu segmento de payload), não as claims em formato legível.
Como se proteger
Verifique a assinatura antes de ler qualquer claim, e trate direitos como estado do lado do servidor, não como um valor fornecido pelo cliente.
- Verifique a assinatura do JWT com o algoritmo e a chave esperados em toda requisição; rejeite
alg:none. - Confirme tier e plan em um registro autoritativo do lado do servidor (o sistema de cobrança), não apenas na claim do token.
- Mantenha os tokens de curta duração para que um direito desatualizado ou forjado não persista.
- Registre e alerte sobre tokens cujo tier declarado não corresponda à conta, o que revela tentativas de adulteração.