Puis-je me protéger contre les injections SQL en échappant aux guillemets simples et en entourant les entrées de l'utilisateur de guillemets simples ?

Question

Je me rends compte que les requêtes SQL paramétrées sont le meilleur moyen d'assainir l'entrée de l'utilisateur lors de la construction de requêtes qui contiennent l'entrée de l'utilisateur, mais je me demande ce qui est mal de prendre l'entrée de l'utilisateur et d'échapper tous les guillemets simples et d'entourer toute la chaîne de caractères avec des guillemets simples. Voici le code :

sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"

Tous les guillemets simples que l'utilisateur saisit sont remplacés par des guillemets doubles, ce qui élimine la possibilité pour l'utilisateur de terminer la chaîne de caractères, de sorte que tout ce qu'il peut saisir, comme les points-virgules, les pourcentages, etc.

Nous utilisons Microsoft SQL Server 2000, pour lequel je crois 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 tout ce que l'utilisateur tape.

Je ne vois aucun moyen de lancer une attaque par injection SQL contre ce système, mais je me rends compte que si ce système é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 ? Y a-t-il un moyen de faire passer une attaque par injection SQL au-delà de cette technique d'assainissement ? Un exemple d'entrée utilisateur qui exploite cette technique serait très utile.

---

UPDATE :

Je ne connais toujours pas de moyen de lancer efficacement une attaque par injection SQL contre ce code. Quelques personnes ont suggéré qu'une barre oblique inversée permettrait d'échapper à une apostrophe et de laisser l'autre à la fin de la chaîne de manière à ce que le reste de la chaîne soit exécuté dans le cadre de la commande SQL, et je réalise que cette méthode fonctionnerait pour injecter du SQL dans une base de données MySQL, mais dans SQL Server 2000, le seul moyen (que j'ai pu trouver) d'échapper à une apostrophe est d'utiliser une autre apostrophe ; les barres obliques inversées ne le font pas.

Et à moins qu'il n'existe un moyen d'empêcher l'échappement du guillemet simple, aucune des autres entrées de l'utilisateur ne sera exécutée car elles seront toutes considérées comme une seule chaîne contiguë.

Je comprends qu'il existe de meilleurs moyens d'assainir les entrées, mais je suis vraiment plus intéressé à savoir pourquoi la méthode que j'ai fournie ci-dessus ne fonctionne pas. Si quelqu'un connaît un moyen spécifique de monter une attaque par injection SQL contre cette méthode d'assainissement, je serais ravi de le voir.

Answer 1

Tout d'abord, c'est une mauvaise pratique. La validation des entrées est toujours nécessaire, mais elle est aussi toujours incertaine.
Pire encore, la validation par liste noire est toujours problématique, il est bien mieux de définir explicitement et strictement les valeurs/formats que vous acceptez. Certes, ce n'est pas toujours possible, mais dans une certaine mesure, cela doit toujours être fait.
Quelques documents de recherche sur le sujet :

• http://www.imperva.com/docs/WP_SQL_Injection_Protection_LK.pdf
• http://www.it-docs.net/ddata/4954.pdf (Divulgation, ce dernier était le mien ;) )
• https://www.owasp.org/images/d/d4/OWASP_IL_2007_SQL_Smuggling.pdf (basé sur le document précédent, qui n'est plus disponible)

Le fait est que toutes les listes noires que vous établissez (et les listes blanches trop permissives) peuvent être contournées. Le dernier lien vers mon article montre des situations où même l'échappement des guillemets peut être contourné.

Même si ces situations ne s'appliquent pas à vous, c'est toujours une mauvaise idée. De plus, à moins que votre application ne soit très petite, vous allez devoir vous occuper de la maintenance, et peut-être d'une certaine gouvernance : comment vous assurer que tout est fait correctement, partout et tout le temps ?

La façon correcte de le faire :

• Validation de la liste blanche : type, longueur, format ou valeurs acceptées
• Si vous voulez établir une liste noire, allez-y. L'échappement des citations est une bonne chose, mais dans le cadre des autres mesures d'atténuation.
• Utiliser les objets Commande et Paramètre, pour préparer et valider
• Appeler uniquement les requêtes paramétrées.
• Mieux encore, utilisez exclusivement les procédures stockées.
• Évitez d'utiliser le SQL dynamique et n'utilisez pas la concaténation de chaînes de caractères pour construire des requêtes.
• Si vous utilisez des SP, vous pouvez également limiter les autorisations dans la base de données pour exécuter uniquement les SP nécessaires, et ne pas accéder directement aux tables.
• vous pouvez aussi facilement vérifier que l'ensemble de la base de code n'accède à la BD qu'à travers des SP...

