Interview de Thomas Gentilhomme - Ecosystème Node et sécurité
Interview menée par Romy Alula, Développeuse chez CodeWorks, pour le hors-série#8 100% Sécurité de Programmez
Interview menée par Romy Alula, Développeuse chez CodeWorks, pour le hors-série#8 100% Sécurité de Programmez
La sécurité dans les écosystèmes JavaScript et Node.js est un enjeu primordial. Pendant la rédaction de l’article “Comment sécuriser son application Javascript en 2022?”, je me suis intéressée à Node Secure entre autres initiatives. J’ai rencontré Thomas Gentilhomme dans le cadre d’un atelier technique individuel qu’il proposait sur LinkedIn. À cette occasion, j’ai rejoint le serveur Discord de l’ES Community.
En plus d’être mainteneur de Node Secure, il est aussi membre du Node Security Working Group.
Thomas est expert Node.js. Développeur indépendant, il a plus de 300 projets en tous genres à son actif : 50 à 100 en production, 5 ou 6 gros projets représentants des milliers d’heures de développement. Il est également le mainteneur principal de SlimIO, contributeur de Node-Secure, et membre du Node.js Security Working Group.
Avec presque 7 ans d’expérience professionnelle, Thomas développe depuis l’âge de 10 ans. Il a arrêté ses études à 16 ans pour donner vie à ses projets, comme dans une startup. La majorité d’entre eux se sont soldés par “des échecs” qui lui ont beaucoup apporté. Dès son entrée sur le marché du travail, il a commencé à avoir des responsabilités. Avec le recul, il réalise qu’il n’a donc pas réellement eu le temps d’être “junior”.
Thomas Gentilhomme (T.G.) : C’est un groupe de travail réellement focalisé sur l’écosystème Node.js mais aussi sur Javascript.
Son objectif est d’éduquer, évangéliser sur les bonnes pratiques. Très présent dans les communautés, le Node Security WG aide les mainteneurs de packages et les accompagne. C’est ce que j’essaie de faire, à titre personnel, au niveau francophone.
La liste des missions est large :
Puisque ça concerne l’écosystème, il faut faire preuve de créativité, d’inventivité. C’est de l’open-source, libre à chacun d’arriver avec des idées, des suggestions d’amélioration. On peut discuter, se mettre d’accord, et faire les choses tous ensemble.
Un autre aspect consiste au triage des issues sur HackerOne.
Sur la plateforme dédiée, les membres de la communauté rapportent les vulnérabilités et failles de sécurité repérées dans les packages. Le tout sera traité par des collaborateurs d’HackerOne. Faute de temps, cette plateforme n’est plus très active. Dans le WG, on en a discuté. C’est ce qui va peut-être passer sur OpenJS pour des questions de financement. Ce ne sont pas forcément mes sujets. Je sais qu’ils avaient évoqué le fait qu’il faudrait une personne qui travaille dessus à temps plein, ce qui représente un budget. Il est probable qu’à l’avenir il y ait une collaboration entre Node.js et OpenJS.
La liste des responsabilités des membres du groupe se trouve au début du README du repo git. Chacun a son spectre de compétences, son expertise et intervient selon ses disponibilités.
Pour la sécurité dans Node.js, ce sont les contributeurs core de Node.js qui la prennent en charge. Généralement, ils font partie des 2 groupes. Il arrive qu’ils nous tagguent et nous demandent notre avis. Les releases de sécurité sont vraiment décorrélées des interventions du WG.
T.G. : J’ai été accepté le 28 septembre 2020, après un délai d’environ 3 mois. La validation a pris du temps, faute de réunions pendant de longs mois. Année 2020 oblige.
T.G. : Depuis plusieurs années, plus sérieusement depuis quelques mois. Je suis leurs meetings qui sont ouverts au public. Il existe plusieurs groupes : Node-API, core, next-10... Le Security WG se réunit tous les mois. Les rediffusions sont disponibles sur la chaîne officielle de Node.js.
Je leur ai présenté Node Secure. Ça faisait déjà 3 ou 4 ans que j’étais sur le Slack, et je connaissais déjà la plupart des membres du groupe.
J'ai immédiatement senti que je pouvais apporter une plus value. J'ai une très haute estime du niveau de compétences des membres de ce groupe de travail et c’est Vladimir, l’un des seuls membres francophones, qui m’a encouragé à déposer ma candidature :
(habituellement, la nomination ne peut être demandée que par soi-même ou un ou plusieurs membre(s) du groupe. cF lien : https://github.com/Nodejs/security-wg/issues/678
L’effectif actuel : une dizaine d’actifs internationaux sur 18 au total (liste github) : ce qui entraîne une complexité en termes d’organisation.
Depuis septembre 2020, seuls 2 ou 3 meetings ont eu lieu et une réorganisation est en cours afin de permettre à davantage de personnes d’y participer. La COVID ayant fortement impacté la contribution et la fréquentation des meetings. D’autre part, le fait de devoir consacrer beaucoup de temps à mes projets pros a drastiquement réduit celui dédié à l’open-source.
T.G. : J’interviens peu sur les issues et me suis principalement spécialisé dans l’analyse statique. Je ne me considère contributeur que lorsque j’apporte une réelle contribution.
Encore une fois, j’ai beaucoup d’estime pour les personnes avec lesquelles je travaille : Elles font partie des meilleurs devs de classe mondiale ! Ce sont des gens très humbles qui m'impressionnent beaucoup. J’ai rarement l’habitude de ressentir de la pression ou de galérer techniquement sur des sujets, c’est donc incroyable de pouvoir travailler avec eux ! En effet, quand tu as en face de toi des gens qui ont contribué pendant 5 ou 6 ans à un aboutissement concret, tu as tendance à relativiser les quelques lignes de codes que tu as rédigées. À l’heure actuelle, il y a des sujets auxquels je ne participe pas parce qu’ils ne font pas partie de mon domaine d’expertise. Je ne considère pas mon intervention comme une réelle contribution pour le moment. Mes compétences sont tellement spécifiques que je ne peux pas intervenir ou donner mon avis sur tous les sujets.
À mon échelle, je contribue à la sécurité de l’écosystème avec Node Secure ou encore mon document rendu public (Devenir un(e) développeur(se) Node.js).
Quand tu travailles avec des virtuoses, tu as juste envie de t’impliquer encore plus, toujours plus. Ce qui est difficile, à ce niveau-là, c’est que c’est beaucoup de sacrifices. Tu n’en retires pas grand chose, à l’instant T. Là, tu es vraiment dans la passion et le sacrifice. Ce sont des centaines d’heures de travail (rémunérées ou non). Or parfois, cette charge de travail investie par certains développeurs peut représenter des dizaines de millions d’euros, en termes d’impact.
Quand tu fais de l’open-source. Mieux vaut être solide. Tu peux te faire bouffer si t’es un peu fragile et que le succès arrive. Il y a beaucoup de choses néfastes qui viennent avec. Certains ne sont pas préparés à ça. Personnellement, je ne prends à cœur ni les retours négatifs, ni les positifs. Mais quand tu commences à y prêter attention, c’est là que ça commence à te détruire. Il faut juste savoir prendre de la distance. Par exemple, avec l’expérience, on apprend à déprécier (`deprecated`) certains aspects de la codebase.
Au final, certains tombent parfois en dépression, après avoir travaillé pendant des années sur un sujet. Par exemple, quand, en tant que mainteneur, tu n’as plus ni la force, ni l’envie, ni le temps, il faut savoir arrêter de maintenir ta solution. Parfois, la communauté ne juge que la finalité, sans regarder la masse de travail abattu. Ce sont des gens à qui on doit beaucoup, dans la communauté et l’écosystème Node. Après, la vie te le rendra toujours, en tant que développeur. Il y a des entreprises qui te sollicitent. Tes compétences sont reconnues par tes pairs, tu gagnes en légitimité. Par exemple, aujourd’hui, on ne me demande plus, systématiquement, mon CV (NDLR : et heureusement :)).
Actuellement dans le WG, et en raison de la période difficile, nous manquons de sujets.
L’un des seuls thèmes, à l’ordre du jour, c’est de se baser sur l’Open JS Fondation : Il présente des avantages, avec du renfort dans la maintenance ou la gestion d’incidents critiques pour l’écosystème JavaScript. Le Node WG et la fondation OpenJS travaillent dans le même but : de servir positivement l’écosystème JS.
T.G. : Oui, tout à fait. L'écosystème est très riche et présente de nombreux packages et solutions.
Il y a une diversité de solutions et de frameworks en tout genre. Avec le temps, ça va se stabiliser et les gros projets resteront. L'écosystème Node est encore très jeune avec seulement 5 à 6 ans à maturation réelle. En face, on trouve d’autres écosystèmes comme PHP, Python qui ont plus de 20 ans, en termes de backend. Il reste donc beaucoup de choses à faire qui s'amélioreront dans les années à venir.
Une stack full JS permet la mutualisation de packages, outils, projets et connaissances, un partage, même en cas de séparation front et back. C’est une distinction qui devient de plus en plus floue.
Le frontend et le backend sont deux métiers complexes et différents. Même si le code est en JS côté front et back, les développeurs qui sont sur des projets full JS ne deviennent pas automatiquement full-stack. On peut avoir du JS sur toute la stack, et de vrais équipes segmentées : front & back. Monter une équipe complètement transverse, ce n’est pas forcément une bonne idée. Ça finit souvent très mal. Je ne suis pas un grand fan des profils full-stack. Pour moi, il existe des compétences back métier comme : sécurité, architecture, monitoring ou encore le développement d’add-ons natifs en C. Compétences qui demandent beaucoup, beaucoup d’investissement.
Il m’arrive parfois de consulter des offres labellisées “backend Node.js”. En réalité, dans la plupart des cas, c’est 80% front et 20% back. C’est vraiment symptomatique de notre écosystème et difficile à entendre en tant que développeur backend. Il y a un travail d’éducation au backend à faire dans les entreprises. Parfois, les gens ne comprennent pas qu’ils ont des besoins en sécurité, en monitoring. Avoir ces compétences est une grande force. Aujourd’hui, le backend est toujours très pauvre, finalement. Certains aspects très importants, comme la sécurité, sont négligés : memory leak, vulnérabilités, architecture à refaire totalement, après 3 ans, ça va coûter 3 millions d’euros. Souvent, il est déjà trop tard. On apprend par l’expérience.
T.G. : Le monitoring devient une compétence rare. Ça te permet de comprendre plein de choses : savoir comment améliorer les performances, savoir ce que tes utilisateurs utilisent côté backend. Il y a de vraies opportunités à se créer, même pour les juniors ! Les entreprises ont tendance à accorder leur confiance quand on s’applique à développer toute cette activité backend. Les avantages se font ressentir directement.
Certains hackers commencent à industrialiser leurs attaques. Ce qui met les entreprises en difficulté, d’autant plus, avec le manque de compétences backend pures, en interne !
Qu’il soit question d’API ou d’autres types de projets : avec Node.js, on a un des systèmes de module les plus puissants, et pourtant, personne ne l’utilise. Souvent le métier est un ensemble d’algorithmes pouvant être implémentés à part : modules avec tests et doc dédiés. Ça peut être un package privé dans un registre privé. Souvent, ce que je fais, dans un premier temps, c’est de segmenter par modules. On peut très bien construire un monolithe de cette façon comme on le fait avec NPM. La partie Métier est ultra claire, complètement découplée. Elle peut être importée dans plusieurs projets. Il ne reste plus qu’à travailler ses API et autres interactions avec la base de données. Aujourd'hui, il y a aussi le mono repo mais les gens ne sont pas encore habitués ou ils n’y pensent tout simplement pas.
La “big picture”. Le backend se compose de modules avec les tests et documentation dédiés :
- Métier
- Services
- Utilitaires, s’il y en a beaucoup
Par exemple, dans le cadre de la comptabilité, les calculs, la gestion des plans comptables sont faits dans le package Métier. C’est un module documenté, maintenu à part.
En ce moment, je travaille souvent sur des micro-services qui font des tâches très spécifiques.
Un conseil : n’appliquez pas les méthodologies aveuglément ! Il faut une réflexion au long cours, c'est tout. Certaines pratiques n’y pourront rien : le projet ne sera pas sauvé. Je ne me considère pas comme un expert sur ces pratiques. Simplement, je m’y intéresse beaucoup, notamment au Domain Driven Design. Lier le métier à la technique, c’est vital pour construire un bon projet.
Pour aller plus loin : voir l’architecture modulaire de SlimIO. Avec des contraintes différentes de celles de projet de type monolithe.
On améliore le code en continu. Toutes les 3 semaines environ, on passe en revue l’architecture, la mise à jour des dépendances, les abstractions*.
Plus le besoin évolue, plus tu réalises que tu peux mutualiser le code par endroits.
* WET (Write Everything Twice : l’idée étant de n’écrire une abstraction qu’au bout de la troisième répétition du code)
AHA (Avoid Hasty Abstraction).
T.G. : J’évite de perdre trop d’énergie avec ces profils : ils resteront réfractaires. Généralement, on les repère vite. Ils ont une opinion bien forgée qu’ils ont déjà exposée à qui veut l’entendre. La plupart du temps, les personnes réfractaires ont une vision ancienne de JavaScript. C’est toute une catégorie de devs mal guidés.
La seule chose à faire serait de les guider vers de meilleures solutions dans l’écosystème. Choisir un bon framework, qui corresponde au scope attendu. Par exemple, pour des habitués de Laravel ou Ruby on Rails avec son ORM intégré, on peut les orienter vers des frameworks équivalents, côté Node.js. Adonis ou Nest leur permettront de s’y retrouver en termes de fonctionnalités. Tout est embarqué, on n’a plus qu’à se concentrer sur la couche Métier.
L’écosystème de Node.js est grand mais nombreux sont ceux le jugent par rapport à la qualité de dépendances de build, par exemple. Alors qu’en Node.js pur, on a des packages qui sont extrêmement bien conçus. Sur un de mes repos publics, awesome crafted Node.js (https://github.com/fraxken/awesome-crafted-Nodejs) liste ces packages. NPM et son écosystème sont incroyables. Node.js reste quand même assez bas niveau.
Un jour, Node pourrait créer un routeur, gérer l'authentification… mais jusqu’où est-ce que ça irait après ? Donner trop d’accessibilité pourrait s’avérer dangereux. Un jour peut-être, un module core Node.js rassemblera ces fonctionnalités clés.
T.G. : Je peux citer Sqreen (https://www.sqreen.com) qui a été racheté récemment par Datadog. Ceux qui s’investissent vraiment et qui ont des outils sont peu nombreux. Vladimir travaille chez Sqreen, notamment. Je citerai aussi Node Source (https://Nodesource.com/).
D’autres acteurs sont listés dans la liste awesome Node.js security (https://github.com/lirantal/awesome-Nodejs-security#companies).
Entre l’offre commerciale et l’open-source, c’est le jour et la nuit : l’offre professionnelle de Snyk est limitée. Elle donne accès à un support avancé, des rapports, des APIs et services pour de grosses entités. Augmenter les limites permettrait de rendre les offres plus accessibles. Celle de Snyk reste très chère (417$/mois). Après ça reste relatif puisqu’il s’agit d’un investissement sur la sécurité. Quand on travaille sur des projets open-source non financés, on ne peut pas se le permettre.
J’aimerais travailler avec Snyk, mais sans l’offre payante, ça m’est aujourd’hui impossible.
L’abonnement pro est indispensable pour utiliser leurs API dans Node Secure. L’offre gratuite est grillée instantanément : la limite des tests étant à 200, en trois lancements de Node Secure, on atteint 600 tests.
T.G. : La liste awesome Node.js security rassemble des outils références : https://github.com/lirantal/awesome-Nodejs-security
Les auteurs et utilisateurs l'alimentent régulièrement.
On va avoir des outils plutôt orientés analyse statique du code (Static Code Analysis, analyse du code source sans l'exécuter). Comme certains outils sur lesquels je travaille, ils vont récupérer la chaîne de caractères qui constitue le code et identifient les éléments problématiques comme les dépendances importées pour alerter l’utilisateur.
Safe regex (https://www.npmjs.com/package/safe-regex), par exemple, détecte les expressions régulières dangereuses.
Cette librairie permet d’éviter les attaques Re-Dos (version regex du Denial of Service - Dos, déni de service) qui bloquent l’event-loop.
L’analyse dynamique de code - dynamic analysis security testing (DAST), elle, consiste à exécuter le code dans une sandbox (un environnement maîtrisé). Et observer son comportement :
Après, on trouve aussi de nombreux packages pour la sanitisation. Ils sont utilisés dans le cadre de la validation de formulaires. Attention aux XSS et autres attaques côté client ! Le problème se pose aussi à la récupération des infos dans le backend. Du code peut alors être exécuté, une fois que le client est alimenté. Un bon conseil : ne jamais faire confiance à ce qui nous est envoyé.
La méthode `eval()`est à bannir. Elle consiste à interpoler les chaînes de caractères en instructions JavaScript. Il existe, là encore, des outils capables d’alerter en cas d’utilisation. Ils fonctionnent en identifiant des mots-clés et patterns.
D’autres packages repèrent l’exposition des secrets. Sur Github, des bots qui recherchent des tokens dans les projets et sont automatisés à un très haut niveau.
T.G. : Pratiquant la sécurité activement depuis 2017, je ne me suis pas forcément renseigné avant cette période.
Mon sentiment, c’est qu’il y avait trop d’outils séparés faisant des choses unitaires (secrets, package-lock…). Et peu de grands projets rassemblant un maximum de fonctionnalités. Node Secure (2 ans d’existence) est composé de 5 à 10 projets. Le projet est une composition d'un bon nombre de fonctionnalités auparavant dispersées, ce qui simplifie les choses pour les mainteneurs.
L’explosion des attaques avec la crise sanitaire est prise au sérieux par les entreprises. La sécurité, à elle seule, n’épargne pas contre les attaques et autres exploitations de failles de sécurité. Il faudrait beaucoup plus d’investissement et de rigueur. Réduire la durée de vie de session à 30 min à 1h au lieu d’1 semaine, c’est contraignant pour l’utilisateur. C’est l’entreprise propriétaire qui porte la responsabilité de la protection du produit et des données.
De nombreux projets open-source sont gérés par une seule personne. Ce qui fait que de nombreux packages sont “morts” (non maintenus) mais restent très utiles. On y trouve un tas de code à récupérer. Quand on cherche à créer des choses, c’est toujours bien d’avoir 80% du travail qui est déjà fait.
En sécurité, on manque cruellement de contributeurs investis [pour découvrir la contribution à l’open-source : Tonygo et Thomas ont réalisé un live coding intitulé “[LIVE-CODING] Open source session (Pixi.JS)” (https://www.youtube.com/watch?v=YepBl3Uxe8I, NDLR]. D’autant qu’il n’y a pas assez d'investissements des entreprises.
Snyk est un bon investisseur et contributeur, notamment grâce à ses ressources en interne. Leurs contributeurs sont financés.
La fondation OpenJS apporte un financement conséquent à l’open-source. Elle fournit un support très important et plus global.
ES-Community (EcmaScript Community, https://github.com/ES-Community)
T.G. : Il y a 6 ans, je faisais partie d’un groupe Skype de 15 personnes environ. La communauté ES-Community a été montée par 2 membres de ce groupe et moi. J’ai posé les fondations selon ma vision : uniquement JavaScript afin d’éviter les débats stériles entre langages. L’idée était de créer une communauté où tout le monde puisse contribuer avec un code de conduite sérieux.
Je me permets une mise en garde à ce sujet : attention au manque de sérieux dans les communautés. Il peut nuire à toute la communauté et sa mentalité. Les juniors peuvent en être d’autant plus impactés. Il faut bien la choisir.
On manque beaucoup de ce genre de communautés dans les langages bas niveau.
ES-Community tend à l’organisation horizontale : tout le monde est membre. Mentors et fondateurs doivent appliquer les mêmes règles. dans un respect mutuel. C’est la communauté qui prend les décisions. Par exemple, aujourd’hui, avec Xavier et Théotime, nous avons le titre honorifique de fondateur.
source code de conduite : https://github.com/ES-Community/Code-of-conduct
Les mentors sont là pour aider et guider les devs. C’est un travail de fond. Je prends tout ça très au sérieux.
La communauté est libre. Tout est spécifié. S’il y a une sanction, c’est en application du Code de Modération. En réalité, on a très peu de problèmes grâce à l’autorégulation.
Les effectifs : 7 mentors pour 300 membres, 50 à 100 actifs ou spectateurs assidus, 20 à 30 les plus actifs. Aussi actifs que certaines communautés avec 1000 membres.
T.G. : Non. Notre communauté est complètement francophone. En France, il existe deux grosses communautés : FranceJS et ES-Community.
Les organisateurs et fondateurs en ont discuté mais elles vivent indépendamment. Il ne serait pas pertinent de les rassembler. Vladimir, entre autres, gère aussi FranceJS.
Organiser des événements communs serait très compliqué. Peu de gens sont prêts à se lancer dans les talks et les partages.
Est-ce qu’il y aurait une plus value ? FranceJS a plus d’expérience dans l’organisation d’événements en présentiel.
ParisJS fait des formats courts. Dans l’ES Community, les mentors et administrateurs sont plutôt jeunes (25-30 ans). Je pense que ça joue sur certains aspects. Chez FranceJS, ce sont des pros qui ont 15-20 ans d’entreprise. Ils ont un réseau professionnel plus important, ce qui peut être pas mal pour héberger ou sponsoriser des événements. J’aimerais bien en organiser.
T.G. : Pas sûr que FranceJS porte des projets. Avec Node Secure, ma volonté personnelle c’est d’être plus actif dans la sécurité et l’open-source. J’ai envie d’apporter beaucoup. D’ailleurs, j’ai une longue liste de projets en préparation. J’aimerais apporter des contributeurs, faire découvrir l’open-source aux juniors. Il y a des projets challengeants et donc des bénéfices pros à en tirer. C’est un véritable booster de carrières. J’ai une réelle passion pour l’open-source. Je veux fédérer.
T.G. : Sur SlimIO, on a une centaine de projets. On avait du mal à comprendre les interactions entre eux. L’ancêtre de Node Secure, c’est le Dependency Analyzer, (https://github.com/SlimIO/Dependency-Analyser). Il permettait d’analyser les liens entre les projets. Node Secure, lui, donne plus de visibilité sur le graphe des dépendances.
C’est une super idée venue de notre vécu. On était très confiants dans la qualité et l’intérêt du projet dès le début. Il répondait à des cas d’usage très précis et concrets. Son impact a été confirmé dès les premiers prototypes. Depuis 2 ans, Node Secure a continué à évoluer.
Concernant les dépendances de SlimIO, avec une centaines de projets, on a 2665 packages open-source, ce qui est peu, grâce à une belle optimisation.
Chez Myunisoft, mon client actuel, on a 2960 dépendances pour une dizaine de projets.
Pour donner un ordre de grandeur, quand il y a du front, on peut facilement dépasser les 3000 dépendances pour un projet donné. De nombreux facteurs entrent en jeu mais c’est une moyenne. Généralement, le front engendre beaucoup de dépendances. Ça monte très vite. Vu qu’on les installe très facilement, on ne se rend pas compte qu’on utilise une grande variété de packages. Ce qui est assez incroyable.
T.G. : Node Secure utilise la même API que npm audit. La commande `npm audit` va chercher les vulnérabilités connues dans le npm advisatory. Elle remonte la plupart du temps des CVE - Common Vulnerabilities Exposure. La fonctionnalité est disponible sur la branche principale. Mais elle n’est pas encore publiée.
T.G. : Depuis 2 ans, rester en v.0.x a été un choix délibéré car j’étais encore débutant en termes de sécurité.
On aura une v1 très aboutie lorsqu’on aura franchi toutes ces étapes :
js-x-ray (JavaScript & Node.js open-source SAST - Static Application Security Testing - scanner, https://github.com/fraxken/js-x-ray, version actuelle 3.1.1)
T.G. : C’est un outil capable de prendre un code source sans l'exécuter et d’y trouver des patterns et codes malicieux. Notre travail est basé sur des attaques précédentes dans l’écosystème pour une détection instantanée.
C’est un outil d’analyse. C’est aux devs de se documenter. Le public visé est intermédiaire et senior.
T.G. : C’est un projet né d’un code qui était dans Node Secure. Il a été mis à part pour de meilleures optimisations, maintenance, évolution. Dans notre démarche de segmentation de Node Secure, JS-x-ray est devenue une lib indépendante.
Avec cet outil, un de mes kifs serait d’analyser tout l’écosystème NPM, passer régulièrement à travers tous les packages JavaScript et en sortir des statistiques. Améliorer les faux positifs, découvrir de nouveaux positifs, ce serait le Graal pour moi.
Comment tu t’y prends pour répertorier un maximum de code malicieux ? Quelles sont tes sources ?
T.G. : Dans la sécurité, j’ai un parcours atypique. Je ne fais pas de pen testing (test d’intrusion). Je ne participe pas beaucoup aux concours. Pour moi, c’est un investissement personnel dans l'écosystème qui me passionne.
L’analyse statique (AST - Abstract Syntax Tree) m’a permis de faire un lien avec la sécurité. Je suis très axé sur le code, sa compréhension, son analyse. Ma zone de compétences est bien délimitée dans la sécurité.
Dans l’analyse de code, il y a peu de monde et peu d’expertise. En France, je ne connais quasiment personne d’autre qui s’investisse dans l’analyse. Pas dans l’open-source, en tout cas.
À la lecture d’un article, j’ai découvert que des hackers avaient encodé du code JS en morse pour le rendre illisible. Ça m’a fait ultra rire. Je me suis dit que c’était trop beau pour ne pas le gérer. Ça m’a permis de me replonger dans le morse. Aujourd’hui, JS-x-ray est capable de le détecter (en théorie) !
Dans l’informatique, tu finis toujours par apprendre un truc.
Snyk, avec la puissance qu’ils ont pourrait collaborer avec NPM en demandant l’accès à ces codes malicieux, essayer d’utiliser les post-mortem. Contrairement aux contributeurs open-source, on n’a pas la même légitimité.
Face à un vecteur d’attaque fort, un remède simple peut être préconisé : si tu peux faire un code JS avec des boucles et conditions, c’est recommandé plutôt qu’une regex. Dans le cas où une regex est indispensable, il vaudrait mieux utiliser une lib spécialisée comme validator ou safe-regex (https://github.com/goldbergyoni/Nodebestpractices#-616-prevent-evil-regex-from-overloading-your-single-thread-execution).
Comment est-ce que je pourrais la blinder dès le premier commit ?
T.G. : Sujet très vaste. La sécurité regroupe énormément de choses :
Tout ça représente un large scope de métiers et demande une rigueur d’ensemble. La sécurité, c’est aussi être conscient des risques et toujours se remettre en question.
Éventuellement, dans des entreprises comme Thalès, ils savent faire preuve d’une grande rigueur. Après, pour une personne qui débute, ça va être très difficile, voire impossible, de sécuriser son projet dès le début.
Je considère avoir 10% des compétences. Appliquer les bonnes pratiques (cf awesome Node security) peut permettre une sécurisation à 99%. Pour le dernier pourcent, la consultation d’experts et un audit externe sont fortement recommandés.
T.G. : Quelques ressources intéressantes :
Tout ça, ce sont des premiers pas. Après, il faut se lancer, lire et s’y intéresser.
Il existe également des listes “awesome security” généralistes et leur version par langage. Les repos sont dispos en ligne.
T.G. : Face à Express* et sa grande popularité, Fastify, c’est l’apothéose de ce qui se fait de mieux dans l’écosystème Node.js : la sécurité y est optimale. C’est maintenu par des contributeurs core de Node, avec une communauté d’experts très actifs.
Node n’est pas dépassé. C’est aux devs d’aller chercher les modules les plus récents et optimaux. Dans 2 ou 3 ans, Express sera déprécié. Il faudrait faire une analyse des dépendances, découper le métier pour le séparer du serveur HTTP. Beaucoup de packages sont en train de mourir. Souvent ce sont des middlewares. Express, c’est beaucoup de middlewares qui ne sont plus maintenus. Le coeur d’Express sera maintenu mais pas les packages spécifiques.
*Passer d’Express à Fastify n’est pas forcément très compliqué. Ce sont tous deux des frameworks low scope. Il existe un mode de compatibilité pour migrer plus facilement. Un package de huit ans sans mise à jour, c’est un vecteur d’attaque, d’instabilité. Il faut assurer la maintenance soi-même, ça demande beaucoup de travail. NSecure peut être installé à la racine du projet pour analyser les dépendances : est-ce qu’elles sont à jour ?
Je lutte contre les répercussions de ce framework bloqué en 2015 avec des callbacks, un système de middlewares dépassé et pourtant choisi par les entreprises et utilisé dans de nombreux tutos destinés aux juniors. Il entraîne des dégâts d’image, alors qu’il y a des solutions stables existant depuis des années.
Notre manière de coder dans Node.js n’a plus rien à voir avec celle d’il y cinq ou six ans.
L’écosystème, c’est les packages. Les libs en coulisse sont souvent les mêmes.
Comprendre l’historique permet d'éviter les dégâts causés par certaines libs.
Le travail d’écriture permet de toucher un autre public.
Awesome Node.js security - https://github.com/lirantal/awesome-Nodejs-security
Awesome cross platform Node.js - https://github.com/bcoe/awesome-cross-platform-Nodejs
SlimIO - https://github.com/SlimIO
Node.js security working group - https://github.com/Nodejs/security-wg
Notre Manifeste est le garant des droits et devoirs de chaque CodeWorker et des engagements que CodeWorks a vis-à-vis de chaque membre.
Il se veut réaliste, implémenté, partagé et inscrit dans une démarche d'amélioration continue.
Tu veux partager tes connaissances et ton temps avec des pairs empathiques, incarner une vision commune de l'excellence logicielle et participer activement à un modèle d'entreprise alternatif, rejoins-nous.
.png)
