Hacking Web – Inyección SQL

por | Ene 15, 2024 | Pentesting Web | 0 Comentarios

Bienvenido a este post donde hablaremos de Hacking Web – Inyección SQL. La inyección SQL es un tipo de ataque de inyección en el cual un atacante inserta código malicioso en una consulta SQL para ejecutar comandos no deseados en la base de datos. Los atacantes pueden utilizar la inyección de comandos para ejecutar comandos arbitrarios en el sistema, lo que podría permitirles obtener acceso no autorizado, modificar o eliminar datos, o incluso tomar el control total del sistema. Las inyecciones a menudo se realizan a través de campos de entrada, como formularios web, parámetros de URL o encabezados HTTP.

Table of Contents

¿Te gustaría enterarte de cuando lanzamos descuentos y nuevos cursos?

Inyección SQL y plugins

Los complementos de WordPress más útiles tienen algún tipo de interacción con la base de datos. La entrada del usuario se envía con frecuencia a la base de datos, ya sea porque necesita almacenarse en la base de datos, necesita modificar algo en la base de datos o porque se utiliza como parte de una declaración SELECT. Si la entrada del usuario no se valida ni se escapa correctamente, un atacante puede reemplazar esa entrada del usuario con comandos que puede enviar directamente a la base de datos.

Hay dos tipos de inyección SQL. Una vulnerabilidad de inyección SQL «clásica» es aquella en la que la entrada del usuario sin filtrar permite a un atacante enviar comandos a la base de datos y la salida se envía de vuelta al atacante. Una vulnerabilidad de inyección SQL «ciega» se produce cuando el atacante puede enviar comandos a la base de datos pero en realidad no ve la salida de la base de datos.

Según el análisis de Wordfence las vulnerabilidades de inyección SQL son la segunda vulnerabilidad más común que se encuentra en los complementos de WordPress.

Cómo funciona una vulnerabilidad de inyección SQL clásica

Para comprender cómo funciona una vulnerabilidad de inyección SQL clásica, veamos un ejemplo de WordPress:

1	global $wpdb;
2	$title = $wpdb->get_var("select post_title from " . $wpdb->posts . " where ID=" . $_GET['id']);
3	echo $title;

El código anterior es un ejemplo de una vulnerabilidad de inyección SQL (SQLi). Es una vulnerabilidad de SQLi porque la entrada del usuario en $_GET[‘id’] se envía directamente a la base de datos sin desinfección ni escape. Esto permite a un atacante enviar comandos directamente a la base de datos.

Luego, la salida de la base de datos se envía directamente al navegador del usuario. Debido a que el resultado se envía al navegador, esto convierte a la vulnerabilidad en una vulnerabilidad SQLi clásica, a diferencia de una vulnerabilidad de inyección SQL ciega, que se analiza a continuación.

Al utilizar esta vulnerabilidad, un atacante puede enviar comandos directamente a la base de datos. Estos incluyen comandos SELECT para descargar su base de datos completa, incluida la información de identificación personal (PII) del usuario. En algunos casos, también incluye comandos INSERTAR y ACTUALIZAR para crear nuevas cuentas de usuario o modificar cuentas de usuario existentes.

Corregir la vulnerabilidad anterior es relativamente fácil. En WordPress simplemente necesita usar el método de preparación que desinfectará y escapará automáticamente cualquier dato que envíe a la base de datos. El código anterior se puede modificar de la siguiente manera para eliminar la vulnerabilidad SQLi:

1	global $wpdb;
2	$title = $wpdb->get_var($wpdb->prepare("select post_title from " . $wpdb->posts . " where ID=%d", $_GET['id']));
3	echo $title;

Tenga en cuenta que utilizamos el método $wpdb->prepare() para escapar de los datos que estamos enviando a la base de datos. Tiene una sintaxis similar a la función sprintf() que le permite utilizar marcadores de posición. %d es un número entero, %f es un flotante (o decimal) y %s es una cadena (o texto). Si utiliza %s como marcador de posición, no necesita incluir comillas, ya que se agregan automáticamente.

Cómo funciona una inyección SQL ciega

Una vulnerabilidad de inyección SQL ciega se parece a la siguiente:

1	global $wpdb;
2	$title = $wpdb->get_var("select post_title from " . $wpdb->posts . " where ID=" . $_GET['id']);
3	//Do something with title, but don't echo.

En el ejemplo anterior, la entrada del usuario sin procesar y no desinfectada se envía directamente a la base de datos concatenando la variable $_GET[‘id’] directamente a la consulta SQL. Para corregir esta vulnerabilidad, simplemente usaría el método prepare() como se indicó anteriormente para desinfectar y escapar de cualquier entrada de la base de datos.

La diferencia aquí es que el resultado nunca se envía al navegador. Una vulnerabilidad SQLi ciega es tan grave como una vulnerabilidad SQLi normal porque, en algunos casos, un atacante puede insertar o actualizar datos fácilmente en su base de datos. La diferencia es que resulta más difícil extraer datos de la base de datos porque el atacante no puede ver el resultado de la base de datos porque no está escrito en el navegador web.

Ataques SQL ciegos basados ​​en el tiempo

Generalmente, hay dos formas en que un atacante extrae datos de una base de datos mediante un ataque de inyección SQL ciega. El primero es utilizar un ataque basado en el tiempo. Supongamos que, utilizando la vulnerabilidad SQLi anterior, un atacante puede enviar cualquier comando a la base de datos, pero no puede ver el resultado. Sólo pueden ver la página web resultante.

