Pourquoi la protection contre l'injection SQL n'est-elle pas une priorité?

Sur Stack Overflow, je vois beaucoup de code PHP dans les questions et réponses contenant des requêtes MySQL extrêmement vulnérables aux attaques par injection SQL, bien que les solutions de contournement de base soient largement disponibles depuis plus de 10 ans.

Y a-t-il une raison pour laquelle ces types d'extraits de code sont encore utilisés aujourd'hui?

Je pense que cela est principalement dû à a) l'ignorance b) la paresse. Les débutants ne savent généralement pas grand chose à propos de l'injection SQL, et même quand ils en entendent parler, ils l'ignorent car c'est tellement plus simple et plus facile à coder de cette façon.

PHP facilite délibérément la tâche des personnes qui savent très peu créer des pages Web dynamiques et utiles. Cela signifie que PHP va attirer un grand nombre de débutants, qui créent quelque chose d'utile, tirent des enseignements d'autres exemples utiles et se tournent pour apprendre aux autres comment faire cette chose cool et utile. Le résultat est beaucoup de mauvais code et une réserve de programmeurs qui ne connaissent pas mieux.

Cela ne fait qu'aggraver les choses qu'une grande partie des programmeurs compétents ne veulent rien avoir à faire avec PHP. Cela réduit le nombre de personnes expérimentées disposées à mieux enseigner aux autres. Mais pourquoi évitent-ils PHP? Bien pour une combinaison de facteurs. En partie, ils n'aiment pas traiter avec les verrues linguistiques. Et c’est en partie parce qu’ils préféreraient travailler avec un bon code et qu’il n’existe pas beaucoup de PHP de qualité.

Cette constellation exacte de problèmes infligeait Perl. Prenons comme exemple probant le cas de Matt Wright, un adolescent enthousiaste qui a entrepris de fournir de nombreux scripts utiles, bien documentés et faciles à installer dans les années 1990. Malheureusement, il ne comprenait rien à la sécurité, pas plus que les personnes qui souhaitaient utiliser ses affaires. Le résultat fut les archives de script de Matt Wright, qui constituaient un flot incessant de problèmes de sécurité pour les premiers scripts CGI. Malgré des efforts tels que http://www.scriptarchive.com/nms.html , le problème ne s'est pas amélioré pour Perl jusqu'à ce que les fournisseurs d'hébergement mutualisé rendent PHP plus pratique qu'autre chose. Cela a conduit au problème de passer de Perl à PHP.

Malheureusement, il existe des tonnes de tutoriels PHP plus que médiocres et certains livres PHP plus anciens ont aussi du mal à dire aux gens d'écrire du code correct (sans utiliser register_globals, etc.).

De plus, avec l' magic_quotes_gpcactivation antérieure, les gens ne se souciaient pas de s'échapper parce que "ça marchait tout simplement".

Personnellement, je pense que PHP est facile à utiliser, donc naturellement, il est facile à utiliser.

En tant qu'humain et programmeur, je trouve remarquablement facile de faire des erreurs et d'oublier certaines choses, en particulier lorsque le temps presse.

Il est facile, et peut-être trop tentant, de reprocher à un certain langage d'être trop accessible pour son propre bien. Mais ce serait dissimuler le problème plus vaste de la faillibilité humaine, quelle que soit la langue choisie pour programmer.

Certes, nous avons parcouru un long chemin depuis le langage assembleur, et je pense que je serais bien plus productif dans un langage plus moderne, tel que PHP, Python, Ruby ou Java.

