Escrevendo relatórios vencedores

A diferença entre ser pago e ser ignorado

O que você vai descobrir

Habilidades que você vai dominar

🔧 Template de relatório

Use esta estrutura para cada relatório. Cada seção tem um propósito:

## Resumo
[Uma frase: Qual vulnerabilidade, onde, o que é afetado]
Propósito: Permitir que triagers entendam rapidamente o problema

## Tipo de vulnerabilidade
[IDOR, XSS, SSRF, SQLi, etc.]
Propósito: Ajuda na categorização e atribuição

## Passos para reproduzir
1. [Passo exato - seja específico]
2. [Passo exato - inclua URLs, parâmetros]
3. [Passo exato - o que clicar, o que observar]
Propósito: Alguém não familiarizado com o app deve reproduzir em <5 min

## Impacto
[O que um atacante pode fazer? Quais dados estão em risco? Quem é afetado?]
Propósito: Justifica avaliação de severidade e pagamento

## Prova de conceito
[Capturas de tela, requisições/respostas HTTP, vídeo para bugs complexos]
Propósito: Prova que a vulnerabilidade é real, não teórica

## Correção sugerida (Opcional)
[Breve recomendação, não código]
Propósito: Mostra que você entende a causa raiz

Princípio chave: Escreva como se o leitor nunca tivesse visto a aplicação e tivesse 5 minutos para validar seu relatório.

Escrevendo relatórios eficazes

Relatório ruim vs relatório bom

A diferença na qualidade afeta diretamente se você é pago:

"Encontrei IDOR no seu site. Pf corrijam."

## Resumo
Vulnerabilidade IDOR em /api/invoices/{id} permite que qualquer
usuário autenticado acesse faturas de outros usuários
contendo PII (nomes, endereços, histórico de compras).

## Tipo de vulnerabilidade
IDOR (Insecure Direct Object Reference)

## Passos para reproduzir
1. Logar como Usuário A em https://<target>/login
   (Usei conta de teste: test-user-a@example.com)
2. Navegar para "Minhas Faturas" no dashboard
3. Abrir DevTools do navegador (F12) > aba Network
4. Clicar em qualquer fatura para visualizar
5. Observar a requisição: GET /api/invoices/12345
6. Anotar o ID da fatura do Usuário A (12345 neste exemplo)
7. Modificar a requisição para /api/invoices/12346
   (incrementando o ID em 1)
8. Observar: Fatura pertencendo a um OUTRO usuário é retornada

## Impacto
Qualquer usuário autenticado pode enumerar e acessar TODAS as faturas
no sistema iterando através dos IDs.

Cada fatura expõe:
- Nome legal completo
- Endereço residencial
- Endereço de email
- Histórico de compras completo
- Método de pagamento parcial (últimos 4 dígitos)

Com aproximadamente 50.000 usuários na plataforma, isso
representa exposição significativa de PII e risco de conformidade LGPD.

## Prova de conceito
[Captura de tela: Faturas de dois usuários diferentes acessadas de
uma única sessão autenticada]
[Requisição/resposta Burp mostrando as chamadas de API]

## Correção sugerida
Validar que o usuário autenticado é dono da fatura solicitada
antes de retornar dados. A API deve retornar 403
Forbidden para faturas pertencendo a outros usuários.

Demonstrando impacto

Impacto determina pagamento. Impacto vago recebe baixa severidade; impacto específico recebe avaliações mais altas:

# IMPACTO FRACO (pagamento provavelmente baixo)
"Um atacante poderia ler dados."

# Por que é fraco:
# - Quais dados? Dados de usuário, logs de sistema, info pública?
# - Quanto? Um registro, todos os registros?
# - Quem é afetado? Um usuário, todos os usuários?

# IMPACTO FORTE (justifica severidade mais alta)
"Um atacante pode acessar de qualquer usuário:
 - Nome legal completo
 - Endereço residencial
 - Endereço de email
 - Histórico de compras completo
 - Detalhes do método de pagamento (últimos 4 dígitos do cartão)

 Com aproximadamente 50.000 usuários na plataforma, isso
 expõe PII significativa e cria risco regulatório:
 - LGPD: Até 2% do faturamento anual em multas
 - CCPA: Até $7.500 por violação intencional
 - PCI-DSS: Potencial violação de conformidade

 Exploração requer apenas autenticação (qualquer usuário
 pode fazer isso) e pode ser automatizada para extrair todos os registros
 em minutos."

