Cet exemple isolé est invulnérable à l'injection.
Mais vous devez réaliser que la protection contre l'injection sql n'est pas seulement un remplacement de caractère . Et les circonstances peuvent différer de celles que vous considérez pour le moment comme allant de soi. Ainsi, votre code deviendrait vulnérable à long terme, en raison des inconvénients essentiels de cette méthode :
- le remplacement de caractère n'est qu'une partie du formatage requis
- ce remplacement particulier ne peut être appliqué qu'aux cordes, laissant les autres parties absolument sans protection.
- un tel remplacement est externe à l'exécution d'une requête, ce qui signifie qu'il est sujet à une erreur humaine de toute sorte.
- un tel remplacement est une mesure essentiellement détachable, ce qui signifie qu'il peut être déplacé trop loin de l'exécution réelle de la requête et éventuellement oublié.
- ce type d'échappement est sujet à attaque d'encodage , ce qui rend la solution trop limitée dans son utilisation.
Il n'y a rien de mal à remplacer des caractères en soi, mais seulement s'il est utilisé dans le cadre d'un formatage complet ; appliqué à la bonne partie de la requête ; et fait par un pilote de base de données, pas un programmeur ; juste avant l'exécution.
Les fonctions que vous avez proposées dans les commentaires sont une bonne étape, mais encore insuffisantes, étant sujettes aux inconvénients énumérés ci-dessus, les rendant sujettes à toutes sortes d'erreurs humaines.
Et l'injection SQL n'est pas le seul problème avec cette approche, c'est aussi un défaut d'utilisabilité, car cette fonction gâcherait vos données, si elle était utilisée comme une incarnation de la fin citations magiques , ou rendre votre code gonflé, s'il est utilisé pour formater chaque variable directement dans le code de l'application.
Ces fonctions peuvent être utilisées uniquement pour traiter un espace réservé , mais bien sûr pas en utilisant une fonction de remplacement maison, mais une fonction appropriée fournie par l'API de base de données.
