3 leçons inspirées des Jedi pour renforcer la sécurité de JavaScript

Vous pensez peut-être que Star Wars est un film réservé aux geeks. Et si je vous disais qu’il renferme de profondes leçons de vie applicables aux pratiques de sécurité des développeurs ? Préparez votre sabre laser et plongez dans la sécurité JavaScript !

Star Wars est une saga épique de science-fiction écrite et réalisée par George Lucas, qui n’a souvent pas besoin d’être présentée. J’en suis moi-même fan et je me reconnais dans beaucoup de citations des chevaliers Jedi de la saga.

Comme vous l’avez sans doute deviné, je suis un grand admirateur du légendaire maître Jedi Yoda et je pense que nombre de ses enseignements sont de profondes leçons de vie — et de sécurité des applications.

« N’essaie pas. Fais-le, ou ne le fais pas. Il n’y a pas d’essai. » — Yoda, Star Wars, épisode V : L’Empire contre-attaque

Il peut parfois sembler intimidant de se lancer dans quelque chose de nouveau, surtout si cela sort un peu de votre zone de confort et de votre domaine d’expertise. La sécurité des applications peut vous donner cette impression, mais concentrez-vous sur le fait d’agir plutôt que de chercher la perfection.

Faut-il réaliser des revues de code sécurisé ou simplement effectuer des tests dynamiques de sécurité des applications ? Utiliser un workflow de développement avec des hooks préalables pour détecter les secrets, ou intégrer cette détection via une application GitHub ? Quels outils faut-il intégrer aux tests de sécurité de votre pipeline CI ?

Tant de questions ! C’est pourquoi j’aime cette citation de Yoda : « Fais-le, ou ne le fais pas. Il n’y a pas d’essai. » En matière de pratiques de codage sécurisé, tout commencement est un bon commencement. L’essentiel, c’est de multiplier les couches de sécurité (autrement dit, d’appliquer une défense en profondeur).

Voici quelques outils pratiques de sécurité JavaScript que vous pouvez intégrer dès aujourd’hui, sans difficulté :

1. Vous voulez détecter et neutraliser efficacement les attaques de type trojan source dans vos bases de code JavaScript avec ESLint ? Consultez le dépôt GitHub pour découvrir les instructions rapides d’installation et d’utilisation de eslint-anti-trojan-source, puis lisez notre article de blog pour comprendre pourquoi c’est important.

2. Vous utilisez régulièrement les fichiers lock de npm et de yarn, mais avez-vous pensé au fait que les fichiers lock de npm peuvent constituer un angle mort de sécurité permettant d’injecter des modules malveillants ? Découvrez le projet lockfile-lint et intégrez-le à vos outils de lint.

3. Avez-vous entendu parler de l’exfiltration de données d’entreprises du Fortune 500 par le biais d’une attaque de la chaîne d’approvisionnement open source appelée Dependency Confusion ? Intégrez snync à votre CI pour éviter ce type de problème.

4. Corriger les vulnérabilités de sécurité open source n’a jamais été aussi simple qu’avec Snyk. Lancez simplement la CLI Snyk avec npm install -g snyk, puis ajoutez une étape snyk test à vos scripts npm run. Importez vos dépôts GitHub dans l’interface Snyk pour recevoir rapidement des alertes sur les nouvelles vulnérabilités, bénéficier de l’analyse statique du code et analyser les fichiers manifest, ainsi que les projets Terraform, Kubernetes et les conteneurs Docker via le Dockerfile.

5. Et si vous receviez des informations sur les vulnérabilités de votre propre code, mais aussi de vos dépendances tierces ? L’extension Snyk pour les IDE vous permet de vérifier votre code au fur et à mesure que vous l’écrivez, pour intégrer la sécurité de façon efficace et fluide.

« Vos yeux peuvent vous tromper ; ne leur faites pas confiance. » — Obi-Wan Kenobi, Star Wars, épisode IV : Un nouvel espoir

Soyons honnêtes : programmer, c’est difficile. Écrire du code, c’est difficile. Lire du code, c’est encore plus difficile, mais c’est une compétence qui porte ses fruits à long terme, car vous lisez plus de code que vous n’en écrivez.

