Como escrever um bom relatório de pentest

#O que é um relatório de pentest

Um relatório de pentest é o registro escrito de um teste de segurança autorizado. Ele diz o que foi testado, o que foi encontrado, como um leitor pode confirmar cada achado e o que deve ser mudado. O teste termina quando o testador para de enviar requisições. O relatório é o que o dono do sistema guarda, compartilha com os desenvolvedores e usa para mostrar que o trabalho ficou dentro do escopo combinado.

O NIST SP 800-115, guia técnico sobre testes e avaliações de segurança da informação, cobre o processo inteiro, incluindo a análise dos achados e o desenvolvimento de estratégias de mitigação. O Web Security Testing Guide da OWASP tem um capítulo de Reporting que começa pela estrutura do relatório e por um esquema de nomes para os achados. Leia os dois quando puder. Este artigo foca na parte que você vai escrever primeiro: um relatório claro, com um achado que outra pessoa consiga reproduzir.

#Por que o relatório importa

Um bug real que ninguém consegue reproduzir raramente é corrigido. Desenvolvedores precisam de passos que possam executar a partir de um estado limpo. Gestores precisam entender o que o risco significa para o negócio. Auditores precisam de prova de que o trabalho respeitou a autorização. Um único documento tem que atender às três leituras.

O relatório também protege quem testou. Um escopo escrito e um registro datado do que foi testado mostram que cada ação ficou dentro da autorização. Sem esse registro, um testador que encontrou uma falha real pode acabar discutindo se o teste era permitido.

#As seções de um relatório

Uma estrutura prática tem seis partes:

• Sumário executivo. Uma ou duas páginas para quem não vai ler o resto. Diz o que foi testado, o risco geral, os achados mais importantes em linguagem simples e as primeiras ações a tomar. Escreva por último, mesmo que ele apareça primeiro.
• Escopo e autorização. Os hosts, URLs e contas que estavam no escopo, o que ficou de fora, as datas do teste, quem autorizou o trabalho e qualquer limite, como não fazer testes de negação de serviço.
• Metodologia. A abordagem e as ferramentas, com versões, em detalhe suficiente para que alguém consiga repetir o trabalho. Diga quais verificações foram manuais.
• Achados. Uma entrada por problema, ordenada por severidade. Cada entrada usa o mesmo modelo.
• Correções. As correções agrupadas por responsável ou tema, com prioridades. Cada correção tem uma forma de verificar que funcionou.
• Apêndice. Evidências brutas com segredos removidos, capturas completas de requisições e respostas, e um glossário para termos que o público pode não conhecer.

#Como escrever um achado

Cada achado responde às mesmas perguntas, na mesma ordem.

• Título. Diz qual é a falha e onde ela está. "Cross-site scripting refletido no parâmetro de busca" informa mais do que "vulnerabilidade XSS". O artigo sobre cross-site scripting explica a classe de falha por trás desse exemplo.
• Ativo afetado. A URL exata, o endpoint, o parâmetro, o componente ou a versão.
• Passos para reproduzir. Passos numerados que um desconhecido consiga seguir a partir de uma sessão limpa do navegador. Inclua a requisição exata sempre que um passo depender dela.
• Evidência. A prova de que os passos funcionaram: uma captura de tela ou a saída de curl -i, com segredos removidos. Numere cada evidência para que os passos possam apontar para ela.
• Impacto. O que um atacante poderia fazer nas condições que você verificou.
• Severidade. Um vetor CVSS v4.0 e a sua classificação, calculados a partir do que você verificou.
• Correção. Uma solução específica e uma verificação que mostre que ela funciona.

Um achado que o leitor não consegue reproduzir só com a página não está pronto, por melhor que seja o título.

#Descreva o impacto sem exagerar

O impacto segue a evidência. Se você mostrou que um script rodou no navegador de uma conta de teste no seu próprio laboratório, escreva exatamente isso. Uma frase como "um atacante pode tomar conta de todas as contas" sem demonstração é exagero, e um desenvolvedor vai perceber. Isso também custa credibilidade no achado seguinte. Quando você não verificou algo, diga isso e nomeie o teste que confirmaria.

#Saída de scanner é pista, não achado

O resultado de um scanner mostra onde olhar. Antes de ele entrar no relatório, reproduza à mão, registre a requisição e a resposta e confirme o comportamento por conta própria. Você pode citar o scanner como origem da pista. Não cole a saída bruta como prova, porque ela pode estar errada e o leitor não consegue saber quais partes alguém conferiu.

#Calcule a severidade com CVSS v4.0

A especificação do CVSS v4.0 define um grupo de métricas Base com dois lados. As métricas de exploração são vetor de ataque (AV), complexidade do ataque (AC), requisitos de ataque (AT), privilégios necessários (PR) e interação do usuário (UI). As métricas de impacto cobrem o sistema vulnerável (VC, VI, VA) e os sistemas subsequentes (SC, SI, SA). Uma string de vetor começa com CVSS:4.0 e lista todas as métricas base.

As faixas qualitativas de severidade são None em 0.0, Low de 0.1 a 3.9, Medium de 4.0 a 6.9, High de 7.0 a 8.9 e Critical de 9.0 a 10.0.

O escore tem quatro variantes conforme os grupos de métricas usados: CVSS-B só com Base, CVSS-BT com Base e Threat, CVSS-BE com Base e Environmental, CVSS-BTE com os três. Um primeiro relatório costuma trazer só o escore Base, então rotule como CVSS-B e não o apresente como avaliação completa de risco.