Un atacante podría hacerle a la base de datos una pregunta como “¿La primera letra de la primera cuenta de administrador comienza con ‘a’? Si es así, duerme 5 segundos y si no es así, no duermas nada. Si la página web tarda menos de 5 segundos en generarse y regresar al navegador web, saben que la cuenta de administrador no comienza con la letra ‘a’ y pasan a la siguiente letra, ‘b’, y preguntan. la misma pregunta.

Con esta técnica, un atacante puede lanzar un ataque basado en el tiempo en un sitio web y determinar los nombres de las cuentas de administrador y puede extraer contraseñas de usuario con hash.

El SQL real enviado a la base de datos podría verse similar al siguiente:

1	select post_title from wp_posts where ID=1 
2	  union select IF(
3	    substring(wp_users.user_login,1,1)='a', 
4	    BENCHMARK(5000000,ENCODE('blah','asdf')),
5	    null)
6	  from wp_users where ID=1

Lo que dice este SQL es «seleccione el título de la publicación donde el ID de la publicación es 1, pero combine en una consulta que llevará mucho tiempo si suponemos que la cuenta de usuario con ID 1 (que generalmente es una cuenta de administrador) tiene la letra ‘ a’ como primera letra del nombre de usuario”.

Cuando se ejecuta esta consulta, si la página tarda mucho en cargarse, el atacante ha adivinado correctamente la primera letra del nombre de usuario del administrador. Luego pueden pasar a las letras dos y tres hasta que tengan su nombre de usuario de administrador. Una vez que lo tengan, pueden extraer su contraseña hash de administrador, su correo electrónico de administrador, cualquier correo electrónico de usuario o cualquier dato que deseen, siempre que se tomen el tiempo suficiente para ejecutar el ataque.

Recuerde, estos ataques son automatizados y las conjeturas incorrectas no toman tiempo, por lo que los datos se pueden extraer con relativa rapidez utilizando esta técnica.

Ataques de inyección SQL ciegos basados ​​en contenido

Un ataque de inyección SQL ciega basado en contenido es otra forma en que un atacante extrae datos de una base de datos cuando no puede ver la salida de la base de datos.

Si la consulta que genera el contenido es la siguiente (recuerde, el resultado de la consulta no se envía al usuario)

select post_status from wp_posts where ID=1

Supongamos que el valor ‘1’ anterior es un parámetro de consulta sin filtrar agregado a la consulta de la base de datos como en nuestro ejemplo anterior. Por tanto, un atacante puede controlar todo el texto después de ‘ID=’.

Un atacante puede agregar lo siguiente a la consulta para verificar que si incluye una condición falsa, verá generado contenido inusual:

select post_status from wp_posts where ID=1 and 1=2

Obviamente, 1 no es igual a 2, por lo que en la consulta anterior la base de datos devolverá un conjunto de resultados vacío. 

Ejemplos de inyección SQL ciegos

El atacante examinará la página resultante y si es una página sin contenido o un mensaje de error que dice algo como «sin contenido», sabrá cómo se ve la respuesta de una consulta vacía con una condición falsa. Luego, el atacante puede incluir algo como lo siguiente:

1	select post_status from wp_posts where ID=1 
2	  and (select ID from wp_users where
3	  user_login='admin' and ID=1)

La consulta anterior estará vacía si el usuario de la base de datos con ID 1 no tiene el nombre de usuario ‘admin’. Sin embargo, devolverá un resultado normal no vacío al navegador si el usuario con ID 1 tiene el nombre de usuario «admin». Con esta técnica, un atacante puede extraer datos de una base de datos comprobando si hay respuestas vacías y no vacías de la aplicación.

Otro ejemplo de una consulta de inyección SQL ciega basada en contenido es:

1	select post_status from wp_posts where
2	  ID=1 and (select 1 from wp_users where
3	  substring(user_pass,1,1) = 'a' and ID=1)

La consulta anterior verificará si la primera letra de la contraseña hash para el usuario con ID 1 es una ‘a’. Con esta técnica, un atacante puede revisar cada carácter y extraer la contraseña hash de las cuentas de administrador.

CONSECUENCIAS

Las consecuencias de una inyección SQL pueden incluir:

  • Pérdida o alteración de datos: el atacante puede eliminar, modificar o extraer información de la base de datos.
  • Inestabilidad del sistema: el código malicioso puede causar que la base de datos deje de funcionar correctamente, lo que puede resultar en tiempos de inactividad y pérdida de disponibilidad.
  • Dificultad para detectar y mitigar el ataque: debido a que el código malicioso se inserta en una consulta SQL legítima.
  • Posibilidad de propagación del ataque: si el atacante tiene acceso a datos sensibles, como contraseñas de usuario, puede utilizarlos para propagar el ataque a otros sistemas.
  • Acceso no autorizado: un atacante podría obtener acceso no autorizado al sistema o a la aplicación web, lo que le permitiría acceder a información confidencial o realizar acciones maliciosas en el sistema.
  • Modificación de datos: un atacante podría modificar, eliminar o agregar datos al sistema, lo que podría tener graves consecuencias en la integridad y exactitud de los datos.
  • Ejecución de código malicioso: un atacante podría ejecutar código malicioso en el sistema, lo que podría resultar en la toma de control del sistema o en el robo de información confidencial.
  • Denegación de servicio: un atacante podría utilizar la inyección de comando para sobrecargar el sistema y hacer que se vuelva inoperable.

La no corrección de esta falla puede causar divulgación no autorizada de su información y la de sus clientes que podría dar lugar a fraude, usurpación de identidad y a sanciones reglamentarias.

