La inyección SQL (SQLi) ocurre cuando una aplicación construye una consulta a su base de datos mezclando datos del usuario sin separarlos del comando. El atacante introduce texto que la base interpreta como instrucción en lugar de dato. Es parte de la categoría Injection del OWASP Top 10.
Por qué sucede
La aplicación arma la consulta concatenando la entrada del usuario:
-- Inseguro: el input se pega directo en la consulta
SELECT * FROM usuarios WHERE user = '" + entrada + "';
Si el usuario escribe ' OR '1'='1, la consulta resultante siempre es verdadera y devuelve filas que no debería.
Qué puede lograr un atacante
- Saltar la autenticación (entrar sin contraseña válida).
- Leer datos de otros usuarios o de toda la base (correos, hashes, tarjetas).
- Modificar o borrar registros.
- En ciertos motores, leer archivos o ejecutar comandos en el servidor.
Tipos comunes
| Tipo | Cómo se ve el resultado |
|---|---|
| In-band / UNION | Los datos extraídos vuelven en la propia respuesta |
| Basada en errores | El motor revela información en mensajes de error |
| A ciegas (blind) | No hay salida visible; se infiere por respuestas verdadero/falso o por tiempos de demora |
La defensa (una y definitiva)
Consultas parametrizadas (prepared statements). Los datos del usuario viajan por un canal separado del comando, así nunca se interpretan como instrucción.
-- Seguro: el valor viaja como parámetro, no como código
SELECT * FROM usuarios WHERE user = ?;
Complementos: usar un ORM que parametrice por defecto, aplicar mínimo privilegio en la cuenta de base de datos y validar la entrada. Nunca confiar solo en escapar comillas a mano.
La inyección SQL ataca la base de datos del servidor. La siguiente falla cambia de víctima: ataca el navegador de otros usuarios. Es el Cross-Site Scripting (XSS), el próximo tema.