Cómo escribir un bug bounty report que se acepte — estructura y errores comunes

[Vulnerability] in [Endpoint] leads to [Impact]

## Summary
[2 líneas — qué encontraste y cuál es el impacto en negocio]

## Severity
[Tu propuesta de severity + CVSS 3.1 con justificación]

## Impact
[Qué puede hacer el atacante. Business language, no técnico.]

## Steps to reproduce
1. ...
2. ...
3. ...

## Proof of Concept
[Video + curl reproducible + screenshots]

## Suggested remediation
[Fix concreto. Si conoces el stack, mejor.]

## References
[Links a docs, CVEs similares, blog posts]

1. Crear dos cuentas: victim (id=1001) y attacker (id=2042).
2. Login como attacker. Obtener JWT del response (cookie `auth_token`).
3. Hacer la siguiente request con el JWT de attacker pero el id de victim:

```bash
curl -X GET 'https://target.com/api/v1/users/1001/exports' \
  -H 'Authorization: Bearer <attacker_JWT>' \
  -H 'Accept: application/json'

### PoC video — el multiplicador

El video PoC es lo que separa €500 de €2500 en el mismo bug. Triage lo aprueba 3× más rápido.

**Template del video (60-90 segundos):**

> [!success] Tools de PoC video
> Loom (web), OBS Studio (desktop), QuickTime (Mac). Sin audio narration — triage prefiere video silencioso con annotations textuales. Subir a YouTube unlisted o al servicio del programa si lo ofrece (H1 Attachments, Bugcrowd Files).

---

## CVSS 3.1 — los 4 vectores que pesan

No necesitas memorizar CVSS, pero entender estos 4 mueve la severity 2 puntos:

| Vector | Subir score | Bajar score |
|---|---|---|
| `AV` (Attack Vector) | Network (N) | Local (L) |
| `AC` (Attack Complexity) | Low (L) | High (H) |
| `PR` (Privileges Required) | None (N) | High (H) |
| `UI` (User Interaction) | None (N) | Required (R) |

**Reglas que aplican el 90% de los casos:**
- Bug accesible vía HTTP → `AV:N`.
- Sin pre-conditions raras → `AC:L`.
- Funciona sin login → `PR:N` (Critical likely).
- Funciona con click del victim → `UI:R` (Medium likely).

Ejemplo: stored XSS auth-required que necesita que la víctima abra una página → `AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N` = 8.3 (High).

---

## Los 10 errores que rechazan reports

| # | Error | Cómo evitarlo |
|---|---|---|
| 1 | No buscar dupes antes de enviar | Search en disclosed reports + Hacktivity con keywords del bug |
| 2 | Severity inflada (CVSS 9.0 para un info leak) | Sé conservador. Triage premia honestidad. |
| 3 | PoC vago ("intenta esto y verás") | Curl completo + video + steps numerados |
| 4 | No probar tu propio repro antes de enviar | Cierra sesión, abre incógnito, repite tus steps. |
| 5 | Reportar issues out of scope | Lee el scope **completo** antes de empezar |
| 6 | Sin impact statement | Siempre incluye "qué puede hacer el atacante en términos de negocio" |
| 7 | Reportar problemas de configuración trivial (HTTP headers, banner version) | Sólo si hay chain con impacto real |
| 8 | Múltiples bugs en un report | Un report = una vuln. Reports separados se pagan separados. |
| 9 | Tono agresivo en comments | "Esto es Critical, no entiendo cómo no lo veis" → N/A garantizado |
| 10 | No responder a triage en 7 días | Reports en queue se cierran sin payout |

> [!warning] Anti-dupe checklist
> Antes de submit: search en la plataforma con 3 keywords distintas del bug (endpoint, vuln type, payload). Si encuentras incluso uno parecido, lee a fondo. Mejor dejarlo 30 min más analizando que comerse un dupe.

---

## Templates para los reports más comunes

### XSS reflejado

```markdown
## Summary
El parámetro `q` en `/search` refleja sin sanitizar el input del usuario en el contexto HTML, permitiendo ejecución de JavaScript arbitrario.

## Steps to reproduce
1. Visitar: https://target.com/search?q=<script>alert(document.domain)</script>
2. Observar alert con el domain → XSS confirmado.

## Impact
Atacante puede craftear URL maliciosa y enviarla a usuarios autenticados. Al hacer click, el script ejecuta en el contexto del dominio víctima → robo de cookies (no HttpOnly verificado), acciones en nombre del usuario, defacement.

## PoC
[video con steal de cookie y exfil al collaborator]

## Summary
El endpoint `/api/users/{id}/data` no valida ownership entre el `id` del path y el JWT del request. Cualquier user autenticado lee data privada de otros users.

## Steps to reproduce
1. Crear 2 cuentas: A (id=1001), B (id=1002).
2. Login como A. Capturar JWT.
3. Request: GET /api/users/1002/data con JWT de A → 200 OK con data de B.

## Impact
Enumeración completa de PII de los N users de la plataforma (id secuencial). GDPR violation.

## Summary
El parámetro `category` en `/products/list` es vulnerable a SQLi error-based. La payload `' OR 1=1--` dispara error MySQL filtrando structure de la query.

## Steps to reproduce
1. GET /products/list?category=' OR 1=1-- → 500 con MySQL error
2. Confirmar via sqlmap: `sqlmap -u "https://target/products/list?category=1" --dbs`
3. Output: 12 databases, including `users_prod`.

## Impact
Lectura completa de la DB `users_prod` (incluyendo password hashes, emails, payment refs). Posible RCE via `INTO OUTFILE` si MySQL user tiene FILE privilege.