Inyección SQL clásica y su corrección

Una consulta SQL tiene dos partes que no deberían mezclarse: la estructura (qué se pide y de dónde) y los valores (qué se busca). Cuando el código arma la consulta uniendo texto con lo que escribió la persona, ese valor puede dejar de ser un valor y pasar a ser parte de la estructura. La prueba más pequeña para saberlo es enviar un carácter que tiene significado en la sintaxis, como una comilla, y mirar si la respuesta cambia de manera que solo se explica porque la consulta se rompió.

Lee peticiones.txt y log-de-depuracion.txt. Una comilla provoca un error y dos comillas no. Esa asimetría es la pista: no prueba que se pueda extraer nada, pero sí dice cómo trata el código lo que recibe.

La página recibe tres parámetros y no todos son igual de peligrosos. Un buen informe dice cuál lo es y por qué los otros no. Un valor que se compara contra una lista cerrada o se convierte a número antes de usarse no puede arrastrar sintaxis; uno que se concatena tal cual, sí. Esa diferencia se lee en el código, no en la interfaz.

Abre catalogo-codigo.txt y compara cómo trata cada parámetro antes de entrar en la consulta, y cruza con la tabla de peticiones.txt para ver que las pruebas lo confirman.

La corrección que elimina la causa es la consulta parametrizada: el código envía al motor la estructura con marcadores de posición y, por separado, los valores. El motor ya compiló la estructura cuando llegan los valores, así que nada de lo que contenga un valor puede alterarla. Es lo que recoge CWE-89 como mitigación principal.

Lo que no corrige la causa: filtrar caracteres sospechosos (siempre falta una variante), esconder el mensaje de error (el fallo sigue ahí) o confiar en que nadie lo encuentre. Esas medidas son capas adicionales, no la solución. Un caso aparte son los nombres de columna o de orden, que no se pueden enviar como valor: se resuelven con una lista de valores permitidos, como hace catalogo-corregido.txt.

La inyección es peor o menos grave según lo que pueda hacer la cuenta con la que la aplicación abre la base de datos. El principio de mínimo privilegio dice que esa cuenta solo debe poder lo que el código necesita. Cuando un fallo de inyección se combina con permisos de más, el daño potencial crece, y por eso el informe lo anota como un hallazgo propio aunque nadie lo haya explotado.

En permisos-bd.txt tienes lo que la cuenta puede leer y, debajo, lo que el equipo de desarrollo dice que usa cada página. Compara las dos listas.

Un hallazgo de inyección se redacta con lo mínimo que lo prueba: la petición, la respuesta, la línea de código si la hay, el impacto razonado y la corrección. No hace falta leer datos para demostrar que el fallo existe, y hacerlo suele violar las reglas de manejo de datos del contrato. El impacto se razona con lo que sí está en la evidencia, como los permisos de la cuenta, y no con lo que se podría haber extraído.