¿Qué es una inyección SQL y cómo funciona?

Es un ataque donde el atacante introduce código SQL malicioso en campos de entrada de una aplicación web (formularios, URLs, cabeceras) para que el servidor de base de datos lo ejecute. Permite extraer datos, modificar registros o incluso ejecutar comandos en el sistema operativo.

¿Cómo detecta un perito forense un ataque de inyección SQL?

Analizando logs del servidor web (Apache, Nginx), logs del WAF si existe, logs de la base de datos (general_log, slow_query_log), y correlacionando patrones de tráfico anómalo con las queries ejecutadas en la base de datos.

¿Qué consecuencias legales tiene sufrir una inyección SQL con brecha de datos?

La empresa víctima debe notificar a la AEPD en 72 horas según el RGPD. Si se demuestra negligencia en la seguridad (falta de parametrización de queries, ausencia de WAF), puede enfrentar sanciones de hasta 20 millones de euros o el 4% de facturación global.

Inyección SQL - Análisis Forense de SQLi | Glosario Forense

¿Qué es la inyección SQL?

La inyección SQL (SQL injection o SQLi) es una vulnerabilidad de seguridad web que permite a un atacante interferir con las consultas que una aplicación realiza a su base de datos. Mediante la inserción de código SQL malicioso en campos de entrada —formularios de login, barras de búsqueda, parámetros de URL o cabeceras HTTP—, el atacante consigue que el servidor de base de datos ejecute instrucciones no previstas por los desarrolladores.

Según el informe OWASP Top 10 de 2021, la inyección (donde SQLi es la variante más común) ocupa la tercera posición entre los riesgos de seguridad más críticos para aplicaciones web. A pesar de ser una vulnerabilidad conocida desde finales de los años 90, sigue siendo responsable de algunas de las brechas de datos más graves a nivel mundial. El informe de Verizon Data Breach Investigations Report (DBIR) 2024 señala que las inyecciones de código, incluyendo SQLi, continúan entre los vectores de ataque más frecuentes contra aplicaciones web.

En el ámbito del peritaje informático forense, la inyección SQL requiere un análisis riguroso y multidimensional: no basta con identificar la vulnerabilidad explotada, sino que es necesario reconstruir toda la cadena de ataque, cuantificar los datos comprometidos y preservar la evidencia con garantías procesales para que sea admisible en procedimientos judiciales.

Impacto real de la inyección SQL

Un solo ataque de inyección SQL exitoso puede comprometer la totalidad de una base de datos: credenciales de usuarios, datos financieros, información personal protegida por el RGPD e incluso configuraciones internas del servidor. La gravedad depende del nivel de privilegios que tenga la cuenta de base de datos utilizada por la aplicación.

Cómo funciona la inyección SQL

Mecanismo básico del ataque

En una aplicación web vulnerable, el código del servidor construye consultas SQL concatenando directamente la entrada del usuario sin validarla ni parametrizarla. Un formulario de login típico podría generar esta consulta:

-- Consulta esperada por el desarrollador
SELECT * FROM usuarios WHERE username='admin' AND password='miClave123';

-- Lo que el atacante introduce en el campo de usuario:
-- admin'--
-- Consulta resultante:
SELECT * FROM usuarios WHERE username='admin'--' AND password='loquesea';

El doble guion (--) es un comentario en SQL, por lo que todo lo que viene después se ignora. El atacante accede como administrador sin conocer la contraseña.

Tipos de inyección SQL

Tipo	Mecanismo	Dificultad de detección	Impacto
In-band (clásica)	La respuesta de la base de datos se muestra directamente en la página	Baja - deja rastros claros en logs	Extracción directa de datos
UNION-based	Usa UNION SELECT para combinar resultados de otras tablas	Baja - queries UNION anómalas en logs	Acceso a cualquier tabla
Error-based	Provoca errores SQL que revelan estructura de la base de datos	Media - errores pueden no loguearse	Reconocimiento de estructura
Blind boolean	Infiere datos observando respuestas true/false de la aplicación	Alta - una petición por bit de información	Extracción lenta pero efectiva
Blind time-based	Usa funciones de retardo (SLEEP, WAITFOR) para inferir datos	Alta - múltiples peticiones con tiempos	Extracción muy lenta
Out-of-band	Exfiltra datos vía DNS o HTTP hacia servidor del atacante	Muy alta - datos salen por canal diferente	Bypass de firewalls
Second-order	Payload almacenado se ejecuta en otro contexto posterior	Muy alta - la inyección es diferida	Persistente y difícil de rastrear

