L’insécurité mise en évidence par des exemples illustre la nécessité d’un WAF

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

L’apprentissage en ligne occupe une place importante, en particulier chez les personnes qui se considèrent comme des développeurs. Si vous jetez un œil à l’enquête annuelle de Stack Overflow auprès des développeurs (qui recueille des dizaines de milliers de réponses), vous constaterez qu’une bonne partie des développeurs n’ont pas suivi de formation officielle :

• Parmi les développeurs professionnels actuellement en activité dans le monde, 76,5 % des personnes interrogées ont déclaré être titulaires d’une licence ou d’un diplôme de niveau supérieur, tel qu’un master ou un diplôme équivalent.
• 20,9 % ont déclaré avoir étudié dans d’autres domaines, tels que le commerce, les sciences sociales, les sciences naturelles, les disciplines d’ingénierie autres que l’informatique ou les arts.
• Parmi les développeurs professionnels actuellement en activité, 32 % ont déclaré que leur formation initiale avait peu ou pas du tout contribué à leur réussite professionnelle. Ce constat n’est pas vraiment surprenant, sachant que 90 % des développeurs se considèrent globalement comme au moins en partie autodidactes : un diplôme ne constitue qu’un aspect de leur formation, et une grande partie de leur travail pratique au quotidien dépend des choix technologiques propres à leur entreprise.

Notez la partie mise en évidence dans les résultats de l’enquête. Je pourrais écrire une thèse pour expliquer pourquoi il en est ainsi, mais disons simplement que, pendant mes études de licence, je programmais en Pascal, C++ et LISP. Mon premier véritable poste de développeur exigeait de maîtriser le C/C++, donc, de ce côté-là, tout allait bien. Mais par la suite, j’ai dû apprendre Java. Et SQL. Je ne suis pas retourné à l’université pour cela. Je me suis tourné vers des livres, des fichiers d’aide et toute autre documentation que je pouvais trouver. L’apprentissage en autodidacte est la norme, que l’on ait suivi une formation académique ou non, car les technologies évoluent et les professionnels n’ont pas le temps de retourner à l’université simplement pour apprendre un nouveau langage ou framework.

Je pense que cela n’a rien d’inhabituel pour aucun d’entre nous. Nous ne retournons pas à l’école pour apprendre à utiliser une nouvelle interface en ligne de commande ou une nouvelle API. Nous ne nous inscrivons pas à un nouveau cursus diplômant simplement pour apprendre Python ou Node.js. Nous nous tournons vers les livres, les contenus disponibles sur Internet et les communautés, et nous nous appuyons largement sur des « exemples de code ».

Je continue de m’appuyer sur des blogs et de la documentation, provenant 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 les aboutissants du framework Express ou de JQuery.

Il n’est donc pas surprenant que les ingénieurs réseau et les équipes d’exploitation (qui, en tant que parties prenantes de la deuxième vague du DevOps, seront désormais désignés sous le nom de NetOps) se tournent eux aussi vers les mêmes types de ressources pour acquérir les compétences nécessaires à la maîtrise des outils et technologies requis. Pour ceux qui nous rejoignent, il s’agit des langages de script et des API. Eux aussi feront sans doute des copier-coller à tout-va à mesure qu’ils se familiariseront avec le langage et les systèmes, commençant ainsi à automatiser le pipeline de production.

Nous en arrivons donc à la raison pour laquelle j’écris aujourd’hui : les exemples de code.

Il y en a beaucoup. Et c’est du bon code : ne partez pas en pensant que je manque de reconnaissance ou que je n’accorde aucune valeur aux exemples de code. Ils constituent une ressource inestimable pour quiconque cherche à apprendre de nouveaux langages et de nouvelles API. Ce qui me fait grogner, c’est le décalage entre les exemples de code et la sécurité, auquel il faut remédier. Car lorsque nous apprenons à coder aux débutants, nous devrions aussi leur inculquer au moins une certaine sensibilisation à la sécurité, plutôt que de l’ignorer ouvertement.

Je dis cela parce que la sécurité des applications n’est pas – je répète, PAS – facultative. Je pourrais citer des statistiques à n’en plus finir, mais j’espère qu’à ce stade, je prêche des convaincus. La sécurité des applications n’est pas facultative, et il est important de diffuser cette conviction jusqu’à ce qu’elle soit considérée comme faisant partie intégrante du développement. Cela vaut non seulement pour les applications, mais aussi pour les scripts et les systèmes qui permettent aux équipes DevOps et NetOps de piloter l’automatisation.

Voici l’exemple qui est à l’origine de mon inquiétude.

Le code lui-même est magnifique. Vraiment. Bien formaté, bien aéré. Lisible. J’adore ce code. À l’exception de la partie qui enfreint totalement la Règle de sécurité zéro.

TU NE FERAS JAMAIS CONFIANCE AUX DONNÉES SAISIES PAR L’UTILISATEUR. JAMAIS.

Je suis déçu qu’il n’y ait même pas la moindre allusion à la nécessité d’assainir les données saisies. Ni dans les commentaires, ni dans le texte de l’article. Le code se contente de transmettre « username » à une autre fonction sans se soucier un seul instant du fait que cette valeur puisse contenir du contenu malveillant.

Mais Lori, ce code est évidemment destiné à illustrer la mise en œuvre de quelque chose qui n’est pas conçu pour être réellement mis en production. Il n’y a donc aucun risque.

Ce n’est pas la question. La question est que si nous continuons à apprendre aux gens à programmer, nous devrions au moins essayer de leur apprendre à le faire de manière sécurisée. Il faudrait le mentionner aussi systématiquement que l’on explique aux développeurs qui débutent en C/C++ que s’ils n’allouent pas de mémoire à un pointeur avant d’y accéder, le programme va planter.

Je pourrais remplir des blogs entiers d’exemples montrant à quel point la sécurité et le cycle de vie du développement logiciel ne sont pris en compte que pour la forme ; mais dès qu’il s’agit de passer aux choses sérieuses et d’apprendre aux gens à programmer, la sécurité se retrouve soudain seule dans son coin, entourée d’un champ SEP (« problème de quelqu’un d’autre »).

C’est une raison de plus pour laquelle les pare-feu d’applications web constituent un élément essentiel de toute stratégie de sécurité applicative. Les organisations ont besoin d’une barrière de protection entre les saisies des utilisateurs et les applications qui les acceptent aveuglément comme légitimes, afin d’éviter de devenir les dernières victimes d’une longue liste de failles de sécurité applicative.

Car même si nous aimons parler de la sécurisation du code, lorsque nous l’enseignons concrètement aux autres, nous ne joignons pas le geste à la parole. Nous devons prendre davantage conscience de ce manque d’attention porté à la sécurité, y compris dans les exemples de code, car c’est ainsi que les développeurs (et, de plus en plus, les équipes NetOps) apprennent. Mais tant que nous n’aurons pas changé nos pratiques, nous aurons besoin de solutions de sécurité telles que les WAF pour combler les lacunes laissées par un code non sécurisé.

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

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie