SQL Injection

Resumen

SQL Injection —SQLi— ocurre cuando una aplicación construye queries SQL concatenando strings con datos del usuario sin sanitizar. Si el input es ' OR 1=1 --, la query se transforma en algo que el atacante controla. En el peor caso, puede leer todas las tablas, modificar datos o ejecutar comandos en el sistema operativo.

La defensa es simple y universal: nunca concatenar datos de usuario en queries SQL. Usar siempre consultas parametrizadas —prepared statements— o un ORM que las use internamente. Si por algún motivo necesitás construir queries dinámicas, validar y escapar rigurosamente.

Alcance y supuestos

Cubre SQL Injection, sus vectores y prevención. Asume familiaridad con SQL.

Modelo mental

Un formulario de aeropuerto donde escribís tu nombre y te imprimen una credencial. Si escribís "Juan OR VIP=1", esperás que la máquina solo imprima tu nombre. Si la máquina evalúa tu input como código, te imprime una credencial VIP. SQLi es lograr que la base de datos ejecute tu input como código.

Uso práctico

• ❌ Nunca: db.query("SELECT * FROM users WHERE name = '" + userName + "'")
• ✅ Siempre: db.query("SELECT * FROM users WHERE name = ?", [userName])

Ejemplo trabajado: SQLi clásico

SELECT * FROM users WHERE name = 'admin' OR '1'='1' AND password = 'cualquiera'. El atacante bypasea el login. Con prepared statements: SELECT * FROM users WHERE name = ? AND password = ?, el input es tratado como dato, nunca como código.

Evidencia

• SQL Injection está en el puesto #3 del OWASP Top 10 2021. Es prevenible al 100% con prepared statements.