Il n'y a pas de correctif général pour SQLi car il n'y a pas de correctif pour la stupidité humaine. Il existe des techniques établies qui sont faciles à utiliser et qui résolvent les problèmes (en particulier la liaison de paramètres) mais il faut encore utiliser ces techniques. Et de nombreux développeurs ne sont tout simplement pas conscients des problèmes de sécurité. La plupart se soucient que l'application fonctionne du tout et ne se soucient pas beaucoup de la sécurité, surtout si cela rend les choses (même légèrement) plus complexes et entraîne des coûts supplémentaires comme les tests.

Ce type de problème ne se limite pas à SQLi mais vous le trouverez avec des dépassements de tampon, la vérification des certificats, XSS, CSRF .... Il est plus coûteux de faire une programmation sécurisée en raison des tests supplémentaires et de l'expertise supplémentaire requise par le développeur (donc plus coûteux). Et tant que le marché le préfère bon marché et ne se soucie pas beaucoup de la sécurité, vous obtenez des solutions bon marché et peu sûres. Et bien que la sécurité dès la conception aide beaucoup à l'améliorer, les développeurs contournent souvent cette conception parce qu'ils ne la comprennent pas et que c'est juste sur leur chemin.

Parce que ce n'est pas un problème.

• À quand remonte la dernière fois qu'une entreprise avec une vulnérabilité d'injection SQL a été traînée devant le tribunal et giflée d'une grosse amende pour avoir été imprudente avec les données des utilisateurs et les administrateurs avertis, condamnés à une amende ou enfermés pour négligence?

• À quand remonte la dernière fois qu'une entreprise a perdu un gros contrat parce que sa page de connexion au site Web de l'entreprise ne l'a pas fait valider correctement les mots de passe?

• À quand remonte la dernière fois qu'un régulateur / auditeur qualifié d'une organisation professionnelle a dû approuver et approuver un système informatique public avant qu'il puisse être mis en service ?

On pourrait penser que «les gens vont mourir» serait une raison suffisante pour construire des bâtiments avec des matériaux ignifuges, des alarmes et de bonnes voies d'évacuation. Ce n'était pas. Nous avons introduit une réglementation pour forcer les matériaux de construction ininflammables, des conceptions de sécurité incendie avec des coupe-feu, des alarmes d'incendie.

Vous pourriez penser que "des gens vont mourir" serait une raison suffisante pour inciter tout le monde se soucient de la conception structurelle du bâtiment. Ce n'est pas. Ce n'est tout simplement pas. Nous devons avoir une réglementation pour que les ingénieurs qualifiés approuvent la conception des bâtiments, qu'ils soient conçus et construits pour des utilisations spécifiques, et lorsque les choses échouent, la société poursuit les ingénieurs en justice.

On pourrait penser que "les gens vont mourir" serait une raison suffisante pour rendre la transformation des aliments propre et sûre, mais ce n'était pas le cas.

L'injection SQL est moins évidente, moins visible publiquement, et a moins d'impact sur la gravité, et est dans une industrie complètement non réglementée.

Même les entreprises qui s'en soucient, elles ne peuvent pas annoncer utilement " Aucune vulnérabilité d'injection SQL connue dans notre code " comme une puce marketing qui intéresse tout le monde. Ce n'est pas le genre de question que les clients posent aux vendeurs. Ce n'est pas un avantage concurrentiel pour eux, c'est un coût, des frais généraux. Se protéger contre cela les rend moins compétitifs, plus lents, faisant plus de travail pour la même fonctionnalité.

Les incitations sont toutes alignées pour qu'il continue d'exister. Donc, cela continue d'exister.

Faites de l'injection SQL un problème pour les entreprises, et elles le feront disparaître.

[Edit: Mais il existe une réglementation de l'UE selon laquelle les sites Web doivent vous avertir s'ils utilisent des cookies. Et ils le font. Donc, réglementer les systèmes informatiques destinés au public pour les rendre plus ennuyeux peut entrer en vigueur - même si la réglementation actuelle est assez inutile.]

L'injection SQL est toujours d'actualité car le monde du logiciel ne comprend toujours pas que la génération programmatique de valeurs structurées en arborescence (comme les requêtes ou le balisage) doit être effectuée en construisant des arbres de syntaxe en tant qu'objets de première classe , pas en concaténant des chaînes qui représentent des fragments d'un langage.

