JWT e OAuth: os sete erros de autenticação que abrem a porta sem quebrar a criptografia
Quase nunca é a criptografia que falha — é como o token é validado, onde é guardado e o que o fluxo OAuth confia. Os sete padrões de autenticação quebrada que mais encontramos, o que testar e como corrigir.
O ataque não arromba o cadeado — usa a porta das traseiras
Quando uma autenticação com JWT ou OAuth cai num pentest, quase nunca é porque quebrámos AES ou RSA. É porque a validação do token tem um buraco, o fluxo confia num parâmetro que o atacante controla, ou o token vive num sítio de onde pode ser roubado. Autenticação quebrada é o item A07 do OWASP Top 10, e é onde uma única falha se torna acesso à conta de qualquer utilizador.
Abaixo, os sete padrões que mais encontramos — o que são, como testamos e o que corrige.
1. alg: none e variantes
O JWT diz como deve ser verificado no próprio header (alg). Bibliotecas antigas ou mal configuradas aceitam alg: none — token sem assinatura — ou não fixam o algoritmo esperado. Teste: trocar o alg para none, remover a assinatura, ver se o backend aceita. Correção: fixar o algoritmo no servidor (allowlist); nunca ler alg do token para decidir como validar.
2. Confusão RS256 → HS256
O servidor usa RS256 (chave pública/privada). O atacante muda o header para HS256 (simétrico) e assina o token usando a chave pública — que é, por definição, pública — como se fosse o segredo HMAC. Bibliotecas que escolhem o verificador pelo alg do token caem nisto. Correção: verificador estritamente ligado ao algoritmo esperado.
3. Segredo HMAC fraco ou revelado
HS256 com um segredo secret, changeme, o nome da empresa, ou um segredo que apareceu num repositório público. Com o segredo, o atacante forja qualquer token — torna-se admin numa linha. Teste: ataque de dicionário offline sobre a assinatura. Correção: segredo aleatório de alta entropia, fora do código, rotacionável.
4. Claims não validados
A assinatura confere, mas o backend não valida exp (expiração), aud (audiência) ou iss (emissor). Token expirado continua válido; token emitido para outro serviço é aceite. Teste: reutilizar token expirado, usar token de outro ambiente/serviço. Correção: validar sempre exp, nbf, aud, iss; rejeitar por defeito.
5. redirect_uri frouxo no OAuth
O coração de muitos account takeovers via SSO. Se o servidor de autorização compara redirect_uri por prefixo ou permite subdomínios/paths arbitrários, o atacante desvia o code ou o token para um domínio que controla. Variações: um open redirect encadeado no fluxo, state ausente (CSRF no login), PKCE não exigido em clientes públicos. Teste: manipular redirect_uri, remover state, intercetar o code. Correção: allowlist exata de redirect_uri, state obrigatório, PKCE em SPA e mobile.
6. Token no sítio errado
Um JWT em localStorage é lido por qualquer XSS — e aí um único XSS torna-se roubo de sessão persistente. Token em logs, no URL (o referer revela), na cache de um CDN. Correção: cookies HttpOnly, Secure, SameSite; nunca token de sessão em localStorage; nunca token na query string.
7. Sem revogação e sessão eterna
O JWT é stateless: uma vez emitido, vale até expirar. Se o exp é longo e não há lista de revogação nem refresh token rotacionado, um token roubado funciona horas ou dias, e mudar a palavra-passe não desliga o atacante. Correção: exp curto + refresh token rotacionado e revogável; invalidar sessões na mudança de palavra-passe e no logout.
Porque é que o scanner não apanha
Quase todos exigem manipular o token e perceber o fluxo — dois contextos, duas contas, um proxy a intercetar o handshake OAuth. Um scanner vê um login que funciona e segue em frente. É teste manual, guiado pelo OWASP WSTG (secção de autenticação) e pelas boas práticas de OAuth 2.0 / OIDC.
O que pedir no pentest
Peça cobertura explícita de: manipulação de alg, confusão de algoritmo, força bruta offline do segredo, validação de claims, todo o fluxo OAuth/OIDC (incluindo redirect_uri, state, PKCE), armazenamento do token e ciclo de vida da sessão. E peça o encadeamento até ao impacto — "forjei um token de admin" vale mais do que "o exp não é validado".
Como a Pentest Machine testa isto
Nos pentests de web e API tratamos a autenticação como superfície de primeira classe: manipulação de JWT, fluxos OAuth/OIDC completos, SSO, armazenamento e sessão, com PoC reproduzível para cada falha e o caminho até ao account takeover quando existe. Relatório executivo + técnico e reteste incluídos. Se usa SSO ou emite JWT para clientes, este é o teste que separa "parece seguro" de "é seguro".