Tutorial de inyección SQL: aprenda con el ejemplo

⚡ Resumen inteligente

La inyección SQL es un ataque que manipula sentencias SQL dinámicas para eludir la autenticación o exponer datos, aprovechando aplicaciones web que generan consultas a partir de datos de usuario no validados. Esta página explica cómo funciona el ataque y cómo prevenirlo.

  • ???? Definición: La inyección SQL inserta código SQL malicioso en una consulta a través de un campo de entrada no validado.
  • 🔓 Repercusiones: Un ataque exitoso puede eludir las credenciales de inicio de sesión y leer, modificar o eliminar registros.
  • 🧪 Ejemplo: Una condición que siempre se cumple, sumada a un comentario, convierte una comprobación de inicio de sesión en una forma de eludirla.
  • 🛠️ Herramientas: SQLMap y jSQL automatizan la detección y explotación de parámetros inyectables.
  • 🛡️ Prevención: Las consultas parametrizadas, la validación de entradas y las cuentas con privilegios mínimos reducen esta brecha.
  • 🤖 Borde moderno: Los escáneres y cortafuegos basados ​​en inteligencia artificial detectan patrones de inyección que las firmas fijas no detectan.

Tutorial de inyección SQL

¿Qué es una inyección SQL?

La inyección SQL es un ataque que manipula sentencias SQL dinámicas para comentar ciertas partes de la sentencia o añadir una condición que siempre será verdadera. Aprovecha las vulnerabilidades de diseño de las aplicaciones web mal diseñadas para explotar las sentencias SQL y ejecutar código SQL malicioso.

Los datos son uno de los componentes más vitales de los sistemas de información. Las organizaciones utilizan aplicaciones web basadas en bases de datos para obtener datos de los clientes. SQL es el acrónimo de lenguaje de consulta estructuradoSe utiliza para recuperar y manipular datos en la base de datos.

Diagrama de cómo una inyección SQL manipula una consulta dinámica de base de datos.

¿Cómo funciona un ataque de inyección SQL?

Los tipos de ataques que se pueden realizar mediante inyección SQL varían según el tipo de motor de base de datos. El ataque funciona con sentencias SQL dinámicas. Una sentencia dinámica es aquella que se genera en tiempo de ejecución utilizando parámetros pasados ​​desde un formulario web o una cadena de consulta URI.

Ejemplo de inyección SQL

Consideremos una aplicación web sencilla con un formulario de inicio de sesión. El código HTML del formulario se muestra a continuación.

<form action=‘index.php’ method="post">

<input type="email" name="email" required="required"/>

<input type="password" name="password"/>

<input type="checkbox" name="remember_me" value="Remember me"/>

<input type="submit" value="Submit"/>

</form>

AQUÍ,

  • El formulario anterior acepta la dirección de correo electrónico y la contraseña, y luego las envía a un PHP archivo llamado index.php.
  • Tiene la opción de almacenar la sesión de inicio de sesión en una cookie. Lo hemos deducido de la casilla de verificación remember_me. Utiliza el método post para enviar datos. Esto significa que los valores no se muestran en la URL.

Supongamos que la instrucción en el backend para verificar el ID del usuario es la siguiente.

SELECT * FROM users WHERE email = $_POST['email'] AND password = md5($_POST['password']);

AQUÍ,

  • La instrucción anterior utiliza los valores del array $_POST[] directamente sin sanitizarlos.
  • La contraseña se cifra mediante el algoritmo MD5.

Ilustraremos un ataque de inyección SQL utilizando SQL Fiddle. Abre el URL http://sqlfiddle.com/ en su navegador web. Aparecerá la siguiente ventana.

Nota: tendrás que escribir las sentencias SQL.

Vacío SQL Fiddle Ventana lista para el esquema y la consulta.

Paso 1) Introduzca este código en el panel izquierdo.

CREATE TABLE `users` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `email` VARCHAR(45) NULL,
  `password` VARCHAR(45) NULL,
  PRIMARY KEY (`id`));
  
  
insert into users (email,password) values ('m@m.com',md5('abc'));

Paso 2) Haga clic en Crear esquema.

Paso 3) Introduzca este código en el panel derecho.

select * from users;

Paso 4) Haz clic en Ejecutar SQL. Verás el siguiente resultado.

