L’insécurité induite par l’exemple illustre la nécessité du WAF

Apprendre en ligne est une chose importante. Surtout pour ceux qui s’identifient comme développeurs. Si vous jetez un œil à l'enquête annuelle de Stack Overflow auprès des développeurs (dans laquelle ils reçoivent des dizaines de milliers de réponses), vous constaterez qu'une bonne partie des développeurs ne sont pas formellement formés :

• Parmi les développeurs professionnels actuels à l’échelle mondiale, 76,5 % des répondants ont déclaré avoir un baccalauréat ou un diplôme supérieur, comme un master ou un équivalent.
• 20,9 % ont déclaré avoir choisi d’autres domaines comme le commerce, les sciences sociales, les sciences naturelles, l’ingénierie non informatique ou les arts.
• Parmi les développeurs professionnels actuels, 32 % ont déclaré que leur formation formelle n’était pas très importante, voire pas du tout importante, pour leur réussite professionnelle. Cela n’est pas entièrement surprenant étant donné que 90 % des développeurs se considèrent au moins quelque peu autodidactes : un diplôme officiel n’est qu’un aspect de leur formation, et une grande partie de leur travail pratique au quotidien dépend des décisions individuelles de leur entreprise en matière de pile technologique.

Notez la partie surlignée des résultats de l’enquête. Je pourrais écrire une thèse expliquant pourquoi c’est vrai, mais il suffit de dire que lorsque j’étudiais pour ma licence, j’écrivais en Pascal, C++ et LISP. Mon premier vrai travail de développeur nécessitait du C/C++, donc j'étais bon là-dedans. Mais plus tard, on m’a demandé d’apprendre Java. Et SQL. Je ne suis pas retourné à l’école pour faire ça. Je me suis tourné vers des livres, des fichiers d’aide et toute autre documentation sur laquelle j’ai pu mettre la main. L’autodidacte est la norme, que vous ayez suivi une éducation formelle ou non, car la technologie évolue et les professionnels n’ont pas le temps de retourner à l’école simplement pour apprendre un nouveau langage ou un nouveau cadre.

Ce n’est pas du tout inhabituel pour aucun d’entre nous, je suppose. Nous ne retournons pas à l’école pour apprendre une nouvelle interface de ligne de commande ou une nouvelle API. Nous ne nous inscrivons pas à un nouveau diplôme juste pour apprendre Python ou Node.js. Nous nous tournons vers les livres et le contenu sur Internet, vers les communautés, et nous nous appuyons largement sur le « code d’exemple ».

Je m’appuie toujours sur les blogs et la documentation, non seulement de nos propres ingénieurs et architectes, mais aussi d’autres personnes. Parce que m'inscrire à un doctorat maintenant ne va pas vraiment m'aider à apprendre* les tenants et aboutissants du framework Express ou de JQuery .

Il n’est donc pas surprenant que les ingénieurs et les opérateurs réseau (qui, faisant partie de la première partie de la deuxième vague de DevOps, seront désormais connus sous le nom de NetOps) soient également susceptibles de se tourner vers les mêmes types de supports pour acquérir les compétences dont ils ont besoin pour maîtriser les outils et les technologies requis. Ce sont des langages de script et des API, pour ceux qui viennent de se connecter. Et eux aussi vont sans doute copier et coller avec enthousiasme à mesure qu'ils se familiariseront avec le langage et les systèmes pour commencer à automatiser le pipeline de production .

Et nous en arrivons ainsi à la raison pour laquelle j’écris aujourd’hui. Exemple de code.

Il y en a beaucoup. Et c'est du bon code, ne partez pas en pensant que je ne suis pas reconnaissant ou que je n'apprécie pas les exemples de code. C'est une ressource inestimable pour quiconque essaie d'apprendre de nouveaux langages et API. Ce que je vais grogner, c'est qu'il y a un décalage entre l'exemple de code et la sécurité qui doit être résolu. Parce que lorsque nous enseignons le codage à de nouveaux arrivants, nous devrions également leur inculquer au moins une conscience de la sécurité, plutôt que de l'ignorer de manière flagrante.

Je dis cela parce que la sécurité des applications n’est pas – je répète, PAS – facultative . Je pourrais lancer statistique après statistique après statistique, mais j'espère qu'à ce stade je prêche des convertis. La sécurité des applications n’est pas facultative et il est important de promouvoir cette attitude jusqu’à ce qu’elle soit considérée comme faisant partie intégrante du développement. Il ne s’agit pas seulement d’applications, mais également de scripts et de systèmes qui pilotent l’automatisation au bout des doigts de DevOps et de NetOps.

Je présente comme source de mon angoisse cet exemple. 

Le code lui-même est magnifique. Vraiment. Bien formaté, bel espacement. Lisible. J'adore ce code. Sauf la partie qui viole complètement la règle de sécurité zéro .

TU NE FERAS PAS CONFIANCE AUX INFORMATIONS DES UTILISATEURS. JAMAIS.

Je suis déçu qu’il n’y ait même pas un hochement de tête indiquant la nécessité de nettoyer les entrées. Ni dans les commentaires ni dans le texte de l’article. Le code transmet simplement le « nom d’utilisateur » à une autre fonction sans se soucier du fait qu’il puisse contenir du contenu malveillant.

Mais Lori, il est évident que ce code est destiné à illustrer l’implémentation de quelque chose qui n’est pas conçu pour être réellement mis en production. Ce n’est pas un risque.

Là n’est pas la question. Le fait est que si nous continuons à enseigner aux gens à coder, nous devrions au moins essayer de leur apprendre à le faire en toute sécurité . Pour le mentionner aussi régulièrement que l'on fait remarquer aux développeurs novices en C/C++ que si vous n'allouez pas de mémoire à un pointeur avant d'y accéder, il va planter.

Je pourrais remplir blog après blog d’exemples de la façon dont la sécurité et le SDLC sont considérés comme des sujets de conversation, mais quand il s’agit de passer aux choses sérieuses et d’apprendre aux gens à coder, ils se retrouvent soudainement seuls dans un coin avec un champ SEP (le problème de quelqu’un d’autre) autour d’eux.

C'est une autre raison pour laquelle les pare-feu application Web sont un élément essentiel de toute stratégie de sécurité des applications. Les organisations ont besoin d’un pare-feu entre les saisies des utilisateurs et les applications qui les acceptent aveuglément comme légitimes pour éviter de devenir la dernière victime d’une longue liste de failles de sécurité des applications.

Car même si nous aimons parler de la sécurisation du code, lorsque nous l’enseignons aux autres, nous ne le faisons pas. Nous devons être plus conscients de ce manque d’attention à la sécurité – même dans les exemples de code, car c’est là que les développeurs (et de plus en plus NetOps) apprennent – mais en attendant de commencer à le faire, nous avons besoin de solutions de sécurité comme WAF pour combler les lacunes laissées par le code non sécurisé.
 

* Ou anglais, apparemment. Oh allez, je le fais exprès. Parce que parfois, c’est amusant de le dire de travers.