hunt-forgot-password

⚠️ USO AUTORIZADO APENAS Esta habilidade destina-se apenas a 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.

Portão de confirmação obrigatório 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.

Prioridade de Teste Autônomo

Comece com a enumeração de nomes de usuário — é a vitória mais rápida e controla o resto.

Padrão 1 — Enumeração de nomes de usuário (diferença de resposta para e-mail válido vs. inválido):

1. POST para o endpoint "esqueci minha senha" com um e-mail claramente inválido (por exemplo, nonexistent@fakedomain12345.com) — registre o corpo da resposta, código de status e comprimento
2. POST com um e-mail que você sabe que existe (ou tente padrões comuns como admin@target.com, test@target.com, user@target.com)
3. Compare as respostas: mensagem diferente ("E-mail enviado" vs. "E-mail não encontrado"), código de status HTTP diferente ou comprimento do corpo significativamente diferente = enumeração de nome de usuário confirmada
4. Prova: a enumeração é confirmada quando as duas respostas diferem mensuravelmente (linha de base vs. sonda) em texto da mensagem, código de status ou comprimento do corpo

Padrão 2 — Token de redefinição exposto na resposta da API: Algumas APIs retornam o token de redefinição diretamente no corpo da resposta (em vez de apenas enviá-lo por e-mail). POST para o endpoint "esqueci minha senha" e procure por um token, link ou código na resposta JSON/HTML. Se um token aparecer que permite redefinir a senha, esse é um vetor imediato de tomada de conta.

Padrão 3 — Repetição de token de redefinição (reutilização após uso):

1. Complete um ciclo completo de redefinição de senha: solicite token → use-o para redefinir a senha
2. Tente imediatamente enviar o mesmo token novamente para o endpoint de redefinição de senha
3. Se a segunda submissão retornar 200 ou "sucesso" → token não invalidado após o uso

Padrão 4 — Sem limite de taxa em solicitações de redefinição: Envie o endpoint "esqueci minha senha" 10-20 vezes rapidamente com o mesmo e-mail. Se todos forem bem-sucedidos sem um 429, bloqueio ou CAPTCHA → sem limite de taxa (enumeração + inundação de tokens é possível).

Content-type: Endpoints de "esqueci minha senha" são frequentemente APIs REST baseadas em JSON. Use application/x-www-form-urlencoded apenas se o endpoint for um formulário HTML tradicional (verifique o HTML da página de login para determinar a codificação do formulário).

Prova: Enumeração de nome de usuário = resposta mensuravelmente diferente (corpo/status/comprimento). Exposição de token = token no corpo da resposta. Repetição de token = segundo uso bem-sucedido de um token consumido.

Classes de Vulnerabilidade Nesta Habilidade

1. Enumeração de Nome de Usuário via Redefinição de Senha

Mensagens de erro diferentes para contas válidas vs. inválidas vazam a lista de usuários sem autenticação. Até mesmo diferenças de tempo (rápido "usuário não encontrado" vs. lento "e-mail enfileirado") contam.

Alvos de alto valor: contas de administrador, padrões de e-mail de funcionários, chaves de API derivadas de nomes de usuário.

2. Tokens de Redefinição Fracos / Previsíveis

Um token de redefinição derivado de timestamp, nome de usuário ou IDs sequenciais pode ser forçado por força bruta:

• base64(email + timestamp) — decodificável
• Código numérico de 4-6 dígitos — 10 mil tentativas, facilmente viável sem limite de taxa
• Sequencial token=1234, token=1235 — trivialmente enumerável

3. Token Não Vinculado à Sessão ou IP

A maioria dos aplicativos gera um token, o envia por e-mail e o aceita de qualquer navegador. Um token verdadeiramente vinculado só deve funcionar do mesmo IP ou exigir o cookie de sessão original. Se nenhum for aplicado → encaminhamento de link = tomada de conta.

Vazamento de token via Referer / recursos de terceiros. Quando o token viaja na URL da página de redefinição (/reset?token=…) e essa página carrega qualquer recurso de origem cruzada (analíticos, anúncios, fontes, uma imagem CDN), a URL completa — incluindo o token — vaza para esse terceiro no cabeçalho Referer. Verifique as solicitações de saída da página de redefinição: se o token aparecer em qualquer Referer de origem cruzada, ele é coletável sem a caixa de entrada da vítima. Mesmo vazamento via uma configuração incorreta de <meta name=referrer> ou um link de saída que a vítima clica na página de redefinição. Vazamento de token divulgado → classe ATO: https://hackerone.com/reports/173551.

…