Prevencion de Inyeccion SQL

El Problema

La inyeccion SQL sigue siendo la clase de vulnerabilidad mas peligrosa y explotada despues de decadas de concientizacion. Los desarrolladores todavia concatenan input de usuario en strings de queries, usan nombres de tablas dinamicos sin whitelist, o confian en abstracciones de ORM que silenciosamente caen a raw queries. Un solo endpoint inyectable puede exponer toda tu base de datos — registros de clientes, datos de pago, credenciales de admin — en minutos.

El Prompt

Eres un especialista en seguridad de bases de datos. Analiza el siguiente codigo en busca de vulnerabilidades de inyeccion SQL, incluyendo inyeccion de segundo orden, inyeccion ciega y patrones de bypass de ORM.

LENGUAJE/ORM: [ej. Node.js/Knex, Python/SQLAlchemy, PHP/PDO, Java/Hibernate]
BASE DE DATOS: [ej. PostgreSQL, MySQL, SQLite, MSSQL]

CODIGO:
[pega codigo de interaccion con base de datos — queries, modelos, repositorios, stored procedures]

Para cada hallazgo:
1. **Tipo de Inyeccion**: Clasica / Ciega / Segundo Orden / Basada en UNION / Basada en Tiempo
2. **Vector de Ataque**: Payload exacto que usaria un atacante
3. **Impacto**: A que datos se puede acceder o modificar
4. **Codigo Vulnerable**: Linea exacta con la falla
5. **Reemplazo Seguro**: Query parametrizada o equivalente ORM

Tambien verificar:
- Nombres de tabla/columna dinamicos desde input de usuario
- Clausulas LIKE sin escape de wildcards
- ORDER BY con nombres de columna controlados por el usuario
- Metodos de raw query en codigo ORM (ej. .raw(), execute())
- Stored procedures con SQL dinamico (EXEC, sp_executesql)
- Inyeccion JSON/NoSQL en queries hibridas

Proporcionar un checklist de codigo seguro especifico para [LENGUAJE/ORM] al final.

Ejemplo de Salida

## Auditoria de Inyeccion SQL: 4 vulnerabilidades encontradas

### CRITICA: Inyeccion SQL Clasica
Linea 34: `db.query(\`SELECT * FROM users WHERE email = '\${email}'\`)`
Payload: `' OR '1'='1' --` retorna todos los usuarios.
Solucion: `db.query('SELECT * FROM users WHERE email = $1', [email])`

### ALTA: Inyeccion ORDER BY
Linea 67: `query += \` ORDER BY \${req.query.sort}\``
Payload: `sort=1;DROP TABLE users--` ejecuta SQL arbitrario.
Solucion: Whitelist de columnas permitidas: `const allowed = ['name','date']; const col = allowed.includes(sort) ? sort : 'name'`

Cuando Usar

Ejecutar en cada capa de interaccion con base de datos antes del deployment, especialmente al agregar nuevos endpoints de API o funcionalidad de busqueda. Critico al migrar entre ORMs, actualizar drivers de base de datos o agregar busqueda de texto completo. Usarlo siempre que un desarrollador escriba un raw SQL query en lugar de usar el query builder del ORM.

Tips Pro

• Prueba con payloads reales — pide a la IA que genere payloads compatibles con SQLMap para cada hallazgo y asi entender la ruta real de explotacion.
• Revisa el escape hatch del ORM — cada ORM tiene metodos de raw query (.raw(), execute(), $queryRaw) que evitan las protecciones integradas. Busca estos primero.
• Incluye stored procedures — SQL del lado del servidor con concatenacion dinamica es igual de vulnerable que el codigo de la aplicacion.
• Atencion a la inyeccion de segundo orden — datos guardados de forma segura pero usados de forma insegura despues (ej. nombre de usuario almacenado correctamente pero inyectado al usarse en un query de reporte).