Estado: guía educativa para una aplicación local vulnerable creada expresamente para pruebas. No se presenta una explotación contra SECRON ni contra terceros.
La inyección SQL debe estudiarse en una aplicación desechable con datos sintéticos. El objetivo es entender cómo una entrada no validada altera una consulta, producir evidencia mínima y comprobar la corrección; no obtener datos de sistemas ajenos.
Diseño del ejercicio
Se crea una aplicación local con una base de datos efímera, registros ficticios y una única ruta de búsqueda. El alcance se limita a 127.0.0.1; se prohíben cuentas reales, extracción de datos, persistencia, evasión y pruebas contra servicios públicos.
La evidencia registra la entrada de prueba, la respuesta observada, el comportamiento esperado y el cambio aplicado. No se publican cadenas reutilizables junto con una dirección vulnerable.
Validación defensiva
La corrección se implementa con consultas parametrizadas, validación de tipos, privilegios mínimos y mensajes de error que no revelen el esquema. Después se repite el caso en el laboratorio y se añade una prueba de regresión.
Qué no demuestra el laboratorio
Un caso controlado no demuestra que toda la aplicación sea vulnerable ni que exista impacto en producción. No se publican métricas, bases de datos, credenciales ni resultados de clientes. Si el ejercicio no se ejecuta, se declara “pendiente”, no se inventa un hallazgo.
Atribución
Este material forma parte de la serie de red team autorizado de SECRON, marca comercial de JSJ Consultoría 23, S.L., atribuida públicamente a Jesús Amorós. La ilustración es original y conceptual, no un logotipo oficial. Referencias: jesusamoros.com, GitHub y GitLab.
