¿Qué hace Cazador de Recompensas de Seguridad?
Úsalo cuando el objetivo sea el descubrimiento práctico de vulnerabilidades para divulgación responsable o presentación de recompensas, no una revisión amplia de mejores prácticas.
Cuándo Usarlo
- Escaneando un repositorio en busca de vulnerabilidades explotables
- Preparando una presentación de recompensa en Huntr, HackerOne o similar
- Triaje donde la pregunta es "¿esto realmente paga?" en lugar de "¿es teóricamente inseguro?"
Cómo Funciona
Se inclina hacia vectores de ataque alcanzables remotamente y controlados por el usuario, y descarta patrones que las plataformas rechazan rutinariamente como informativos o fuera de alcance.
Patrones Dentro del Alcance
Estos son los tipos de problemas que consistentemente importan:
| 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 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 alcanzables | CWE-89 | Exfiltración de datos, bypass de autenticación, destrucción de datos |
| Inyección de comandos en manejadores de solicitudes | CWE-78 | Ejecución de código |
| Path traversal en rutas de servicio de archivos | CWE-22 | Lectura o escritura arbitraria de archivos |
| XSS de activación automática | CWE-79 | Robo de sesión, compromiso de administrador |
Saltar Estos
Estos generalmente son de baja señal o están fuera del alcance de recompensas a menos que el programa diga lo contrario:
pickle.loads,torch.loado equivalentes solo locales sin ruta remotaeval()oexec()en herramientas solo de línea de comandosshell=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 CI/CD que no es parte del alcance del programa objetivo
- Código de demostración, ejemplo o solo de prueba
Flujo de Trabajo
- Verificar primero el alcance: reglas del programa, SECURITY.md, canal de divulgación y exclusiones.
- Encontrar puntos de entrada reales: manejadores HTTP, subidas, trabajos en segundo plano, webhooks, analizadores y endpoints de integración.
- Ejecutar herramientas estáticas donde ayude, pero tratarlo solo como entrada de triaje.
- Leer la ruta de código real de principio a fin.
- Probar que el control del usuario llega a un sumidero significativo.
- Confirmar explotabilidad e impacto con la PoC más pequeña y segura posible.
- Verificar duplicados antes de redactar un informe.
Ejemplo de Bucle de Triaje
semgrep --config=auto --severity=ERROR --severity=WARNING --json
Luego filtrar manualmente:
- eliminar tests, demos, fixtures, código vendido
- eliminar rutas solo locales o no alcanzables
- mantener 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é importa]
## Código Vulnerable
[Ruta del archivo, rango de líneas y un pequeño fragmento]
## Prueba de Concepto
[Solicitud o script mínimo funcional]
## Impacto
[Qué puede lograr el atacante]
## Versión Afectada
[Versión, commit o despliegue específico probado]
Puerta de Calidad
Antes de presentar:
- La ruta de código es alcanzable desde un usuario real o un límite de red
- La entrada es genuinamente controlada por el usuario
- El sumidero 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