Il y a eu un peu de progrès ces dernières années avec la disponibilité croissante des outils de création de requêtes comme LINQ to SQL ou SQLAlchemy, mais c'est du côté du langage de programmation. Les bases de données relationnelles n'offrent toujours pas une interface alternative standard et convaincante qui n'est pas fondamentalement basée sur l'envoi de requêtes sous forme de chaînes.

Les instructions préparées avec des paramètres de requête ne sont guère une amélioration, car elles ne sont faciles à utiliser que si le La structure de vos requêtes (quelles tables sont jointes, quelles conditions de filtrage, quelles colonnes projeter) est fixe . Lorsque vous avez une application qui doit créer du texte de requête au moment de l'exécution, les paramètres de requête préparés sont très difficiles à utiliser.

Donc, si un protocole normalisé, non textuel et structuré en arborescence pouvait être construit pour décrire et communiquer des requêtes à la base de données, et qu'il était conçu pour être plus facile à utiliser que les requêtes textuelles, cela résoudrait le problème. problème à long terme. Mais le problème ne disparaîtra pas tant que l’industrie n’aura pas adopté quelque chose où le chemin de moindre résistance est sûr. Tant que nous insistons sur des systèmes non sécurisés par défaut où l'écriture de code sécurisé demande des efforts inutiles, les problèmes seront avec nous. (Pensez à tous les débordements de tampon qui n'existent pas du tout dans les langages gérés en mémoire!)

Notez que le même problème fondamental que l'injection SQL sévit sur le Web, sous le nom de cross-site scripting - qui n'est en réalité qu'une injection Javascript dans des pages HTML dynamiques. Un modèle très courant est celui des programmeurs Javascript qui, au lieu de travailler avec le DOM en le traitant comme un arbre d'objets, ont recours à la propriété innerHTML pour le définir sur du texte HTML construit par concaténation de chaînes naïve. De nombreuses vulnérabilités XSS n'auraient jamais existé si la propriété innerHTML n'avait jamais été placée dans les implémentations DOM des navigateurs.

Aussi, pour les gens qui n'ont pas vu le discours de Tony Hoare sur les pointeurs nuls, il est à la fois orthogonal (pointeurs nuls, pas d'injection SQL) mais en même temps incroyablement pertinent:

• Tony Hoare, "Null References: The Billion Dollar Mistake".

Lors des tests, il est très facile de tester ce à quoi vous vous attendez . Par exemple, lorsque vous remplissez un champ "nom" dans une base de données, vous choisirez probablement quelque chose que vous connaissez bien, comme "John Doe". Cela fonctionne et votre application semble bien fonctionner.

Puis, un jour, quelqu'un nomme son enfant Robert '); DROP TABLE Étudiants; - (petites tables Bobby).

Bien sûr, vous ne testez pas votre application pour des noms comme celui-là , donc la faille de sécurité qu'un tel nom expose glisse à travers tous vos tests.

Il y a un commentaire intéressant ici: L'infalsifiabilité des revendications de sécurité

C'est Il est facile de prouver qu'il existe une faille de sécurité (il vous suffit de tester un nom comme celui ci-dessus). Il est également facile de prouver qu'un trou particulier a été corrigé. Il est difficile de prouver qu’il n’existe aucune autre faille de sécurité.

Steffen fait valoir de bons points dans sa réponse, mais j'aimerais ajouter quelque chose. Le pourquoi, je pense, peut être expliqué dans les sujets suivants:

• Manque de connaissances ou de formation des développeurs
• Churn dans un environnement de développement d'entreprise
• Pression pour livrer plus tôt que prévu
• Insistance insuffisante du haut sur la sécurité

Alors décomposons-les.

Formation des développeurs

De nos jours, on met beaucoup l'accent sur l'éducation des utilisateurs. Apprenez aux utilisateurs à conserver des mots de passe forts. Apprenez aux utilisateurs à identifier le phishing. Apprenez aux utilisateurs à ... Vous voyez l'idée. Certaines entreprises, probablement beaucoup, mais je ne peux parler que de mon expérience professionnelle et je n'ai pas travaillé dans beaucoup d'entreprises;), ont des programmes de formation. Mais ces programmes de formation peuvent être incomplets ou ne pas atteindre la profondeur des connaissances nécessaires. Il ne s'agit pas de dénigrer le travail acharné qui est nécessaire pour élaborer ces programmes. Mais dire que tout comme en milieu scolaire, différentes personnes apprennent différemment. Et à moins d'avoir un programme de formation continue pour les développeurs, il sera difficile de communiquer "utiliser des requêtes paramétrées, et voici comment le faire en PHP, Java, Python, Ruby, Scala, NodeJS, ...". C'est un travail acharné pour développer, fournir et maintenir des programmes pour développeurs qui atteignent efficacement le public.

