Detect SQL Injection

Question

Je suis venu dans une entreprise qui a déjà un projet complet ... mais les codeurs qui travaillaient ici avant moi ne suivaient pas les conventions et n'utilisaient pas les requêtes SQL paramétrées ... en conséquence il y a plus de 1000 places dans un très gros projet qui peut éventuellement être vulnérable à l'injection SQL ...

J'ai besoin de trouver une solution qui détectera automatiquement s'il y a une injection SQL dans le code. Ainsi, par exemple, il existe un formulaire qui permet à l'utilisateur d'entrer des commentaires concernant un produit, qui seront envoyés à la base de données sur submit ... comment s'assurer qu'un utilisateur n'a pas entré une requête dangereuse au lieu d'un texte normal?

Existe-t-il un code avancé/une expression régulière/magie qui peut détecter si ce texte contient une requête SQL au lieu d'un texte normal inoffensif? J'accepterai n'importe quels liens, morceaux de code dans n'importe quelle langue ou même logiciel commercial qui le fera pour moi.

Merci

Answer 1

Il n'y a pas de solution miracle ici. Les injections SQL peuvent prendre de nombreuses formes obscures et tenter de les détecter à l'aide d'expressions régulières ou d'une autre forme dans votre pare-feu, ou une application peut vous protéger des formes d'injection SQL les plus simples. Comme AdaTheDev l'a déjà noté, les outils automatisés qui inspectent votre code, tels que l'outil d'analyse de code MS, peuvent vous donner un coup d'envoi, mais là encore, il n'y a pas de solution miracle. Vous devrez passer en revue toute votre demande.

Lorsque cela représente beaucoup de travail, vous devriez faire un plan. Tout d'abord, faites un guide qui indique comment ces types d'attaques peuvent être atténués. Essayez également de diviser votre application en plusieurs parties, de très critique à moins critique. De cette façon, vous pouvez mieux estimer les coûts de réparation des bugs et laisser la direction décider de ce que cela peut coûter et donc du risque qu'ils sont prêts à prendre. Les parties de votre application auxquelles des utilisateurs non authentifiés peuvent accéder sont les plus critiques. Si tout le monde (dans le monde) peut créer un compte dans votre application, toutes les fonctionnalités auxquelles ces utilisateurs peuvent accéder sont très critiques. Plus la population est petite et plus vous faites confiance à ces utilisateurs, plus le risque est faible. Vous pouvez peut-être vous en sortir en réparant ces pièces plus tard. Mais ne jamais sous-estimer un bon hacker. Il/elle pourrait être en mesure de compromettre le compte d'un utilisateur avec des privilèges élevés et commencer à tester les possibilités d'injection SQL en utilisant ce compte.

Toujours essayer d'avoir une stratégie de défense en profondeur, avoir plusieurs (ou plusieurs) couches de défense. Par exemple, ne vous connectez jamais avec votre base de données en tant que SA à partir de votre application. Créez un compte avec seulement les privilèges nécessaires et peut-être même créer plusieurs comptes SQL, un compte par rôle (ou par un groupe de rôles). Bien que restreindre les privilèges à la base de données aide beaucoup à atténuer le risque, encore une fois, ne pariez pas sur elle comme une seule couche de défense. Par exemple, This article, explique comment un pirate peut abuser d'un compte de privilège inférieur quand il est capable de faire une injection SQL. Il est admirable que vous posiez cette question ici, parce que j'ai vu de nombreux développeurs dans le passé qui ne veulent tout simplement pas savoir, ce qui est très effrayant, car l'entreprise fait souvent confiance à ses développeurs (ce qui est effrayant bien).

Je vous souhaite la meilleure des chances.

Answer 2

Je salue votre volonté de plonger et arranger les choses, et non pas seulement hausser les épaules et dire: « ehh .. personne ne va attaquer notre site de toute façon ».

Je pense que la meilleure approche serait peut-être d'assainir les intrants, en supposant qu'ils sont innocents, dans tous les domaines. Le problème est, il pourrait y avoir des raisons légitimes pour quelqu'un d'entrer l'un des caractères qui pourraient déclencher l'injection SQL. Essayer simplement de détecter de tels modèles serait sujet à des résultats d'attaque faussement positifs; Peut-être que quelqu'un essaie de chercher john's car, ne sachant pas du tout que la citation unique pourrait être «mauvaise». Et peut-être qu'ils ont vraiment besoin de chercher cela. Ou, qu'avez-vous ...

Answer 3

Vous devez vérifier où les variables sont passées dans les chaînes SQL. Pour les valeurs de chaîne, vous devez remplacer chaque instance d'un guillemet simple par un guillemet double. Pour les valeurs non-chaînes (celles qui passeront au SQL non-cité), vous devez vous assurer qu'elles sont fortement typées.

E.g. ne pas passer quelque chose comme "SELECT * FROM Users WHERE UserID = " + my_string_user_id. Au lieu de cela, utilisez le code "SELECT * FROM Users WHERE UserID = " + userId_as_int.

Cela a fonctionné dans le jour où j'avais une base de code similaire sans aucune requête paramétrée du tout.

Answer 4

Afin de vraiment faire cela correctement, vous devez simplement diviser l'application et passer par un module/page/classe/tout à la fois.

Cela vous permettra non seulement de résoudre le problème, mais aussi de vous familiariser avec la base de code en général.

MISE À JOUR
Basé sur le commentaire que je voulais ajouter une chose:

La seule chose qu'un outil peut faire est de dire regard, voici quelques entrées ... qui assainies, le plus probable, est va être à peu près toutes les requêtes de votre application. Ce qui signifie que vous aurez une liste d'environ 3000 fichiers à corriger. À ce moment-là, la seule chose que vous pouvez faire est de désigner un jour, comme le vendredi, en tant que Fix Sql Day. Divisez le travail et demandez à tout le monde de passer une journée (ou même quelques heures) à réécrire les requêtes sur quelques pages.

À un certain point, vous finirez ou trouverez suffisamment d'autres erreurs pour déterminer si recommencer est une bonne idée.

Answer 5

Vous pouvez donner le MS Code Analysis Tool un tourbillon qui (citation):

CAT.NET est un outil d'analyse de code binaire qui permet d'identifier les variantes communes de certaines vulnérabilités existantes qui peuvent donner lieu à une attaque commune vecteurs tels que Cross-Site Scripting (XSS), Injection SQL et XPath Injection.

Je ne l'ai jamais utilisé moi-même, mais ça vaut le coup d'essayer.