Metodologia de pentest: das regras de engajamento ao reteste

A fase de reconhecimento levanta o que existe antes de decidir onde gastar tempo. Em teste externo, isso inclui subdomínios, serviços expostos, tecnologias em uso e informação pública que ajude a montar o cenário. Em teste autenticado, inclui percorrer a aplicação com cada perfil e registrar cada função disponível.

O resultado dessa fase é um inventário do alvo, não uma lista de vulnerabilidades. É esse inventário que evita o problema mais comum de um teste malfeito: descobrir depois que uma parte inteira da aplicação nunca foi olhada porque ninguém sabia que ela existia.

# serviços expostos no alvo autorizado, com identificação de versão
nmap -sV -Pn --top-ports 1000 -oA evidencias/recon-externo alvo.exemplo

# certificado atual: nomes alternativos revelam hosts esquecidos
openssl s_client -connect alvo.exemplo:443 -servername alvo.exemplo </dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

# cabeçalhos de resposta: pilha, cookies e políticas declaradas
curl -sSI https://alvo.exemplo/ | tee evidencias/headers-raiz.txt

Todo comando executado fica registrado com data e alvo. Esse registro serve para três coisas: reconstruir o que foi feito se algo der errado no ambiente, provar que nada foi executado fora do escopo e permitir que o reteste repita exatamente a mesma verificação.

Ferramenta automatizada cobre volume. Ela encontra componente desatualizado, cabeçalho ausente, configuração fraca de TLS e as injeções mais evidentes. Isso é útil e economiza tempo, mas é também a parte do trabalho que qualquer um consegue reproduzir com uma licença de scanner.

A parte que exige pessoa é a que depende de entender o negócio. Um scanner não sabe que trocar o identificador do pedido na requisição de segunda via de nota fiscal expõe documento de outro cliente, porque a requisição responde 200 nos dois casos e nada no protocolo indica erro. Falha de lógica, quebra de autorização e encadeamento de falhas menores em um caminho de ataque real são território de teste manual.

• Autenticação: fluxo de recuperação de senha, expiração de sessão, segundo fator e enumeração de usuário
• Autorização: acesso horizontal entre contas do mesmo perfil e vertical entre perfis diferentes
• Entrada: injeção em consulta, comando, template e desserialização, com validação manual do que o scanner apontou
• Requisição do lado servidor (SSRF) e acesso a metadados de instância em ambiente de nuvem
• Lógica de negócio: alteração de preço, quantidade negativa, salto de etapa em fluxo de várias telas
• Exposição de dado sensível em resposta, log, mensagem de erro e cabeçalho

A exploração é controlada. O objetivo é comprovar que a falha é real e medir o impacto, não causar dano. Isso significa parar assim que a prova estiver feita, evitar alteração de dado de produção e nunca extrair mais informação do que o necessário para demonstrar o problema.

Achado sem evidência é opinião. E evidência mal registrada é o motivo mais comum de um relatório ser contestado pela equipe de desenvolvimento, o que atrasa a correção e desgasta a relação entre as partes.

• Passos de reprodução numerados, que qualquer pessoa da equipe consiga seguir
• Requisição e resposta relevantes, com dado sensível mascarado no relatório
• Captura de tela quando o efeito é visual, com identificação do ambiente e da data
• Conta ou perfil usado no teste, para distinguir acesso legítimo de acesso indevido
• Delimitação clara do que foi comprovado e do que é consequência plausível não testada

A última linha importa mais do que parece. Um relatório honesto separa o que foi demonstrado do que seria possível. Escrever que a falha permite acesso ao banco inteiro quando só se comprovou acesso a um registro é o tipo de exagero que faz uma equipe técnica desconfiar de todo o resto do documento.

O relatório tem dois públicos com necessidades opostas. Quem decide investimento precisa de um sumário executivo que diga em poucas linhas qual é o risco e o que muda se nada for feito. Quem corrige precisa de detalhe suficiente para reproduzir e resolver. Misturar os dois em um texto só faz com que nenhum dos dois seja atendido.

O reteste fecha o ciclo. Ele verifica se a correção resolveu a causa e se não introduziu comportamento novo, e é a única forma de transformar uma lista de achados em redução de risco comprovada. Um teste sem reteste entrega diagnóstico sem confirmação de tratamento.

• Correção que trata o sintoma e não a causa: bloquear um identificador específico em vez de validar a autorização
• Correção aplicada em um endpoint e esquecida nos outros que compartilham o mesmo defeito
• Validação feita apenas no navegador, com a regra ausente no lado servidor
• Reteste executado em ambiente diferente daquele onde a falha foi encontrada