💡 Este tutorial está traducido por IA desde la versión en inglés. Para ver la versión original, puedes hacer clic aquí
La inyección SQL es una técnica popular utilizada por los atacantes para explotar aplicaciones web creando entradas maliciosas y ejecutando declaraciones SQL arbitrarias en la base de datos del backend. En este laboratorio, configuraremos un entorno de inyección SQL utilizando sqli-labs con Docker y realizaremos experimentos prácticos para comprender los principios y métodos de explotación de las vulnerabilidades de inyección SQL.
Bienvenidos a nuestro curso introductorio sobre pruebas de seguridad web, centrado específicamente en la identificación de posibles vulnerabilidades de inyección SQL. La inyección SQL es un fallo de seguridad común y potencialmente devastador en las aplicaciones web, pero con el conocimiento adecuado, puedes aprender a identificarla y prevenirla.
La inyección SQL es una técnica en la que un atacante inserta código SQL malicioso en una consulta a la base de datos de una aplicación web. Si la aplicación web no sanitiza adecuadamente la entrada del usuario, esto puede llevar a filtraciones de datos, pérdida de datos u otros problemas graves.
Las aplicaciones web que interactúan con una base de datos a menudo tienen URLs que incluyen parámetros. Estos parámetros pueden ser explotados potencialmente si no se sanitizan adecuadamente. Por ejemplo, es posible que veas una URL que se vea así:
http://some-website.com/page.php?id=XXEn esta URL, id es un parámetro que interactúa con la base de datos. Cualquier página web que utilice tales parámetros podría ser potencialmente vulnerable a la inyección SQL si la entrada no se sanitiza adecuadamente.
Una forma sencilla de probar las vulnerabilidades de inyección SQL es utilizar la técnica de la comilla simple. Así es como se hace:
') al valor del parámetro en la URL. Por ejemplo, podrías cambiar la URL para que se vea así: http://some-website.com/page.php?id=1'La razón por la que esto funciona es que tanto los tipos de datos numéricos como los de cadena en SQL generarán un error de sintaxis cuando se introduce una comilla simple desequilibrada. Este error puede revelar la presencia de una vulnerabilidad de inyección SQL.
Si no se muestra ningún error cuando se añade una comilla simple, no necesariamente significa que no haya una vulnerabilidad de inyección SQL. Es posible que la aplicación esté filtrando las comillas simples, lo que requeriría utilizar otras técnicas para probar las vulnerabilidades. No se preocupen, cubriremos estas técnicas más avanzadas en una lección futura.
Recuerden, el hacking ético se trata de mejorar la seguridad. Siempre respeten la privacidad y la legalidad en sus esfuerzos de prueba. ¡Feliz aprendizaje!
¡Excelente trabajo identificando posibles puntos de inyección SQL! Ahora, pasemos al siguiente paso: determinar el tipo de vulnerabilidad de inyección SQL. Hay dos tipos principales en los que nos centraremos: la inyección SQL numérica y la inyección SQL basada en cadenas.
Cuando el parámetro de entrada (llamémoslo x) es tratado como un entero por la aplicación web, la consulta SQL podría verse así:
select * from <table_name> where id = xPara identificar una inyección SQL numérica, utilizamos dos condiciones lógicas simples: and 1=1 y and 1=2. Así es cómo:
http://some-website.com/page.php?id=x and 1=1 en tu navegador. Si la página se carga como se espera, pasa al siguiente paso.http://some-website.com/page.php?id=x and 1=2. Si la página devuelve un error o se comporta de manera diferente, podría indicar una vulnerabilidad de inyección SQL numérica.¿Por qué funciona esto?
Cuando introduces and 1=1, la consulta SQL resultante es:
select * from <table_name> where id = x and 1=1La condición 1=1 es siempre verdadera, por lo que si la página se carga normalmente, sugiere que la entrada se está insertando directamente en la consulta SQL.
Cuando introduces and 1=2, la consulta SQL resultante es:
select * from <table_name> where id = x and 1=2La condición 1=2 es siempre falsa, por lo que si la página se comporta de manera diferente (como devolver un error), sugiere que nuestra entrada está afectando la consulta SQL, lo que indica una posible vulnerabilidad de inyección SQL.
En algunos casos, el parámetro de entrada x es tratado como una cadena. La consulta SQL podría verse así:
select * from <table_name> where id = 'x'Para identificar una inyección basada en cadenas, utilizamos un enfoque similar al de la inyección numérica, pero con condiciones de cadena: and '1'='1' y and '1'='2'. Así es cómo:
http://some-website.com/page.php?id=x' and '1'='1 en tu navegador. Si la página se carga como se espera, pasa al siguiente paso.http://some-website.com/page.php?id=x' and '1'='2. Si la página devuelve un error o se comporta de manera diferente, podría indicar una vulnerabilidad de inyección SQL basada en cadenas.¿Por qué funciona esto?
Cuando introduces and '1'='1', la consulta SQL resultante es:
select * from <table_name> where id = 'x' and '1'='1'La condición '1'='1' es siempre verdadera, por lo que si la página se carga normalmente, sugiere que la entrada se está insertando directamente en la consulta SQL.
Cuando introduces and '1'='2', la consulta SQL resultante es:
select * from <table_name> where id = 'x' and '1'='2'La condición '1'='2' es siempre falsa, por lo que si la página se comporta de manera diferente (como devolver un error), sugiere que nuestra entrada está afectando la consulta SQL, lo que indica una posible vulnerabilidad de inyección SQL.
En ambos casos, recuerda que una respuesta inusual de la aplicación web es una pista de que es posible que hayas encontrado un punto de inyección SQL. Sin embargo, siempre asegúrate de tener permiso para realizar estas pruebas y utiliza tus habilidades de manera responsable. ¡Feliz aprendizaje!
En este laboratorio, profundizaremos en las vulnerabilidades de inyección SQL. Nuestro enfoque será en cómo explotar estas vulnerabilidades para eludir la autenticación de inicio de sesión, una técnica a menudo conocida como el ataque de la "contraseña universal".
Para comenzar, necesitaremos preparar nuestro entorno de laboratorio. Utilizaremos la Damn Vulnerable Web Application (DVWA) - una aplicación web PHP/MySQL diseñada intencionalmente para ser insegura, lo que la convierte en una herramienta de aprendizaje ideal para comprender la seguridad de las aplicaciones web.
Descargar la imagen Docker de sqli-labs: La imagen Docker de sqli-labs está disponible para descargar en Docker Hub. Utiliza el siguiente comando en tu terminal para descargarla:
docker pull acgpiano/sqli-labsIniciar el contenedor Docker de sqli-labs: Después de descargar la imagen, ejecútala utilizando el siguiente comando:
docker run -it -d --name sqli-labs -p 80:80 -p 13306:3306 acgpiano/sqli-labsEste comando inicia un nuevo contenedor y mapea el puerto 80 y 3306 del contenedor a los puertos 80 y 13306 de tu máquina host, respectivamente.
Siguiendo estos pasos, has configurado con éxito el entorno de laboratorio necesario.
Después de completar la configuración, abre Firefox y escribe http://localhost en la barra de direcciones.
Si es la primera vez que visitas http://localhost, haz clic en Setup/reset Database for lab para preparar el laboratorio y luego actualiza la página web.
Ahora deberías ver una página de inicio de sesión sencilla cuando hagas clic en Less-11. Intenta ingresar un nombre de usuario arbitrario 123 y una contraseña 123.
La página de error te informará "Invalid username or password" (Nombre de usuario o contraseña no válidos).
Examinemos el código del backend responsable del proceso de autenticación:
// take the variables
if(isset($_POST['uname']) && isset($_POST['passwd']))
{
$uname=$_POST['uname'];
$passwd=$_POST['passwd'];
//logging the connection parameters to a file for analysis.
$fp=fopen('result.txt','a');
fwrite($fp,'User Name:'.$uname);
fwrite($fp,'Password:'.$passwd."\n");
fclose($fp);
// connectivity
@$sql="SELECT username, password FROM users WHERE username='$uname' and password='$passwd' LIMIT 0,1";
$result=mysql_query($sql);
$row = mysql_fetch_array($result);
....
}La consulta SQL real que se ejecuta es:
SELECT * FROM users WHERE username='123' AND password='123' LIMIT 0,1Esta consulta es fácil de entender: si devuelve una fila en la que tanto el username como la password coinciden, entonces el inicio de sesión es exitoso.
Basándonos en el conocimiento del laboratorio anterior, intentemos ingresar la siguiente carga útil:
Nombre de usuario: 123' or 1=1 #
Contraseña: 123' or 1=1 #
Curiosamente, esto nos permite iniciar sesión con éxito. La razón es que la consulta SQL real que se ejecuta es:
SELECT * FROM users WHERE username='123' or 1=1 #' AND password='123' or 1=1 #'En MySQL, el símbolo # se utiliza para comentar el resto de la línea, por lo que la consulta se convierte efectivamente en:
SELECT * FROM users WHERE username='123' or 1=1Dado que la condición or 1=1 es siempre verdadera, la consulta siempre devolverá un resultado, lo que lleva a un inicio de sesión exitoso.
También podemos experimentar con una variación que no utiliza el símbolo de comentario:
Nombre de usuario: 123' or '1'='1
Contraseña: 123' or '1'='1
La consulta SQL que se ejecuta entonces es:
SELECT * FROM users WHERE username='123' or '1'='1' AND password='123' or '1'='1'En este caso, las dos condiciones or aseguran que la condición and entre ellas sea siempre verdadera, lo que lleva a un inicio de sesión exitoso.
Como se demostró anteriormente, hay numerosas técnicas que se pueden utilizar para explotar las vulnerabilidades de inyección SQL y saltarse la autenticación. Siéntete libre de explorar y experimentar con diferentes cargas útiles. El objetivo aquí es entender estas vulnerabilidades para que puedas proteger mejor tus propias aplicaciones de ellas. ¡Feliz hacking ético!
En este laboratorio, aprendimos cómo identificar vulnerabilidades de inyección SQL utilizando la técnica de la comilla simple y cómo determinar el tipo de inyección SQL (numérica o basada en cadenas) utilizando cargas útiles específicas. También exploramos la explotación de vulnerabilidades de inyección SQL para saltarse la autenticación de inicio de sesión, un escenario común conocido como el ataque de la "contraseña universal". Al realizar experimentos prácticos, adquirimos experiencia práctica en la comprensión y explotación de vulnerabilidades de inyección SQL, que son comunes en las aplicaciones web si la sanitización de la entrada no se implementa adecuadamente.