Cómo crear un script para pruebas de SQL injection

1. Introducción y objetivos


En este artículo vamos a explicar superficialmente en qué consiste un ataque de estas características, y posteriormente vamos a mostrar cómo crear un pequeño script que nos automatice algunas pruebas de inyección SQL.

Para ello necesitaremos tener al menos unos conocimientos básicos en bases de datos y en programación web. Como máquina atacante vamos a emplear Kali Linux.


2. ¿En qué consiste un ataque de SQL injection (SQLi)?


Un ataque de inyección SQL consiste básicamente en introducir código malicioso SQL a través de un formulario con campos de entrada de datos mal sanitizados. La mala sanitización de los datos se traduce en una vulnerabilidad, y si este formulario conecta con una BBDD estaremos hablando de que tiene una falla de seguridad de tipo SQLi.

De esta manera un atacante puede inyectar código SQL malicioso en la base de datos de la víctima, ejecutando comandos en esta, mediante los cuales puede obtener información sensible, destruir datos, obtener una shell de comandos, y un largo etcétera.

A continuación se muestra una imagen resumen:


SQL injection
SQL injection

3. Cómo realizar un script para SQLi


Vamos a crear un archivo de texto con sentencias propias de SQLi, las cuales podemos obtener de distintas «cheat sheet» que podemos encontrar en la red. Estas sentencias serán procesadas por lectura (con el comando «cat») línea a línea (recorridas por un «for»), por un posterior script “.sh”, que se encargará de llevar a cabo las pruebas de inyección.

Como vemos en la siguiente imagen, hemos creado el archivo de texto “testingSQL.txt”, el cual contiene diferentes patrones clave para la explotación de vulnerabilidades tipo SQLi.



Una vez creado el archivo anterior, y bajo el mismo directorio, pasamos a crear el script que ejecutará el lanzamiento de comprobación SQLi contra el formulario de la web víctima. Lo llamamos “script.sh”.

Este script básicamente lo que hace es leer línea por línea el contenido del archivo «testingSQL.txt», y se encarga de pasar cada linea por argumento al parámetro «name» del archivo web «example1.php».



Una vez tengamos listos ambos archivos, ya estamos preparados para lanzar el ataque desde la línea de comandos. Para ello no tenemos más que dar permisos de ejecución a «script.sh» mediante el comando «chmod +x script.sh», y ejecutarlo como sigue:



Tras el lanzamiento del ataque podemos comprobar cómo efectivamente hemos tenido éxito, y se nos ha devuelto una tabla con los usuarios de la base de datos tras la primera inyección.



Si pasamos a inyectar el código de la primera línea del archivo de texto en la web, podemos observar cómo efectivamente obtenemos la tabla que hemos recibido por la línea de comandos en html.



Así pues, podemos decir que “script.sh” funciona adecuadamente. Ahora no tendríamos más que ir añadiendo al archivo “testingSQL.txt” aquellas sentencias que quisiéramos comprobar. Siempre es conveniente tener preparada una “cheat sheet” con todas las sentencias más comunes en este tipo de ataques.


4. Ejecución de SQLi


Lo que vamos  a explicar a continuación es el por qué del éxito del ataque SQLi, con el llamamiento a la URL que se puede apreciar en la siguiente imagen, mediante la cual hemos conseguido acceder a la BBDD del servidor víctima, explotando el parámetro «id» de la página vulnerable «example7.php».


Para una mejor explicación voy a exponer a continuación el código fuente de la página vulnerable programada en PHP.



Como podemos observar, en el código fuente se comprueba que el parámetro introducido sea un “integer”.

Sin embargo, el programador tuvo un pequeño desliz en la sanitización de los parámetros de entrada, ya que la expresión regular contiene un modificador que permite múltiples líneas (/m). Es por ello que se aprovecha esto para poder bypassear el filtro e inyectar código malicioso en la BBDD.

Si vamos a la tabla ascii podemos comprobar que empleando el “salto de línea” a través del código en hexadecimal “%0A” podemos inyectar nuestro código “or 1=1”.



Gracias a este pequeño desliz no tenemos más que poner tras el parámetro “id=” un “entero” (2) para que se dé por válido el “input” como “integer” y en la misma línea realizar un salto de línea (%0a) y añadir la inyección (or 1=1). Así hemos inyectado nuevamente la sentencia “or 1=1” obteniendo los datos esperados de la BBDD.


5. Conclusiones


En este artículo hemos visto superficialmente cómo realizar un script propio para automatizar distintas pruebas de penetración automatizadas, con el que realizar distintos ataques de SQLi en formularios web.

De esta manera hemos podido ver cómo se lleva a cabo una inyección SQL en una BBDD, mediante la explotación de la vulnerabilidad que supone una mala sanitización en los parámetros de entrada del formulario.

De este modo un atacante puede llevar a cabo una explotación más silenciosa que empleando herramientas automáticas como «sqlmap» o «sqlninja«, las cuales son fáciles de detectar y banear en entornos empresariales.

De estar interesado en adquirir conocimientos introductorios a hacking ético puede optar por matricularse en nuestro curso básico de hacking ético, o si prefiere adquirir conocimientos más avanzados en ciberseguridad ofensiva puede adquirir nuestro curso avanzado.

No puedes copiar el contenido