SQL Fiddle Resultado que muestra el registro de usuario único devuelto

Supongamos que un usuario proporciona admin@admin.sys y 1234 como contraseña. La instrucción ejecutada en la base de datos sería:

SELECT * FROM users WHERE email = 'admin@admin.sys' AND password = md5('1234');

El código anterior puede ser explotado comentando la parte de la contraseña y agregando una condición que siempre será verdadera. Supongamos que un atacante ingresa lo siguiente en el campo de dirección de correo electrónico.

xxx@xxx.xxx' OR 1 = 1 LIMIT 1 -- ' ]

xxx para la contraseña.

La declaración dinámica generada será la siguiente.

SELECT * FROM users WHERE email = 'xxx@xxx.xxx' OR 1 = 1 LIMIT 1 -- ' ] AND password = md5('1234');

AQUÍ,

  • xxx@xxx.xxx termina con una comilla simple que completa la cadena de citas.
  • OR 1 = 1 LÍMITE 1 es una condición que siempre será verdadera y limita los resultados devueltos a un solo registro.
  • — ‘Y… es un comentario SQL que elimina la parte de la contraseña.

Copie la instrucción SQL anterior y péguela en el SQL Fiddle Ejecute el cuadro de texto SQL como se muestra a continuación.

SQL Fiddle Devolviendo el registro después de que se ejecute la condición inyectada.

Actividad de piratería: SQL inyecta una aplicación web

Disponemos de una sencilla aplicación web en http://www.techpanda.org/ Este código es vulnerable a ataques de inyección SQL y se utiliza únicamente con fines demostrativos. El código HTML del formulario anterior proviene de la página de inicio de sesión. La aplicación ofrece seguridad básica, como la validación del campo de correo electrónico. Esto significa que nuestro código no puede utilizarse para eludir el inicio de sesión.

Para sortear esta limitación, aprovechamos el campo de contraseña. El siguiente diagrama muestra los pasos a seguir.

Diagrama de flujo de los pasos para insertar el campo de contraseña del formulario de inicio de sesión.

Supongamos que un atacante proporciona la siguiente información.

  • Paso 1: Ingrese xxx@xxx.xxx como dirección de correo electrónico
  • Paso 2: Ingrese xxx’) O 1 = 1 — ]

Formulario de inicio de sesión con la cadena de inyección introducida en el campo de contraseña.

  • Haga clic en el botón Enviar.
  • Serás dirigido al panel de control.

La sentencia SQL generada será la siguiente.

SELECT * FROM users WHERE email = 'xxx@xxx.xxx' AND password = md5('xxx') OR 1 = 1 -- ]');

El siguiente diagrama ilustra cómo se genera la declaración.

Desglose de cómo se genera la sentencia SQL inyectada

AQUÍ,

  • La afirmación asume, de forma inteligente, que se utiliza el cifrado MD5.
  • Completa la comilla simple y el paréntesis de cierre.
  • Agrega una condición a la afirmación que siempre será verdadera.

En general, un ataque exitoso combina varias técnicas como las que se muestran arriba.

Otros tipos de ataques de inyección SQL

Las inyecciones SQL pueden causar más daño que simplemente eludir los algoritmos de inicio de sesión. Algunos de los ataques incluyen:

  • Borrando datos
  • Actualizando datos
  • Insertar datos
  • Ejecutar comandos en el servidor que pueden descargar e instalar programas maliciosos como troyanos.
  • Exportar datos valiosos, como detalles de tarjetas de crédito, correo electrónico y contraseñas, al servidor remoto del atacante
  • Obtener los datos de inicio de sesión del usuario, etc.
  • Inyección SQL basada en cookies
  • Inyección SQL basada en errores
  • Inyección SQL ciega

La lista anterior no es exhaustiva; simplemente da una idea de lo que puede hacer una inyección SQL.

Herramientas de automatización para inyección SQL

En el ejemplo anterior, utilizamos técnicas de ataque manuales basadas en nuestro amplio conocimiento de SQL. Existen herramientas automatizadas que pueden ayudarle a realizar los ataques de forma más eficiente y en el menor tiempo posible. Estas herramientas incluyen:

Cómo prevenir ataques de inyección SQL

