Una SQL injection permite a un atacante ejecutar consultas arbitrarias contra la base de datos de una web manipulando campos de entrada que el desarrollador dejó sin filtrar. Lleva casi tres décadas en el top del OWASP Top 10 y sigue apareciendo en brechas de empresas que deberían saberlo mejor. La inyección SQL no requiere herramientas sofisticadas: a veces basta con un apóstrofe bien colocado en un formulario de login. Este repaso cubre cómo funciona un ataque SQL, qué variantes de SQLi existen, casos reales que acabaron en tribunales y qué defensas funcionan contra esta vulnerabilidad SQL que sigue presente tres décadas después.
Qué es exactamente una SQL injection
El ataque explota aplicaciones que construyen consultas SQL concatenando input del usuario sin sanitizar. El atacante introduce fragmentos de código SQL en un campo que se espera que contenga, por ejemplo, un nombre de usuario. El servidor ejecuta la consulta completa como si fuera legítima.
El ejemplo clásico es el login. Una query mal escrita tipo SELECT * FROM users WHERE user='$input' AND pass='$input' se convierte en regalo cuando el atacante escribe ' OR '1'='1 en el campo usuario. La condición siempre es verdadera. Dentro.
Andrés Riancho, investigador argentino creador de w3af, lleva años señalando que buena parte del problema es cultural: muchos desarrolladores siguen aprendiendo SQL con ejemplos inseguros heredados de tutoriales antiguos.
Tipos de SQLi que vas a encontrarte
No todas las inyecciones son iguales. La clasificación habitual divide el ataque SQL en tres familias principales según cómo el atacante recupera la información.
- In-band SQLi: el atacante usa el mismo canal para inyectar y recibir resultados. Incluye las variantes error-based (fuerza errores que revelan datos) y UNION-based (combina consultas para extraer columnas extra).
- Blind SQLi: la aplicación no devuelve datos directamente. El atacante deduce información por el comportamiento de la respuesta. Las subvariantes boolean-based y time-based (usando SLEEP() o WAITFOR DELAY) permiten exfiltrar datos bit a bit.
- Out-of-band SQLi: usa canales alternativos como peticiones DNS o HTTP desde el propio servidor de base de datos. Útil cuando el resto está bloqueado.
Las blind son especialmente molestas porque parecen webs totalmente normales mientras la base de datos se vacía en segundo plano. Un script automatizado con sqlmap puede tardar horas, pero funciona sin dejar señales visibles para el usuario final.
Casos reales que costaron millones
La vulnerabilidad SQL tiene una lista de víctimas tan larga que cuesta resumirla. Estos son los episodios más didácticos.
TalkTalk (2015): la operadora británica perdió datos de aproximadamente 157.000 clientes por una SQLi en una sección heredada de su web. La multa del ICO (Information Commissioner's Office) fue de 400.000 libras. Dos adolescentes fueron condenados por el ataque. La empresa aceptó públicamente que la vulnerabilidad era conocida internamente pero no se había parcheado.
Heartland Payment Systems (2008): el procesador de pagos perdió datos de aproximadamente 134 millones de tarjetas. Entrada inicial: SQL injection. El coste total superó los 140 millones de dólares entre multas, demandas y remediación. El atacante principal, Albert Gonzalez, cumple 20 años de prisión.
Sony Pictures (2011): el grupo LulzSec publicó aproximadamente un millón de cuentas tras una inyección SQL básica. Las contraseñas estaban en texto plano. Sony tardó años en recuperar la confianza del sector.
Equifax (2017): aunque el vector inicial fue una vulnerabilidad en Apache Struts, investigaciones posteriores documentaron SQLi secundarias en el movimiento lateral. Datos de aproximadamente 147 millones de personas expuestos. Acuerdo de hasta 700 millones de dólares con la FTC, incluyendo el fondo de compensación a consumidores.
Patrón común: aplicaciones viejas, mantenimiento descuidado y nadie mirando los logs. No es casualidad que muchos ataques contra infraestructuras críticas empiecen por una puerta abierta de hace una década.
Cómo se defiende el código bien escrito
La solución técnica está bien documentada y es barata de implementar. El problema suele ser la deuda técnica y la inercia. Estas son las defensas que funcionan en proyectos reales.
- Consultas parametrizadas (prepared statements): la base. Separan la query de los datos. Disponibles en PDO (PHP), PreparedStatement (Java), psycopg2 (Python), parámetros con signo de interrogación en casi cualquier driver moderno.
- ORMs bien configurados: Doctrine, Hibernate, Eloquent, SQLAlchemy, Prisma. Usados correctamente eliminan la mayoría del riesgo. Cuidado con los métodos raw(): vuelven a abrir la puerta.
- Principio de mínimo privilegio: el usuario de BD de la app no necesita DROP TABLE. Separa cuentas para lectura, escritura y administración.
- WAF con reglas OWASP CRS: ModSecurity, Cloudflare, AWS WAF. Detectan patrones conocidos de SQLi. No son infalibles, pero suben el coste del atacante.
- Validación de entrada por lista blanca: si el campo espera un número, rechaza todo lo que no sea dígito. Nunca blacklist: el atacante encuentra la variante que falta.
- Auditoría automatizada: integra sqlmap, Burp Suite o OWASP ZAP en el pipeline CI/CD. Detectar en preproducción es infinitamente más barato.
Si gestionas una tienda online o cualquier web con formularios, esta checklist debería estar cumplida antes de abrir al público. El coste de una brecha en un ecommerce medio supera fácilmente lo que cuesta un pentest anual.
Herramientas que usan atacantes y defensores
Conocer el arsenal ayuda a entender el riesgo real. Todas las herramientas listadas son legales para usar contra sistemas propios o con autorización explícita.
| Herramienta | Uso | Licencia |
|---|---|---|
| sqlmap | Automatiza detección y explotación de SQLi. El estándar de facto. | GPLv2 |
| Burp Suite | Proxy de pentesting web. Escáner incluido en la versión Pro. | Comunidad / comercial |
| OWASP ZAP | Alternativa libre a Burp. Scanner activo con reglas SQLi. | Apache 2.0 |
| NoSQLMap | Variante para MongoDB, CouchDB y otras NoSQL inyectables. | GPLv3 |
| Have I Been Pwned | Comprueba si tus datos aparecen en brechas públicas, muchas originadas por SQLi. | Servicio público |
Para quien desarrolla o mantiene aplicaciones web, los equipos especializados en desarrollo web profesional y en WordPress seguro aplican estas prácticas por defecto. Que un plugin gratuito de formularios no lo haga no es excusa: la responsabilidad legal según el RGPD y la LOPDGDD recae en el responsable del tratamiento, no en el código de terceros.
Marco legal: qué dice el BOE y la UE
Una brecha por SQLi no es solo un problema técnico. Es un incidente notificable con plazos legales estrictos.
El Reglamento (UE) 2016/679 (RGPD), artículo 33, obliga a notificar a la autoridad de control en un plazo máximo de 72 horas tras conocer la brecha. En España la AEPD recibe estas notificaciones. La LOPDGDD (Ley Orgánica 3/2018) desarrolla las obligaciones nacionales.
La Directiva NIS2 endurece los requisitos para operadores esenciales e importantes. Las sanciones pueden alcanzar el 2% de la facturación global anual.
Para ampliar sobre la economía detrás de las filtraciones, merece la pena leer cómo funcionan los data brokers: buena parte de lo que se extrae vía SQLi acaba en esos catálogos.
Preguntas frecuentes
¿Puede una SQL injection afectar a una web hecha en WordPress?
Sí. El núcleo de WordPress está razonablemente protegido, pero la mayoría de SQLi documentadas en el ecosistema vienen de plugins y temas de terceros mal mantenidos. Wordfence publica boletines periódicos con CVEs de este tipo. Mantener el core y todos los plugins actualizados es la defensa básica.
¿Qué diferencia hay entre SQL injection y XSS?
La SQLi ataca la base de datos del servidor ejecutando consultas no autorizadas. El XSS (Cross-Site Scripting) inyecta JavaScript que se ejecuta en el navegador de otros usuarios. Ambas son vulnerabilidades de inyección según OWASP, pero atacan capas distintas y requieren mitigaciones diferentes.
¿Es legal usar sqlmap?
La herramienta es legal. Usarla contra sistemas sin autorización escrita del propietario constituye delito en España según el artículo 197 bis del Código Penal. Solo debe emplearse en infraestructura propia, entornos de laboratorio o bajo contrato de pentesting con alcance definido.
¿Las bases de datos NoSQL son inmunes a las inyecciones?
No. MongoDB, Redis y similares tienen sus propias variantes de inyección. La sintaxis cambia, el principio es idéntico: input sin sanitizar que acaba interpretado como comando. NoSQLMap automatiza parte del proceso. La solución también es la misma: queries parametrizadas y validación estricta.
¿Cómo sé si mi web ya ha sido víctima de una SQLi?
Revisa logs del servidor buscando patrones como UNION SELECT, SLEEP(, comillas simples inusuales o errores SQL expuestos. Comprueba en Have I Been Pwned si tu dominio aparece en brechas. Un pentest profesional confirma el estado real. La ausencia de alertas no implica ausencia de brecha: las blind SQLi no dejan rastro visible.
El siguiente paso
Ejecuta hoy mismo un escaneo con OWASP ZAP contra tu propia web en modo pasivo (no requiere autorización para pasivo en tu propio dominio). Tarda menos de veinte minutos y te da una foto realista de las vulnerabilidades de inyección expuestas. Si aparece cualquier hallazgo de severidad media o superior, asume que ya hay alguien más mirando.
