Angular vs React : le risque de sécurité des dépendances indirectes

Bienvenue dans le rapport 2019 de Snyk sur l’état de la sécurité des frameworks JavaScript.

Dans cette section, nous examinons le risque de sécurité des dépendances indirectes d’Angular et de React, puis celui de leurs dépendances directes, d’abord pour Angular, puis pour React.

Téléchargez le rapport ici !

Les modules examinés dans cette partie ne constituent pas une liste complète des modules React et Angular vulnérables ; certains modules peuvent suivre des conventions de nommage particulières (par exemple, tous les modules préfixés par ng-, angular- ou react-) et ne pas apparaître dans la recherche par motifs que nous avons effectuée.

Le risque de sécurité des dépendances indirectes

Le plus souvent, les projets basés sur React ou Angular sont générés à l’aide d’un outil d’échafaudage qui fournit un modèle de base pour démarrer le développement. Avec React, les développeurs utilisent généralement le package npm create-react-app, qui crée un point de départ préconfiguré pour le projet, par exemple en intégrant le framework de test Jest, des processeurs CSS et d’autres outils. Avec Angular, c’est le package npm @angular/cli qui permet de le faire.

Pour comparer l’état des dépendances et leur niveau de sécurité (qui reflètent le risque de sécurité global) dans les modèles de base React et Angular, nous avons généré un projet d’exemple. Le résultat est plutôt encourageant : les deux incluent des dépendances de développement vulnérables, mais aucun ne présente de problème de sécurité lié aux dépendances de production.

Voici les vulnérabilités de sécurité introduites dans votre code dès le départ lorsque vous créez un projet à partir du modèle de base Angular ou React :

Il est intéressant de noter qu’Angular dépend de 952 dépendances, qui contiennent au total deux vulnérabilités ; React dépend de 1 257 dépendances, qui contiennent trois vulnérabilités et un éventuel problème de compatibilité de licence.

À propos des licences des logiciels open source

En matière de licences, nous considérons le respect des licences comme un facteur important de l’état global des dépendances, au même titre que les problèmes de sécurité. C’est pourquoi nos analyses incluent également des vérifications de licences. Les résultats obtenus pour les licences reposaient sur les configurations par défaut définies pour nos politiques de licence avant l’analyse.

D’après ces résultats, le projet React généré dépend du package mdn-data, qui utilise la licence copyleft MPL-2.0 de Mozilla. Si vous prévoyez de distribuer votre application React avec des installations sur site ou d’autres configurations similaires incluant la dépendance mdn-data, vérifiez les exigences en matière de licences pour vous assurer que votre projet les respecte.

Nous vous conseillons également de veiller à ce que vos projets soient analysés conformément aux recommandations des politiques propres à votre organisation, lesquelles peuvent signaler ou non d’autres dépendances indirectes de React.

Corriger les chemins vulnérables

Un chemin décrit la manière dont une dépendance open source est introduite dans votre projet. Par exemple, imaginons que vous ayez deux dépendances directes, le projet A et le projet B. Ces deux projets introduisent la dépendance projet C. Le projet C est alors associé à deux chemins différents, car il est installé à la fois par le projet A et par le projet B. Si le projet C contient des vulnérabilités, le développeur doit tenir compte des deux chemins pour les corriger.

Avec React, les trois vulnérabilités se propagent sur 16 293 chemins vulnérables. Avec autant de packages à mettre à niveau dans la chaîne de dépendances, corriger les vulnérabilités en mettant à niveau les packages devient une tâche redoutable. En revanche, les deux vulnérabilités d’Angular se corrigent facilement en ne traitant que deux chemins vulnérables.

L’image suivante provient d’un rapport d’analyse de sécurité datant d’août 2019, réalisé sur un projet généré avec le package npm create-react-app de React. Le rapport met en évidence le problème de chaîne de dépendances à résoudre pour une seule vulnérabilité de sécurité.

Pour corriger la vulnérabilité, il faut récupérer de nouvelles versions de lodash dans chacun des packages concernés de toute la chaîne de dépendances.

En raison de l’utilisation très répandue de lodash dans l’écosystème, sa version vulnérable est finalement utilisée dans des milliers de chemins de dépendances.

Vulnérabilités dans l’écosystème des modules Angular

Dans l’écosystème Angular, les vulnérabilités des modules se manifestent dans trois domaines :

• Modules de l’écosystème Angular

• Versions malveillantes de modules