Churn des développeurs

Ci-dessus, l'une des choses auxquelles j'ai fait allusion était d'atteindre efficacement le public pour différents types d'apprentissage. L'une des raisons à cela est que beaucoup d'entreprises ont un taux de désabonnement élevé pour les développeurs, car les développeurs sont des entrepreneurs qui passent d'un projet à l'autre dans différentes entreprises. Et les entreprises ne sont pas toujours à la même maturité de sécurité. Une entreprise peut ne pas avoir du tout de programme de sécurité, tandis qu'une autre peut avoir un excellent programme de sécurité et le développeur est soudainement bombardé de nouvelles informations qui lui seront demandées pendant les six mois avant de passer à une autre entreprise. C'est triste, mais cela arrive.

Livraison du projet

Livraison du projet dans les délais, voire en avance sur le calendrier. Le chemin le plus rapide pour terminer le projet n'est généralement pas de terminer le projet avec des contrôles de sécurité. C'est faire de la manière la plus brisée qui fonctionne encore. Nous savons que cela entraînera plus de travail, plus de temps et plus d'argent plus tard quand viendra le temps de maintenir le projet et de résoudre les problèmes, mais la direction veut juste que le projet soit retiré.

Un autre élément que j'ai abordé est développer des programmes de formation à la sécurité pour une myriade de langages de programmation. De nombreuses entreprises n'ont pas une ou deux langues définies. Les développeurs aiment donc (ou sont encouragés) à essayer la nouvelle fonctionnalité. Cela inclut les langages et les frameworks. Cela signifie que les programmes de sécurité doivent évoluer en permanence.

Adhésion de la direction

Et nous voici à la direction. Chaque fois, il semble que dans une violation publique, il y avait des contrôles qui auraient pu être mis en œuvre, qui ne sont pas si difficiles, mais qui ont été manqués. Les pressions pour livrer les produits en premier et les inquiétudes en second lieu toujours, malgré leçon après leçon après leçon, reviennent sur les entreprises de produits. La direction doit pousser du haut pour prendre le temps d'intégrer la sécurité au début. Ils doivent comprendre que plus de travail, plus de temps et plus d'argent seront consacrés à la résolution des problèmes, à l'entretien du produit et au paiement des amendes. Mais les analyses coûts-avantages indiquent que le problème est la livraison des produits, et non les amendes ou les travaux de maintenance nécessaires. Ces équations doivent changer, et cela vient, en partie, de l'éducation (wooo, cercle complet) au niveau du MBA. Les chefs d'entreprise doivent apprendre que pour réussir dans un paysage de failles de plus en plus nombreuses, la sécurité doit être au premier plan.

Conclusion

Le pourquoi, même si SQLi a presque 20 ans , a plusieurs raisons. En tant que praticiens de la sécurité, nous ne pouvons pas faire grand-chose pour éduquer et sensibiliser à ce qui se passe lorsque la sécurité n'est pas considérée comme faisant partie intégrante du SDLC.

Je suis d'accord avec beaucoup de réponses, mais un point très important n'est pas fait: le code ne se répare pas comme par magie, et il y a beaucoup de code vieux de 17 ans. J'ai vu de nombreuses entreprises écrire un nouveau code propre et sûr, alors que l'application pouvait encore être attaquée dans certaines de ses sections plus anciennes. Et le pire de tout: réparer l'ancien code coûte cher, car cela oblige les développeurs à se plonger dans un code qui a été écrit à une époque différente avec différents styles de codage et différentes technologies. Parfois, réparer un ancien code pour ne pas provoquer d'injections SQL nécessite de recréer des bibliothèques entières qui ont été rachetées dans la journée (c'est quelque chose que j'ai dû faire il y a quelques années).

