La inyección SQL ocurre cuando datos recibidos por una aplicación pueden alterar una consulta a la base de datos. La corrección principal está en cómo se construyen y ejecutan las consultas.
La defensa que debe revisar desarrollo
OWASP recomienda consultas parametrizadas como una defensa central frente a inyección SQL. Los valores se tratan como datos, en lugar de concatenarlos como instrucciones. Prevención de inyección SQL.
No basta con “limpiar caracteres” de forma general. La validación depende del dato esperado, y ciertos elementos de una consulta requieren decisiones de diseño adicionales.
Ejemplo mínimo: datos separados de la consulta
Este fragmento de Python utiliza SQLite en memoria y datos ficticios. La consulta conserva su estructura; el nombre se entrega como parámetro.
import sqlite3
db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE clientes (nombre TEXT)")
db.execute("INSERT INTO clientes VALUES (?)", ("O'Connor",))
nombre = "O'Connor"
fila = db.execute(
"SELECT nombre FROM clientes WHERE nombre = ?", (nombre,)
).fetchone()
assert fila == ("O'Connor",)
db.close()
El apóstrofo es parte del dato y no necesita convertirse en una concatenación SQL. La interfaz exacta depende del controlador; en Python, la documentación de sqlite3 explica los marcadores de parámetros. Los nombres de columnas y el ordenamiento dinámico requieren decisiones adicionales, como seleccionar opciones permitidas; no se tratan igual que un valor parametrizado.
Esta comprobación demuestra el comportamiento del ejemplo, no la seguridad completa de una aplicación. Revisa también autorización, permisos y otros puntos donde se construyen consultas.
Qué pedir en una revisión
- Localizar consultas construidas a partir de entradas externas.
- Revisar parametrización y bibliotecas utilizadas.
- Comprobar permisos de la cuenta de aplicación.
- Verificar errores y registros sin exponer información sensible.
- Ejecutar pruebas autorizadas sobre los puntos corregidos.
El papel de otras capas
Un WAF puede ayudar a filtrar determinados patrones, pero no sustituye corregir el código. Limitar la exposición de la base de datos y sus permisos reduce otros riesgos y puede contener el impacto de un fallo.
Cómo aceptar una corrección
Pide evidencia de la consulta corregida y de que la operación legítima sigue funcionando. Revisa también rutas similares: corregir un formulario no demuestra que todas las consultas estén protegidas.
Si administras el negocio, no necesitas ejecutar pruebas ofensivas por tu cuenta. Identifica qué aplicación maneja la información, quién mantiene su código y qué evidencia entregará para dar seguimiento a la corrección.
Para profundizar en las tareas relacionadas: Qué comprueban las pruebas unitarias; Qué hace un WAF para proteger una aplicación.
¿Necesitas revisar una aplicación?
Comparte qué aplicación utilizas, quién mantiene su código y qué comportamiento necesitas corregir. Primero hay que delimitar el trabajo y la evidencia disponible.
Conocer desarrollo de software