Use a calculadora oficial em https://www.first.org/cvss/calculator/4.0 para montar o vetor e obter a pontuação. Coloque o vetor no relatório, não só o número, para que o leitor veja quais premissas você usou. A string abaixo mostra apenas o formato. Ela não é a pontuação de nenhum achado do seu laboratório:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Pontue o que você verificou. Se o ataque depende de uma condição que você não conseguiu reproduzir, a métrica precisa refletir isso.

#Remova segredos antes de compartilhar

As evidências costumam conter cookies de sessão, tokens bearer, senhas e dados pessoais. Remova tudo isso antes de o arquivo sair da sua máquina. Mantenha o nome do cabeçalho e o formato do valor, para que o leitor ainda consiga acompanhar a requisição:

Cookie: session=<REDACTED>
Authorization: Bearer <REDACTED>

Não cole um token válido em chat, ticket ou repositório público, e não faça commit de um arquivo que ainda o contenha. Se um segredo foi exposto no seu próprio laboratório, troque-o mesmo assim e registre a troca no relatório.

#Mãos à obra: um achado do seu laboratório Juice Shop

Você precisa do container OWASP Juice Shop do seu laboratório, rodando na sua própria máquina. Este exercício toca apenas essa instância local em 127.0.0.1. Não execute nenhum destes passos contra um site que você não possui ou para o qual não tem permissão escrita de teste.

#1. Confirme que o laboratório é local

Rode:

docker ps

Olhe a coluna de portas. O mapeamento deve começar com 127.0.0.1, o que significa que só a sua máquina consegue acessar o serviço. Se aparecer 0.0.0.0 ou nenhum endereço, pare o container e inicie de novo com o endereço de loopback na flag de publicação.

docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Depois confira se o laboratório responde:

curl -i http://127.0.0.1:3000

A linha de status deve mostrar um código de resposta de sucesso. Guarde a saída. Ela vai na seção de Escopo como prova do alvo testado.

#2. Escolha um problema que você consiga reproduzir

Escolha um comportamento que você testou no navegador ou com uma única requisição, e que consiga descrever em poucos passos. Mantenha o escopo pequeno. Um achado bem sustentado é mais útil do que oito achados não verificados.

#3. Capture a evidência

Repita a requisição com curl -i para que os cabeçalhos fiquem visíveis. Troque o caminho pelo que o seu achado usa e salve a saída em um arquivo:

curl -i "http://127.0.0.1:3000/<caminho-testado>" > evidence-01.txt

A flag -i mostra os cabeçalhos da resposta antes do corpo. Leia a linha de status, o cabeçalho Content-Type e qualquer cabeçalho do qual o seu achado depende. Depois remova qualquer token ou cookie do arquivo antes de fazer commit.

#4. Preencha o modelo

Crie report.md no repositório do seu laboratório e use este modelo. Troque cada marcador pelo que você observou de fato:

## Scope

- Target: http://127.0.0.1:3000, my own OWASP Juice Shop container
- Authorization: I run this lab on a machine I own
- Dates: <start date> to <end date>
- Out of scope: everything else

## Finding title

<Flaw> in <exact location>

## Steps to reproduce

1. <Start from a clean browser session at http://127.0.0.1:3000>
2. <Exact action or request>
3. <What you see>

## Evidence

<Screenshot file name, or the redacted curl -i output file, matched to the steps>

## Impact

<What you verified. What you did not verify, and the test that would check it.>

## CVSS vector

<CVSS:4.0 vector from the calculator, and its rating>

## Remediation

<The specific fix, and how to check that it works>

#5. Faça commit do relatório

Veja o que o Git vai registrar antes de fazer commit, para que um arquivo sem redação não entre por engano:

git add report.md
git status
git commit -m 'First lab finding'

Confirme o commit com git log --oneline -1. A linha deve mostrar a sua mensagem. Ao terminar, pare o container do laboratório com docker stop <container-name> e rode docker ps para confirmar que ele não aparece mais.

#Erros comuns

• Começar pelo impacto. Escreva os passos primeiro e depois decida o que eles provam.
• Passos que dependem de uma sessão que o leitor não tem. Comece de um estado limpo e diga isso.
• Evidência sem ligação com os passos. Numere a evidência e cite o número em cada passo.
• Colar a saída do scanner como prova.
• Escolher a severidade pelo sentimento. Use o vetor e registre as premissas por trás dele.
• Vazar segredos em capturas de tela, logs ou commits.
• Uma correção sem forma de verificar.
• Descrever um teste que você não rodou. O relatório diz o que aconteceu, na ordem em que aconteceu.
• Gastar a maior parte do relatório com metodologia. A seção de achados deve ser a maior.

#Como ir além

• Leia o NIST SP 800-115 por inteiro. A publicação é gratuita no site do NIST.
• Leia o capítulo de Reporting do WSTG, começando pela estrutura do relatório e pelos esquemas de nomes.
• Leia a especificação do CVSS v4.0, métrica por métrica, antes de pontuar qualquer achado importante.
• Entregue o seu achado a alguém que não o escreveu e peça que reproduza apenas com os passos. Se essa pessoa não conseguir, o achado ainda não está pronto.
• Leia as regras de engajamento antes de testar qualquer sistema que você não possui. O artigo sobre regras de engajamento em bug bounty explica como os programas definem esses limites.

#Fontes

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide, Reporting
• Penetration Testing Execution Standard, Reporting
• FIRST, CVSS v4.0 Specification Document
• FIRST, CVSS v4.0 Calculator