Para evitar la inyección de comandos, es importante validar y filtrar todas las entradas de usuario en las aplicaciones web, y evitar el uso de comandos de shell en aplicaciones web. Además, es importante mantener todas las aplicaciones y sistemas actualizados y parcheados para evitar que se exploten vulnerabilidades conocidas.

SOLUCIÓN

Es una tarea difícil determinar si una cadena de usuario es maliciosa o no. Por lo tanto, la mejor manera de hacerlo es “escapar” de los caracteres especiales en la entrada del usuario. Puede escapar una cadena antes de construir la consulta en PHP usando la función mysql_escape_string(). O en MySQL usando la función mysqli_real_escape_string().

Mientras se muestra la salida como HTML, también tendrá que convertir la cadena para asegurarse de que los caracteres especiales no interfieren con el marcado HTML. Puede convertir caracteres especiales en PHP usando la función htmlspecialchars(). Alternativamente, puede usar sentencias preparadas para evitar las inyecciones de SQL. Una sentencia preparada es una plantilla de una consulta SQL, en la que se especifican los parámetros en una etapa posterior para ejecutarla. Aquí hay un ejemplo de una declaración preparada en PHP y MySQL.

$query = $mysql_connection->prepare(«select * from user_table where username = ? and password = ?»);

$query->execute(array($username, $password));

Medidas a tomar para prevenir la inyección SQL avanzada

Para prevenir y solucionar la inyección SQL avanzada, se pueden tomar las siguientes medidas:

  • Validar y sanitizar todas las entradas de datos: Asegúrese de que todas las entradas de datos, ya sean proporcionadas por los usuarios o por otras fuentes, sean validadas y sanitizadas adecuadamente antes de ser utilizadas en una consulta SQL.
  • Utilizar consultas parametrizadas: En lugar de construir una consulta SQL dinámicamente utilizando cadenas de texto, utilice consultas parametrizadas que permitan que los parámetros sean pasados como argumentos separados. Esto reducirá la posibilidad de inyección SQL, ya que los valores de los parámetros son tratados como datos, no como parte de la consulta SQL.
  • Limitar los permisos de la base de datos: Asegúrese de que los usuarios de la base de datos tengan solo los permisos necesarios para realizar sus funciones y nada más. Esto limitará el alcance de cualquier posible ataque.
  • Utilizar herramientas de seguridad y pruebas de penetración: Realice pruebas regulares de seguridad y pruebas de penetración en la aplicación para identificar posibles vulnerabilidades y errores de seguridad. También puede utilizar herramientas de seguridad de terceros para proteger la aplicación contra la inyección SQL.
  • Actualización y parcheo del software de la base de datos y uso de firewalls de aplicación web (WAF)

En resumen, para solucionar y prevenir la inyección SQL avanzada, es necesario validar y sanitizar todas las entradas de datos, utilizar consultas parametrizadas, limitar los permisos de la base de datos y utilizar herramientas de seguridad y pruebas de penetración.

REFERENCIAS 

Pruebas de inyección SQL: todo lo que necesita saber

Para mejorar sus habilidades de pentester de aplicaciones web, es importante aprender a detectar vulnerabilidades de inyección SQL. Profundizarwmoa en los principios y métodos de prueba que pueden descubrir los detalles de esta amenaza. Exploraremos técnicas de prueba manuales, como analizar URL y formularios, comprender la interacción del usuario y el procesamiento de aplicaciones.

Además, proporcionaremos ejemplos reales de cargas útiles de inyección SQL que puede utilizar en sus propias pruebas. Para mejorar aún más sus habilidades, cubriremos la automatización con herramientas como SQLmap y Burp Suite, que ofrecen información de expertos de la industria sobre técnicas modernas. También obtendrá conocimientos sobre la interpretación de mensajes de error complejos que son cruciales para identificar y resolver problemas. Al dominar las técnicas básicas y avanzadas descritas en este artículo, podrá mejorar la seguridad de sus aplicaciones y contribuir a un entorno digital más seguro.

Comprender las inyecciones SQL

Las inyecciones SQL son una vulnerabilidad informática que puede afectar aplicaciones web y bases de datos que utilizan el lenguaje SQL. Estos ataques aprovechan las vulnerabilidades en los formularios de entrada y las URL dentro de las aplicaciones. Insertan intencionalmente declaraciones SQL dañinas en las solicitudes del servidor. El objetivo principal de un ataque de inyección SQL es controlar cómo funciona la base de datos. Esto permite el acceso no autorizado a datos confidenciales extrayéndolos, modificándolos o eliminándolos.

Los ataques de inyección SQL se pueden dividir en varias categorías. Los más conocidos son:

Inyección basada en errores: esta técnica implica insertar entradas dañinas en la base de datos de un sistema para provocar errores. Estos errores potencialmente pueden brindarle información útil.

Inyección basada en unión: el operador UNION le permite combinar los resultados de una consulta dañina y una consulta válida. Esto les permite acceder a datos de otras tablas sin permiso.

Inyección ciega : en este tipo de ataque, el perpetrador no recibe una respuesta directa del servidor. En cambio, infieren información sobre el comportamiento del sistema para recopilar datos. 

Inyección ciega basada en el tiempo : esta técnica implica agregar intencionalmente retrasos a las consultas para verificar la precisión de condiciones específicas. Al analizar los mensajes de error, puede extraer información valiosa sobre la base de datos, lo que ayuda a una mayor explotación, como descubrir nombres de tablas o detalles del sistema, sin generar alarmas ni sospechas.


Pruebas manuales de inyección SQL