• Outils de développement Lorsque nous examinons l’écosystème des modules Angular, les modules suivants se distinguent par leur nombre de téléchargements et les vulnérabilités associées :

Si nous classons les types de vulnérabilités selon le nombre de téléchargements des modules qui les contiennent, nous constatons clairement que les vulnérabilités XSS arrivent en tête, comme l’indique également le Top 10 de l’OWASP des risques de sécurité web à surveiller :

Modules Angular malveillants

Au total, nous avons identifié trois versions malveillantes publiées pour les modules Angular suivants : angular-bmap, ng-ui-library, ngx-pica.

angular-bmap est peut-être le moins intéressant, comme le montre sa page d’état des dépendances : ses huit versions publiées remontent toutes à septembre 2017. Pourtant, une version 0.0.9 d’angular-bmap a été publiée avec du code malveillant qui exfiltre des informations sensibles relatives aux mots de passe et aux cartes de crédit saisies dans les formulaires, puis les envoie à l’URL contrôlée par l’attaquant https://js-metrics.com/minjs. php?pl=. Cette version malveillante 0.0.9 a été retirée du registre npm.

Contrairement au module Angular bmap, ng-ui-library est toujours maintenu et compte plus de 150 versions publiées, dont sept rien qu’en 2019. Cependant, la version 1.0.987 de ng-ui-library contient le même code malveillant que celui repéré dans angular-bmap. ng-ui-library totalise toujours près de 400 à 3 000 téléchargements par mois.

Le même code malveillant qui dérobe des informations de carte bancaire se retrouve également dans une version malveillante de ngx-pica, un module compatible avec Angular v5 et Angular v7 qui redimensionne les images dans le navigateur et totalise environ 800 téléchargements mensuels.

Il est intéressant de noter que toutes ces versions malveillantes n’ont été découvertes que récemment. Elles ont toutes été divulguées en juin 2019, alors que le code malveillant avait été intégré à une version publiée un mois auparavant.

Outils de développement Angular

Dans le cadre de nos recherches sur l’écosystème des modules, nous avons repéré un module utilisé comme serveur HTTP polyvalent pour distribuer les ressources d’applications monopages créées avec Angular, React, Vue et d’autres technologies.

Le module angular-http-server s’est révélé vulnérable à deux reprises à une traversée de répertoires. Les deux versions vulnérables datent d’un an, et six versions plus récentes ont déjà été publiées. Bien que le responsable du module précise clairement qu’il ne recommande pas d’utiliser cet outil comme service prêt pour la production, ses téléchargements ont augmenté cette année, avec 20 670 téléchargements enregistrés en mai 2019.

Compte tenu de l’adoption croissante de cet outil de développement de serveur HTTP Angular, nous tenons à signaler qu’un exploit public existe pour cette vulnérabilité.

Vulnérabilités dans l’écosystème des modules React

Comme pour Angular, nous avons constaté que l’écosystème React comprend plusieurs modules malveillants publiés à un moment donné. Voici la répartition des types de vulnérabilités de sécurité et leur nombre pour l’ensemble des modules vulnérables que nous avons recensés, avec notamment quatre packages malveillants : react-datepicker- plus, react-dates-sc, awesome_react_utility, react- server-native.

Les quatre modules malveillants contiennent le même code malveillant, qui dérobe les informations de cartes de crédit et d’autres données sensibles ; cette attaque a également compromis des modules de l’écosystème React.

Cela souligne encore davantage qu’en tant que responsable d’un projet open source, il est essentiel d’activer l’authentification multifacteur, notamment la prise en charge de l’authentification à deux facteurs (2FA) proposée par le registre de packages npm, afin d’éviter d’exposer vos utilisateurs au risque qu’un tiers compromette votre compte et publie des versions malveillantes de votre package.

Si ce n’est pas encore fait, nous vous invitons à activer la 2FA sur votre compte développeur npmjs.org et à suivre les autres bonnes pratiques de sécurité npm.

Modules vulnérables notables recensés dans l’écosystème React :

• Une vulnérabilité XSS de gravité élevée dans react-marked-markdown, pour laquelle aucun correctif n’est disponible. Pourtant, ce composant React qui encapsule la bibliothèque JavaScript Markdown marked totalise encore des milliers de téléchargements, soit 65 790 au cours des 12 derniers mois.

