Inyección SQL en la máquina DVWA
En este apartado estaremos analizando y practicando inyección SQL en la máquina DVWA. Particularmente en los niveles Medium y High para reforzar nuestro conocimiento y conocer nuevos métodos. Como así también, saber cómo protegernos ante la misma.
Nivel “Medium”
Podemos notar que ahora no tenemos una barra para colocar datos, y tampoco podemos hacerlo desde nuestro navegador.
Vemos que solo nos permite colocar cinco números. Cada uno perteneciente a un usuario.
Ahora bien, podemos verificar los datos que enviamos mediante un Proxy como “BurpSuit”, o también, verificar si podemos generar una inyección sql en la máquina DVWA mediante código HTML. Veamos cómo funciona esto:
Primero hacemos click derecho y luego en “Inspeccionar Propiedades”. También puede aparecer “Ver código fuente” depende del navegador que estemos usando. En este caso Firefox.
Una vez hecho esto, nos dirigimos a “Inspector” y primero, damos click en 1 (Para marcar con el mouse lo que queremos buscar en dicho código fuente). Segundo, damos click en 2 (Botón de User ID).
Una vez hecho esto, se nos aparecerá una lista de números, los cuales pertenecen al “User ID” mostrado en el sitio web.
Arriba de dichos números encontramos «method=POST» con lo que podemos suponer que los siguientes datos son aquellos que van al servidor desde el lado del cliente. Por lo tanto, podemos modificar ‘value = “x”’ y probar colocando consultas.
Inyección SQL mediante código HTML
A continuación, probaremos si podemos encontrar alguna vulnerabilidad SQLI modificando el primer valor con 1” or 1=1 . Presionamos enter y luego subimos la consulta dando click en ‘submit’.
Sin embargo, no hemos tenido éxito, ya obtenemos como resultado el valor ID = 1 como vemos en la siguiente imagen.
Esto se debe a la configuración que se encuentra por detrás del sitio. Es decir, ahora el sitio web posee cierto grado de seguridad contra las inyecciones SQL. Veamos una parte del script de este nivel:
Podemos ver remarcada la función “mysqli_real_escape_string”. Básicamente lo que hace es «escapar» los caracteres especiales. Es decir, que les coloca por delante un símbolo de escape () para evitar que se usen determinados caracteres, evitando así, salto de líneas, comillas, etc. Habitualmente. algunos de ellos suelen ser \x00, \n, \r, \, ‘, « y \x1a. De esta manera se evita que dichos caracteres reservados se inyecten en un valor usado dentro de una sentencia SQL.
Ahora bien, si nos fijamos en la consulta SQL, se establece value=»1″. Entonces, la idea aquí no es colocar una inyección empezando con una comilla. Sino, aprovecharnos de la misma y simplemente colocar or 1=1. Por ejemplo:
Luego le damos Submit, y obtendremos el siguiente resultado:
Recordemos, con esto le hemos pedido a la base datos un valor 1 y otro TRUE (1=1). Este último tiene prioridad por sobre «1». Por tal motivo, se nos listas todos los valores con su respectivo id. Esto lo explicamos en detalle en la introducción.
Uso de la cláusula UNION
Recordemos que anteriormente habíamos descubierto las columnas user y password en la tabla users. Por lo tanto, la consulta a utilizar simplemente sería: unión select user,password from users
Veamos lo que sucede a continuación:
Como vemos, no hemos tenido éxito. Por lo tanto, lo que podemos hacer es comparar dicha consulta con la consulta “1 or 1=1” y así obtener ambos resultados. De esta manera nuestra consulta UNION la “atamos” a la consulta de valor true.
Veamos el resultado de esta consulta:
Hemos logrado obtener tanto el resultado de la primera consulta (First_name y Surname) como también, de la segunda consulta (user y password).
Nivel “HIGH”
Este nivel es muy similar al nivel low. Solo que aquí no realizamos una simple petición GET, es decir, utilizamos otro sitio web para transferir los valores de entrada hacia la consulta vulnerable.
Por lo tanto, haciendo click en “here to change your ID” nos llevará a la siguiente página:
Entonces, teniendo esto en cuenta, ya podemos probar algunas consultas para comprobar si es vulnerable a SQLI. Por ejemplo:
Sabiendo que es vulnerable y, teniendo dicho resultado, ya podríamos ir probando otras consultas con la cláusula UNION para ir obteniendo más información.
¿Cómo protegernos de Inyecciones SQL?
Hemos visto que la inyección SQL en la máquina DVWA, y en otras prácticas, se producen en cualquier entorno de comunicación. Lo primero que debemos tener en cuenta es validar o verificar las consultas Cliente-Servidor. Es decir, deben ser sanitizadas todas las entradas, antes de ser insertadas en las bases de datos o servidor.
De igual modo, debemos tener en cuenta los framework que utilizamos ya que, si estos se encuentran desactualizados o sin parches de seguridad, no nos servirán de mucho como protección. Por ejemplo, con respecto al nivel Medium, la función mysql_real_escape_string está obsoleta y se elimina en PHP7. Por tanto, no se recomienda utilizar. Como respuesta a esto es que salió mysqli_real_escape_string con diferencia en una letra, pero con funcionalidad diferente (De igual manera, se recomienda verificar si se sigue utilizando).
La descripción del nivel imposible en la máquina en DVWA dice lo siguiente:
“Las consultas están parametizadas (en lugar de ser dinámicas). Es decir, que las mismas han sido definidas por el desarrollador y ha distinguido qué secciones son códigos y el resto son datos”
Podemos ver en detalle como aplicar y protegernos de las inyecciones SQL en bases de datos Mysql y SQLite en nuestro artículo. El cual, se demuestra a través del lenguaje Python.
