¿Qué hace Cazador de Recompensas de Seguridad?
Úsalo cuando el objetivo sea el descubrimiento práctico de vulnerabilidades para divulgación responsable o envío de recompensas, no una revisión amplia de mejores prácticas.
Cuándo Usarlo
- Escaneando un repositorio en busca de vulnerabilidades explotables
- Preparando un envío a Huntr, HackerOne o un programa de recompensas similar
- Triage donde la pregunta es "¿esto realmente paga?" en lugar de "¿es teóricamente inseguro?"
Cómo Funciona
Se inclina hacia vectores de ataque accesibles remotamente y controlados por el usuario, y descarta patrones que las plataformas rechazan rutinariamente como informativos o fuera del alcance.
Patrones Dentro del Alcance
Estos son los tipos de problemas que realmente importan de manera consistente:
| Patrón | CWE | Impacto típico |
|---|---|---|
| SSRF a través de URLs controladas por el usuario | CWE-918 | acceso a red interna, robo de metadatos en la nube |
| Bypass de autenticación en middleware o guards de API | CWE-287 | acceso no autorizado a cuentas o datos |
| Deserialización remota o rutas de subida a RCE | CWE-502 | ejecución de código |
| Inyección SQL en endpoints accesibles | CWE-89 | exfiltración de datos, bypass de autenticación, destrucción de datos |
| Inyección de comandos en manejadores de peticiones | CWE-78 | ejecución de código |
| Path traversal en rutas de servicio de archivos | CWE-22 | lectura o escritura arbitraria de archivos |
| XSS auto-ejecutable | CWE-79 | robo de sesión, compromiso de administrador |
Saltar Estos
Estos suelen ser de baja señal o fuera del alcance de recompensas a menos que el programa indique lo contrario:
pickle.loads,torch.loado equivalentes solo locales sin ruta remotaeval()oexec()en herramientas solo de CLIshell=Trueen comandos completamente hardcodeados- Cabeceras de seguridad faltantes por sí solas
- Quejas genéricas de limitación de tasa sin impacto de explotación
- Self-XSS que requiere que la víctima pegue código manualmente
- Inyección en CI/CD que no sea parte del alcance del programa objetivo
- Código de demostración, ejemplo o solo de pruebas
Flujo de Trabajo
- Verifica el alcance primero: reglas del programa, SECURITY.md, canal de divulgación y exclusiones.
- Encuentra puntos de entrada reales: manejadores HTTP, subidas, trabajos en segundo plano, webhooks, analizadores y endpoints de integración.
- Ejecuta herramientas estáticas donde ayuden, pero trátalas solo como entrada de triage.
- Lee la ruta de código real de principio a fin.
- Demuestra que el control del usuario llega a un 'sink' significativo.
- Confirma la explotabilidad y el impacto con la PoC más pequeña y segura posible.
- Verifica duplicados antes de redactar un informe.
Bucle de Triage de Ejemplo
semgrep --config=auto --severity=ERROR --severity=WARNING --json
Luego filtra manualmente:
- descarta pruebas, demostraciones, fixtures, código externo
- descarta rutas solo locales o no accesibles
- conserva solo hallazgos con una ruta clara de red o controlada por el usuario
Estructura del Informe
## Descripción
[Qué es la vulnerabilidad y por qué es importante]
## Código Vulnerable
[Ruta del archivo, rango de líneas y un pequeño fragmento]
## Prueba de Concepto
[Solicitud o script funcional mínimo]
## Impacto
[Qué puede lograr el atacante]
## Versión Afectada
[Versión, commit o despliegue objetivo probado]
Control de Calidad
Antes de enviar:
- La ruta del código es accesible desde un usuario real o un límite de red
- La entrada es genuinamente controlada por el usuario
- El 'sink' es significativo y explotable
- La PoC funciona
- El problema no está ya cubierto por un aviso, CVE o ticket abierto
- El objetivo está realmente dentro del alcance del programa de recompensas