Pour ne pas dire que tout le nouveau code est exempt d'injections SQL, mais personnellement, je n'ai vu aucun nouveau code écrit par des professionnels au cours des 4 ou 5 dernières années qui les contenait. (La seule exception étant lorsque les développeurs doivent faire une correction rapide et sale dans l'ancien code et utiliser le même style / technologie dans lequel le reste du code est écrit.)

Je pense que c'est parce que de nombreux développeurs apprennent juste assez pour faire le travail, pour une certaine valeur de "fait". Ils apprennent à créer du code SQL, souvent à partir de didacticiels en ligne obsolètes, puis lorsque le code "fonctionne" dans la mesure où ils peuvent dire "Je peux mettre des éléments dans la base de données et je peux générer la page de résultats", alors ils êtes satisfait.

Considérez ce type sur l'échelle:

Pourquoi fait-il ça? Pourquoi n'a-t-il pas un échafaudage approprié? Parce qu'il fait le travail. Mettez l'échelle contre le mur au-dessus des escaliers, et cela fonctionne très bien. Jusqu'à ce que ce ne soit pas le cas.

Même chose avec INSERT INTO users VALUES ($ _ POST ['user']) . Cela fonctionne très bien. Jusqu'à ce que ce ne soit pas le cas.

L'autre chose est qu'ils ne sont pas conscients des dangers. Avec le gars sur l'échelle instable, nous comprenons la gravité et la chute. Avec la création d'instructions SQL à partir de données externes non validées, ils ne savent pas ce qui peut être fait.

J'ai parlé à un groupe d'utilisateurs de développeurs Web le mois dernier, et sur les 15 développeurs de l'audience, deux avaient entendu d'injection SQL.

Je pense que la principale raison est que la formation des développeurs ne commence pas par les meilleures pratiques, elle commence par la compréhension du langage. Ainsi, les nouveaux programmeurs, croyant qu'ils ont été formés avec les outils pour créer quelque chose, procèdent à la création des requêtes comme on leur a appris. La prochaine étape, et la plus dangereuse, est de permettre à quelqu'un de développer quoi que ce soit sans examen et donc de continuer à faire des choix plus pauvres sans savoir qu'il y a quelque chose qui ne va pas et de produire de nouvelles habitudes qui ignorent les meilleures pratiques acceptées dans l'ensemble du secteur. Donc, pour résumer - des programmeurs mal formés opérant dans un environnement qui ne valorise rien d'autre que le produit final.

Cela n'a rien à voir avec l'intelligence ou la "stupidité humaine". Il existe une approche systématique qui a été bien définie au fil des ans et il est négligent pour quiconque produit des logiciels d'ignorer ce processus au nom d'une mise en œuvre plus rapide ou moins chère. Peut-être qu'un jour les ramifications juridiques de ce comportement nous permettront d'avoir plus de contrôles en place, comme les industries médicales ou de construction, où le non-respect de ces règles et des pratiques acceptées entraînera la perte de licence ou d'autres sanctions.

Pourquoi les vulnérabilités d'injection SQL n'ont-elles pas encore disparu? Métaphoriquement parlant, pour la même raison que les accidents de voiture existent toujours depuis la toute première voiture en 1895 et même les voitures autonomes les plus innovantes et modernes d'aujourd'hui, Tesla modèle S (sur le pilote automatique) ou une voiture autonome Google s'écrase de temps à autre.

Les voitures sont créées (et contrôlées) par des humains, les humains font des erreurs.

Les sites Web et les applications (Web) sont construits par des programmeurs humains. Ils ont tendance à faire de mauvaises erreurs dans la conception de la sécurité ou à casser les choses avec des «correctifs rapides» lorsque quelque chose était sécurisé, mais en introduisant en fait une nouvelle vulnérabilité, par exemple parce que le temps / budget pour développer un correctif était limité, ou le développeur a eu une grande gueule de bois lorsqu'il a écrit le correctif .

Est-ce toujours causé par les développeurs? Essentiellement oui, mais pas toujours par le développeur de première ligne . Par exemple, un supermarché local a demandé à une société de développement Web de créer un site Web pour eux. Les développeurs louent un espace d'hébergement partagé à une société d'hébergement pour héberger le site et ils installent WordPress et quelques plugins utiles.

Désormais, les développeurs de la société de développement Web n'ont pas forcément à se tromper en introduisant une vulnérabilité d'injection SQL pour être vulnérables. Qu'est-ce qui pourrait mal tourner ici? Quelques exemples:

1. L'hébergeur n'a pas mis à jour vers la dernière version PHP et les versions PHP utilisées se sont révélées vulnérables à SQLi en général.
2. L'hébergement L'entreprise a configuré des logiciels supplémentaires publics tels que phpMyAdmin et ne l'a pas mis à jour.
3. La version WordPress utilisée s'avère vulnérable à SQLi mais la mise à jour a été manquée ou il n'y a pas encore de correctif disponible.
4. Un plugin WordPress utilisé est vulnérable à SQLi.

Maintenant la question qui est soulevée , qui est responsable? Le supermarché, la société de développement Web, la société d'hébergement, la communauté WordPress, les développeurs de plugins WordPress ou l'attaquant qui a abusé de la vulnérabilité, rhétoriquement parlant? - Ce n'est pas une déclaration, c'est exagéré et juste quelques questions qui sont susceptibles d'être posées en cas de problème.

Souvent, la discussion ci-dessus (questions sur la responsabilité, bien que légèrement exagérées) est également un facteur de risque car certains développeurs ont tendance à avoir un "ce n'est pas mon code "-attitude . Vous pouvez imaginer à quel point cela complique parfois la situation.

Premièrement, personne n'écrit correctement les exigences de sécurité, ils disent quelque chose comme "Le produit doit être sécurisé", ce qui n'est en aucun cas testable

Deuxièmement, les développeurs de profession ne sont pas stupides, et le dire est plutôt malhonnête, ils sont tous susceptibles d'avoir des diplômes universitaires et ont résolu des problèmes que nous n'avons même pas commencé à rechercher ... Le problème est qu'ils n'ont jamais appris ce que signifie développer un logiciel en toute sécurité. Cela commence dans les écoles, puis à l'université, puis quel que soit le travail qu'ils occupent, où toute formation est «sur le tas» parce que les entreprises de logiciels ont trop peur de former des développeurs en cas de départ.

Les développeurs sont également sous la pression croissante de faire plus de travail en moins de temps, ils sont occupés à résoudre un problème et à passer au suivant, ils ont peu de temps pour réfléchir au prochain problème.

Les développeurs ne sont pas incités à tester au-delà de ce qu'ils sont en train de développer, s'ils trouvent un problème, ils seront probablement le développeur pour le résoudre. Le mantra du développeur ici est "Ne testez pas ce que vous n'êtes pas prêt à corriger"

Troisièmement, les testeurs sont également pas formé pour trouver des vulnérabilités de sécurité, pour la même raison que les développeurs de logiciels. En fait, de nombreux tests (à mon avis) consistent simplement à répéter les tests effectués par l'équipe de développement.

marché est un facteur énorme , si vous êtes sur le marché en premier, vous gagnez de l'argent, développer en toute sécurité est considéré comme ayant un grand impact sur la vitesse de développement - je veux dire vraiment, qui a le temps pour un modèle de menace! ;)

Enfin, il n'y a pas que des injections SQL, les débordements de tampon sont connus depuis les années 1960 et vous pouvez toujours les trébucher avec une régularité alarmante.

Oui, anthropologiquement, les humains sont stupides.

Oui, politiquement, la structure d'incitation ne pénalise pas suffisamment les candidatures vulnérables

Oui, le processus est défectueux - code est écrit à la hâte; le mauvais / ancien code n'est pas toujours jeté.

Et, oui, techniquement, traiter et mélanger les données comme du code est plus difficile à faire par défaut.

Mais, il y a une vue plus positive (ignorons les 99% de vulnérabilités SQLi que les réponses ci-dessus expliquent). SQLi existe toujours sur des sites Web extrêmement bien conçus et soigneusement développés car nous sommes géniaux . Règle des pirates. Il suffit de regarder les centaines de vecteurs d'attaque et les milliers de charges utiles SQLi qui ont été développés au cours des dix-sept dernières années pour regagner une certaine confiance dans la race humaine. Chaque année apporte avec elle de nouvelles techniques présentées DEFCON / BlackHat / RSA / IEEESSP. Les programmes de primes de bogues pour Facebook, Google et autres ont tous dû débourser au moins une fois pour un SQLi critique.

C'est en partie à cause de la complexité et du nombre de couches de notre système, chacune faisant muter les données de manière plus récente et plus intéressante. Nous avons de plus en plus besoin de faire plus, plus vite, en utilisant moins de ressources. Et tant que nous ne pouvons pas tester de manière réalisable tous les chemins d'accès au système, personne ne certifiera une solution aux problèmes d'injection.

Parce que ces problèmes de sécurité ne sont pas couverts pendant la plupart des cycles de formation de 3 ans et des études équivalentes, et de nombreux développeurs ont suivi cette piste (y compris moi-même). Compte tenu de l'ampleur du champ, 3 ans ne suffisent même pas pour faire face au programme d'études proprement dit. Des choses comme la sécurité sont donc abandonnées.

C'est malheureux, mais puisque certains des nouveaux développeurs ont gagné ' N'essayez jamais d'apprendre de nouvelles choses par eux-mêmes, ces personnes écriront toujours du code sujette à SQLi jusqu'à ce qu'un collègue plus instruit signale le problème (ou jusqu'à ce qu'un SQLi réel se produise).

Au cours de mes études (il y a de nombreuses années), nos professeurs nous ont toujours dit d'utiliser PreparedStatements lors de la création de requêtes SQL manuelles, car c'est la "meilleure pratique", mais ils n'ont pas dit pourquoi. C'est mieux que rien, mais plutôt triste, je ne sais pas si ces professeurs se connaissaient eux-mêmes.

Nous avons appris comment afficher des éléments sur un jsp, mais pas ce qu'est le Cross-Site-Scripting.

J'ai la "chance" d'être un développeur passionné avec un peu de temps dans mon mains, j'ai donc appris toutes ces choses par moi-même il y a longtemps, mais je suis sûr que de nombreux développeurs ne font que 8 heures par jour (pour des raisons légitimes d'ailleurs), et tant que personne ne leur montre quoi est faux, cela ne changera pas.

