Une déclaration paramétrée peut-elle empêcher toute injection SQL ?

Question

Si oui, pourquoi y a-t-il toujours autant d'injections SQL réussies ? Juste parce que certains développeurs sont trop bêtes pour utiliser des instructions paramétrées ?

Answer 1

Les liens que j'ai postés dans mes commentaires à la question expliquent très bien le problème. Je résume ci-dessous mon sentiment sur la raison pour laquelle le problème persiste :

1. Ceux qui débutent peuvent ne pas avoir conscience de l'injection SQL.

2. Certains sont conscients de l'injection SQL, mais pensent que l'échappement est la (seule ?) solution. Si vous effectuez une recherche rapide sur Google pour php mysql query la première page qui apparaît est la page mysql_query sur laquelle se trouve un exemple qui montre l'interpolation d'une entrée utilisateur échappée dans une requête. Il n'est pas fait mention (du moins pas à ma connaissance) de l'utilisation d'instructions préparées à la place. Comme d'autres l'ont dit, il y a tellement de tutoriels qui utilisent l'interpolation de paramètres, qu'il n'est pas vraiment surprenant que cette méthode soit encore utilisée.

3. Un manque de compréhension du fonctionnement des déclarations paramétrées. Certains pensent qu'il s'agit simplement d'un moyen sophistiqué d'échapper des valeurs.

4. D'autres connaissent les déclarations paramétrées, mais ne les utilisent pas parce qu'ils ont entendu dire qu'elles étaient trop lentes. Je soupçonne que de nombreuses personnes ont entendu dire que les instructions paramétrées sont incroyablement lentes, mais n'ont pas fait de tests par elles-mêmes. Comme Bill Karwin l'a souligné dans son exposé, la différence de performances devrait rarement être utilisée comme facteur dans l'examen de l'utilisation des instructions préparées. Les avantages de préparer une fois, exécuter plusieurs fois On semble souvent oublier les améliorations en matière de sécurité et de maintenabilité du code.

5. Certains utilisent partout des instructions paramétrées, mais avec interpolation de valeurs non vérifiées telles que les noms de tables et de colonnes, les mots-clés et les opérateurs conditionnels. Les recherches dynamiques, telles que celles qui permettent aux utilisateurs de spécifier un certain nombre de champs de recherche différents, de conditions de comparaison et d'ordre de tri, en sont des exemples parfaits.

6. Faux sentiment de sécurité lors de l'utilisation d'un ORM. Les ORM permettent toujours l'interpolation de parties d'instructions SQL - voir 5.

7. La programmation est un sujet vaste et complexe, la gestion des bases de données est un sujet vaste et complexe, la sécurité est un sujet vaste et complexe. Le développement d'une application de base de données sécurisée n'est pas facile - même les développeurs expérimentés peuvent être pris au dépourvu.

8. De nombreuses réponses sur stackoverflow ne sont d'aucune aide. Lorsque les gens écrivent des questions qui utilisent le SQL dynamique et l'interpolation de paramètres, il y a souvent un manque de réponses qui suggèrent d'utiliser des instructions paramétrées à la place. À quelques reprises, j'ai vu des personnes réfuter ma suggestion d'utiliser des instructions préparées - généralement en raison de la perception d'une surcharge de performance inacceptable. Je doute sérieusement que les personnes qui posent la plupart de ces questions soient dans une situation où les quelques millisecondes supplémentaires nécessaires à la préparation d'une instruction paramétrée auront un effet catastrophique sur leur application.

Answer 2

Je ne dirais pas "stupide".

Je pense que les tutoriels sont le problème. La plupart des tutoriels SQL, des livres, etc. expliquent le SQL avec des valeurs soulignées, sans mentionner du tout les paramètres de liaison. Les personnes qui apprennent à partir de ces didacticiels n'ont pas la possibilité d'apprendre correctement.

Answer 3

Parce que la plupart du code n'est pas écrit avec la sécurité à l'esprit, et la direction, si elle a le choix entre ajouter des fonctionnalités (surtout quelque chose de visible qui peut être vendu) et la sécurité/stabilité/fiabilité (qui est beaucoup plus difficile à vendre), elle choisira presque invariablement la première. La sécurité n'est une préoccupation que lorsqu'elle devient un problème.

Answer 4

Pour protéger votre application contre l'injection SQL, effectuez les étapes suivantes :

Étape 1. Contrainte de l'entrée. Étape 2. Utilisez des paramètres avec des procédures stockées. Étape 3. Utilisation de paramètres avec le SQL dynamique.

Se référer à http://msdn.microsoft.com/en-us/library/ff648339.aspx

Answer 5

Non, les requêtes paramétrées n'empêchent pas toutes les injections sql - certaines requêtes dynamiques sont composées dans des procédures stockées dans la base de données.

Quant à la raison pour laquelle nous avons toujours l'injection sql : de vieux (mauvais) exemples, des langages et des systèmes qui ne supportent pas la paramétrisation, et le fait que réparer quelque chose qui fonctionne est plus difficile à vendre que de nouvelles fonctionnalités/corrections de bugs.