Je me rends compte que les requêtes SQL paramétrées sont le moyen optimal de nettoyer les entrées utilisateur lors de la création de requêtes contenant des entrées utilisateur, mais je me demande ce qui ne va pas avec la saisie des entrées utilisateur et en échappant aux guillemets simples et en entourant la chaîne entière avec des guillemets simples. Voici le code:
sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"
Tout guillemet simple saisi par l'utilisateur est remplacé par des guillemets simples doubles, ce qui élimine la possibilité pour les utilisateurs de terminer la chaîne, de sorte que tout ce qu'ils peuvent taper, comme des points-virgules, des signes de pourcentage, etc., fera partie de la chaîne et pas réellement exécuté dans le cadre de la commande.
Nous utilisons Microsoft SQL Server 2000, pour lequel je pense que le guillemet simple est le seul délimiteur de chaîne et le seul moyen d'échapper au délimiteur de chaîne, il n'y a donc aucun moyen d'exécuter quoi que ce soit que l'utilisateur tape.
Je ne vois aucun moyen de lancer une attaque par injection SQL contre cela, mais je me rends compte que si c'était aussi infaillible qu'il me semble, quelqu'un d'autre y aurait déjà pensé et ce serait une pratique courante.
Quel est le problème avec ce code? Existe-t-il un moyen de faire passer une attaque par injection SQL au-delà de cette technique de nettoyage? Un exemple d'entrée utilisateur exploitant cette technique serait très utile.
METTRE À JOUR:
Je ne connais toujours aucun moyen de lancer efficacement une attaque par injection SQL contre ce code. Quelques personnes ont suggéré qu'une barre oblique inverse échapperait à un guillemet simple et laisserait l'autre pour terminer la chaîne afin que le reste de la chaîne soit exécuté dans le cadre de la commande SQL, et je me rends compte que cette méthode fonctionnerait pour injecter SQL dans une base de données MySQL, mais dans SQL Server 2000, le seul moyen (que j'ai pu trouver) d'échapper à un guillemet simple est d'utiliser un autre guillemet simple; les barres obliques inverses ne le feront pas.
Et à moins qu'il n'y ait un moyen d'arrêter l'échappement du guillemet simple, aucune des autres entrées utilisateur ne sera exécutée car tout sera considéré comme une chaîne contiguë.
Je comprends qu'il existe de meilleures façons de nettoyer les entrées, mais je suis vraiment plus intéressé à savoir pourquoi la méthode que j'ai fournie ci-dessus ne fonctionnera pas. Si quelqu'un connaît un moyen spécifique de monter une attaque par injection SQL contre cette méthode de désinfection, j'aimerais le voir.