Si vous saviez pourquoi une injection SQL se produit, vous seriez en mesure de répondre à cette question vous-même.
Voyons voir. Le CWE décrit les injections SQL (CWE-89) comme suit :
De plus :
Donc, fondamentalement :les entrées influencées de l'extérieur dans une requête SQL générée ne sont pas interprétées comme prévu. La partie importante ici est :non interprété comme prévu .
Si une entrée utilisateur est destinée à être interprétée comme une chaîne MySQL littéral mais ce n'est pas le cas, c'est une injection SQL. Mais pourquoi cela arrive-t-il ?
Eh bien, littéraux de chaîne ont une certaine syntaxe par laquelle ils sont identifiés par l'analyseur SQL :
De plus :
De plus, pour pouvoir utiliser des guillemets dans les littéraux de chaîne :
Comme toutes ces dernières séquences mentionnées sont spéciales aux littéraux de chaîne, il est nécessaire que toute donnée destinée à être interprétée comme un littéral de chaîne soit correctement traitée pour se conformer à ces règles. Cela signifie en particulier :si l'un des caractères mentionnés est destiné à être utilisé dans un littéral de chaîne, il doit être écrit de l'une des manières mentionnées.
Donc, si vous le regardez de cette façon, ce n'est même pas une question de sécurité mais simplement de traitement des données afin qu'elles soient interprétées comme prévu .
Il en va de même pour les autres littéraux ainsi que pour d'autres aspects de SQL.
Alors qu'en est-il de votre question ?
Oui, ce serait à l'abri des injections SQL. bin2hex renvoie une chaîne contenant uniquement des caractères hexadécimaux. Et aucun de ces caractères ne nécessite un traitement spécial lors de leur utilisation dans un littéral de chaîne MySQL.
Mais sérieusement, pourquoi quelqu'un voudrait-il utiliser ces techniques de formatage encombrantes alors qu'il existe des bibliothèques et des frameworks qui fournissent des techniques pratiques telles que des instructions paramétrées/préparées ?