Ejemplo detallado: UNION-based injection

-- Paso 1: Determinar número de columnas
/productos?id=1 ORDER BY 1--    (OK)
/productos?id=1 ORDER BY 2--    (OK)
/productos?id=1 ORDER BY 3--    (OK)
/productos?id=1 ORDER BY 4--    (ERROR - solo 3 columnas)

-- Paso 2: Identificar columnas visibles
/productos?id=-1 UNION SELECT 1,2,3--
-- La página muestra "2" y "3" en algún campo visible

-- Paso 3: Extraer datos del sistema
/productos?id=-1 UNION SELECT 1,version(),database()--
-- Revela: MySQL 8.0.32, base de datos "tienda_online"

-- Paso 4: Listar tablas
/productos?id=-1 UNION SELECT 1,table_name,3 FROM information_schema.tables WHERE table_schema='tienda_online'--

-- Paso 5: Extraer datos sensibles
/productos?id=-1 UNION SELECT 1,username,password FROM usuarios--

Herramientas automatizadas

Los atacantes suelen utilizar herramientas como SQLMap que automatizan todo este proceso, realizando cientos o miles de peticiones en minutos para mapear la base de datos completa. Esto deja un patrón de tráfico muy reconocible en los logs del servidor web y del WAF.

Análisis forense de un ataque SQLi

Fuentes de evidencia

La investigación forense de una inyección SQL requiere recopilar y correlacionar evidencia de múltiples fuentes:

Fuente	Ubicación típica	Información clave
Logs del servidor web	`/var/log/apache2/access.log`, `/var/log/nginx/access.log`	URLs con payloads SQLi, IPs de origen, timestamps
Logs del WAF	Varía según proveedor (ModSecurity, Cloudflare, AWS WAF)	Peticiones bloqueadas y permitidas, reglas activadas
Logs de la base de datos	MySQL: `general_log`, `slow_query_log`; PostgreSQL: `pg_log`	Queries ejecutadas, usuarios, duración
Logs de aplicación	Directorio de la aplicación (varía)	Errores, excepciones, queries con parámetros
Capturas de red	Archivos pcap de IDS/IPS o mirror de tráfico	Peticiones HTTP completas, respuestas del servidor
Logs del sistema operativo	`/var/log/syslog`, Event Viewer	Accesos a archivos, procesos, conexiones

Proceso de investigación forense

