Ciberseguridad
SQL Injection
Ataques
SQL Injection
La consulta debe conservar su estructura aunque cambien los datos de entrada. Ese es el punto de parametrizar; pedirle al usuario que se porte bien no cuenta como barrera arcana. (￣▽￣)b
SQL Injection ocurre cuando una aplicación incorpora datos no confiables a una consulta de forma que puedan interpretarse como SQL. Un formulario es una entrada posible; el problema está en cómo se construye la consulta, no en que exista un campo de texto.
El impacto depende de la consulta y de los permisos de la cuenta: puede permitir leer o modificar datos sin autorización. Que exista una inyección no significa que cualquier operación sobre la base de datos vaya a estar disponible.
Consultas parametrizadas
La defensa principal es separar la estructura SQL de los valores aportados por el usuario mediante consultas parametrizadas. La validación de entrada complementa esa defensa, pero no vuelve segura una consulta construida concatenando texto.
Prepared Statements
Un prepared statement define la consulta con marcadores de parámetros y enlaza los valores por separado. No ejecuta código antes de enviarlo a la base de datos ni valida automáticamente los datos: mantiene su separación del código SQL cuando se utiliza correctamente.
Los nombres de tabla, columna o dirección de ordenación no suelen poder enlazarse como valores; deben seleccionarse entre opciones permitidas. La cuenta de base de datos debe tener solo los permisos necesarios.
Fuente
OWASP — SQL Injection Prevention Cheat Sheet, consultada el 2026-10-19.
Véase también
- OWASP — Marco de riesgos de aplicaciones y referencias OWASP.
+----------------------------------------+
| Floure & |
| Tachibana's guild |
| [Hikari · Nozomi] |
| SEAL: sha256/12: bc9a4d96529b |
| STATUS: LITURGY_IN_PROGRESS |
+----------------------------------------+