Créer des conditions de recherche sécurisées pour la clause SQL WHERE

Question

Je dois créer des conditions de recherche à utiliser avec la clause WHERE. Cette condition de recherche est ensuite transmise à une application différente pour être exécutée dans le cadre d'une requête SQL. Parce que les conditions de recherche peuvent être assez complexes (y compris les sous-requêtes), je ne crois pas que la réception d'une application puisse les analyser intelligemment pour empêcher les attaques par injection SQL. Les meilleures pratiques indiquent que les requêtes paramétrées doivent être utilisées. Cela fonctionne correctement lorsque vous utilisez l'objet de commande pour exécuter la requête vous-même. Dans mon cas, je souhaite obtenir cette chaîne de requête avec les paramètres qui y sont fusionnés, et analyser la partie de recherche qui m'intéresse. Y a-t-il un moyen de le faire?

Je travaille avec MS SQL Server et remplace actuellement simplement toutes les guillemets simples par deux guillemets simples dans la chaîne que je reçois d'un appelant. Existe-t-il un meilleur moyen d'atteindre un certain niveau de protection contre les attaques par injection SQL?

Answer 1

Jetez un oeil à ces 2 liens

Does this code prevent SQL injection?

et

Proving SQL Injection

Answer 2

certains guidelines de OWASP

Answer 3

Je pense vous êtes bien: Selon le SQL Server Books Online , une solita ry seule citation semble être la seule façon de quitter une chaîne entre guillemets qui a été démarrée avec un seul guillemet. Ainsi, remplacer ' par '' devrait suffire pour éviter l'injection SQL à travers string variables.

Je ne peux pas penser à un moyen d'injecter SQL par le biais d'autres, non-chaîne types de données natifs C#, si elles sont correctement (locale invariante) converties en chaînes. Néanmoins, les requêtes paramétrées constituent la solution «recommandée». À l'heure actuelle, votre application semble être organisée comme suit:

1. La partie A crée une instruction WHERE basée sur l'entrée de l'utilisateur.
2. Une chaîne contenant cette instruction WHERE est transmise à la partie B.
3. La partie B ajoute SELECT, etc., et l'envoie à SQL Server.

Serait-ce une option pour réécrire votre application comme ça?

1. La partie A crée une instruction WHERE paramétrée plus un ensemble de paramètres basés sur l'entrée de l'utilisateur.
2. Une chaîne contenant l'instruction WHERE plus un Hashtable (ou quelque chose de similaire) contenant les paramètres est passé à la partie B.
3. partie B crée une commande, ajoute SELECT etc., ajoute les paramètres et il envoie à SQL Server.

j'étais dans une situation similaire et a résolu le problème en créant une classe SubSQL, qui contient essentiellement une chaîne paramétrés avec le CommandText et une table de hachage avec les paramètres.Vous pouvez ensuite utiliser cela comme mySubSQL.CommandText += ..., mySubSQL.Parameters("@myfield") = myValue et mySubSQL.MergeInto(myCommand) (la mise en œuvre devrait être évidente et directe).