Inyección SQL ciega, lo que revela la respuesta

En una inyección ciega por respuesta, la aplicación no devuelve el dato ni un error, pero se comporta de manera distinta según se cumpla o no una condición que quien evalúa añadió a la consulta. Para confirmar el fallo basta un par de pruebas inertes: una afirmación siempre cierta y otra siempre falsa. Si la respuesta de la primera es idéntica a la normal y la de la segunda es distinta, la base de datos está evaluando lo que se le envió.

Lee registro-booleano.txt. Fíjate en qué se parecen BO-01 y BO-02, en qué se parecen BO-03 y BO-04 y en qué se diferencian los dos grupos entre sí.

Una forma práctica de comparar respuestas es fijarse en su longitud y en el texto que la página muestra. Cuando la longitud de una respuesta coincide con la de un caso conocido (por ejemplo, un pedido que no existe), esa es la huella de una afirmación falsa. En un informe, esa cifra se anota junto a la de la respuesta normal para que quien repita la prueba pueda comprobarla.

El boletín devuelve siempre el mismo texto con la misma longitud. Si hay inyección, la única señal posible es el tiempo: una condición que, si se cumple, pide a la base de datos que espere unos segundos. Una respuesta mucho más lenta que la línea base, y solo cuando la condición es cierta, es la evidencia. Es una prueba lenta y ruidosa, por eso se repite para descartar que sea la red, y se detiene en cuanto el fallo queda confirmado: no hace falta más para el hallazgo.

Abre registro-tiempos.txt y compara cada tiempo con los dos primeros, que son la línea base.

El equipo de Trapiche respondió con dos medidas: páginas de error genéricas y un filtro que quita algunas palabras de SQL de los parámetros. Ninguna toca la causa. Un error genérico no impide que la respuesta siga cambiando según la condición, y un filtro de palabras es una lista de lo que alguien pensó que era peligroso; siempre falta algo.

La corrección es la misma que en la sala anterior: consultas parametrizadas. Las otras dos medidas pueden quedarse como capas adicionales, pero no cierran el hallazgo.

Una inyección ciega se redacta con precisión sobre lo que se probó. Se confirmó que la base evalúa lo enviado, por respuesta en un parámetro y por tiempo en otro; no se extrajo nada, y el informe no dice que sí. El impacto se razona por lo que esa clase de fallo permite en principio y por los permisos de la cuenta (la sala anterior), pero se marca como potencial, no como probado.