Vulnerabilidades de JWT: alg=none e confusão de chaves

Os JWTs são assinados criptograficamente, mas muitas bibliotecas apresentaram vulnerabilidades graves. As mais exploradas são o ataque alg=none, o ataque de confusão RS256→HS256 e a força bruta contra segredos fracos. Todos decorrem de confiar em campos do cabeçalho controlados pelo invasor.

A especificação de JWT permite alg:"none" para tokens sem proteção. Bibliotecas defeituosas aceitavam isso e ignoravam completamente a verificação da assinatura. Um invasor modifica a carga útil (por exemplo, "role":"admin"), define alg:"none", remove a assinatura e o servidor aceita o token.

Original: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Ataque: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (assinatura vazia, ponto final). Um servidor vulnerável verifica o token com sucesso e concede acesso de administrador.

Nunca aceite alg:"none" em produção. Defina explicitamente uma lista de permissões para os algoritmos aceitos: jwt.decode(token, key, algorithms=["HS256"]). A maioria das bibliotecas modernas (PyJWT 2+, jsonwebtoken 9+) rejeita alg=none por padrão.

Se um servidor usa RS256 e um cliente altera alg para HS256, o servidor poderá verificar usando sua chave pública RSA como segredo HMAC. Como a chave pública é... pública, o invasor assina cargas úteis arbitrárias com ela e o servidor as verifica.

Etapas: 1) Busque a chave pública no endpoint JWKS. 2) Crie uma carga útil maliciosa. 3) Assine com HMAC-SHA256 usando os bytes brutos da chave pública PEM como segredo HMAC. 4) Defina alg:"HS256" no cabeçalho. 5) O caminho HS256 do servidor verifica o token com sucesso.

Sempre especifique explicitamente o algoritmo esperado na chamada de verificação. Nunca derive o algoritmo do cabeçalho do token. Use caminhos de código separados para RS256 e HS256, que não possam ser alternados pelo chamador.

HS256 com segredos fracos (menos de 256 bits de entropia) pode ser quebrado por força bruta offline. Ferramentas como hashcat permitem quebrar JWTs: hashcat -a 0 -m 16500 token.txt wordlist.txt. Use segredos criptograficamente aleatórios de pelo menos 32 bytes.

O cabeçalho kid (ID da chave) seleciona qual chave usar. Se o servidor usar kid como parâmetro de consulta SQL ou caminho do sistema de arquivos sem higienização: kid="../../dev/null" → HMAC com chave vazia → token falsificado aceito. Sempre higienize kid.

O cabeçalho jwk incorpora uma chave pública para verificação. Um servidor vulnerável poderá usar diretamente a chave incorporada, permitindo que o invasor forneça seu próprio par de chaves, assine o token com a chave privada e incorpore a chave pública. Verifique somente com chaves registradas.

Algumas implementações esqueceram de verificar a declaração exp ou usaram o horário do servidor de forma inconsistente. Sempre valide explicitamente exp, nbf e iat. Use uma biblioteca que faça essas verificações por padrão e nunca desative a validação de declarações em produção.

No ataque de confusão de chaves RS256→HS256, o que o invasor usa como segredo HMAC?

As vulnerabilidades de JWT surgem de confiar no cabeçalho alg, aceitar alg=none e usar segredos fracos. Correção: fixe os algoritmos no verificador, use segredos fortes e higienize kid. Próximo: práticas para implementar JWTs com segurança.