Profundicemos ahora en las técnicas manuales de prueba de inyección SQL examinando de cerca la estructura de la URL. Al hacerlo, podemos identificar vulnerabilidades potenciales y explotarlas con fines de evaluación de seguridad.

Analizando la estructura de la URL

Durante el proceso de prueba manual de inyección SQL, un análisis profundo de la estructura de la URL es esencial para identificar y evaluar vulnerabilidades en las aplicaciones web. Este enfoque implica identificar debilidades en la aplicación inyectando intencionalmente código SQL malicioso a través de parámetros que se encuentran dentro de las URL.

Analizar la vulnerabilidad

Para analizar la vulnerabilidad de un sitio web a los ataques de inyección SQL, es importante identificar cualquier entrada del usuario que se transmita a través de los parámetros de la URL. Estos parámetros pueden servirle potencialmente como puntos de entrada. Una vez que se identifican estos parámetros, probar su manipulabilidad se vuelve crucial.

Esto implica insertar varias cadenas de prueba, caracteres especiales y secuencias de escape para determinar si la aplicación maneja adecuadamente dichas entradas sin generar errores.

Otro paso importante es examinar minuciosamente los mensajes de error que produce la aplicación. Estos mensajes pueden exponer inadvertidamente vulnerabilidades internas en el sistema, descubriendo potencialmente debilidades de inyección SQL.

Por ejemplo, en la imagen de arriba, puede ver un error generado al manipular el parámetro de usuario en la URL, lo que nos ayuda a identificar la consulta SQL específica  que está causando el error. Esto luego podría usarse para intentar explotar la vulnerabilidad que está causando el error o lanzar un ataque de denegación de servicio (DoS) en el sitio web enviando demasiadas consultas SQL no válidas.

Un análisis mas profundo

Para profundizar más en las pruebas de este tipo de URL, puede intentar identificar dónde se inserta la entrada del usuario en la consulta SQL. Puede ser un campo de entrada, una variable en la URL o cualquier forma de entrada del usuario.

Para comenzar, puede utilizar una carga útil de SQL básica como esta:’ OR ‘1’=’1

Inserte esta carga útil en la entrada sospechosa y vea si el mensaje de error de SQL desaparece. Si el mensaje de error desaparece o se produce un comportamiento diferente, podría ser una señal de que el sitio es vulnerable a un ataque de inyección SQL. Si la carga útil básica no produce resultados significativos, es posible que desee experimentar con cargas útiles de SQL más avanzadas, como la inyección SQL ciega basada en UNION o basada en tiempo. Por ejemplo, una carga útil basada en UNION que podrías probar es: ‘ UNION

SELECT null, username, password FROM users–

Este tipo de carga útil intenta extraer información de la tabla de usuarios. Sin embargo, tenga cuidado al utilizar cargas útiles avanzadas como esta, ya que pueden afectar negativamente al sitio que está probando, si no se usan correctamente.

En resumen, analizar la estructura de la URL en las pruebas manuales de inyección SQL puede ayudar a identificar vulnerabilidades potenciales y evaluar la capacidad de una aplicación para manejar entradas maliciosas, brindándole datos importantes para continuar con su pentest.

Campos de formulario y mecanismos de validación

Los campos de formulario en una aplicación web sirven como punto de entrada para la entrada del usuario. Puede explotar estos campos mediante inyecciones SQL, donde inyecta código SQL dañino. Estos campos de formulario se utilizan comúnmente para recopilar datos importantes del usuario, como nombres, direcciones de correo electrónico, contraseñas y más.

La combinación de campos de formulario bien diseñados con mecanismos de validación sólidos puede mitigar eficazmente el riesgo de inyecciones de SQL. Por ejemplo, un campo de correo electrónico debe aceptar estrictamente sólo direcciones de correo electrónico válidas, evitando la inserción de caracteres especiales que podrían manipular consultas SQL. Este no es siempre el caso y está sujeto a abuso.

Probar para ver si el formulario acepta caracteres especiales o entradas no típicas puede indicar la posibilidad de enviar comandos o solicitudes maliciosos a la base de datos.

Cuando se prueban manualmente las vulnerabilidades de inyección SQL, las medidas de seguridad existentes, como la validación de las entradas del usuario, a veces pueden impedir el proceso de inyección. En tales casos, vale la pena explorar cargas útiles básicas, como insertar ‘OR 1=1– en el campo de entrada; Este tipo de cargas útiles se denominan cargas útiles de omisión porque utilizan una condición que siempre es verdadera para manipular una entrada vulnerable y omitir la autenticación, acceder a datos no autorizados o ejecutar comandos maliciosos.

Si bien la validación de entradas es una salvaguarda importante, no siempre es infalible, por lo que para identificar posibles vulnerabilidades es esencial realizar pruebas completas y exhaustivas.

Valores de cookies y encabezados HTTP

En las pruebas de inyección SQL manuales, puede manipular las solicitudes explotando los valores de las cookies y los encabezados HTTP de una aplicación web. Estos elementos se consideran entradas externas, por lo que es importante que realice pruebas adecuadas con las herramientas correctas (como Burp Suite).

Las cookies, que contienen información almacenada en el navegador de un usuario, pueden ser vulnerables a la manipulación. Un método común es inyectar código SQL dañino alterando los datos dentro de una cookie. Si se utiliza una cookie, por ejemplo, para almacenar una identificación de usuario en una aplicación, puede intentar modificar esa identificación dentro de la propia cookie. Este tipo de explotación podría dar lugar a un acceso no autorizado a datos o funciones sensibles.

