Un solo carácter. Eso fue todo lo que hizo falta para convertir una prueba rutinaria en un hallazgo de dos mil dólares.
En 2023, estaba revisando un nuevo programa de bug bounty. Alcance nuevo, código desconocido, el proceso habitual de mapear la superficie de ataque. Llegué a uno de los dominios dentro del alcance y vi un parámetro ID en la URL.
Ya sabes lo que viene después. Cualquiera que haya hecho este trabajo sabe exactamente lo que viene después.
Añadí una comilla simple al parámetro.
GET /product?id=123' HTTP/1.1
Host: target.example.comLa página devolvió un error. No un error cualquiera, sino una excepción SQL detallada que incluía algo que no esperaba: las credenciales completas de la base de datos. Usuario, contraseña, host, nombre de la base de datos. Todo lo necesario para conectarse directamente al backend.
System.Data.SqlClient.SqlException: Unclosed quotation mark after
the character string '123''.
at System.Data.SqlClient.SqlConnection.OnError(...)
Connection string: Server=[REDACTED];Database=[REDACTED];
User ID=[REDACTED];Password=[REDACTED];En ese momento, el hallazgo se dividió en dos problemas distintos. La inyección SQL en sí era una vulnerabilidad. La filtración de credenciales en el mensaje de error era otra. Ambas eran lo suficientemente graves como para justificar una calificación de severidad crítica.
Documenté las dos, redacté los pasos de reproducción, expliqué el impacto y envié los reportes. El programa los clasificó rápidamente. Ambos volvieron como Críticos con una puntuación de severidad de 9.8. Cada uno fue recompensado con mil dólares.
Esto no es lo habitual. Esto no es lo que parece el bug bounty la mayoría de los días. La mayoría de los días no acaban con hallazgos críticos y pagos de cuatro cifras. La mayoría de los días son reconocimientos que no llevan a ningún sitio, duplicados que llegan cinco minutos antes que los tuyos y reportes que acaban degradados o disputados.
Escribo sobre casos así porque son interesantes. Son los momentos que hacen que la frustración merezca la pena. Pero son excepciones.
Por cada hallazgo como este, hay semanas en blanco. Programas que no responden. Vulnerabilidades que resultan ser problemas conocidos o riesgos aceptados. Horas interminables de pruebas que no dan ningún resultado.
La técnica de la comilla simple es básica. Es una de las primeras cosas que aprendes cuando empiezas a probar aplicaciones web. Intentas romper la validación de entrada. Buscas sitios donde la entrada del usuario no se sanea correctamente antes de llegar a una consulta de base de datos. Es lo más elemental.
Lo que hizo diferente este caso no fue la técnica. Fue la gestión de errores. En algún punto de la pila de la aplicación, un desarrollador decidió que los mensajes de error detallados eran más importantes que la seguridad. Quizá fue una configuración de depuración que nunca se desactivó. Quizá fue un valor por defecto del framework que nadie se molestó en restringir. Sea cual sea la razón, el resultado fue una divulgación de información crítica encima de una inyección SQL ya explotable.
La lección aquí no es que debas ir añadiendo comillas simples a cada parámetro que veas. Eso ya lo haces. Lo hacemos todos. La lección es que la gestión de errores importa. Los mensajes de error detallados en producción son un regalo para los atacantes. Convierten fallos de inyección simples en compromisos completos de credenciales.
Desde la perspectiva de un investigador, estos hallazgos son directos. Documentas el punto de inyección, muestras los datos filtrados, explicas el riesgo y sigues adelante. Desde la perspectiva de un desarrollador, son bochornosos. Nadie quiere ser la persona que dejó credenciales de base de datos expuestas en la salida de errores.
Así es este trabajo. Encuentras las brechas. Las reportas. A veces son configuraciones incorrectas menores. A veces son vulnerabilidades críticas que exponen infraestructura sensible. La diferencia muchas veces se reduce a una pequeña decisión tomada meses o años atrás por alguien que no pensó en las implicaciones de seguridad.
Dos mil dólares por una comilla simple. Suena bien contado así. Lo que no se ve son los cientos de pruebas que no funcionaron, los programas que no tenían nada interesante, el tiempo invertido en conocer los sistemas lo suficiente como para saber dónde buscar.
Eso es el bug bounty. Los momentos brillantes son geniales. La realidad es un trabajo constante salpicado de victorias de vez en cuando.
