SQL Injection Progress

Tipo: In-band (Basada en lógica booleana)

Objetivo: Explotar una vulnerabilidad en el mecanismo de filtrado de productos para evadir las restricciones de la base de datos.

Explicación técnica de la vulnerabilidad:

Se identifica que el parámetro category de la aplicación web es vulnerable a inyección de código SQL. El sistema captura el texto introducido por el usuario y lo inserta de manera directa en la instrucción interna que consulta la base de datos. Al carecer de un proceso robusto de sanitización o validación de los datos entrantes, es posible introducir caracteres especiales que alteran la estructura de la consulta original. En términos administrativos, esto significa que un atacante puede reescribir las reglas de negocio que dictan qué información es pública, transformando una solicitud de búsqueda rutinaria en una orden directa para extraer datos corporativos restringidos.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando la herramienta Burp Suite Proxy.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo.
3. Se localiza el parámetro vulnerable, category, dentro de la cadena de consulta de la solicitud GET.
4. Se inyecta una secuencia de caracteres lógicos (payload) directamente en el valor del parámetro mencionado, alterando la instrucción prevista por el sistema.
5. Se transmite la solicitud modificada al servidor para evaluar el comportamiento y procesamiento de la base de datos.
6. Se analiza la respuesta devuelta por el servidor. Se constata la recepción de un código de estado 200 OK acompañado de un incremento significativo en el volumen de los datos transferidos. Esto confirma de manera concluyente que la base de datos ha devuelto la totalidad de los registros de la tabla de productos, ignorando exitosamente los filtros de visibilidad programados.

Análisis del payload:

Esta cadena de caracteres está diseñada con el propósito específico de manipular la sintaxis de la base de datos.

