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


39

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?


37
blâmez-le sur des tutoriels en ligne mal écrits. le plus souvent, il suffit de copier / coller le code trouvé sur le net. JavaScript est également une autre victime de cette pratique.
KJYe.Name

34
Blame les blogs. Oh, et W3Schools ...
Brian Driscoll

13
Oui, absolument W3Schools - voir w3fools.com
DisgruntledGoat

2
Je vois constamment des gens mettre en garde contre l'injection SQL - donc je ne pense même pas que la prémisse de cette question est valable. Il est une grande priorité.
GrandmasterB

3
Ce que je vois dans beaucoup de réponses, c'est qu'il est plus facile d'enseigner un PHP critiqué de manière critique que de le faire, eh bien, un PHP qui ne l'est pas de manière critique. Vous ne pouvez pas accepter cet argument et prétendre toujours que PHP n'est pas un mauvais langage
user16764

Réponses:


34

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.


8
J'ai essayé de corriger de telles choses ailleurs, mais on m'a dit que ce n'était pas pertinent pour le problème à résoudre. Donc, parce que beaucoup de gens préfèrent un simple hack à une bonne solution légèrement plus complexe, les mauvais exemples sont laissés de côté.
l0b0

6
La plupart des gens ne s’intéressent pas vraiment à l’injection SQL tant qu’ils ne sont pas touchés. Puis tout à coup, ils se demandent où sont allés leurs tables.
Joel Etherton

1
L'autre raison est que l'injection SQL n'est pas toujours considérée comme une préoccupation pertinente pour les applications internes. (Pas qu'ils ont raison.)
John Fisher

1
N'oubliez pas que les réponses sont là pour répondre à la question. Ce sont souvent des pseudo-codes (ou SQL) destinés à répondre à la question, pas nécessairement à fournir une solution de copier-coller sûre et sécurisée (malgré la manière dont la réponse peut être utilisée dans la réalité).
Dalin Seivewright

1
@ l0b0 Je connais quelqu'un qui a poussé les gens à prendre au sérieux les correctifs d'injection SQL en démontrant réellement une attaque par injection SQL contre le code de production actuel.
user16764

26

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.


Comme vous l'avez dit, le problème n'est pas perl ou PHP, c'est que ces langages permettent aux débutants de faire beaucoup de choses, ce qui est bien, mais ne fournit pas toujours les moyens de les faire aussi clairement.
Zachary K

2
@ZacharyK: N'est-ce pas cela la faute de la langue par défaut?
Courses de légèreté avec Monica

6
@ tomalak-geretkal: Vous utilisez le mot "faute" comme si permettre de faire des choses est une mauvaise chose. Les mêmes caractéristiques qui conduisent à beaucoup de mauvais codes entraînent également de nombreux problèmes réels résolus. Il n'est pas clair que c'est une mauvaise chose dans l'ensemble.
mardi

Re 'fault': si HTML (ou plutôt les navigateurs l’interprétant) avaient été aussi tolérants aux fautes que XSL, il n’aurait jamais existé de toile mondiale ...
Benjol

8

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".


4

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


2

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 n'ai rien dit sur "tous les programmeurs PHP".
Courses de légèreté avec Monica

2

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

c'est plus ou moins la façon dont on m'a enseigné php +1
Rémi

1

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.


6
Cela ne devrait pas être un aparté. Cela devrait faire partie de la leçon de base. Peut-être avec un gros, gros, mettant en garde sur la mauvaise façon de faire les choses. Les gens ont tendance à couper et coller ce qu'ils voient en premier, et vous voulez vraiment que ce soit la bonne façon de faire les choses.
mardi

Certes, dans le monde .NET, le paramétrage est assez simple de nos jours et devrait en fait être du type "page un".
Alan B

1

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.


5
Il est certainement possible de sur-concevoir des sites avec des frameworks complexes dont vous n’avez simplement pas besoin. Je dirais que les suggestions de Rasmus sont à la limite du dangereux, mais il y a définitivement un juste milieu.
Courses de légèreté avec Monica

De nos jours, utiliser ORM n’est pas trop technique; c'est standard. Il en va de même pour le modèle MVC.
vartec

3
@vartec: Il est à peine « standard » juste parce que tous les moutons utilisent (et, pour ce que ça vaut, même pas tous les moutons sont l' utilisent). Pour de petits scripts, cela peut facilement être une ingénierie excessive.
Courses de légèreté avec Monica

1
@Tomalak: c'est la norme, car c'est la manière de mettre en œuvre des projets propres et durables. Les "petits scripts" ont tendance à se développer avec le temps et à se transformer en monstruosités non maintenues.
vartec

2
@vartec: Je pense que vous avez mal compris le sens du mot "standard".
Courses de légèreté avec Monica

1

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


2
À un moment donné, toutes les variables étaient échappées comme si elles utilisaient spécifiquement MySQL, qu’elles l’aient été ou non . Note aux concepteurs de langages: lorsque vous vous trouvez devant une implémentation stripslashes(), vous vous êtes déjà trompé.
Dan Ray

0

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.


3
Désolé, mais aucun exemple de code ne devrait jamais mélanger des requêtes mySQL avec PHP. C'est tout simplement mal faire.
Raynos

1

-1 pour most tutorial code I have written has little or no error/exception checking..
Yannis

Je peux voir le point de l'OP. Irresponsable est, quand un employeur embauche un gars qui manque de connaissances sur l'injection SQL et similaires.
Raffael

Je pense que cette approche est défendable si vous incluez directement dans le code des commentaires disant "Ne l'utilisez pas en production!". De cette façon, le copieur / pasteur n'a aucune excuse.
Benjol

-1

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?


2
Toutefois, lorsque vous enseignez la langue, vous devez toujours utiliser les API préférées dans vos exemples. Comme toujours, utilisez la forme paramétrique des requêtes SQL, éventuellement avec une note de bas de page du type "Ne pensez jamais à utiliser l’interpolation pour construire SQL à la place. Cela semble un peu plus facile, mais il est extrêmement sujet aux vulnérabilités en matière de sécurité."
Jan Hudec

Oui, bons points. Les notes de bas de page seraient un bon rappel, et cela vaut également pour les tutoriels en ligne. Sérieusement, il serait bien que les auteurs de livres de toutes les langues puissent incorporer les conseils de l'OWASP dans les textes pour débutants. Même à titre de référence. La Fondation OWASP fait du bon travail.
Steve Rathbone

@indifferentDrum: Vous pouvez aussi apprendre aux gens à conduire avec les pieds - cela ne veut pas dire que c'est une bonne idée.
Courses de légèreté avec Monica
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.