Preservación inmediata de la evidencia: Antes de cualquier análisis, crear copias forenses con hash SHA-256 de todos los logs relevantes: servidor web, WAF, base de datos y aplicación. Documentar la cadena de custodia desde el primer momento. Si la base de datos sigue activa, deshabilitar la rotación de logs y crear un snapshot.
Análisis de logs del servidor web: Buscar patrones de inyección SQL en los access logs del servidor web. Los indicadores más comunes incluyen: comillas simples en parámetros ('), cláusulas UNION SELECT, comentarios SQL (--, /**/, #), funciones de tiempo (SLEEP, WAITFOR DELAY), y palabras clave SQL en parámetros de URL (information_schema, sysobjects, LOAD_FILE).
Correlación con logs del WAF: Si existe un WAF (Web Application Firewall), sus logs revelan tanto las peticiones bloqueadas como las que pudieron pasar. Analizar las reglas activadas (CRS de OWASP, reglas personalizadas) y correlacionar timestamps con los logs del servidor web para identificar los payloads que tuvieron éxito.
Análisis de logs de la base de datos: Examinar el general_log o slow_query_log para identificar las queries realmente ejecutadas. Buscar consultas con patrones anómalos: SELECT sin cláusula WHERE sobre tablas sensibles, UNION SELECT con número de columnas inconsistente, acceso a information_schema o tablas de sistema.
Reconstrucción del timeline: Crear una línea temporal completa correlacionando las distintas fuentes. Identificar el momento exacto del primer intento, la fase de reconocimiento (pruebas de número de columnas, detección de versión), la exfiltración exitosa y la última actividad del atacante.
Cuantificación del impacto: Determinar exactamente qué tablas fueron consultadas, cuántos registros se extrajeron, si hubo modificaciones (INSERT, UPDATE, DELETE) o si el atacante logró escribir archivos en el servidor (INTO OUTFILE) o ejecutar comandos del sistema operativo (xp_cmdshell en SQL Server).
Identificación del atacante: Analizar las IPs de origen (pueden ser VPN, Tor o proxies), los User-Agent utilizados, los patrones de tiempo entre peticiones (automatizado vs manual), y cualquier otro indicador que pueda atribuir el ataque.

Patrones forenses en logs del servidor web

# Patrón típico de reconocimiento SQLMap (User-Agent delator)
192.168.1.100 - - [15/Feb/2026:03:45:12 +0100]
  "GET /productos?id=1%27%20OR%201=1-- HTTP/1.1" 200 4523
  "sqlmap/1.7.2#stable (https://sqlmap.org)"

# Inyección UNION-based (URL-encoded)
192.168.1.100 - - [15/Feb/2026:03:45:23 +0100]
  "GET /productos?id=-1%20UNION%20SELECT%201,username,password%20FROM%20usuarios-- HTTP/1.1" 200 8912

# Blind time-based (respuesta lenta = verdadero)
192.168.1.100 - - [15/Feb/2026:03:46:01 +0100]
  "GET /productos?id=1%20AND%20SLEEP(5)-- HTTP/1.1" 200 4523
  # Tiempo de respuesta: 5.003s (normal sería menos de 100ms)

# Intento de escritura de webshell
192.168.1.100 - - [15/Feb/2026:03:48:15 +0100]
  "GET /productos?id=-1%20UNION%20SELECT%201,%27%3C%3Fphp%20system(%24_GET[cmd])%3B%3F%3E%27,3%20INTO%20OUTFILE%20%27/var/www/html/shell.php%27-- HTTP/1.1" 403 287

Urgencia en la preservación

Los logs de servidores web se rotan por defecto cada semana o cuando alcanzan cierto tamaño. En servidores con mucho tráfico, un log de accesos puede sobrescribirse en días. La preservación forense inmediata es absolutamente crítica.

Clasificación OWASP y estándares

OWASP Top 10

La inyección SQL se enmarca en la categoría A03:2021 - Injection del OWASP Top 10. Esta clasificación es relevante en contextos periciales porque OWASP es el estándar de referencia internacional para seguridad de aplicaciones web, y los tribunales y aseguradoras lo reconocen como benchmark de diligencia debida.

CWE (Common Weakness Enumeration)

Código CWE	Descripción	Relevancia forense
CWE-89	Improper Neutralization of Special Elements used in an SQL Command	Clasificación principal de SQLi
CWE-564	SQL Injection: Hibernate	Variante en frameworks ORM
CWE-566	Authorization Bypass Through User-Controlled SQL	Bypass de autorización
CWE-943	Improper Neutralization of Special Elements in Data Query Logic	Variantes NoSQL

Mitigaciones según OWASP

Mitigación	Eficacia	Ejemplo
Prepared statements (parametrizadas)	Muy alta	`SELECT * FROM users WHERE id = ?`
Stored procedures	Alta	Procedimientos almacenados sin SQL dinámico
Validación de entrada (whitelist)	Media-alta	Solo permitir caracteres alfanuméricos donde corresponda
Escape de caracteres	Media	`mysql_real_escape_string()` (último recurso)
WAF (Web Application Firewall)	Media	Detección por firmas y anomalías
Principio de mínimo privilegio	Complementaria	Cuenta de BD de la app sin permisos de admin

Caso práctico: brecha de datos en e-commerce

Escenario

Una tienda online española con 45.000 clientes registrados detecta actividad anómala en su base de datos. El equipo de sistemas observa que los tiempos de respuesta de las consultas se han degradado significativamente y aparecen registros de acceso inusuales en los logs del servidor web durante la madrugada.

Investigación forense

Fase 1: Preservación

# Hash de logs antes de copiarlos
sha256sum /var/log/nginx/access.log > /evidencia/hashes_originales.txt
sha256sum /var/log/mysql/general.log >> /evidencia/hashes_originales.txt

# Copia forense
cp -a /var/log/nginx/ /evidencia/nginx_logs/
cp -a /var/log/mysql/ /evidencia/mysql_logs/

# Volcado de base de datos con estado actual
mysqldump --single-transaction --all-databases > /evidencia/db_dump_20260210.sql
sha256sum /evidencia/db_dump_20260210.sql >> /evidencia/hashes_originales.txt

Fase 2: Análisis de logs del servidor web

# 2.847 peticiones desde la misma IP en 4 horas (madrugada)
185.234.xx.xx - - [09/Feb/2026:02:12:05 +0100]
  "GET /buscar?q=1'%20AND%201=1-- HTTP/1.1" 200 15234
185.234.xx.xx - - [09/Feb/2026:02:12:06 +0100]
  "GET /buscar?q=1'%20AND%201=2-- HTTP/1.1" 200 8921
  # Diferente tamaño de respuesta = blind boolean SQLi

Fase 3: Timeline reconstruido

Hora	Actividad	Evidencia
02:12	Primeras pruebas de inyección (boolean blind)	access.log: 200 respuestas
02:18	Atacante identifica 5 columnas con ORDER BY	access.log: secuencia ORDER BY
02:20	Primera extracción con UNION SELECT	general_log: query anómala
02:25	Enumeración de tablas vía information_schema	general_log: 23 queries
02:31	Extracción tabla `clientes` (45.000 registros)	general_log: SELECT completo
02:48	Extracción tabla `pedidos` (127.000 registros)	general_log: SELECT completo
03:15	Extracción tabla `pagos` (datos de tarjeta parciales)	general_log: acceso a datos financieros
03:52	Intento fallido de INTO OUTFILE (permisos denegados)	general_log: error 1045
04:01	Última actividad registrada	access.log: última petición

Fase 4: Cuantificación del impacto

Tabla comprometida	Registros	Datos expuestos	Criticidad RGPD
`clientes`	45.000	Nombre, email, teléfono, dirección	Alta (datos personales)
`pedidos`	127.000	Historial de compras, importes	Media (datos comerciales)
`pagos`	89.000	Últimos 4 dígitos tarjeta, titular, fecha expiración	Crítica (datos financieros)
`usuarios_admin`	12	Usernames y hashes de contraseñas (bcrypt)	Alta (credenciales)

Conclusiones periciales

El informe pericial documentó:

La vulnerabilidad concreta explotada (falta de parametrización en el parámetro q del buscador)
La ausencia de WAF y de validación de entrada
El alcance exacto de la brecha: 45.000 datos personales comprometidos
La necesidad de notificación a la AEPD dentro de las 72 horas siguientes
Recomendaciones de remediación inmediata

Relevancia para la empresa

Este tipo de informe pericial es necesario tanto para cumplir con la obligación de notificación a la AEPD según el RGPD, como para la reclamación al ciberseguro. Documentar con precisión forense el vector de ataque, el alcance y la timeline es esencial para ambos procesos.

Marco legal en España

Delitos aplicables al atacante

Delito	Artículo Código Penal	Pena	Aplicación a SQLi
Acceso ilícito a sistemas	Art. 197 bis	6 meses - 2 años prisión	Acceso no autorizado a la base de datos
Interceptación de datos	Art. 197.1	1 - 4 años prisión	Captura de datos personales
Daños informáticos	Art. 264	6 meses - 3 años prisión	Si se modifican o destruyen datos
Daños graves a sistemas	Art. 264 bis	3 - 5 años prisión	Si se compromete infraestructura crítica
Revelación de secretos	Art. 197.2	2 - 5 años prisión	Acceso a datos especialmente protegidos

Responsabilidad de la empresa víctima

Según el RGPD y la LOPDGDD, la empresa que sufre una inyección SQL puede tener responsabilidad si no implementó medidas de seguridad adecuadas:

Obligación	Normativa	Consecuencia de incumplimiento
Medidas técnicas adecuadas	Art. 32 RGPD	Sanciones AEPD
Notificación brecha 72h	Art. 33 RGPD	Sanción adicional por ocultación
Comunicación a afectados	Art. 34 RGPD	Sanción + daño reputacional
Evaluación de impacto previa	Art. 35 RGPD	Agravante en procedimiento sancionador
Registro de actividades	Art. 30 RGPD	Dificultad para demostrar diligencia

Estándares de referencia en peritaje

ISO 27001: Sistema de gestión de seguridad de la información
ISO 27037: Directrices para identificación, recopilación, adquisición y preservación de evidencia digital
OWASP ASVS: Application Security Verification Standard (nivel de seguridad exigible)
ENS (Esquema Nacional de Seguridad): Obligatorio para administraciones públicas españolas

Herramientas forenses para análisis de SQLi

Detección y análisis de ataques

Herramienta	Función	Licencia
ModSecurity	WAF open source, logs detallados de intentos SQLi	Open source
SQLMap	Replicar el ataque para documentar alcance (en entorno controlado)	Open source
Burp Suite	Análisis de peticiones HTTP con payloads SQLi	Comercial/Community
Splunk / ELK Stack	Correlación de logs de múltiples fuentes	Comercial/Open source
GoAccess	Análisis rápido de access logs del servidor web	Open source

Análisis de bases de datos

Herramienta	Función	Base de datos
mysqlbinlog	Reconstruir queries desde binlog	MySQL/MariaDB
pg_waldump	Analizar WAL para reconstruir transacciones	PostgreSQL
SQL Server Profiler	Captura y análisis de actividad	SQL Server
pt-query-digest	Análisis estadístico de queries (Percona)	MySQL

Preservación de evidencia

Herramienta	Función
FTK Imager	Imagen forense del servidor completo
sha256sum / hashdeep	Verificación de integridad de logs
Autopsy	Análisis forense del sistema de archivos
Wireshark	Captura de tráfico de red para reconstruir peticiones

Prevención y endurecimiento

Medidas técnicas prioritarias

Usar consultas parametrizadas (prepared statements): Es la defensa más efectiva contra SQLi. En lugar de concatenar la entrada del usuario en la query, se utilizan placeholders que el motor de base de datos trata como datos, nunca como código SQL.
Implementar un WAF con reglas OWASP CRS: Un Web Application Firewall con el Core Rule Set de OWASP detecta y bloquea la mayoría de patrones de inyección SQL conocidos. No es una solución completa por sí sola, pero añade una capa de protección significativa.
Aplicar el principio de mínimo privilegio en la base de datos: La cuenta que utiliza la aplicación web para conectarse a la base de datos no debe tener permisos de administrador. Limitar a SELECT, INSERT, UPDATE y DELETE sobre las tablas estrictamente necesarias.
Validar y sanear toda entrada del usuario: Implementar validación de tipo whitelist (solo permitir los caracteres y formatos esperados) en lugar de intentar bloquear caracteres peligrosos (blacklist).
Monitorizar y conservar logs: Configurar logging detallado tanto en el servidor web como en la base de datos, con retenciones de al menos 90 días, para facilitar la investigación forense en caso de incidente.

Relación con otros conceptos

La inyección SQL se conecta directamente con varias disciplinas del peritaje informático forense:

Query SQL forense: El análisis de las queries ejecutadas en la base de datos es la técnica forense central para reconstruir un ataque SQLi, determinando exactamente qué datos fueron consultados o modificados.
SQLite forense: Muchas aplicaciones móviles y de escritorio utilizan SQLite como base de datos local, y son igualmente vulnerables a inyecciones SQL cuando no parametrizan sus consultas.
Logs de sistema: Los logs del servidor web, la base de datos y el WAF son las fuentes de evidencia primarias en la investigación forense de un ataque de inyección SQL.
Evidencia digital: Los logs, capturas de red y volcados de base de datos obtenidos durante la investigación de un SQLi deben preservarse siguiendo protocolos de evidencia digital para garantizar su admisibilidad judicial.
Cadena de custodia: Cada pieza de evidencia obtenida del análisis del ataque SQLi debe documentarse en la cadena de custodia con hashes de integridad y registro de accesos.

¿Has sufrido un ataque de inyección SQL y necesitas documentar el alcance? Contacta con Digital Perito para un análisis forense completo con validez judicial.

Última actualización: 10 de febrero de 2026 Categoría: Seguridad Código: SQL-001