Ejemplos

Por ejemplo, considere una aplicación que utiliza una cookie para controlar al usuario que ha iniciado sesión actualmente. Ahora, supongamos que un hacker con intenciones maliciosas logra alterar esta cookie alterando el ID de usuario que contiene.

Si la aplicación no aborda adecuadamente esta modificación, podría generar involuntariamente una consulta SQL dañina basada en el ID manipulado. Esto podría potencialmente otorgar acceso no autorizado a datos confidenciales.

Además, cuando un navegador envía una solicitud a una aplicación, incluye encabezados HTTP como User-Agents. Usted (el atacante) puede alterar estos encabezados insertando cadenas dañinas en las solicitudes. Por ejemplo, podría utilizar la siguiente carga útil:’UNION SELECT null, username, password FROM users–

Esta carga útil está diseñada para extraer datos de la tabla de «usuarios» de una base de datos. Supongamos que tiene una solicitud HTTP GET que incluye un parámetro «cat» en el que colocar la carga útil. En la pestaña «Solicitud HTTP» de Burp Suite, cambie el parámetro «cat» para que contenga la carga útil, por ejemplo:cat=’ UNION SELECT null, username, password FROM users–

Comience a enviar la solicitud y observe la respuesta. Si el sitio es vulnerable a una inyección SQL basada en UNION, obtendrá una respuesta que incluye información de la tabla «usuarios».

En ambos casos, es esencial garantizar que la aplicación maneje de forma segura los valores de las cookies y los encabezados HTTP. Las pruebas manuales implican analizar el impacto de dichas manipulaciones en las entradas de la aplicación y verificar su respuesta a posibles ataques de inyección SQL.

Entrada controlada por el usuario (UCI) procesada por la aplicación

Cuando se prueban manualmente las vulnerabilidades de inyección SQL, el concepto de «Entrada controlada por el usuario» o UCI se refiere a cualquier entrada proporcionada por el usuario y posteriormente procesada por la aplicación. Esto puede incluir datos ingresados ​​en campos de formulario, valores de cookies, parámetros en URLs o encabezados HTTP (que ya vimos antes), puedes aprovechar estas oportunidades para inyectar código SQL malicioso y causar grandes daños.

En este enfoque, manipula intencionalmente la entrada proporcionada para insertar caracteres especiales o secuencias de escape (como ‘’ o =). Estas manipulaciones pueden alterar las consultas SQL generadas por la aplicación y explotar vulnerabilidades en su procesamiento de entrada. El objetivo es engañar a la aplicación para que ejecute consultas SQL no deseadas, lo que resulta en una extracción de datos no autorizada o en un compromiso del sistema.

Debe tener una lista de cargas útiles de inyección SQL

Las cargas útiles son fragmentos de código que se insertan intencionalmente en los campos de entrada de las aplicaciones web. Estos fragmentos tienen como objetivo explotar las vulnerabilidades en los sistemas de gestión de bases de datos. Los profesionales de la seguridad y los evaluadores de penetración suelen utilizar estas herramientas para evaluar el nivel de resistencia que tiene una aplicación contra posibles ataques. A continuación, se muestra una lista de las cargas útiles de inyección SQL más comunes utilizadas por Pentesters  y Bug Bounty Hunters  para probar manualmente formularios en busca de vulnerabilidades de inyección SQL.

Lista de las cargas útiles de inyección SQL más comunes

  • payload de inyección SQL básica:  ‘ OR ‘1’=’1 (se utiliza para omitir la autenticación ingresando una condición que siempre es verdadera).
  • Recuperar información:  ‘ UNION SELECT null,username,password FROM users– (Se utiliza para extraer datos confidenciales como nombre de usuario y contraseña de la base de datos).
  • Manipulación de consultas:  ‘; DROP TABLE users; — (Se utiliza para provocar la eliminación de la tabla «usuarios»).
  • Obtener los nombres de las tablas:  ‘ AND 1=0 UNION SELECT table_name, null FROM information_schema.tables– (Se utiliza para extraer los nombres de las tablas en la base de datos).
  • Extraer nombre de la base de datos:  ‘ AND 1=0 UNION SELECT null, database()– (Se utiliza para extraer el nombre de la base de datos actual).
  • Uso de UNION para extraer datos:  ‘ UNION SELECT username, password FROM users– (Se utiliza para extraer datos confidenciales mediante una operación UNION).
  • Uso de comentarios para omitir:  admin’ — (Utiliza un comentario para omitir el resto de la entrada e iniciar sesión como administrador).
  • Uso de SQLi ciego basado en tiempo:  ‘ OR IF(1=1, SLEEP(5), 0)– (Retrasa la respuesta del servidor para confirmar la vulnerabilidad de inyección SQL).
  • Uso de SQLi basado en errores:  ‘ AND 1=CONVERT(int, (SELECT @@version))– (fuerza un error de SQL a revelar información de la base de datos).

Todas estas cargas útiles se pueden usar (y son las más efectivas) en formularios de inicio de sesión vulnerables, URL (usadas como consultas maliciosas) y solicitudes (capturadas y modificadas por usted con la carga útil correcta).

Pruebas automatizadas de inyección de SQL

Cuando se trata de seguridad de la información, herramientas como SQLmap y Burp Suite gozan de gran prestigio en el campo de las pruebas de inyección SQL.

Descripción general de las herramientas: SQLmap y Burp Suite

