Ataques y defensa

SQL Injection

Actualizada el Feb 4, 2026

#injection#web

Vulnerabilidad donde entradas controladas por el usuario se incorporan a consultas SQL de forma insegura, permitiendo leer, modificar o destruir datos o incluso ejecutar acciones…

Resumen (2–4 líneas)

Vulnerabilidad donde entradas controladas por el usuario se incorporan a consultas SQL de forma insegura, permitiendo leer, modificar o destruir datos o incluso ejecutar acciones administrativas en la base de datos.

Cómo funciona

Una aplicación construye una consulta SQL concatenando strings con input no confiable (query/body/cookies/headers). El atacante introduce caracteres y fragmentos SQL que alteran la lógica de la consulta.

Conceptos básicos de bases de datos (del RAW)

Base de datos: conjunto de datos organizado, controlado por un SGBD.
Relacionales: tablas con filas/columnas y claves (MySQL, SQL Server, PostgreSQL, SQLite).
No relacionales (NoSQL): modelos flexibles sin tablas fijas (MongoDB, Cassandra, ElasticSearch).
Tabla: columnas (campos) + filas (registros). Las columnas suelen tener tipos y claves únicas.

Pre-requisitos

Input controlado por usuario llega a una consulta.
Falta de parametrización/ORM seguro o validación insuficiente.
Permisos de BD excesivos amplifican impacto.

Variantes comunes

In-band: error-based (errores visibles), union-based.
Blind: boolean-based, time-based (inferencia por tiempos).
Second-order: payload almacenado y ejecutado después.
NoSQL injection (distinto): aplica a motores no SQL; no confundir.
Out-of-band (OOB): exfiltración por un canal distinto (p.ej., DNS/HTTP) cuando está habilitado.

Técnicas avanzadas (del RAW)

SQLi de segundo orden

La carga maliciosa se almacena y se ejecuta después en otra consulta. Es sigilosa porque puede no generar errores en el momento de inserción.

Punto crítico: validar/parametrizar cuando se reutilizan datos almacenados.
real_escape_string() no sustituye sentencias preparadas.

Evasión de filtros

Cuando hay filtros por palabras clave o caracteres:

Codificación: URL (%27), hexadecimal (0x...), Unicode (\uXXXX).
Sin comillas: contexto numérico, CONCAT()/CHAR() para construir strings.
Sin espacios: comentarios (/**/), %09, %0A, %0D.
La evasión es trial & error; no hay bypass universal.

SQLi fuera de banda (OOB)

Usa canal alterno (HTTP/DNS/SMB) cuando el canal principal no devuelve datos.

MySQL/MariaDB: SELECT ... INTO OUTFILE, load_file.
MSSQL: xp_cmdshell, bcp, OPENROWSET/BULK INSERT.
Oracle: UTL_HTTP, UTL_FILE. Nota: secure_file_priv puede limitar escritura de archivos en MySQL.

Otros vectores avanzados

Headers HTTP (User-Agent/Referer/X-Forwarded-For) si se insertan en SQL sin sanitizar.
Procedimientos almacenados con SQL dinámico vulnerable.
XML/JSON: datos parseados y concatenados en consultas.

Impacto

Divulgación de datos sensibles (PII, credenciales).
Alteración/borrado de datos (integridad).
Escalada de privilegios si hay funciones peligrosas/permisos.
Denegación de servicio por consultas costosas.

Indicadores (IoCs / señales)

Errores SQL expuestos (stack traces).
Parámetros con comillas, comentarios (--, /* */) u operadores inusuales.
Respuestas distintas ante cambios mínimos en parámetros.
Aumento de latencia correlacionado con requests concretos.

Mitigación / Controles

Mitigación principal: parametrización (prepared statements).

Parametrización en todas las queries (incluyendo LIMIT, ORDER BY con allowlist).
ORMs bien usados (evitar “raw queries” con concatenación).
Validación por allowlist para campos de ordenamiento/filtros.
Mínimo privilegio en la BD (cuentas separadas: lectura/escritura/admin).
Manejo de errores: no exponer mensajes SQL al cliente.
WAF como control complementario (no sustituye parametrización).
Escapar input es un complemento, no sustituto de parametrización.
Auditorías y revisiones de código periódicas.
Procedimientos almacenados parametrizados (evitar SQL dinámico concatenado).

Detección (SIEM/EDR/logs)

Logs de aplicación: parámetros, rutas y latencias (con sanitización/PII minimizada).
Logs de base de datos: consultas anómalas, picos de errores, consultas largas.
Detección de patrones: ' OR, UNION SELECT, comentarios, timeouts repetidos.
Alertas por volumen: mismo endpoint con alta tasa de fallos/latencia.

Consultas SQL básicas (del RAW)

SELECT, INSERT, UPDATE, DELETE y UNION son los bloques comunes para entender SQLi:

SELECT: recuperar filas/columnas con WHERE, LIMIT, LIKE.
UNION: combinar resultados (requiere mismo número y tipo de columnas).
INSERT/UPDATE/DELETE: modificar datos; su abuso implica impacto directo en integridad.

Ejemplo de SQLi en banda (del RAW)

Patrón típico en blogs:

1
SELECT * FROM blog WHERE id=1 AND private=0 LIMIT 1;

Si el input id no se valida, id=2;-- elimina la parte private=0 y expone contenido.

Ejemplos / Payloads (solo educativos)

1
# Señales típicas (no usar fuera de laboratorio/permiso)
2
'           # prueba de ruptura de string
3
' OR '1'='1 # prueba lógica booleana
4
--          # comentario en algunos dialectos

En práctica profesional, se valida con evidencia reproducible (request/response) y se reporta con impacto realista y mitigación.

Automatización

Herramientas comunes para detección/explotación:

SQLMap (multi-DB, muy completo).
SQLNinja (MSSQL).
jSQL Injection (Java).
BBQSQL (blind SQLi). Usar siempre con autorización y validar manualmente resultados.

Ejemplo de reconocimiento previo (lab)

Identificar DB/OS ayuda a elegir técnicas (p. ej., MSSQL vs MySQL):

nmap -A -T4 -p 3306,3389,445,139,135 MACHINE_IP

Diagrama

sequenceDiagram
participant U as Usuario
participant A as App
participant D as DB
U->>A: Input (parámetro)
alt Query insegura
A->>D: SQL concatenado + input
D-->>A: Datos alterados/expuestos
else Query segura
A->>D: Prepared statement (parametrizado)
D-->>A: Resultado esperado
end

Integración con otras notas

Relacionado: Injection (OWASP Top 10 2025 - A05).
Herramientas: Burp Suite, Burp Suite Repeater, Burp Suite Intruder.
Checklist: Web App Testing Checklist (OWASP-inspired).
Ver tambien: NoSQL Injection, ORM Injection.