• Si vous utilisez preact, sachez que la bibliothèque preact-render-to-string est vulnérable au Cross-Site Scripting dans toutes les versions antérieures à la 3.7.2. Son utilisation a augmenté au cours des 12 derniers mois, avec 3 228 049 téléchargements sur cette période.

• Si vous utilisez des info-bulles dans votre application React front-end, vous faites peut-être partie des utilisateurs de react-tooltip, qui a enregistré près d’un million de téléchargements (994 903) en juillet 2019 à lui seul. Cette bibliothèque est toutefois vulnérable aux attaques de type Cross-Site Scripting dans toutes les versions antérieures à la 3.8.1, comme cela a été divulgué en septembre 2018.

• Si vous travaillez souvent avec des SVG, il y a de fortes chances que vous utilisiez react-svg, qui a totalisé 1 446 442 téléchargements au cours des 12 derniers mois. En avril 2018, le chercheur en sécurité Ron Perris a divulgué une vulnérabilité Cross-Site Scripting de gravité élevée affectant toutes les versions antérieures à la 2.2.18.

• Une vulnérabilité d’injection CSV dans mui-datatables a été divulguée en mars 2019. Cette bibliothèque React fournit un composant d’interface de tableau de données basé sur le framework Material UI et a totalisé plus de 350 000 téléchargements au cours des 12 derniers mois.

Parmi tous les modules React vulnérables que nous avons recensés, nous avons dénombré huit vulnérabilités de sécurité sur les trois dernières années : deux en 2017, six en 2018 et deux jusqu’en août 2019. Cela souligne l’importance d’utiliser les logiciels open source de manière responsable et de détecter et corriger les vulnérabilités aussi rapidement que possible.

À la une : les vulnérabilités de sécurité de Next.js

Next.js est le framework React populaire proposé par ZEIT. Il permet aux développeurs web de tirer parti de leurs connaissances de React pour créer des applications web optimisées pour le référencement, des applications avec rendu côté serveur, des applications web progressives (PWA) et même des applications basées sur Electron, le tout avec le framework Next.js.

Next.js continue de séduire les développeurs, avec 8 414 925 téléchargements au cours des 12 derniers mois. À mesure que le projet se développe, il devient de plus en plus important de faire le point sur son niveau de sécurité.

Entre 2017 et 2018, nous avons recensé trois vulnérabilités de gravité élevée de type Directory Traversal et deux vulnérabilités de gravité moyenne de type Cross-Site Scripting affectant le framework React Next.js. Il convient également de souligner que l’équipe de sécurité de ZEIT a rapidement corrigé ces cinq vulnérabilités et proposé une mise à niveau de Next.js pour les résoudre en moins d’une semaine.

Dans l’ensemble, ZEIT applique des pratiques de sécurité rigoureuses dont les autres projets open source devraient s’inspirer. Parmi les points particulièrement remarquables :

• L’équipe réagit rapidement aux signalements de vulnérabilités en publiant des correctifs sans tarder. La période pendant laquelle le risque de sécurité est réel est ainsi réduite au minimum. ZEIT propose aux utilisateurs une mise à niveau qui leur permet de corriger rapidement la vulnérabilité.

• Pour éviter les régressions en matière de sécurité, l’équipe a écrit des tests unitaires de sécurité afin d’éviter que les mêmes erreurs se reproduisent.

• Les notes de version communiquent clairement les informations relatives à la sécurité, les répercussions des problèmes et les mesures à prendre pour rester à jour avec les correctifs de sécurité.

• Le projet dispose d’une liste de diffusion dédiée aux signalements de sécurité, d’une politique de divulgation responsable et d’une adresse e-mail dédiée au signalement des problèmes.

ZEIT et sa gestion du framework Next.js illustrent parfaitement les bonnes pratiques de sécurité pour les projets open source. ZEIT prend la sécurité au sérieux et démontre, par ses politiques et ses actions, un véritable engagement en faveur de la sécurité de ses utilisateurs. Les autres projets devraient suivre cet exemple.

Téléchargez le rapport ici !

Poursuivez avec les points forts de la section suivante :

• État de la sécurité des frameworks JavaScript : rapport 2019

• Angular vs React : le match de la sécurité 2019

• Comparaison côte à côte des vulnérabilités de sécurité d’Angular et de React en 2019

• 10 bonnes pratiques de sécurité pour React

• Comparaison des pratiques de codage sécurisé de React et d’Angular

• 84 % des sites web sont concernés par les vulnérabilités XSS de jQuery

Vous pouvez également télécharger la version complète du rapport au format numérique.