Adultere o Token: Forjando um JWT Quando a Assinatura Não É Verificada
O desafio
Este painel decide o que você pode ver a partir da claim role dentro do seu JWT - e ele nunca verifica a assinatura, então a claim é sua para mudar. Na bancada, edite o payload para que role vire admin. O token se reconstrói ao vivo. Copie o token forjado inteiro (as três partes, com os pontos) e envie.
O que você vai aprender
- Entender que a assinatura de um JWT só protege as claims se o servidor a verificar
- Adulterar uma claim do payload e observar o token ser recodificado em tempo real
- Forjar um token com privilégios escalados alterando a claim role para admin
- Reconhecer falhas na verificação de assinatura (checagens puladas, alg:none) como falhas críticas de autenticação
Habilidades testadas
Pré-requisitos
- Noção de que JWTs carregam claims como role e user id
- Edição básica de JSON
Como funciona
Um JSON Web Token se divide em três partes base64url: header, payload e assinatura. A assinatura é a única coisa que torna o payload confiável - ela é um hash com chave sobre o header e o payload, então se alguém edita uma claim, a assinatura deixa de bater e um servidor correto rejeita o token. Tire essa verificação e o JWT vira o que ele fisicamente é: uma lista de claims simples e editável, com uma string inútil grudada no final.
É essa a falha aqui. O painel lê role diretamente do payload para decidir o acesso, mas nunca verifica a assinatura (um bug real comum, junto com aceitar alg:none). Então você pode simplesmente reescrever a claim. Na bancada você decodifica o payload, muda "role":"guest" para "role":"admin", e a ferramenta recodifica o payload e reconstrói o token ao vivo. A assinatura original - agora matematicamente errada - é mantida sem alteração, e como o servidor não a verifica, seu token forjado autentica você como administrador.
O objetivo do exercício é o ato de forjar, não de ler. Só decodificar não revela nada que um token honesto também não mostraria; a vulnerabilidade só aparece quando você muda uma claim e o servidor ainda confia nela.
Erros comuns
- Apenas ler o payload. Decodificar não custa nada e não prova nada - o bug é que você pode mudar uma claim e ainda assim ser confiado.
- Editar o campo errado. A decisão de acesso é a claim
role; mude o valor dela paraadmin, não o user ou o sub. - Enviar o JSON decodificado. A resposta é o token reconstruído e recodificado (ou seu segmento de payload), não as claims legíveis que você digitou.
- Tentar consertar a assinatura. Você não precisa de uma assinatura válida aqui - o ponto todo é que o servidor nunca a verifica.
Como se proteger
A correção não é negociável: sempre verifique a assinatura com o algoritmo e a chave esperados antes de confiar em qualquer claim, e rejeite alg:none de imediato. Nunca tome uma decisão de autorização com base em um token não verificado.
- Verifique a assinatura do JWT em cada requisição, fixando o algoritmo no lado do servidor (sem
none, sem alg escolhido pelo cliente). - Derive a autorização apenas de claims verificadas e prefira tokens de vida curta.
- Considere sessões no lado do servidor ou revogação de tokens para papéis sensíveis, para que um único token forjado ou roubado não seja o fim do jogo.
