SQL Injection - Introducción 

Un ataque de Inyección SQL consiste en la inserción o “inyección” de datos en una consulta

SQL desde un cliente de la aplicación. El éxito en una inyección SQL puede leer datos
sensibles de la base de datos, modificar los datos (insertar/actualizar/borrar), realizar
operaciones de administración sobre la base de datos (como reiniciar el DBMS), recuperar el
contenido de un archivo del sistema de archivos del DBMS y, en algunos casos, ejecutar
comandos en el sistema operativo.

Descripción  
Los ataques de de Inyección SQL están divididos en las tres siguientes clases:

Inband: los datos son extraídos usando el mismo canal que es usado para inyectar el código
SQL. Este es el tipo de ataque más simple, en el que los datos recibidos se muestran en la
propia aplicación web.

Out-of-band: los datos son extraídos usando un canal diferente (por ejemplo, un correo con
el resultado de la consulta es generado y enviado al auditor)

Inferential: no hay transferencia de datos, pero el auditor puede reconstruir la información

enviando peticiones y observando el comportamiento que mantiene el servidor de bases de
datos.

Independientemente del tipo de ataque, una Inyección SQL correcta requiere que el atacante
pueda construir una consulta SQL correcta. Si la aplicación devuelve un mensaje de error a
causa de una consulta incorrecta, entonces en fácil reconstruir de forma lógica la consulta
original y, por lo tanto, entender cómo realizar una inyección correctamente.

Sin embargo, si la aplicación oculta los mensajes de error, un auditor puede conseguir por
medio de ingeniería inversa la lógica de la consulta original. Este último caso se conoce como
“Inyección SQL Ciega” (Blind SQL Injeccion).

Detección 
El primer paso en esta prueba es entender cuando nuestra aplicación conecta a un servidor
de bases de datos (BBDD) para acceder a algún dato. Los ejemplos típicos de casos en los
que una aplicación necesita comunicarse con una BBDD incluyen:

Formularios de autenticación: cuando la autenticación es realizada usando un formulario

web, es probable que las credenciales de un usuario sean comprobadas contra una BBDD
que contenga todos los usuarios y claves (o mejor, el hash de las claves)

Motores de búsqueda: la cadena enviada por el usuario puede ser usada en una consulta
SQL que recupere todos los registros relevantes de la BBDD.
Webs de E-Commerce: los productos y sus características (precio, descripción,
disponibilidad,...) son siempre almacenados en una BBDD relacional.

Un auditor tiene una lista de todos los campos que pueden ser usados para crear una
consulta SQL, incluyendo los campos ocultos de una petición POST y entonces los prueba por
separado, intentando modificar la consulta real y producir un error.

La prueba más básica consiste en añadir una comilla simple (') o un punto y coma (;) al
campo que se quiere probar. Lo primero es usado como fin de cadena y, si la aplicación no
está filtrada puede llevar a una consulta incorrecta. Lo segundo es el fin de una sentencia
SQL y, si no está filtrado, puede generar un error. La salida de un campo vulnerable puede
ser similar a lo siguiente (para el caso de Mutillidae)

********************************

error: You have an error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near ''''' at line 1

Query: SELECT * FROM accounts WHERE username='fabian' AND password=''' (0)

********************************

También los comentarios (--) y otras palabras reservadas como ‘AND’ y ‘OR’ pueden ser
usadas para intentar modificar una consulta. Una técnica muy simple pero aún efectiva es
insertar una cadena en un campo donde se espera un número.

Un mensaje de error, como los ejemplos anteriores, ofrece una gran cantidad de información
al auditor con el fin de crear una inyección con éxito. Sin embargo, las aplicaciones a
menudo no ofrecen mucho detalle: un simple ‘500 Server Error’ o una página de error
preparada puede ser lo que se muestre, lo que significa que necesitamos usar técnicas de
inyección SQL ciega (Blind SQL Injection).

En cualquier caso, es muy importante probar cada campo por separado: solo una variable
debe variar mientras que todas las demás se mantienen constantes, con el fin de entender
correctamente qué parámetros son vulnerables y cuáles no lo son.