Answer 2

Ok, cette réponse sera liée à la mise à jour de la question :

"Si quelqu'un connaît un moyen spécifique de monter une attaque par injection SQL contre cette méthode d'assainissement, j'aimerais bien le voir."

Outre l'échappement de la barre oblique inversée de MySQL, et compte tenu du fait que nous parlons en fait de MSSQL, il existe en fait 3 façons possibles d'injecter votre code en SQL

sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"

Tenez compte du fait qu'elles ne seront pas toutes valables à tout moment et qu'elles dépendent fortement du code qui les entoure :

1. Injection SQL de second ordre - si une requête SQL est reconstruite à partir de données extraites de la base de données. après s'être échappé les données sont concaténées sans marquage et peuvent être injectées indirectement par SQL. Voir
2. Troncature de chaîne - (un peu plus compliqué) - Le scénario est que vous avez deux champs, disons un nom d'utilisateur et un mot de passe, et le SQL les concatène tous les deux. Et les deux champs (ou juste le premier) ont une limite stricte de longueur. Par exemple, le nom d'utilisateur est limité à 20 caractères. Disons que vous avez ce code :

username = left(Replace(sInput, "'", "''"), 20)

Ce que vous obtenez alors, c'est le nom d'utilisateur, échappé, puis réduit à 20 caractères. Le problème ici est que je vais placer mon guillemet dans le 20ème caractère (par exemple après 19 a), et votre guillemet d'échappement sera coupé (dans le 21ème caractère). Ensuite, le SQL

sSQL = "select * from USERS where username = '" + username + "'  and password = '" + password + "'"

combiné avec le nom d'utilisateur malformé mentionné plus haut, le mot de passe sera déjà à l'extérieur de les guillemets, et contiendra simplement la charge utile directement.
3. Contrebande d'Unicode - Dans certaines situations, il est possible de faire passer un caractère unicode de haut niveau qui regarde comme une citation, mais n'est pas - jusqu'à ce qu'il arrive à la base de données, où soudainement c'est . Puisque ce n'est pas une citation lorsque vous la validez, elle passera facilement... Voir ma réponse précédente pour plus de détails, et le lien vers la recherche originale.

Answer 3

En un mot : Ne faites jamais d'évasion de requêtes vous-même. Vous risquez de vous tromper. Utilisez plutôt des requêtes paramétrées, ou si vous ne pouvez pas le faire pour une raison quelconque, utilisez une bibliothèque existante qui le fait pour vous. Il n'y a aucune raison de le faire vous-même.

Answer 4

Je réalise que cela fait longtemps que la question a été posée, mais

Une façon de lancer une attaque contre la procédure "citer l'argument" est de tronquer les chaînes de caractères. Selon MSDN, dans SQL Server 2000 SP4 (et SQL Server 2005 SP1), une chaîne trop longue sera discrètement tronquée.

Lorsque vous citez une chaîne de caractères, celle-ci augmente en taille. Chaque apostrophe est répétée. Cela peut ensuite être utilisé pour pousser des parties du SQL en dehors du tampon. Ainsi, vous pouvez effectivement supprimer des parties d'une clause "where".

Cela serait probablement utile dans le cas d'une page d'administration d'utilisateur où l'on pourrait abuser de l'instruction "update" pour ne pas faire toutes les vérifications qu'elle est censée faire.

Donc, si vous décidez de citer tous les arguments, assurez-vous de connaître la taille des chaînes de caractères et veillez à ne pas vous heurter à la troncature.

Je vous recommande d'opter pour les paramètres. Toujours. J'aimerais juste pouvoir le faire respecter dans la base de données. Et comme effet secondaire, vous avez plus de chances d'obtenir de meilleurs résultats dans le cache parce que davantage de déclarations se ressemblent. (C'était certainement vrai sur Oracle 8)

Answer 5

L'assainissement des intrants n'est pas quelque chose que vous devez négliger. Utilisez tout votre cul. Utilisez des expressions régulières sur les champs de texte. Essayez de convertir vos données numériques dans le type numérique approprié et signalez une erreur de validation si cela ne fonctionne pas. Il est très facile de rechercher des modèles d'attaque dans vos entrées, comme ' --. Supposez que toutes les entrées de l'utilisateur sont hostiles.