⚠️ 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.

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

1. Peça ao usuário para declarar o URL, IP, conta ou recurso exato do 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

A ausência de HttpOnly em cookies é detectada automaticamente — concentre seus testes ativos na invalidação do ciclo de vida (maior impacto).

Padrão 1 — Sessão sobrevive ao logout (descoberta de alto valor mais comum):

1. Faça login e anote o valor do token/cookie da sessão
2. Chame o endpoint de logout (/logout, POST /api/logout, etc.)
3. Tente usar o token de sessão ANTIGO para acessar um recurso protegido (/api/me, /dashboard, /account)
4. Se 200 com dados do usuário → sessão não invalidada no logout = persistência de ATO

Padrão 2 — Sessão não regenerada no login (fixação de sessão):

1. GET qualquer página para receber um token/cookie de sessão pré-autenticação
2. POST credenciais válidas para o endpoint de login
3. Compare o token de sessão ANTES e DEPOIS do login
4. Se o token não foi alterado → vulnerabilidade de fixação de sessão

Padrão 3 — Sessão sobrevive à alteração de senha:

1. Login → registre o valor da sessão A
2. Altere a senha através do endpoint de configurações da conta
3. Reenvie a sessão A em um endpoint protegido
4. Se 200 → token não rotacionado na alteração de credenciais = ATO persistente (cadeia crítica quando combinada com XSS/roubo de cookie)

Content-type: Endpoints de login e sessão variam — use application/json para APIs REST, application/x-www-form-urlencoded para formulários web tradicionais. Tente ambos se o primeiro retornar uma resposta inesperada.

Prova: Uma resposta 200 de recurso protegido (com dados do usuário) usando um token de sessão que deveria ter sido invalidado confirma a descoberta.

HUNT-SESSION — Gerenciamento de Sessão

Alvos de Joias da Coroa

Fixação de sessão levando a sequestro de admin = Crítico. Sessão sobrevivendo a alteração de senha = Alto a Crítico (ATO persistente a partir de um cookie roubado que a vítima acreditava ter revogado redefinindo sua senha).

Cadeias de maior valor:

• Fixação de sessão — o servidor aceita um ID de sessão definido pelo cliente e NÃO o regenera no login → o atacante pré-implanta um ID, a vítima autentica, o atacante aproveita a sessão agora autenticada → ATO persistente.
• Nenhuma invalidação no logout — o token antigo ainda funciona após /logout → a janela de roubo nunca fecha.
• Nenhuma invalidação na alteração de senha / e-mail — uma sessão roubada sobrevive ao "Acho que fui hackeado, vou redefinir" da vítima → ATO persistente. Esta é a classe de bug de sessão com maior pagamento.
• Reutilização de refresh-token sem detecção de rotação — um refresh token vazado gera novos access tokens para sempre; a falta de detecção de reutilização significa que o refresh posterior do usuário legítimo NÃO revoga o branch do atacante.
• ID de sessão previsível / de baixa entropia — IDs sequenciais, derivados de timestamp ou userId → força bruta ou computa sessões de outros usuários.
• JWT como sessão sem exp / sem lista de revogação — JWT roubado = acesso permanente; logout é cosmético.

Fundamentação — padrões que moldaram cada fase

Nenhum ID de CVE/relatório inventado abaixo. Estes são os padrões nomeados e documentados publicamente que esta habilidade codifica:

• Fixação de sessão, CSRF de login, sem regeneração na autenticação — OWASP WSTG-SESS-03 / WSTG-SESS-01; o clássico artigo de Mitja Kolšek sobre fixação de sessão ACROS. Variante de maior impacto: fixar a sessão de um usuário SSO/admin.
• CSRF de subdomínio irmão SameSite=Lax alcançando estado de sessão — Argo CD CVE-2024-22424 (cookies Lax enviados em navegações cross-site de nível superior de um subdomínio irmão). Use isso quando um cookie de sessão depende de SameSite=Lax como sua única defesa contra CSRF.
• Rotação de refresh-token e detecção automática de reutilização — o modelo Auth0/IETF OAuth-Security-BCP: um refresh token rotacionado, se reutilizado, deve invalidar a família inteira de tokens. Ausência = o bug principal a ser provado.

…