En tant que développeurs, nous avons appris à repérer certains schémas dans la logique et le style du code. Ils nous aident à en comprendre le sens et à remarquer les erreurs qui s’en écartent. Pourtant, nous oublions souvent de rechercher les schémas liés à la sécurité du code.

Ce manque d’analyse de sécurité a permis à certaines vulnérabilités de rester présentes pendant des années avant d’être repérées. La divulgation l’an dernier d’une vulnérabilité de gravité élevée dans le programme Linux sudo, identifiée sous le nom CVE-2021-3156, en est un parfait exemple. Cette vulnérabilité, qui permet une élévation de privilèges jusqu’au superutilisateur root via la commande sudoedit -s, se cachait à la vue de tous dans un projet open source populaire depuis dix ans avant d’être découverte.

Pour éviter ce genre d’oubli, voici quelques conseils pour renforcer la sécurité de vos projets JavaScript.

• Effectuez des revues de code sécurisé. Pour savoir sur quels aspects de votre base de code vous concentrer, consultez les 8 bonnes pratiques de revue de code de sécurité de Trisha Gee et Brian Vermeer.

• Si vous développez en Go, méfiez-vous des attaques par injection et des entrées utilisateur dangereuses. En complément de ces règles générales, lisez les conseils pratiques d’Eric Smalling et Gerred Dillion sur les bonnes pratiques de sécurité en Go pour découvrir d’autres astuces.

• Découvrez comment éviter les attaques par typosquattage, à l’origine de nombreux modules malveillants dans l’écosystème npm.

• Méfiez-vous des packages npm qui semblent très populaires, mais dont les indicateurs de santé sont mauvais. Par exemple, le client HTTP request pour Node.js, très populaire, totalise environ 20 000 000 de téléchargements par semaine. Cela pourrait vous laisser penser qu’il s’agit d’un choix fiable, mais son responsable l’a déclaré obsolète : le dernier commit et la dernière version remontent à deux ans. Utilisez Snyk Advisor pour en savoir plus sur les indicateurs de santé des packages et rester à jour.

« Difficile à voir, toujours en mouvement est l’avenir. » — Yoda, L’Empire contre-attaque

La sécurité des applications est une cible mouvante. Les logiciels évoluent rapidement, tout comme la recherche en sécurité, qui met au jour de nouvelles vulnérabilités. À mesure qu’un écosystème logiciel gagne en maturité et en popularité, les chercheurs en sécurité ont davantage de chances de s’y intéresser. L’écosystème npm de modules open source de JavaScript en est un bon exemple.

Pourquoi intégrer Snyk à votre dépôt Git ? Vous avez peut-être corrigé toutes les vulnérabilités de sécurité qui affectent aujourd’hui votre base de code, mais il est impossible de suivre tous les futurs CVE et toutes les nouvelles vulnérabilités. Heureusement, Snyk peut vous aider. Une fois votre dépôt de code source connecté à Snyk, il fait l’objet d’analyses quotidiennes qui vous alertent dès qu’une nouvelle vulnérabilité apparaît. Si un correctif est recommandé, Snyk ouvre automatiquement une pull request dans votre dépôt. Pour réduire le risque, il vous suffit d’examiner la modification du code et de la fusionner.

La pollution de prototype était rare il y a cinq ans. Aujourd’hui, pourtant, nous voyons souvent des projets JavaScript affectés par les caractéristiques d’héritage prototypique de la norme ECMAScript. Notre incapacité à prévoir les nouvelles vulnérabilités et le manque de temps libre compliquent le suivi des enjeux de sécurité. Heureusement, le centre de ressources Snyk Learn est là pour vous aider. Entièrement gratuit et sans inscription obligatoire, Snyk Learn propose exclusivement des leçons courtes sur les concepts de sécurité des applications. Vous pouvez même choisir des leçons en fonction de l’écosystème de langages de programmation que vous préférez, qu’il s’agisse de Java, JavaScript, Python ou d’autres langages.

Pour conclure, je vous souhaite un joyeux 4 mai, et que la Force soit avec vous !