Kaique Mitsuo Silva Yamamoto
Seguranca informacao

Reporting: como reportar vulnerabilidades

Estrutura de reporte, CVSS scoring, disclosure responsável, triage de bugs e como escrever write-ups que maximizam payout e reputação.

Encontrar a vulnerabilidade é metade do trabalho. Reportar corretamente é a outra metade — e muitas vezes é o que separa um bounty máximo de um "informative" ou "duplicate".


Anatomia de um Bom Reporte

Template padrão

## [Título claro e específico]
Ex: "Stored XSS via profile bio field allows account takeover"

### Descrição
[O que é a vulnerabilidade, onde está, e qual o impacto]

### Passos para reproduzir
1. Acesse https://target.com/login
2. Faça login com user_a / user_a_password
3. Navegue para https://target.com/profile/edit
4. No campo "Bio", insira: <script>alert(document.cookie)</script>
5. Salve o perfil
6. Acesse o perfil público https://target.com/user/user_a
7. O JavaScript é executado no contexto de qualquer visitante

### Impacto
[Quem é afetado, dados expostos, ações possíveis]
Um atacante pode injetar JavaScript no perfil e roubar cookies de sessão
de qualquer usuário que visualize o perfil. Isso permite:
- Account takeover de qualquer usuário que acesse o perfil
- Redirecionamento para phishing
- Execução de ações em nome da vítima

### Prova de conceito (PoC)
[Screenshots, vídeos, curl commands]
[Screenshots mostrando o alert(1) ou o request/response]

### Evidências
[Request/response capturados no Burp]
POST /api/profile HTTP/1.1
Host: target.com
Cookie: session=abc123
Content-Type: application/json

{"bio": "<script>alert(document.cookie)</script>"}

HTTP/1.1 200 OK
{"status": "success"}

### Sugestão de remediação
Sanitizar input do campo "bio" usando DOMPurify ou equivalente.
Implementar Content-Security-Policy header.
Usar HttpOnly flag nos cookies de sessão.

### CVSS estimado
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N → 8.7 (High)

### Referências
- CWE-79: Cross-site Scripting (XSS)
- OWASP XSS Prevention Cheat Sheet

Escrevendo Títulos Impactantes

RuimBom
"XSS found""Stored XSS in profile bio → account takeover of all profile visitors"
"SQL injection""Blind SQL injection in search parameter → database dump"
"IDOR""IDOR in /api/orders/{id} → access to 50K+ customer orders"
"SSRF""SSRF via PDF export → AWS IAM credential theft via metadata"

Fórmula do título

[Tipo de vulnerabilidade] em [localização] → [impacto de negócio]

CVSS Scoring

Base Score Metrics

MétricaValoresImpacto
Attack Vector (AV)Network(N), Adjacent(A), Local(L), Physical(P)Como o atacante explora
Attack Complexity (AC)Low(L), High(H)Dificuldade de exploração
Privileges Required (PR)None(N), Low(L), High(H)Permissões necessárias
User Interaction (UI)None(N), Required(R)Vítima precisa interagir
Scope (S)Unchanged(U), Changed(C)Impacto além do componente
Confidentiality (C)None(N), Low(L), High(H)Vazamento de dados
Integrity (I)None(N), Low(L), High(H)Manipulação de dados
Availability (A)None(N), Low(L), High(H)Indisponibilidade

Exemplos práticos

Stored XSS em perfil público:
AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N = 8.7 (High)

Reflected XSS em página autenticada:
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1 (Medium)

IDOR em API de orders:
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5 (Medium)

SSRF → cloud metadata:
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N = 8.6 (High)

RCE via file upload:
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9 (Critical)

Calculadoras


Disclosure Responsável

Timeline padrão

Dia 0:    Reporte enviado
Dia 1-7:  Triage pela plataforma/empresa
Dia 7-30: Empresa investiga e corrige
Dia 30-90: Janela de correção
Dia 90+:  Disclosure público (se empresa concordar)

Regras:
- NÃO publicar antes de 90 dias (ou correção)
- NÃO explorar além do PoC mínimo
- NÃO acessar dados de usuários reais além do necessário para PoC
- NÃO vender/dados a terceiros

Quando publicar write-up

1. Após correção confirmada
2. Com permissão do programa
3. Após período de disclosure (90 dias)
4. Sem expor dados sensíveis de usuários
5. Com crédito ao programa (positivo para reputação)

Gerenciando Triages

Respostas comuns e como lidar

RespostaO que fazer
"Duplicate"Verificar se seu PoC é diferente/melhor; pedir mais detalhes
"Informative"Argumentar impacto real com cenário de ataque
"N/A"Verificar scope; argumentar impacto de negócio
"Needs more info"Responder rápido com detalhes adicionais
"Triaged"Aguardar; não pressionar

Como argumentar impacto

Em vez de: "XSS is dangerous because..."

Use: "Um atacante pode:
1. Criar um perfil com bio maliciosa
2. Compartilhar o link do perfil em redes sociais
3. Qualquer visitante terá sua sessão roubada
4. O atacante acessa a conta como a vítima
5. Dados financeiros/de perfil ficam expostos

Isso impacta TODOS os usuários que visualizam o perfil,
não apenas o próprio usuário."

Write-ups Públicos

Onde publicar

PlataformaFormatoAlcance
MediumArtigo longoComunidade geral
HackerOne HacktivityReporte diretoComunidade de hunters
Blog pessoalArtigo completoSEO, autoridade
Twitter/XThread curtaEngagement rápido
YouTubeVídeo walkthroughComunidade visual

Estrutura de write-up

# Título: [Tipo] em [Alvo] — [Impacto]

## TL;DR
Resumo em 2-3 linhas do que foi encontrado.

## Contexto
O que eu estava testando e por quê.

## Descoberta
Como encontrei a vulnerabilidade (passo a passo).

## Exploração
PoC completo com screenshots e requests.

## Impacto
Análise de impacto real (não teórico).

## Correção
O que a empresa fez (se souber).

## Lições aprendidas
O que faria diferente, dicas para outros hunters.

## Timeline
Datas de reporte, triage, correção, payout.

Referências

On this page