Este ejemplo aislado es invulnerable a la inyección.
Pero debe darse cuenta de que la protección contra la inyección de sql no es solo un reemplazo de carácter . Y las circunstancias pueden diferir de las que usted da por sentadas en este momento. Por lo tanto, su código se volvería vulnerable a largo plazo, debido a inconvenientes esenciales de este método :
- el reemplazo de personaje es solo una parte del formato requerido
- este reemplazo en particular se puede aplicar solo a cadenas, dejando otras partes absolutamente desprotegidas.
- tal reemplazo es externo a la ejecución de una consulta, lo que significa que es propenso a un error humano de cualquier tipo.
- tal reemplazo es una medida esencialmente separable, lo que significa que puede alejarse demasiado de la ejecución de la consulta real y eventualmente olvidarse.
- este tipo de escape es propenso a ataque de codificación , lo que hace que la solución sea demasiado limitada en uso.
No hay nada de malo en el reemplazo de caracteres per se, pero solo si se usa como parte del formateo completo; aplicado a la parte de consulta derecha; y realizado por un controlador de base de datos, no por un programador; justo antes de la ejecución.
Las funciones que propusiste en los comentarios son un buen paso, pero aún insuficientes, ya que están sujetas a los inconvenientes enumerados anteriormente, lo que las hace propensas a todo tipo de errores humanos.
Y la inyección de SQL no es el único problema con este enfoque, también es una falla de usabilidad, ya que esta función estropearía sus datos, si se usa como una encarnación de los últimos comillas mágicas , o inflar su código, si se usa para formatear cada variable directamente en el código de la aplicación.
Estas funciones se pueden usar solo para procesar un marcador de posición , pero, por supuesto, no mediante el uso de una función de reemplazo casera, sino una función adecuada proporcionada por la API de la base de datos.