Si vous utilisez correctement les instructions préparées, l'injection SQL n'est pas possible.

"Si le modèle de déclaration d'origine n'est pas dérivé d'une entrée externe, l'injection SQL ne peut pas se produire."

https://en.m.wikipedia.org/wiki/ Prepared_statement

Malheureusement, les gens n'utilisent généralement pas correctement les instructions préparées, voire pas du tout.

L'injection SQL appartiendrait au passé s'ils le faisaient.

Et oui, php / MySQL a une implémentation de déclaration préparée depuis très longtemps, plus de 10 ans si ma mémoire est bonne ...

Les autres réponses ont indiqué presque toutes les raisons. Mais il y a autre chose, qui, à mon avis, est le problème de sécurité le plus dangereux de tous. Les développeurs tentent d'ajouter de plus en plus de fonctionnalités aux technologies et s'écartent parfois de l'objectif réel de la technologie. Un peu comme la façon dont un langage de script côté client a fini par être utilisé pour le codage côté serveur ou a été autorisé à accéder aux ressources distantes ainsi qu'au stockage local côté client.Au lieu de les superposer en tant que technologies distinctes, ils ont tous été placés dans un gros pot de miel. En examinant certaines des injections SQL avancées, nous pouvons voir comment elles ont joué un rôle dans l'accent constant des attaques SQLi.

Cependant, avec SQL, je suppose que la plus grande erreur était le couplage des commandes et des paramètres. C'est un peu comme appeler run (value, printf) au lieu de printf(value).

Oh et une dernière chose, alors que c'est assez facile à convertir entre différents types de bases de données, les changements requis dans le code côté serveur sont gigantesques.

Quelqu'un devrait faire des abstraits entre différents types de bases de données et faciliter le passage d'une base de données à l'autre. Dites un plugin php qui prend en entrée les commandes QL et le type de base de données, et peut être un filtre sur liste blanche pour nettoyer l'entrée.

Personnellement, je pense que c'est un cas spécifique d'un problème plus général de programmation, que les IDE et les langages sont trop permissifs. Nous donnons à nos développeurs un pouvoir immense au nom de la flexibilité et de l'efficacité. Le résultat est "ce qui peut arriver arrivera", et les défaillances de sécurité sont inévitables.

PDO (ou d'autres méthodes "sûres") n'est pas plus sécurisée que mysql_ (ou d'autres méthodes "non sûres"). Il est plus facile d'écrire du code sécurisé, mais il est encore plus simple de simplement concaténer les chaînes fournies par l'utilisateur non échappé dans la requête et de ne pas se soucier des paramètres.