# TÉCNICAS DE QUANTIFICAÇÃO DE IMPACTO:
- Contar usuários afetados: "Todos os 10.000 usuários registrados"
- Estimar exposição financeira: "Acesso a $X em dados de transação"
- Identificar implicações de conformidade: LGPD, HIPAA, PCI-DSS
- Descrever potencial de automação: "Pode extrair todos os registros via script"
- Referenciar escalação de privilégios: "Poderia acessar painel admin"

Entendendo o scoring CVSS

CVSS (Common Vulnerability Scoring System) é uma forma padronizada de avaliar severidade de vulnerabilidades em uma escala de 0 a 10. Entender CVSS ajuda você a avaliar vulnerabilidades com precisão e justificar sua avaliação.

Níveis de severidade e exemplos

# CRÍTICO (CVSS 9.0-10.0) - P1
Exemplos:
- Execução remota de código (RCE)
- Bypass de autenticação para admin
- SQL injection com acesso ao banco de dados
- Tomada de conta afetando todos os usuários

Pagamento: Tipicamente $1.000 - $50.000+

# ALTO (CVSS 7.0-8.9) - P2
Exemplos:
- IDOR expondo PII sensível
- XSS armazenado afetando muitos usuários
- SSRF com acesso à rede interna
- Escalação de privilégios

Pagamento: Tipicamente $500 - $5.000

# MÉDIO (CVSS 4.0-6.9) - P3
Exemplos:
- XSS refletido requerendo interação do usuário
- CSRF em ações sensíveis
- Divulgação de informação limitada
- Open redirect (depende do contexto)

Pagamento: Tipicamente $100 - $1.000

# BAIXO (CVSS 0.1-3.9) - P4
Exemplos:
- Self-XSS (só afeta você mesmo)
- Headers de segurança faltando (impacto limitado)
- Divulgação de informação sem dados sensíveis
- Problemas de rate limiting com impacto mínimo

Pagamento: Tipicamente $50 - $200

# INFORMATIVO - P5
Exemplos:
- Recomendações de boas práticas
- Sem impacto de segurança demonstrado
- Vulnerabilidades teóricas

Pagamento: Geralmente nenhum, ou apenas reconhecimento

Básico do calculador CVSS

Use o calculador CVSS oficial em https://www.first.org/cvss/calculator/3.1. Aqui está o que as métricas chave significam:

# VETOR DE ATAQUE (AV) - Como atacante pode alcançar a vulnerabilidade?
Network (N):  Explorável remotamente pela internet
Adjacent (A): Requer mesmo segmento de rede (WiFi, LAN)
Local (L):    Requer acesso local ao sistema
Physical (P): Requer acesso físico ao dispositivo

# COMPLEXIDADE DE ATAQUE (AC) - Quão difícil é explorar?
Low (L):  Sem condições especiais necessárias
High (H): Condições específicas ou preparação requeridas

# PRIVILÉGIOS REQUERIDOS (PR) - Qual nível de acesso necessário?
None (N):  Qualquer um pode explorar (não autenticado)
Low (L):   Requer conta de usuário normal
High (H):  Requer conta admin/privilegiada

# INTERAÇÃO DO USUÁRIO (UI) - Vítima precisa fazer algo?
None (N):     Atacante pode explorar diretamente
Required (R): Vítima deve clicar link, visitar página, etc.

# MÉTRICAS DE IMPACTO
Confidentiality (C): Atacante pode ler dados? None/Low/High
Integrity (I):       Atacante pode modificar dados? None/Low/High
Availability (A):    Atacante pode interromper serviço? None/Low/High

# EXEMPLOS DE CÁLCULOS CVSS:
IDOR expondo todos os dados de usuário:
  AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5 (Médio)

RCE via upload de arquivo:
  AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 (Crítico)

XSS refletido:
  AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1 (Médio)

Erros comuns de relatório

Perguntas frequentes

🎯 Você sabe escrever relatórios vencedores!

Estrutura clara, passos de reprodução específicos, impacto quantificado, avaliação CVSS adequada - você agora sabe como escrever relatórios que são pagos. Lembre-se: a mesma vulnerabilidade paga 10x mais com um relatório bem escrito.

Pronto para evitar duplicatas e fechamentos N/A