• La comilla simple (') tiene la función de cerrar prematuramente el campo de texto que el sistema había abierto para recibir el nombre legítimo de la categoría.
• La instrucción lógica OR 1=1 introduce una condición de evaluación matemática que siempre resulta verdadera. En el contexto operativo, esto ordena a la base de datos que devuelva un registro si pertenece a la categoría indicada "O" (OR) si el número 1 es igual al número 1. Al ser esta última una verdad universal, el sistema aprueba la visualización de todos los registros existentes en la tabla de productos.
• Los caracteres de doble guion (--) actúan como un comando de comentario en el lenguaje SQL. Su objetivo es neutralizar y ordenar al sistema que ignore el resto del código programado por los desarrolladores (la regla restrictiva AND released =1 que mantenía los productos ocultos).
• Los signos de suma (+) se emplean para representar espacios en blanco dentro del formato de la URL, asegurando que el servidor web interprete la instrucción con la separación correcta.

Tipo: In-band (Evasión de Autenticación / Logic Bypass)

Objetivo: Acceder a la aplicación web obteniendo los privilegios de administrador, evadiendo la validación de contraseñas.

Explicación técnica de la vulnerabilidad:

Se identifica una vulnerabilidad de severidad crítica en la función de inicio de sesión de la aplicación web. El parámetro de entrada correspondiente al nombre de usuario (username) carece de mecanismos de sanitización y validación antes de ser concatenado y procesado por el motor de la base de datos. En términos ejecutivos, el sistema confía de manera implícita en la información ingresada en el formulario y la interpreta directamente como instrucciones de sistema. Esto hace posible que un agente externo introduzca caracteres especiales para alterar la regla lógica de validación original. En lugar de que el sistema verifique simultáneamente la existencia del usuario y la exactitud de su contraseña, la alteración obliga a la base de datos a comprobar únicamente la existencia del usuario, anulando el requisito de la contraseña y permitiendo el acceso no autorizado.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP de tipo POST dirigida a la ruta de autenticación del servidor utilizando la herramienta de intercepción Burp Suite Proxy.
2. Se envía la petición interceptada a la herramienta Burp Repeater para facilitar un análisis iterativo e inyección controlada de datos.
3. Se localiza el parámetro username dentro del cuerpo de la petición y se sustituye su valor estándar por un vector de ataque (inyección SQL) diseñado específicamente para truncar la consulta del servidor.
4. Se asigna un valor arbitrario al parámetro password, dado que la lógica de validación de este campo será evadida.
5. Se transmite la petición manipulada al servidor web.
6. Se analiza la respuesta del servidor, observando la recepción de un código de estado HTTP/2 302 Found junto con la asignación de un token de sesión válido para el perfil de administrador. Este comportamiento confirma que el sistema ha autorizado el acceso sin requerir las credenciales legítimas completas.

Análisis del payload:

El éxito de esta intrusión radica en la manipulación de la estructura lógica de la consulta SQL subyacente (específicamente en la cláusula WHERE).

• La comilla simple (') actúa como un carácter de escape y delimitador. Su función técnica es indicarle a la base de datos que la cadena de texto correspondiente al nombre de usuario ha finalizado prematuramente.
• El doble guion (--) es el operador estándar reconocido por múltiples motores de bases de datos relacionales para marcar el inicio de un comentario. Al concatenar ambos elementos, la instrucción original del sistema es seccionada. La base de datos ejecuta de manera exitosa la instrucción de buscar al usuario "administrator", mientras que el resto del código original programado por los desarrolladores (la sección encargada de comparar la contraseña) queda convertida en un comentario inofensivo, siendo ignorada de forma absoluta por el servidor.

Tipo: In-band (UNION-based)

Objetivo: Determinar la versión exacta y la edición del motor Oracle subyacente.

Explicación técnica de la vulnerabilidad:

La vulnerabilidad reside en el parámetro category perteneciente a la funcionalidad de filtrado de productos. La aplicación procesa el texto introducido en dicho parámetro y lo concatena directamente en la consulta a la base de datos sin aplicar rutinas de sanitización o validación de seguridad. Esta falla arquitectónica permite que un usuario malintencionado introduzca caracteres especiales para cerrar prematuramente la instrucción original e inyectar comandos de bases de datos adicionales. Al procesarse, el sistema interpreta la carga útil maliciosa como una instrucción legítima, forzando a la base de datos a revelar información interna de su infraestructura en lugar del catálogo de productos previsto.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy, capturando el tráfico en tiempo real antes de que alcance su destino.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo y manipulación aislada.
3. Se ejecuta una fase de reconocimiento inyectando valores nulos para deducir la estructura de la tabla de la base de datos. Debido a los requisitos estructurales del motor Oracle, se emplea la tabla virtual del sistema denominada DUAL.
4. Se determina que la consulta legítima devuelve exactamente dos columnas al obtener una respuesta HTTP 200 (Exitosa) tras inyectar la sentencia de selección de dos elementos nulos.
5. Se verifica la compatibilidad de los tipos de datos insertando caracteres alfabéticos simples en ambas columnas, confirmando que el sistema tiene la capacidad de procesar y mostrar cadenas de texto.
6. Se construye y ejecuta la carga útil (payload) final dirigida a la vista del sistema v\$version, un repositorio interno de Oracle que custodia los metadatos de la infraestructura.
7. Se inspecciona el código fuente de la respuesta del servidor, verificando la extracción y renderizado exitoso de la cadena de texto que expone la versión completa de Oracle Database.

Análisis del payload:

El diseño del payload altera la lógica de la base de datos de forma meticulosa:

• El carácter de apóstrofe (') actúa como un comando de escape. Su función es interrumpir y cerrar la cadena de texto original programada por el desarrollador (la categoría del filtro), preparando el terreno para nuevas instrucciones.
• El operador UNION SELECT ordena a la base de datos fusionar los resultados de la búsqueda de productos legítima con los resultados de la consulta inyectada, consolidándolos en una única respuesta visible.
• La estructura banner, NULL garantiza el cumplimiento de la regla de homogeneidad estructural del operador UNION. Extrae el contenido de la columna de metadatos (banner) en la primera posición visible de la pantalla y asigna un valor vacío (NULL) a la segunda para coincidir con las dos columnas esperadas por la aplicación.
• El fragmento FROM v\version especifica la tabla de origen de los datos, apuntando a una vista administrativa exclusiva de entornos Oracle.
• Los guiones dobles (--) representan el símbolo universal de comentario en bases de datos. Su propósito crítico es anular cualquier fragmento de código residual que la aplicación intentara procesar después del punto de inyección, evitando errores de sintaxis que impedirían la ejecución del ataque.

Tipo: In-band (UNION-based)

Objetivo: Extraer la versión exacta del motor de base de datos.

Explicación técnica de la vulnerabilidad:

Se identifica que el parámetro de filtrado de productos (específicamente, category) es vulnerable a inyección SQL. La aplicación web toma el texto introducido en este filtro y lo anexa directamente a la orden interna que se envía a la base de datos, sin realizar una validación o neutralización previa de caracteres especiales. En términos ejecutivos, el sistema confía ciegamente en la entrada del usuario. Esto permite que un actor malicioso manipule la instrucción original, forzando al sistema a ejecutar comandos adicionales no previstos. Como resultado, es posible eludir las restricciones de acceso y extraer información sensible directamente desde el núcleo de la base de datos.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy al momento de interactuar con los filtros de la interfaz gráfica.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo.
3. Se realizan pruebas de inyección utilizando la cláusula UNION para descubrir la estructura interna de las tablas. Mediante este proceso, se confirma que la consulta original devuelve exactamente dos columnas de información y que ambas son capaces de procesar y mostrar texto.
4. Se inyecta una carga útil (payload) diseñada específicamente para consultar las variables de entorno internas del sistema gestor de bases de datos.
5. Se analiza el código renderizado en la respuesta del servidor, confirmando que la cadena de versión correspondiente a Microsoft SQL Server se muestra de forma visible en la interfaz, lo que valida la explotación exitosa de la vulnerabilidad.

Análisis del payload:

Este conjunto de caracteres altera la lógica de la consulta original de la siguiente manera:

• El carácter de comilla simple (') actúa como un interruptor. Le indica a la base de datos que la entrada de texto normal ha terminado, abriendo la puerta para insertar nuevos comandos.
• La instrucción UNION SELECT es el núcleo del ataque. Su función es combinar los resultados legítimos que la aplicación iba a mostrar, con una nueva tabla de resultados controlada íntegramente por el atacante.
• El término @@version es una variable del sistema propia de motores como Microsoft SQL Server. Al colocarla aquí, se le ordena al servidor que revele su versión exacta, información crítica para planear ataques más sofisticados.
• El valor NULL se introduce para rellenar la segunda columna de datos. El ataque UNION exige matemáticamente que la nueva consulta tenga el mismo número de columnas que la original; este relleno asegura que el sistema no arroje un error por discrepancia estructural.
• Los caracteres de doble guion (--) funcionan como un bloqueador. Le indican al motor de la base de datos que ignore cualquier fragmento de código original que haya quedado después de la inyección, previniendo errores de sintaxis que arruinarían el ataque.

Tipo: In-band (UNION-based)

Objetivo: Extraer credenciales consultando information_schema.

Explicación técnica de la vulnerabilidad:

El parámetro category utilizado para filtrar productos en la tienda es vulnerable a inyección SQL. La aplicación web toma el valor proporcionado por el usuario en la URL y lo concatena directamente en la consulta de la base de datos sin ningún tipo de validación, sanitización o parametrización previa. Esto permite que un actor malicioso altere la estructura original de la consulta introduciendo comandos adicionales (en este caso, mediante el operador UNION), forzando a la base de datos a devolver información confidencial que originalmente no estaba destinada a ser pública. En términos gerenciales y de negocio, es el equivalente a que un visitante de una biblioteca no solo pida un libro, sino que incluya instrucciones ocultas en su formulario de solicitud que obliguen al sistema a entregarle, además del libro, el registro privado de todos los empleados y sus contraseñas maestras.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo.
3. Se inyecta un primer payload dirigido a la vista estándar de metadatos information_schema.tables para listar todas las tablas existentes en la base de datos.
4. Se analiza la respuesta del servidor, identificando entre los resultados una tabla con sufijos ofuscados destinada a almacenar datos de usuarios (users_qbvywo).
5. Se inyecta un segundo payload dirigido a la vista information_schema.columns, aplicando una cláusula de filtrado (WHERE) específica para la tabla de usuarios recién descubierta, con el fin de mapear su estructura interna.
6. Se examina la nueva respuesta del servidor, logrando identificar las columnas exactas que albergan el nombre de usuario y la contraseña (username_pqbuks y password_uqpynv).
7. Se diseña y envía un tercer payload final para extraer directamente el contenido de las columnas descubiertas dentro de la tabla de usuarios.
8. Se analiza la respuesta del servidor para confirmar el éxito de la extracción, la cual expone en texto plano las credenciales del usuario administrator (ioc7llbwatolit9w69bj).
9. Se utilizan dichas credenciales en el portal de autenticación de la aplicación web, logrando el compromiso de la cuenta con máximos privilegios.

Análisis del payload:

• La comilla simple (') inyectada al inicio sirve para cerrar prematuramente la cadena de texto de la consulta original programada por los desarrolladores.
• El operador UNION se utiliza para combinar los resultados de esa consulta legítima con un conjunto de resultados completamente nuevo diseñado durante la prueba.
• La cláusula SELECT se instruye para extraer específicamente las columnas descubiertas de forma previa (username_pqbuks y password_uqpynv) desde la tabla de usuarios objetivo (users_qbvywo).
• Finalmente, la secuencia de dos guiones medios (--) actúa como un símbolo de comentario en el motor de la base de datos, indicando que se debe ignorar todo el código legítimo restante de la aplicación, evitando con esto errores de sintaxis que impedirían la ejecución exitosa del ataque.

Tipo: In-band (UNION-based)

Objetivo: Exfiltrar el contenido en Oracle para obtener y escalar privilegios.

Explicación técnica de la vulnerabilidad:

Se identificó que el parámetro category (categoría), utilizado para filtrar los productos en la tienda virtual, es vulnerable a inyección de código. La aplicación web toma el texto ingresado en este filtro y lo inserta directamente en la consulta de la base de datos sin un proceso previo de limpieza o validación. En términos de negocio, esto significa que el sistema no distingue entre una instrucción legítima ("muéstrame los regalos") y una orden maliciosa ("muéstrame las contraseñas"). Al reflejar los resultados de las consultas directamente en la página web que visualiza el cliente, se abre la puerta para utilizar un ataque de tipo UNION, el cual permite "grapar" o adjuntar subrepticiamente los resultados de una tabla confidencial (como la de usuarios) a los resultados de una tabla pública (como la de productos).

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy al momento de hacer clic en una categoría de producto.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo y controlado.
3. Se determina el número exacto de columnas devueltas por la consulta original inyectando sentencias de ordenamiento (ORDER BY 2, ORDER BY 3), confirmando que la base de datos opera con dos columnas al recibir un error en el tercer intento.
4. Se verifica que ambas columnas admiten datos de tipo texto mediante la inyección de una consulta de prueba utilizando la tabla predefinida de Oracle (UNION SELECT 'a', 'b' FROM dual).
5. Se extrae el listado maestro de tablas del sistema consultando la vista all_tables, identificando la tabla crítica denominada USERS_IRAUIG.
6. Se enumeran las columnas específicas de la tabla descubierta consultando la vista all_tab_columns, revelando los campos USERNAME_FBFFOG y PASSWORD_WKNSGM.
7. Se ejecuta la inyección final para volcar el contenido de dichas columnas, analizando la respuesta del servidor en formato HTML para localizar las credenciales renderizadas en pantalla.
8. Se utiliza la contraseña extraída perteneciente al usuario administrator para iniciar sesión de manera exitosa, confirmando el compromiso total del sistema.

Análisis del payload:

El funcionamiento de este vector de ataque se divide en cuatro componentes críticos:

• El apóstrofo inicial (') cumple la función de cerrar prematuramente la cadena de texto de la consulta original programada por los desarrolladores.
• El operador UNION SELECT es el núcleo del ataque; instruye al motor de base de datos a ejecutar una segunda consulta completamente nueva y combinar sus resultados con la primera.
• La declaración FROM USERS_IRAUIG dirige la extracción de datos específicamente hacia la tabla confidencial descubierta durante la fase de enumeración, solicitando las columnas de usuario y contraseña.
• Los guiones dobles finales (--) actúan como un símbolo de comentario en SQL. Su propósito es anular o ignorar cualquier porción de código legítimo que la aplicación web intente añadir después de la inyección, evitando así errores de sintaxis que delatarían o frustrarían el ataque. (Los signos + actúan como codificación URL para los espacios en blanco, garantizando que el servidor web interprete la instrucción correctamente) .

Tipo: In-band (UNION-based)

Objetivo: Determinar el número exacto de columnas de la consulta.

Explicación técnica de la vulnerabilidad:

Se identifica que el parámetro category, utilizado en la funcionalidad de filtrado del catálogo de productos, es directamente vulnerable a Inyección SQL. La aplicación web toma el valor suministrado a través de la URL y lo incorpora en la consulta de la base de datos sin aplicar mecanismos de desinfección de datos ni separación de comandos. En términos ejecutivos, el sistema confía ciegamente en el texto que el usuario introduce, permitiendo que un atacante inserte instrucciones adicionales que el motor de la base de datos interpreta y ejecuta como comandos legítimos. Debido a que los resultados de esta consulta alterada se muestran directamente en la página web del usuario, se habilita la posibilidad de utilizar la técnica UNION para extraer información no autorizada de otras tablas del sistema, siendo el primer paso necesario descubrir la estructura (número de columnas) de la consulta original.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP (método GET) dirigida al servidor web utilizando la herramienta de proxy local Burp Suite.
2. Se envía la petición interceptada a la herramienta Burp Repeater para facilitar su análisis y modificación iterativa de forma controlada.
3. Se procede a manipular el parámetro category inyectando el operador SQL UNION. Dado que esta técnica exige que la consulta inyectada contenga exactamente el mismo número de columnas que la consulta original, se realiza un proceso de enumeración secuencial utilizando el valor universal NULL.
4. Se inyecta inicialmente el payload de prueba para una sola columna ('+UNION+SELECT+NULL--). El servidor responde con un código 500 Internal Server Error, evidenciando una discrepancia en la estructura de las columnas.
5. Se incrementa el número de columnas en la inyección. Al probar con dos columnas ('+UNION+SELECT+NULL,NULL--), el servidor mantiene la respuesta de error 500.
6. Finalmente, al inyectar el payload para tres columnas ('+UNION+SELECT+NULL, NULL, NULL--), el servidor responde con un código de éxito 200 OK y la página se renderiza correctamente. Este comportamiento confirma de manera irrefutable que la consulta original de la base de datos opera con exactamente tres columnas.

Análisis del payload:

Este fragmento de código está diseñado para alterar la lógica original de la base de datos de la siguiente manera:

• La comilla simple ('): Actúa como un carácter de ruptura. Su función es cerrar prematuramente la cadena de texto que el desarrollador definió originalmente.
• El signo más (+): Representa un espacio en blanco codificado para su correcta transmisión a través de la URL, permitiendo separar los comandos SQL inyectados.
• La instrucción UNION SELECT NULL,NULL,NULL: Instruye al motor de base de datos a combinar los resultados de la búsqueda legítima con una nueva fila de datos generada por el atacante, compuesta por tres columnas vacías. El uso de la palabra reservada NULL es estratégico; al representar la "ausencia de valor", es compatible con cualquier tipo de dato (texto, números, fechas), evitando que la base de datos genere errores por incompatibilidad de formatos.
• Los dos guiones medios (--): Representan el símbolo de comentario estándar en bases de datos. Su función es indicar al sistema que ignore por completo cualquier código residual que el programador original haya escrito después de este punto de inyección, garantizando que la consulta maliciosa se ejecute sin errores de sintaxis.

Tipo: In-band (UNION-based)

Objetivo: Identificar qué columna es compatible con cadenas de texto.

Explicación técnica de la vulnerabilidad:

El parámetro category procesa la entrada del usuario incluyéndola directamente en la consulta a la base de datos sin la debida validación, sanitización o parametrización. Al omitir estas barreras de seguridad, el motor de base de datos interpreta los caracteres especiales introducidos por el usuario como instrucciones ejecutables en lugar de tratarlos como simple texto. Esta deficiencia permite anexar una segunda instrucción lógica (mediante el operador UNION), forzando a la base de datos a extraer información adicional cuyos resultados se reflejan directamente en la interfaz que visualiza el usuario final.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo.
3. Se inyecta un vector de prueba inicial en el parámetro category para determinar la cantidad de columnas empleadas por la aplicación. Mediante el uso de valores nulos, se confirma empíricamente que la base de datos procesa y devuelve tres columnas sin generar alertas ni excepciones.
4. Se procede a inyectar la cadena de texto objetivo en cada una de las posiciones de las columnas detectadas, de manera secuencial.
5. Se analiza la respuesta del servidor ante cada intento: al introducir el texto en la primera columna, el servidor arroja una excepción técnica (500 Internal Server Error), indicando una incompatibilidad en el formato de datos. Posteriormente, al posicionar el texto en la segunda columna, el servidor responde con un código de éxito (200 OK) y despliega la cadena de caracteres en la pantalla, confirmando que dicha columna es la ruta viable para la extracción de texto.

Análisis del payload:

• La comilla simple ('): Finaliza prematuramente la instrucción legítima programada originalmente por el desarrollador de la tienda.
• El signo de suma (+): Actúa como la codificación de un espacio en blanco en la barra de direcciones de internet, sirviendo para separar los comandos introducidos.
• El comando UNION SELECT: Es la instrucción principal que ordena al sistema combinar los resultados de la tienda normal con la nueva consulta fabricada para el análisis.
• El uso de valores NULL: Se ubican en la primera y tercera posición para evitar conflictos de formato. Este valor representa un "vacío" que es universalmente aceptado por cualquier columna, lo que previene que el sistema colapse mientras se evalúan otras posiciones.
• La cadena 'QQOyuu': Se ubica intencionalmente en la segunda posición para forzar al sistema a evaluar si dicha columna tiene la capacidad de procesar y mostrar datos alfanuméricos.
• Los guiones dobles (--): Funcionan como un símbolo de "comentario" técnico. Indican al sistema que ignore el resto del código original de la aplicación, previniendo errores de sintaxis que de otro modo bloquearían la ejecución del análisis.

Tipo: In-band (UNION-based)

Objetivo: Extraer credenciales para acceder a la cuenta admin.

Explicación técnica de la vulnerabilidad:

La vulnerabilidad reside en el parámetro category de la función de filtrado de productos. La aplicación web toma el texto introducido en este parámetro y lo inserta directamente en la consulta a la base de datos sin ningún tipo de limpieza o validación previa (sanitización). Para comprenderlo desde una perspectiva gerencial: el sistema está diseñado para solicitar al servidor "muéstrame los productos de la categoría X". Al no verificar qué es exactamente "X", un tercero puede manipular la solicitud para que diga "muéstrame los productos de la categoría X, y también muéstrame los nombres de usuario y contraseñas del sistema". La base de datos obedece ambas órdenes y la aplicación web termina mostrando información altamente confidencial en la pantalla del usuario, tratándola visualmente como si fueran artículos del catálogo de productos.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo.
3. Se realiza una fase de reconocimiento inyectando consultas de prueba para determinar la estructura de la base de datos, descubriendo que la consulta original devuelve exactamente dos columnas capaces de procesar y mostrar texto.
4. Se inyecta el operador lógico que unifica consultas dentro del parámetro category, solicitando específicamente las columnas de usuario y contraseña de la tabla interna de registros de la plataforma.
5. Se analiza el código fuente de la respuesta del servidor en la sección "Response", localizando la inserción de las credenciales confidenciales dentro de las etiquetas HTML de la tabla de productos.
6. Se aísla y documenta la contraseña en texto plano correspondiente al usuario administrador.
7. Se navega al portal de autenticación del sistema y se ingresan las credenciales sustraídas, confirmando el acceso privilegiado no autorizado.

Análisis del payload:

El funcionamiento de esta cadena maliciosa se divide en instrucciones específicas para alterar la lógica del motor de base de datos:

• La comilla simple ('): Actúa como un carácter de escape. Su función es cerrar prematuramente la cadena de texto de la consulta original que el desarrollador programó, permitiendo que lo que siga se interprete como comandos SQL ejecutables y no como simple texto de búsqueda.
• La instrucción UNION SELECT: Es un operador legítimo de SQL utilizado aquí de forma maliciosa. Su función es combinar los resultados de la consulta original de productos con los resultados de una consulta completamente nueva y arbitraria elaborada por el atacante.
• Los campos username, password: Representan las dos columnas exactas que se desea extraer. Al ser dos columnas, se cumple el requisito técnico del operador UNION, el cual exige que ambas consultas coincidan en el número de elementos devueltos.
• La directiva FROM users: Especifica el origen de los datos, indicando al motor de la base de datos que la información solicitada se encuentra en la tabla de almacenamiento de usuarios.
• El doble guion medio (--): Es el símbolo de comentario en SQL. Su función crítica es anular o "comentar" cualquier fragmento de código legítimo que la aplicación tuviera previsto ejecutar después del parámetro evaluado. Esto evita que se generen errores de sintaxis en el servidor, garantizando que la inyección se ejecute de manera limpia e indetectable por los controles básicos.

Tipo: In-band (UNION-based)

Objetivo: Extraer credenciales concatenando valores en 1 columna.

Explicación técnica de la vulnerabilidad:

El parámetro vulnerable es la categoría (category) utilizado en los filtros de búsqueda de la aplicación. La falla ocurre porque el sistema toma el texto exacto que ingresa el usuario y lo une directamente con las instrucciones internas de la base de datos sin realizar ninguna limpieza, desinfección o verificación previa. En términos gerenciales, es el equivalente a entregar un formulario firmado en blanco donde cualquier persona puede añadir instrucciones adicionales que el sistema ejecutará ciegamente. Al introducir comandos especiales, la consulta original de la aplicación se altera, obligando a la base de datos a no solo buscar los productos de una categoría, sino también a anexar y revelar información confidencial almacenada en otras tablas internas, como los nombres de usuario y contraseñas.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy al momento de seleccionar una categoría de producto.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su manipulación y análisis iterativo.
3. Se inyecta la cláusula ORDER BY para interactuar con la estructura de la base de datos y determinar el número exacto de columnas que devuelve la consulta original, confirmando que la respuesta consta de dos columnas.
4. Se inyectan valores de prueba (texto nulo y cadenas de caracteres) utilizando el comando UNION SELECT para identificar qué columna es capaz de procesar y mostrar datos de texto en la pantalla final. El análisis de la respuesta confirma que la segunda columna es la única apta para este fin.
5. Se diseña e inyecta un vector de ataque en el parámetro vulnerable, utilizando un operador lógico de concatenación para unir el nombre de usuario y la contraseña en un solo bloque de texto continuo. Esto permite extraer ambos datos simultáneamente a través de la única columna de texto disponible.
6. Se analiza la respuesta HTML del servidor, confirmando el éxito del ataque al visualizar las credenciales de la cuenta administradora impresas de forma directa en la interfaz visual de la tienda.
7. Se extraen las credenciales obtenidas y se utilizan en el panel de inicio de sesión para tomar control de la cuenta objetivo.

Análisis del payload:

• El apóstrofo inicial (') tiene la función de cerrar prematuramente la instrucción legítima de la aplicación.
• El comando UNION SELECT indica a la base de datos que debe combinar los resultados de la búsqueda de productos con una nueva instrucción no autorizada.
• El valor NULL se coloca en la primera posición para respetar la estructura requerida de dos columnas sin causar errores de incompatibilidad de datos.
• La sección central, username||'~'||password, es el núcleo del ataque: utiliza el operador de doble barra vertical (||) para fusionar (concatenar) el nombre de usuario y la contraseña, separados por un símbolo de tilde (~) como delimitador. Esta técnica logra que dos datos distintos quepan en una sola columna.
• Finalmente, FROM users indica la tabla objetivo que contiene la información confidencial, y los guiones dobles (--) comentan o anulan cualquier código residual de la aplicación original para evitar errores de sintaxis que delatarían el ataque.

Tipo: Blind (Boolean-based)

Objetivo: Extraer la credencial mediante inferencia lógica en la respuesta ("Welcome back").

Explicación técnica de la vulnerabilidad:

El parámetro vulnerable reside en la cookie de seguimiento asignada a la sesión del usuario (identificada como Trackingld). La aplicación presenta una falla de seguridad al tomar este valor y concatenarlo directamente dentro de una consulta interna de la base de datos sin un proceso previo de saneamiento o validación. Aunque el sistema está diseñado para no mostrar errores técnicos o información de la base de datos en la pantalla, altera su comportamiento visual de forma predecible. Específicamente, si la consulta inyectada resulta ser matemáticamente o lógicamente "verdadera", la página web muestra un mensaje de bienvenida (Welcome back). Si la consulta es "falsa", el mensaje se omite. Este comportamiento permite a un atacante formular preguntas lógicas afirmativas o negativas al sistema, logrando extraer información confidencial letra por letra de manera indirecta, sin necesidad de ver la base de datos de frente.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo.
3. Se inyectan sentencias lógicas en el parámetro vulnerable de la cookie para consultar, en primer lugar, la longitud total de la contraseña del usuario administrador.
4. Se implementa un enfoque de búsqueda binaria, enviando peticiones que comparan secuencialmente si el valor numérico de un carácter específico de la contraseña es mayor o menor a una letra de referencia.
5. Se analiza la respuesta del servidor en cada intento: la aparición del mensaje de bienvenida en el código fuente de la respuesta confirma que la condición evaluada es verdadera, reduciendo así las posibilidades a la mitad en cada paso.
6. Se automatiza este flujo de comprobación lógica mediante un script que itera sobre las 20 posiciones de la contraseña, logrando su extracción completa (zp5jy1l5taltb3wm7m9l).
7. Se verifica el éxito del procedimiento iniciando sesión en el portal utilizando las credenciales extraídas.

Análisis del payload:

El fragmento inyectado altera la lógica original de la consulta aislando y evaluando fragmentos de datos.

• El primer apóstrofo (') se encarga de cerrar de manera prematura la consulta legítima que el sistema intentaba realizar.
• Posteriormente, el operador lógico AND impone una nueva condición obligatoria.
• La función SELECT SUBSTRING extrae un único carácter de la contraseña almacenada en la base de datos (en este ejemplo, el carácter en la primera posición).
• Finalmente, el operador matemático > compara dicho carácter contra una letra específica (la 'm'). Al procesar esto, la base de datos determina si la letra real está por encima de la 'm' en el alfabeto. Si es así, la condición completa se evalúa como verdadera y la aplicación web reacciona mostrando el mensaje de bienvenida. Cada carácter especial y función cumple el propósito de transformar una consulta de base de datos en una simple pregunta de respuesta afirmativa o negativa.

Tipo: Blind (Errores Condicionales)

Objetivo: Extraer la contraseña forzando errores matemáticos condicionales.

Explicación técnica de la vulnerabilidad:

Se identifica una vulnerabilidad crítica en el manejo de la cookie de seguimiento (Trackingld). La aplicación web toma el valor de esta cookie y lo incorpora directamente en una consulta a la base de datos sin aplicar la sanitización o validación adecuada. Dado que la aplicación no muestra en pantalla los resultados de la base de datos, no es posible extraer la información de forma visual directa. Sin embargo, el sistema sí revela si ha ocurrido un error interno grave. Explotando esta característica, se pueden inyectar fragmentos de código que formulen preguntas de "sí o no" a la base de datos. Si la respuesta es afirmativa, el código malicioso fuerza intencionalmente un colapso matemático (como dividir un número entre cero), lo que se traduce en un mensaje de error del servidor. Si la respuesta es negativa, el sistema funciona con normalidad. Evaluando cuándo la página falla y cuándo no, es posible adivinar y reconstruir datos confidenciales, como contraseñas, carácter por carácter.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo.
3. Se inyecta una comilla simple al final del valor de la cookie Trackingld para desestabilizar la consulta SQL original, confirmando la vulnerabilidad al recibir un error interno del servidor (HTTP 500).
4. Se estabiliza la consulta concatenando una instrucción SQL válida que hace referencia a una tabla genérica (FROM dual). Al recibir una respuesta exitosa (HTTP 200), se confirma que el sistema subyacente utiliza el motor de base de datos Oracle.
5. Se diseña un código de automatización (script) para iterar sobre las 20 posiciones estimadas de la contraseña del administrador.
6. Se ejecuta el script, el cual inyecta condiciones matemáticas que fuerzan un error en el servidor de manera controlada, revelando secuencialmente cada letra y número de la credencial.
7. Se recopila la contraseña completa (sa4294rne60goxujz6fi) a partir de los resultados del script.
8. Se accede al portal de inicio de sesión de la aplicación y se ingresan las credenciales obtenidas para confirmar el acceso no autorizado y resolver el laboratorio.

Análisis del payload:

El payload funciona alterando la lógica de búsqueda de la base de datos mediante la concatenación de comandos adicionales, representados por las barras verticales (||).

• Se introduce una estructura condicional (CASE WHEN) que actúa como un filtro de validación.
• La función SUBSTR se encarga de aislar un único carácter de la contraseña del administrador en una posición específica (en este caso, la primera posición). Luego, se compara ese carácter con una letra o número específico (en el ejemplo, la letra 'a').
• Si la base de datos confirma que esa letra es la correcta, se ejecuta la instrucción TO_CHAR(1/0). Esta es una operación matemática inválida (división por cero) que provoca que la base de datos falle de inmediato, lo que a su vez hace que el servidor web devuelva un error visible.
• Si la letra es incorrecta, la instrucción ELSE simplemente devuelve un espacio vacío, permitiendo que la página cargue sin problemas. Al automatizar este proceso y cambiar la letra buscada en cada intento, se puede reconstruir la contraseña completa basándose puramente en los errores del sistema.

Tipo: In-band (Error-based)

Objetivo: Extraer la contraseña aprovechando outputs de error expuestos.

Explicación técnica de la vulnerabilidad:

La vulnerabilidad reside en el procesamiento inseguro del parámetro TrackingId contenido en la cookie de sesión. La aplicación integra este valor directamente en una consulta SQL sin realizar una validación o saneamiento previo. Al manipular este parámetro, se altera la estructura de la sentencia ejecutada por el servidor. El fallo crítico se manifiesta debido a que el servidor web está configurado para mostrar errores detallados de la base de datos en las respuestas HTTP. Esta configuración permite que un atacante fuerce errores intencionales, como fallos de conversión de tipos de datos, provocando que la base de datos incluya el resultado de subconsultas (datos sensibles) dentro del propio mensaje de error devuelto al cliente.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando Burp Suite Proxy.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo.
3. Se inserta una comilla simple (') al final del valor de la cookie TrackingId para confirmar la vulnerabilidad; el servidor responde con un error 500 que revela parte de la consulta SQL interna.
4. Se estabiliza la consulta utilizando caracteres de comentario (--) para anular el resto de la sentencia original y verificar que el error de sintaxis desaparece.
5. Se inyecta una función de conversión de tipos CAST() junto con una subconsulta para extraer información. Se utiliza la estructura AND 1=CAST((SELECT password FROM users LIMIT 1) AS int) para forzar al sistema a intentar convertir una cadena de texto (la contraseña) en un número entero.
6. Se procede a eliminar el valor original de la cookie Trackingld para liberar espacio en el búfer de la consulta, evitando que el servidor trunque el payload y permitiendo que la sentencia se ejecute de forma completa.
7. Se identifica la contraseña del administrador dentro del mensaje de error devuelto por la base de datos en la respuesta del servidor.
8. Finalmente, se utilizan las credenciales obtenidas para iniciar sesión en la sección de administración de la aplicación, confirmando el compromiso total de la cuenta.

Análisis del payload:

• ' (Comilla simple): Funciona como carácter de escape para cerrar la cadena de texto original en la cláusula WHERE de la consulta SQL.
• AND 1=: Introduce una condición lógica adicional que debe ser evaluada por el motor de base de datos.
• CAST(... AS int): Es la función encargada de la exfiltración. Al intentar convertir el resultado de la subconsulta (texto) en un tipo de dato entero (int), el motor de base de datos genera un error de ejecución. Debido a la naturaleza del error de conversión, el sistema incluye el valor que intentó convertir (la contraseña del administrador) en el mensaje de error.
• SELECT password FROM users LIMIT 1: Subconsulta diseñada para recuperar específicamente la contraseña del primer registro de la tabla de usuarios.
• -- (Guion doble): Indica al motor de base de datos que el resto de la línea debe ser tratada como un comentario, previniendo errores de sintaxis adicionales por fragmentos de código residuales de la consulta original.

Tipo: Blind (Time-based)

Objetivo: Confirmar la inyección provocando retrasos deliberados.

Explicación técnica de la vulnerabilidad:

Se ha identificado que la aplicación web utiliza el valor almacenado en la cookie Trackingid para realizar consultas internas en la base de datos con fines analíticos. La vulnerabilidad se origina debido a que el servidor no sanea ni valida adecuadamente esta entrada antes de incorporarla en la sentencia SQL. Al tratarse de una inyección "ciega", la aplicación no devuelve datos de la base de datos ni mensajes de error descriptivos en la interfaz. Sin embargo, debido a que las consultas se ejecutan de manera síncrona, es posible inyectar comandos que alteren el tiempo de respuesta del servidor, permitiendo confirmar la vulnerabilidad y, potencialmente, extraer información mediante inferencia temporal.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP GET / dirigida al servidor utilizando el módulo Proxy de Burp Suite.
2. Se envía la petición interceptada a la herramienta Burp Repeater para permitir la manipulación y el reenvío controlado de la solicitud.
3. Se localiza el encabezado Cookie en la petición y se identifica el parámetro TrackingId.
4. Se modifica el valor original del parámetro inyectando una cadena de caracteres diseñada para cerrar la sintaxis original y concatenar una función de retardo específica para el motor de base de datos PostgreSQL.
5. Se envía la petición modificada y se observa el panel de respuesta de Burp Repeater.
6. Se verifica que el tiempo de respuesta del servidor sea superior a los 10 segundos (aproximadamente 10,000 ms), lo cual confirma que el comando inyectado fue procesado con éxito por la base de datos.

Análisis del payload:

• x': Se utiliza un carácter arbitrario seguido de una comilla simple para cerrar correctamente la cadena de texto literal que la consulta SQL original espera para el ID de seguimiento.
• ||: En el lenguaje SQL de PostgreSQL, este símbolo representa el operador de concatenación de cadenas. Se emplea aquí para anexar la ejecución de una función al comando inicial sin romper la estructura sintáctica.
• pg_sleep(10): Es una función nativa de PostgreSQL que suspende la ejecución del hilo de la consulta durante el número de segundos especificado (en este caso, 10). Al ser una operación síncrona, el servidor web no puede finalizar la respuesta HTTP hasta que la base de datos complete este tiempo de espera.
• --: Representa el inicio de un comentario en SQL. Su función es invalidar cualquier parte restante de la consulta original que el desarrollador haya programado, evitando que errores de sintaxis posteriores bloqueen la ejecución del payload malicioso.

Tipo: Blind (Time-based conditional)

Objetivo: Extraer secuencialmente la contraseña mediante inyección de tiempos.

Explicación técnica de la vulnerabilidad:

Se identifica una falla crítica en la forma en que la aplicación web procesa la cookie de rastreo denominada Trackingld. Cuando un usuario visita el sitio, el servidor toma el valor de esta cookie y lo inserta directamente dentro de una consulta a la base de datos (PostgreSQL) sin validarlo ni desinfectarlo previamente. La aplicación padece de una inyección "ciega" porque el sistema no muestra mensajes de error en la pantalla ni refleja información de la base de datos en el sitio web. Sin embargo, procesa las instrucciones de forma síncrona. Al no existir visibilidad directa de los datos, el atacante recurre a formular preguntas condicionales a la base de datos (ej. "¿la primera letra de la contraseña es la 'a'?"), instruyéndole a pausar su procesamiento durante una cantidad de segundos específicos si la respuesta es afirmativa. Esto permite deducir información altamente confidencial basándose únicamente en el tiempo que tarda el servidor en responder a la petición web.

Procedimiento paso a paso:

1. Se intercepta la petición HTTP dirigida al servidor utilizando la herramienta de intercepción de tráfico Burp Suite Proxy.
2. Se envía la petición interceptada a la herramienta Burp Repeater para su análisis iterativo y manipulación manual.
3. Se inyecta un comando de prueba de retardo de tiempo en el parámetro Trackingid para confirmar la existencia de la vulnerabilidad. Se observa que el servidor retrasa su respuesta exactamente el tiempo indicado en la inyección.
4. Se procede a diseñar un vector de ataque condicional automatizado (mediante un script externo o Burp Intruder) para iterar sobre el abecedario y los números, evaluando posición por posición los caracteres que conforman la contraseña del administrador.
5. Se analiza el tiempo de respuesta del servidor ante cada petición enviada. Si la respuesta del servidor se retrasa (por ejemplo, 3 segundos), se confirma como verdadera la evaluación lógica y se registra el carácter descubierto. Si la respuesta es inmediata, se descarta el carácter y se prueba el siguiente.
6. Se reconstruye la contraseña completa tras finalizar la iteración sobre todas las posiciones y se utiliza en el portal de autenticación, logrando el compromiso total de la cuenta objetivo.

Análisis del payload:

El vector de ataque está diseñado para alterar el flujo original de la consulta y forzar un comportamiento temporal en el servidor. Funciona mediante la siguiente estructura:

• El carácter x' cierra de manera prematura la cadena de texto de la consulta original programada por los desarrolladores.
• La secuencia %3B representa un punto y coma (;) codificado para la web, lo que le indica a la base de datos que la consulta anterior ha terminado y comienza una instrucción nueva e inyectada por el atacante.
• La instrucción SELECT CASE WHEN actúa como un evaluador lógico (un "si ocurre esto, entonces haz esto").
• La función SUBSTRING se encarga de extraer una única letra de la contraseña almacenada en la base de datos para compararla con una letra de prueba (en este caso, la letra 'a').
• Las instrucciones THEN pg_sleep(3) ELSE pg_sleep(0) dictan el comportamiento del servidor: si la letra extraída coincide con la letra de prueba, la base de datos recibe la orden de "dormir" o pausarse por 3 segundos. Si no coincide, responde en 0 segundos.
• Los caracteres finales actúan como un símbolo de comentario, anulando cualquier código residual legítimo de la aplicación para evitar errores de sintaxis que delatarían el ataque.

Tipo: Out-of-band (OAST)

Objetivo: Provocar conectividad hacia un servidor DNS bajo nuestro control (Collab).

Explicación técnica de la vulnerabilidad:

Se identifica que la aplicación web procesa de manera insegura el valor de una cookie denominada Trackingld. Este valor es concatenado directamente en una consulta SQL que se ejecuta de forma asíncrona en el servidor. Al ser un proceso que no afecta la respuesta HTTP inmediata ni genera errores visibles, la única forma de confirmar la vulnerabilidad es forzando a la base de datos a realizar una solicitud de red externa. La falla reside en la capacidad de inyectar comandos de Oracle que permiten la resolución de entidades externas XML, lo cual puede ser aprovechado para realizar exfiltración de datos o mapeo de infraestructura interna.

Procedimiento paso a paso:

1. Interceptación de tráfico: Se utiliza el módulo Burp Suite Proxy para capturar la petición GET inicial, localizando el parámetro TrackingId dentro de las cabeceras de la cookie.
2. Preparación en el analizador: La petición se envía a Burp Repeater para manipular el vector de ataque sin afectar la navegación principal.
3. Configuración del receptor externo: Se genera un subdominio único a través de un servicio OAST externo para actuar como receptor de la consulta DNS provocada por la inyección.
4. Inyección del vector de ataque: Se sustituye el valor de la cookie por un payload de inyección SQL basado en la función EXTRACTVALUE de Oracle, diseñada para procesar estructuras XML y gatillar solicitudes de red.
5. Codificación y envío: Se aplica codificación URL a la cadena inyectada para asegurar su integridad durante la transmisión. Tras el envío, se recibe una respuesta HTTP 200 OK, confirmando que el servidor procesó la petición.
6. Análisis de fallo en la interacción: Al revisar el panel del receptor externo, no se registran interacciones debido al bloqueo de red perimetral impuesto por la Academia hacia dominios no oficiales. _(Nota: La actividad quedó marcada como no terminada por restricciones del entorno del laboratorio)_.

Análisis del payload:

• El payload comienza con una comilla simple (') para romper la estructura de la cadena original.
• La instrucción UNION SELECT permite ejecutar una consulta adicional.
• Se utiliza la función EXTRACTVALUE junto con xmltype para definir un documento XML malicioso que contiene una Entidad Externa (XXE).
• La directiva SYSTEM obliga a la base de datos a intentar conectarse a la URL proporcionada para resolver dicha entidad.
• Se utiliza la tabla dual por requerimientos de sintaxis en Oracle y los guiones (--) para comentar y anular el resto de la consulta original.