Una organización puede adoptar la siguiente política para protegerse contra ataques de inyección SQL.

  • Nunca se debe confiar en la información proporcionada por el usuario. – Siempre debe ser desinfectado antes de ser utilizado en sentencias SQL dinámicas.
  • Procedimientos almacenados – Estos pueden encapsular las sentencias SQL y tratar todas las entradas como parámetros.
  • Declaraciones preparadas Las sentencias preparadas funcionan creando primero la sentencia SQL y luego tratando todos los datos de usuario enviados como parámetros. Esto no afecta la sintaxis de la sentencia SQL.
  • Expresiones regulares – Estas herramientas pueden utilizarse para detectar código potencialmente dañino y eliminarlo antes de ejecutar las sentencias SQL.
  • Derechos de acceso de usuario a la conexión de la base de datos – solo se deben otorgar los derechos de acceso necesarios a las cuentas utilizadas para conectarse a la base de datos. Esto puede ayudar a reducir lo que las sentencias SQL pueden realizar en el servidor.
  • Los mensajes de error Estos mensajes no deben revelar información confidencial ni el lugar exacto donde ocurrió el error. En lugar de mostrar las sentencias SQL que causaron el error, se pueden usar mensajes de error personalizados sencillos, como «Lo sentimos, estamos experimentando errores técnicos. Nos hemos puesto en contacto con el equipo técnico. Inténtelo de nuevo más tarde».

Actividad de piratería: utilice Havij para inyección SQL

En este escenario práctico, utilizamos el programa Havij Advanced SQL Injection para escanear un sitio web en busca de vulnerabilidades.

Nota: Havij es un proyecto antiguo y sin mantenimiento. Windows La herramienta SQLMap mencionada anteriormente es el estándar de código abierto actual.

Nota: su programa antivirus puede detectarlo debido a su naturaleza. Debería agregarlo a la lista de exclusiones o pausar su antivirus. programa antivirus.

La imagen que aparece a continuación muestra la ventana principal de Havij.

Ventana principal de la herramienta de inyección SQL Havij

La herramienta mencionada anteriormente puede utilizarse para evaluar la vulnerabilidad de un sitio web o una aplicación.

Preguntas Frecuentes

Solo con el permiso por escrito del propietario del sitio. Probar una aplicación que no le pertenece es ilegal según leyes como la Ley de Fraude y Abuso Informático de EE. UU. El alcance de los programas de recompensas por detección de errores define lo que está permitido.

Sí. En el OWASP Top 10:2025, la inyección ocupa el puesto A05, y las pruebas siguen detectando inyecciones en casi todas las aplicaciones. Con miles de nuevas vulnerabilidades CVE de inyección SQL al año, sigue siendo uno de los principales riesgos web.

MD5 es una función hash rápida, no un cifrado, y los atacantes la descifran rápidamente con tablas arcoíris y GPU. En su lugar, utilice un algoritmo lento con sal, como bcrypt o Argon2, para las contraseñas.

Cualquier base de datos consultada mediante SQL generado dinámicamente — MySQL, PostgreSQL, Microsoft SQL Server, Oracle, y SQLiteEl fallo reside en cómo la aplicación concatena la información introducida por el usuario en las consultas, no en el motor de la base de datos.

Los cortafuegos y escáneres con inteligencia artificial aprenden los patrones de tráfico normales y, a continuación, detectan en tiempo real las entradas anómalas, como condiciones o comentarios inyectados. Los modelos de aprendizaje automático detectan las cargas útiles ofuscadas que las firmas fijas no detectan.

A los asistentes de IA les gusta Copiloto de GitHub Pueden sugerir consultas parametrizadas y validación de entrada, pero también reproducen patrones inseguros. Trate cada sugerencia como un borrador y compárela con un analizador de seguridad para su revisión.

La inyección SQL ataca la base de datos inyectando código SQL en las consultas del servidor. El cross-site scripting ataca a otros usuarios inyectando scripts que se ejecutan en sus navegadores. Una técnica expone datos; la otra secuestra sesiones.

Un ORM (mapeador objeto-relacional) construye consultas a partir de objetos de código con parametrización por defecto, lo que previene la mayoría de las inyecciones SQL. Sin embargo, no es infalible: las consultas directas y los métodos inseguros aún pueden filtrar información, por lo que la validación sigue siendo importante.

Resumir este post con: