💉 SQL Injection: Blindando tus consultas en producción

A fecha de hoy, la inyección SQL sigue siendo un vector crítico que, a pesar de ser conocido, continúa comprometiendo infraestructuras por errores básicos de manejo de datos. El problema raíz es confiar en el input del usuario y concatenarlo directamente en la query.

El error (Vulnerable):

# Nunca hagas esto

query = f"SELECT * FROM users WHERE username = '{username}'"
db.execute(query)

Si el usuario introduce: ‘ OR ‘1’=’1, la query se convierte en:

SELECT * FROM users WHERE username = '' OR '1'='1'

Al hacer esto, permites que el atacante altere la lógica de la consulta para saltar autenticaciones o extraer toda la tabla de usuarios.

La solución (Segura):

Usa siempre consultas parametrizadas (Prepared Statements). Esto separa estrictamente el código SQL de los datos enviados por el usuario.

Ejemplo seguro en Python/PostgreSQL

db.execute("SELECT * FROM users WHERE username = %s", (username,))

En este escenario, el motor de la base de datos trata el input como un simple literal, impidiendo que el motor SQL ejecute comandos maliciosos.

Checklist de mitigación:

Prepared Statements: Obligatorios en cualquier interacción con la BD.

ORM nativo: frameworks como Prisma, SQLAlchemy o Eloquent suelen parametrizar por defecto.

Principio de menor privilegio: La cuenta que utiliza la aplicación no debe tener permisos de superusuario ni acceso a tablas que no le corresponden.

Validación de tipos: Si esperas un ID, asegúrate de que el input sea un integer antes de procesarlo.

¿Cuál es la técnica o herramienta que utilizas hoy en día para automatizar la detección de SQLi en tus pipelines de CI/CD?