Estas herramientas son ampliamente utilizadas por los profesionales de la seguridad y brindan soluciones automatizadas efectivas para detectar y explotar vulnerabilidades de inyección SQL en aplicaciones web. Si bien SQLmap se especializa en pruebas y automatización avanzadas, Burp Suite ofrece un ecosistema completo para analizar la seguridad de las aplicaciones. Permite a los expertos identificar, evaluar y abordar vulnerabilidades críticas, incluidas aquellas relacionadas con ataques de inyección SQL.

Herramientas y para qué se utilizan:

SQLmap : es una valiosa herramienta de código abierto que automatiza las pruebas de inyección de SQL. Detecta vulnerabilidades de forma eficaz, extrae datos y compromete los sistemas de bases de datos utilizando una variedad de cargas útiles y técnicas. Los probadores de penetración dependen principalmente de SQLmap para evaluar la seguridad de las aplicaciones.

Burp Suite : es un conjunto completo de herramientas diseñadas para la seguridad de aplicaciones web. Entre sus características, la herramienta incluye un módulo de Seguridad de Aplicaciones Web (WAS), que ayuda a los especialistas en seguridad a identificar y abordar vulnerabilidades en sitios web. Este módulo puede detectar amenazas de seguridad comunes que incluyen, como es de esperar, ataques de inyección SQL.

Ejecución de SQLmap para buscar y explotar inyecciones de SQL

Ahora, usemos SQLmap para descubrir sistemáticamente vulnerabilidades de inyección SQL en un sitio web deliberadamente vulnerable. Nuestro objetivo será VulnWeb ( http://testphp.vulnweb.com ), un sitio web diseñado específicamente para que los estudiantes de Seguridad Cibernética aprendan atacando y explotando sus vulnerabilidades.

Si encuentra una URL web como, en este caso, http://testphp.vulnweb.com/listproducts.php? cat=1 , donde el parámetro ‘GET’ está resaltado, podría indicar que el sitio web es susceptible a ataques de inyección SQL. En tales casos, es posible que pueda acceder a información confidencial de la base de datos. Se sabe que SQLmap es el más eficaz en escenarios que involucran sitios web basados ​​en PHP.

Paso 1: Evaluación del parámetro de la URL

Una forma sencilla de determinar si su sitio web es vulnerable es reemplazar el valor en el parámetro de solicitud de obtención con un *  (asterisco).

Este tipo de error sugiere que el sitio web es vulnerable a algún tipo de ataques de inyección SQL.

Paso 2: comprobar la URL con SQLmap

Necesitamos ingresar la URL web deseada que debe verificarse, usando el parámetro -u . Generalmente el objetivo principal es determinar si es posible acceder a una base de datos, por lo que podemos utilizar la opción –dbs  para este propósito. Al utilizar –dbs, podemos obtener una lista de todas las bases de datos disponibles.

El primer comando será:

sqlmap -u http://testphp.vulnweb.com/listproducts.php?cat=1 –dbs

Paso 3: comprender el resultado

En el resultado anterior, puede ver en amarillo las partes donde SQLmap encontró vulnerabilidades de inyección SQL y en naranja las mejores cargas útiles, sugeridas por SQLmap, para usar ese tipo específico de inyección SQL (por ejemplo, la primera vulnerabilidad encontrada es una vulnerabilidad booleana). Inyección SQL ciega basada y la carga útil sugerida es: cat-1 AND 1050-1050). Tomemos, por ejemplo, la última parte del resultado, resaltada en amarillo, que dice: “El parámetro GET ‘cat’ es ‘ Consulta UNION genérica ‘.

Esta parte del resultado nos dice que el parámetro «cat» de una solicitud GET (que es el tipo de solicitud web que, en este caso, SQLmap está usando para probar la URL) dentro de «http://testphp.vulnweb.com /listaproductos.php? cat =1” es vulnerable a una consulta UNION genérica.

Pero ¿qué es una consulta UNION Genérica?

Es un ataque que normalmente implica manipular la consulta SQL para combinar los resultados de 2 o más tablas de bases de datos, lo que le permite obtener acceso no autorizado a datos confidenciales. En resumen, este resultado de SQLmap sugiere que se necesitan más pruebas para confirmar si el parámetro ‘cat’ es realmente vulnerable a un ataque de inyección SQL de «consulta UNION genérica». Es una señal para investigar y potencialmente explotar una vulnerabilidad en la validación de entrada de la aplicación (que es la parte de la aplicación web que verifica y permite la entrada del usuario según la consulta utilizada).

Y es por eso que podemos ver, en el último resultado resaltado en naranja, que SQLmap sugiere una carga útil específica, para probar manualmente el sitio web vulnerable para ese tipo de ataque de inyección SQL.

Análisis de mensajes de error

Durante el proceso de análisis de errores en las pruebas de inyección SQL, los errores generados por una aplicación pueden ofrecer información importante sobre la existencia de vulnerabilidades. Por ejemplo, los mensajes de error que contienen información confidencial como nombres de tablas, errores flagrantes de sintaxis SQL en los comentarios de la aplicación y respuestas inconsistentes, como resultados faltantes o duplicados, pueden indicar una posible manipulación de la consulta.

Estos mensajes de error pueden ofrecer información valiosa sobre el funcionamiento interno del sistema. Para activar estos mensajes, se pueden ingresar intencionalmente datos maliciosos que provoquen que las consultas fallen. En la imagen de arriba, puede ver un error de sintaxis SQL (que ya mencionamos antes) que aparece después de cambiar el valor del parámetro cat de » 1 » a * (ejemplo de entrada maliciosa).

