Blind SQL Injection (IV). El Valor por Defecto

El problema del Conjunto Vacío (o cuál es el valor sin inyectar de referencia) en el análisis de un parámetro para averiguar si es vulnerable o no a SQL Injection y a explotación mediante Blind SQL Injection es muy importante. Tanto, que la elección del valor que utilicemos como conjunto vacío determinará que lleguemos a la conclusión correcta o a una conclusión errónea.

Para entender el problema analicemos un ejemplo. Tenemos una aplicación web con un programa que se llama programa.cod y de él, tras haber realizado un crawling (o recogida de todas las URLs de la web) tenemos un valor para uno de los parámetros que tenemos, digamos el parámetro id con el valor 1.

En resumen tenemos una URL del siguiente tipo:

http://www.miservidor.com/programa.cod?id=1

Y queremos saber si el parámetro id es vulnerable a SQL Injection explotable por Blind SQL Injection. Para ello probamos inyecciones de cambio de comportamiento 0 y de cambio de comportamiento negativo/positivo con los famosos:

http://www.miservidor.com/programa.cod?id=1 and 1=1
http://www.miservidor.com/programa.cod?id=1 and 1=0

¿Nos llevarán los resultados obtenidos a conocer si el parámetro es vulnerable o no?

Pues depende. Imaginemos, que el programador, ante la ausencia de resultados desde la base de datos muestra un valor por defecto. Si da la casualidad de que ese valor por defecto es justo el valor que tenemos, en este caso el valor 1 para el parámetro id no vamos a poder detectar la vulnerabilidad, ya que vamos a tener como respuesta algo que nos va a simular un parámetro seguro.

Jugando con el Primer Reto Hacking.

El código vulnerable allí era pista.aspx y el parámetro era id_pista. De este parámetro se daban dos valores, uno de ellos, el valor 1, era el valor por defecto, así que si intentabas encontrar la vulnerabilidad utilizando dicho valor, nunca llegarías a verla. Echemos un vistazo.

Primero sin inyección, el conjunto vacío:

http://www.informatica64.com/retohacking/pista.aspx?id_pista=1

Probamos ahora con la inyección and 1=1 para ver si podemos inyectar lógica:


http://www.informatica64.com/retohacking/pista.aspx?id_pista=1 and 1=1

Como se ve hemos obtenido la misma página de resultado, veamos ahora con la inyección and 1=2 para ver si obtenemos otra distinta.


http://www.informatica64.com/retohacking/pista.aspx?id_pista=1 and 1=2

Obtenemos la misma. Es decir, o es segura o estamos frente al parámetro por defecto y no vamos a poder saber si es vulnerable o no. Esto lo comprobamos introduciendo alguna Inyección No Valida, es decir, basura.


http://www.informatica64.com/retohacking/pista.aspx?id_pista=asd'asd

¿Quiere decir ésto que el parámetro es seguro? La respuesta es No. De hecho, si miramos con el valor 2 del parámetro, rápidamente se descubre la vulnerabilidad.


http://www.informatica64.com/retohacking/pista.aspx?id_pista=2

Y ahora probamos las inyecciones and 1=1


http://www.informatica64.com/retohacking/pista.aspx?id_pista=1 and 1=1

Y and 1=2


http://www.informatica64.com/retohacking/pista.aspx?id_pista=1 and 1=2

Y podemos comprobar la vulnerabilidad del parámetro. Esto es importante a la hora de comprobar la vulnerabilidad o no del mismo. La elección del valor por defecto. Analizaré más adelante como hacerlo con algunas herramientas de detección de vulnerabilidades, pero mientras. Una pregunta. ¿Qué pasa si no existiera ese valor 2? ¿Alguna otra solución?

Saludos!