Asterix Soluções • Red Team • Pesquisa ofensiva
O JSON Web Token (JWT) virou o padrão de autenticação de praticamente toda API moderna — e justamente por isso é um dos alvos preferidos de quem ataca. Um token mal validado não é um detalhe: é a chave que abre todas as portas da aplicação.
Neste artigo, nossa equipe de Red Team percorre cinco vulnerabilidades reais que encontramos — e exploramos — em testes autorizados. Para preservar a confidencialidade dos clientes, o host real foi mascarado (api.████████.com) em todos os comandos. O foco aqui é o método, não o alvo.
alg: none — o token sem assinaturaA especificação do JWT permite o algoritmo none, que significa “token sem assinatura”. Se o backend não rejeitar explicitamente esse valor, o atacante simplesmente troca o alg para none, apaga a assinatura e altera os claims à vontade — inclusive role: admin. É a falha mais antiga e ainda surpreendentemente comum.
Quando o servidor assina com RS256 (chave privada/pública) mas confia no campo alg do token, o atacante troca para HS256 e assina usando a chave pública — que é aberta, exposta no jwks.json — como se fosse o segredo HMAC. O servidor valida e aceita. Resultado: forja total sem jamais ter a chave privada.
Tokens HS256 dependem de um segredo compartilhado. Se esse segredo for curto ou previsível (secret, 123456, o nome da empresa…), ele pode ser quebrado offline — sem gerar um único log no servidor. Com o segredo em mãos, o atacante assina qualquer token válido que quiser.
Aqui o token é perfeitamente válido — o problema é de autorização. A aplicação confia no identificador que vem na URL (ou no corpo da requisição) em vez de amarrar o recurso ao sub/user_id do próprio token. Basta trocar um número na URL para ler dados de outros usuários: o clássico IDOR (Insecure Direct Object Reference). Não é preciso forjar nada.
kidO campo kid (key ID) diz ao servidor qual chave usar para verificar o token. Quando esse valor entra em uma consulta a arquivo ou banco sem sanitização, vira vetor de path traversal ou SQL injection: o atacante aponta o kid para um conteúdo que ele controla (ou para um arquivo vazio) e passa a assinar tokens com um segredo conhecido.
As cinco falhas têm a mesma raiz: o servidor confiou em dados controlados pelo atacante — o algoritmo, o segredo, o identificador do recurso, a chave. Um JWT prova identidade, mas a aplicação continua responsável por verificar e autorizar cada ação no servidor.
✓ Fixe o algoritmo no servidor com uma allowlist explícita; rejeite none e a confusão RS256/HS256.
✓ Use segredos fortes e aleatórios (256 bits+) para HS256, ou prefira chaves assimétricas bem gerenciadas.
✓ Valide a autorização no backend: amarre cada recurso ao sub do token — nunca confie no ID da URL. (mata o IDOR)
✓ Não use dados do token (kid, jku) em consultas sem sanitização; restrinja a chaves conhecidas.
✓ Valide exp, iss e aud e use tokens de curta duração com rotação.
✓ Teste de forma ofensiva. Um Red Team encontra essa classe de falha antes do invasor real.
Na Asterix Soluções, simulamos o atacante real para revelar — e ajudar a corrigir — falhas como estas antes que elas custem caro. Segurança além do que você imagina.
Mantenha-se protegido com as nossas soluções de cibersegurança de ponta. A sua segurança é a nossa prioridade.
© 2025 Asterix Soluções. Todos os direitos reservados.