Si encuentra errores de sintaxis SQL, como el comúnmente visto «Tiene un error en su sintaxis SQL» (que podemos ver en la imagen), generalmente significa que la entrada se incluye directamente en las consultas sin la verificación adecuada. Este tipo de errores a menudo indican un comportamiento interno del sistema y ayudan a los expertos en seguridad a identificar posibles debilidades en las aplicaciones.

Preguntas frecuentes

¿Es ilegal realizar pruebas de inyecciones de SQL?

La legalidad de cualquier Pentest depende únicamente de las leyes locales y federales de su país, por lo que es una buena práctica estar informado sobre ellas antes de realizar cualquier tipo de prueba activa. Sin embargo, no debería haber ningún problema siempre que la actividad se realice de manera responsable y en plataformas donde se haya obtenido el permiso por escrito  del propietario.

¿Qué son las técnicas de inyección SQL?

Existen varias técnicas que se pueden utilizar para manipular consultas, como ataques UNION, ataques basados ​​en tiempo y ataques basados ​​en errores. Estas técnicas implican el uso de datos maliciosos para explotar vulnerabilidades.

¿Cuál es la mejor herramienta de inyección SQL?

Para fines de automatización, SQLmap se utiliza ampliamente, mientras que Burp Suite ofrece una solución versátil para análisis de seguridad.

¿Necesito aprender SQL para inyecciones de SQL?

Tener algunos conocimientos de SQL puede resultar útil, pero también hay herramientas disponibles que pueden simplificar el proceso de identificación de vulnerabilidades.

 Advanced SQL Injection

La inyección SQL avanzada es una técnica más sofisticada que la inyección SQL básica, que utiliza técnicas más complejas para explotar vulnerabilidades en las aplicaciones web. Esto puede incluir la manipulación de los datos de entrada de la aplicación, la identificación de patrones de filtrado, la explotación de errores en la aplicación y la utilización de herramientas automatizadas para la inyección de código malicioso. Este ataque puede tener consecuencias graves, como la exposición de información confidencial, el robo de datos, la alteración de la información almacenada en la base de datos y la pérdida de datos importantes. Por lo tanto, es importante que las empresas y desarrolladores de aplicaciones web implementen medidas de seguridad adecuadas para evitar este tipo de ataques. 

 Inyección NoSQL – MongoDB

La Inyección NoSQL (NoSQL Injection) es una vulnerabilidad que ocurre cuando se ingresan datos no validados o maliciosos en una consulta NoSQL, lo que permite a un atacante manipular la consulta para obtener información confidencial, borrar datos o ejecutar código malicioso en el servidor.

Las consecuencias de una Inyección NoSQL pueden ser graves y variadas, dependiendo del tipo de datos que se almacenen en la base de datos y de la capacidad de los atacantes para explotar la vulnerabilidad.

Al igual que cualquier ataque de inyección, consiste en utilizar un vector de ataque que al ejecutarse en la aplicación nos permita alterar el funcionamiento de la misma para obtener información, modificarla o saltearnos el proceso de login. Aunque no usar el lenguaje SQL puede hacer más difícil la ejecución de una inyección de código, no es defensa suficiente en contra de estos ataques.

Es cierto que, entonces, ya no funcionarían herramientas como SQLMap, que sirven para automatizar y facilitar los ataques de inyección SQL. No obstante, también hay exploits para otros tipos de lenguajes comunes como, por ejemplo, MongoDB.

Sencillamente, el atacante necesitará otra sintaxis si desea hacer una inyección de código en una base de datos diferente. Sin embargo, la configuración de tal página debe hacerse rigurosamente si desea evitarse un peligroso ataque de inyección NoSQL, que podría llevar a las mismas consecuencias de uno con SQL. Es decir, desde el robo de datos hasta el control total de la máquina.

CONSECUENCIAS

Algunas de las posibles consecuencias de una Inyección NoSQL son:

  • Fuga de datos confidenciales: Si los atacantes pueden manipular la consulta para obtener información confidencial, pueden acceder a datos como contraseñas, nombres de usuarios, direcciones de correo electrónico, números de tarjetas de crédito y otros datos sensibles.
  • Modificación o eliminación de datos: Si los atacantes pueden manipular la consulta para modificar o eliminar datos, pueden causar daños significativos al sistema y a los datos almacenados.
  • Denegación de servicio (DoS): Si los atacantes pueden manipular la consulta para ejecutar código malicioso en el servidor, pueden causar una sobrecarga del sistema o una denegación de servicio (DoS) que puede dejar fuera de línea el sitio web o la aplicación.
  • Vulnerabilidad en cadena: Una Inyección NoSQL también puede ser el punto de entrada para una cadena de vulnerabilidades, lo que permite a los atacantes aprovechar otras vulnerabilidades en la aplicación o en el sistema para obtener más acceso y control.

En resumen, una Inyección NoSQL puede tener consecuencias graves para la seguridad y privacidad de los datos almacenados en una base de datos NoSQL, lo que puede afectar la reputación de la empresa, la confianza de los usuarios y la estabilidad del sistema. Es importante tomar medidas de seguridad para prevenir la Inyección NoSQL, como la validación de datos, el uso de parámetros en las consultas y la implementación de cortafuegos.

SOLUCIÓN

