Nosso RedTeam está preparado para trazer um cenário de simulação de ameaças onde lançamos mão…
Durante um exercício de Red Team autorizado, nossa equipe foi contratada para avaliar a API de autenticação de um cliente. Por motivos de confidencialidade, o host real foi mascarado ao longo de todo este artigo — o que importa aqui não é quem, mas como uma falha aparentemente inofensiva vira acesso administrativo total.
O alvo usava JSON Web Tokens (JWT) para controlar sessões e permissões. JWT é o padrão por trás de boa parte das autenticações modernas — e também uma das fontes mais recorrentes de falhas críticas quando mal implementado.
Um JWT é composto por três partes separadas por ponto, codificadas em base64url:
1. Header — diz qual algoritmo assina o token (ex.: RS256, HS256).
2. Payload — os dados (claims), como sub, role, exp.
3. Assinatura — garante que o token não foi adulterado.
A diferença crucial: RS256 usa um par de chaves assimétricas (chave privada assina, chave pública verifica), enquanto HS256 usa uma única chave simétrica (o mesmo segredo assina e verifica). É exatamente nessa diferença que mora a falha.
Muitas bibliotecas antigas (e código escrito sem cuidado) deixam o servidor confiar no campo alg que vem dentro do próprio token. O fluxo vulnerável é:
• O servidor espera RS256 e verifica com a chave pública.
• A chave pública é — por definição — pública (exposta em /.well-known/jwks.json).
• O atacante troca o alg para HS256 e assina o token usando essa mesma chave pública como se fosse o segredo HMAC.
• O servidor, ao ver HS256, valida com HMAC usando a chave pública — que o atacante conhece. A assinatura bate.
Resultado: o invasor consegue forjar qualquer token, com qualquer permissão, sem nunca ter a chave privada. Veja a sessão de exploração abaixo:
Com um único token forjado, a equipe escalou de role:user para role:admin e acessou o endpoint /v1/admin/users, que lista todas as contas privilegiadas. Em um cenário real, isso significa controle total da aplicação: criação de usuários, leitura de dados sensíveis, e movimentação lateral para outros sistemas. Tudo isso sem explorar nenhuma senha — apenas a confiança indevida no campo alg.
✓ Fixe o algoritmo no servidor. Nunca aceite o alg vindo do token — defina uma allowlist explícita (ex.: aceitar somente RS256).
✓ Separe as chaves por uso. A chave de verificação RS256 jamais deve ser aceita como segredo HMAC.
✓ Use bibliotecas atualizadas que rejeitam alg:none e a confusão de algoritmos por padrão.
✓ Valide claims críticos (iss, aud, exp) e prefira tokens de curta duração.
✓ Teste de forma ofensiva. Um Red Team encontra essa classe de falha antes que um invasor real o faça.
A Asterix Soluções simula o atacante real para que a sua empresa descubra — e corrija — falhas como esta 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.