PHP (et d'autres langages de script) ont en fait réduit la barrière à l'entrée. Cela peut signifier que plus de nouveaux venus en programmation essaient d'abord PHP. Mais cela ne signifie certainement pas non plus que tous les programmeurs PHP sont en quelque sorte moins qualifiés ou moins en mesure d'apprendre de leurs erreurs que les programmeurs d'autres langages.

Rasmus Lerdorf a créé PHP dans sa forme originale en 1994, il a considérablement évolué depuis. Dans sa version la plus moderne, il prend en charge la programmation orientée objet, ainsi que de superbes frameworks, tels que Symfony. PHP en tant que langage s'est libéré de ses contraintes d'origine et s'est développé pour offrir une grande flexibilité dans la manière dont les programmeurs peuvent choisir de l'utiliser. Vous pouvez l'utiliser pour créer un script de code spaghetti de 9 000 lignes, ou dans le contexte d'un framework MVC moderne, tel que Symfony: à vous de choisir!

Je soupçonne fortement que les vulnérabilités de sécurité ne se limitent pas à une seule langue. Il est tentant d'écrire tous les programmeurs PHP comme moins capables, ou plus enclins à écrire du code non sécurisé. Mais je me demande dans quelle mesure cela constitue un préjugé linguistique et dans quelle mesure est-il un fait?

Je pense qu'une partie du problème réside dans les personnes qui copient simplement du code sans se préoccuper d'apprendre ce qu'elles sont en train de faire, mais je pense vraiment que la façon dont nous enseignons le porgamming est cassée et que c'est l'une des raisons pour lesquelles il y a tant de mauvais code. Nous enseignons la syntaxe hors contexte et les débutants ne savent donc pas quand utiliser quelque chose ou non, ni quels problèmes la syntaxe est censée résoudre et quels problèmes ne sont pas censés résoudre. Ils utilisent donc un marteau quand une clé aurait été le meilleur outil.

Ainsi, par exemple, au lieu d'enseigner uniquement la syntaxe, vous organisez le cours de la manière suivante:

1. Voici comment vous configurez une page Web de base
2. Voici comment vous faites que la page Web extrait les données d'une base de données
3. C’est ainsi que vous envoyez des données d’une page Web à une base de données
4. Voici comment vous vous assurez que les bonnes données sont envoyées.
5. Voici comment vous protégez votre base de données contre la saisie de données malveillantes

Je pense que vous trouverez une quantité similaire d’exemples MS SQL + ASP / ASP.NET qui sont tout aussi vulnérables.

Je pense que le problème provient en partie du fait que lorsque vous essayez d'enseigner quelque chose, filtrer des données à l'aide d'une clause WHERE, vous ne voulez vraiment pas encombrer votre exemple en échappant correctement à votre chaîne de requête ou en utilisant une commande paramétrée.

Je forme des développeurs depuis de nombreuses années et je peux comprendre les personnes qui écrivent du code horrible dans des tutoriels. Parfois, c'est le plus facile à comprendre. Cependant, je signale toujours le code vulnérable et en fait un sujet secondaire intéressant.

L'auteur original de PHP, Rasmus Lerdorf , dans son tristement célèbre billet de blog, préconise le développement "sans cadre" . Bien qu'il utilise PDO pour les requêtes SQL, il n'y a donc aucun risque d'injection SQL. Encore assez moche et obsolète par rapport aux frameworks MVC modernes avec des couches ORM.

Vous pouvez imputer cette mauvaise pratique à PHP lui-même. Les anciennes versions de PHP (jusqu’en 2006 environ) échappaient à toutes les variables d’entrée GET et POST, de sorte qu’elles étaient adaptées à l’interpolation de requêtes de base de données BY DEFAULT. Voir http://php.net/manual/en/security.magicquotes.php

Ne confondez pas l'objectif d'un didacticiel, qui consiste à illustrer quelque chose simplement, avec ce qui devrait être fait dans un environnement de production. Par exemple, la plupart du code de tutoriel que j'ai écrit ne contient que peu ou pas de vérifications d'erreur / exception. J'essaie de rappeler au lecteur que le code montre uniquement comment effectuer une tâche spécifique et non comment couvrir tous les résultats possibles.

Quand j’apprenais PHP, j’ai jeté un œil à ces livres PHP + MySQL et, oui, j’ai l’impression que cela contribue à cette mauvaise pratique. Mais j'ai de la sympathie, car ils enseignent la langue , pas de bonnes pratiques de programmation. Sinon, où cela finirait-il?