Para evitar la inyección NoSQL, es importante implementar las siguientes medidas de seguridad:

  • Validación de entrada de datos: Todos los datos ingresados por los usuarios deben ser validados y filtrados para asegurarse de que no contienen caracteres maliciosos que puedan ser explotados en un ataque.
  • Limitación de permisos: La base de datos debe ser configurada para limitar los permisos de los usuarios y solo permitir el acceso a las funciones y datos necesarios para realizar sus tareas.
  • Encriptación: Los datos sensibles almacenados en la base de datos deben ser encriptados para protegerlos de accesos no autorizados.
  • Auditoría de seguridad: Debe haber un sistema de registro de eventos y seguimiento de auditoría en lugar para detectar cualquier actividad sospechosa en la base de datos.
  • Actualizaciones de seguridad: Mantener la base de datos actualizada con las últimas actualizaciones de seguridad y parches de software puede reducir la exposición a vulnerabilidades conocidas.

Además, es importante educar a los desarrolladores y usuarios sobre las buenas prácticas de seguridad y asegurarse de que todos los procedimientos de seguridad estén documentados y sean fácilmente accesibles para el equipo de desarrollo.

REFERENCIAS  

Conclusión

En resumen, las pruebas de inyección SQL son una herramienta esencial para los evaluadores de penetración de aplicaciones web. En esta exploración exhaustiva, nos hemos sumergido en los principios y metodologías fundamentales que nos permiten descubrir vulnerabilidades. Hemos explorado las pruebas manuales en detalle, donde un análisis profundo de las URL, los formularios y las interacciones de los usuarios revela posibles puntos débiles.

Cuando se trata de prevenir inyecciones SQL, los campos de formulario y los mecanismos de validación son muy importantes. Sin embargo, a veces estas medidas pueden obstaculizar el proceso de prueba y es posible que los evaluadores capacitados necesiten utilizar cargas útiles de derivación. Las herramientas automatizadas como SQLmap y Burp Suite resultan invaluables para realizar evaluaciones exhaustivas.

Hemos explicado en detalle cómo funcionan las vulnerabilidades de inyección SQL y las vulnerabilidades de inyección SQL ciega. La clave para evitar estas vulnerabilidades es desinfectar y escapar de todo lo que envíe a la base de datos. En WordPress, la forma más sencilla de hacerlo es utilizando el método prepare() y marcadores de posición en su SQL. Ahora que comprende cómo los atacantes explotan estas vulnerabilidades, podrá proteger mejor sus propios sitios web y los de sus clientes.

No te detengas, sigue avanzando

Aquí tienes un propósito para este 2024 que debes considerar seriamente: si has querido mejorar tus habilidades en hacking, Ciberseguridad y programación ahora es definitivamente el momento de dar el siguiente paso. ¡Desarrolla tus habilidades aprovechando nuestros cursos a un precio increíble y avanza en tu carrera!

Pentesting Web. Prácticas de un Ethical Hacker Profesional

Aprende Pentesting Web, Hacking Ético y Ciberseguridad. Practicas reales y aprender todo sobre Vulnerar entornos Web.

Calificación: 4,2 de 54,2 (609 calificaciones) 30.473 estudiantes Creado por Alvaro Chirou • 1.800.000+ Enrollments Worldwide, Walter Coto || +440,000 Estudiantes

Lo que aprenderás

  • Hacking Ético Web
  • El TOP 10 Vulnerabilidades Web de OWASP
  • Uso de Burp Suite
  • Identificar Vulnerabilidades Web
  • Explotar Vulnerabilidades Web
  • Identificar Vulnerabilidades que NO son de OWASP TOP 10
  • Prácticar con Escenarios Reales de Hacking Web
  • Las 5 Fases del Pentesting Web

El Pentesting Web se enfoca principalmente en aplicaciones y paginas funcionando en internet. Esto genera que su demanda laboral sea además de muy alta, sumamente importante.

La gran ventaja de esta profesión es que efectivamente, puedes llevarla adelante desde cualquier parte del mundo, con una computadora e internet.

Nosotros te brindaremos los fundamentos teóricos y la base necesaria para que empieces desde 0, y vayas avanzando hacia el ámbito profesional, con laboratorios simulando entornos reales

Hemos creado esta formación profesional donde aprenderás todo lo que necesitas para ser un experto, y con practicas que podrás aplicar en escenarios reales.

Contaras con nuestra supervisión, experiencia y respuesta a todas tus preguntas que tengas sobre el contenido. Así también sobre las actualizaciones que hagamos sobre el curso, el cual será tuyo de por vida y recibirás dichas actualizaciones sin tener que volver a pagar.

Empieza a aprender ya mismo y acompáñame en este increíble curso.

¿Te gustaría enterarte de cuando lanzamos descuentos y nuevos cursos?

Sobre los autores

Álvaro Chirou

Yo soy Álvaro Chirou, tengo más de 20 Años de experiencia trabajando en Tecnología, eh dado disertaciones en eventos internacionales como OWASP, tengo más de 1.800.000 estudiantes en Udemy y 100 formaciones profesionales impartidas en la misma. Puedes serguirme en mis redes:

Laprovittera Carlos

Soy Laprovittera Carlos. Con más de 20 años de experiencia en IT brindo Educación y Consultoría en Seguridad de la Información para profesionales, bancos y empresas. Puedes saber más de mi y de mis servicios en mi sitio web: laprovittera.com y seguirme en mis redes:

¿Quieres iniciarte en hacking y ciberseguridad pero no sabes por dónde empezar? Inicia leyendo nuestra guia gratuita: https://achirou.com/como-iniciarse-en-ciberseguridad-y-hacking-en-2024/ que te lleva de 0 a 100. Desde los fundamentos más básicos, pasando por cursos, recursos y certificaciones hasta cómo obtener tu primer empleo.

Cómo Iniciarse en Hacking y Ciberseguridad en 2024

Cómo Iniciarse en Hacking y Ciberseguridad en 2024

Enviar comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *