L’exécution de code à distance, les scripts intersites et les attaques par déni de service représentent les deux tiers des vulnérabilités connues dans l’écosystème .NET

Découvrez notre nouveau rapport sur la sécurité de l’open source dans l’écosystème .NET. Ce rapport se compose de trois articles :

• La sécurité de l’open source dans l’écosystème .NET

• Dans l’écosystème .NET, 75 % des vingt principales vulnérabilités sont considérées comme très graves

• L’exécution de code à distance, les scripts intersites et les attaques par déni de service représentent les deux tiers des vulnérabilités connues dans l’écosystème .NET

Notre superbe rapport PDF, réalisé avec soin, regroupe toutes ces informations et bien plus encore au même endroit. Et il est gratuit à télécharger !

Que nous apprend Snyk sur la sécurité de l’écosystème .NET ?

Après avoir examiné les vulnérabilités les plus fréquemment observées, prenons un peu de recul pour étudier l’écosystème .NET dans son ensemble. Quels types de vulnérabilités y sont courants ? La tendance aux vulnérabilités très graves se confirme-t-elle à l’échelle de tout l’écosystème ?

Types de vulnérabilités

Le tableau suivant détaille les types de vulnérabilités recensés dans l’écosystème .NET, en incluant ceux qui représentent au moins 1 % des vulnérabilités. Il indique le nombre de vulnérabilités distinctes de chaque type répertoriées dans la base de données de vulnérabilités de Snyk, ainsi que leur part en pourcentage.Malgré la grande diversité des vulnérabilités, trois types seulement constituent la majorité des vulnérabilités recensées. L’exécution de code à distance (RCE), les scripts intersites (XSS) et les attaques par déni de service (DoS) représentent les deux tiers des vulnérabilités .NET présentes dans la base de données de vulnérabilités de Snyk.

L’exécution de code à distance (RCE), les scripts intersites (XSS) et les attaques par déni de service (DoS) représentent les deux tiers des vulnérabilités .NET présentes dans la base de données de vulnérabilités de Snyk.

Zoom sur les vulnérabilités

Cette section constitue un aperçu pratique pour toute personne souhaitant en savoir plus sur les trois principaux types de vulnérabilités de l’écosystème .NET.

Exécution de code à distance

L’exécution de code à distance est un type de vulnérabilité qui permet à un attaquant d’exécuter des commandes ou du code arbitraires dans votre application. Cette exécution peut se produire sur un réseau et n’est donc liée à aucune zone géographique particulière. Une vulnérabilité connexe est l’injection de commandes.

Scripts intersites

Une attaque par script intersite se produit lorsqu’un attaquant trompe une application ou un site Web légitime pour qu’il accepte une requête comme si elle provenait d’une source fiable. Pour ce faire, l’attaquant sort du contexte de l’application Web. Celle-ci transmet alors ces données à ses utilisateurs avec d’autres contenus dynamiques fiables, sans les valider.

Déni de service

Le déni de service désigne une famille d’attaques visant à rendre un système inaccessible aux utilisateurs légitimes auxquels il est destiné. Contrairement à d’autres vulnérabilités, les attaques DoS ne cherchent généralement pas à compromettre la sécurité. Elles visent plutôt à rendre les sites Web et les services indisponibles pour les utilisateurs légitimes, entraînant ainsi une interruption de service.

Les vulnérabilités .NET connues sont souvent très graves

Plus tôt, en examinant les 20 vulnérabilités les plus fréquemment observées, nous avons constaté que la majorité d’entre elles étaient très graves. Cette tendance se confirme-t-elle pour l’ensemble des vulnérabilités .NET de la base de données de Snyk ? Oui ! Les vulnérabilités très graves représentent 70,7 % du total. Les vulnérabilités de gravité moyenne arrivent ensuite, avec 26,9 %. Seules 2,4 % des vulnérabilités .NET de la base de données de Snyk sont considérées comme peu graves.

Les vulnérabilités très graves représentent 70,7 % du total. Les vulnérabilités de gravité moyenne arrivent ensuite, avec 26,9 %.

Ces chiffres peuvent donner une image sombre de la sécurité de .NET. La proportion de vulnérabilités très graves est importante. Cependant, au moment de la rédaction de cet article, Snyk avait trouvé une solution pour chaque vulnérabilité détectée lors d’une analyse des dépendances. Nous ne pouvons pas savoir avec certitude pourquoi, mais cela pourrait s’expliquer en partie par le soutien dont bénéficie l’écosystème .NET de la part de Microsoft.

Au moment de la rédaction de cet article, Snyk avait trouvé une solution pour chaque vulnérabilité détectée lors d’une analyse des dépendances.

Zoom sur la sécurité : corriger les vulnérabilités

Mais que signifie concrètement corriger une vulnérabilité ? Cette section vous présente rapidement les étapes du processus.

Mettre à niveau

Lorsqu’une vulnérabilité est découverte, les responsables du projet intègrent généralement un correctif (si possible) à une version ultérieure, mais les délais peuvent varier considérablement. En règle générale, rester à jour avec les dernières versions permet de mieux suivre les vulnérabilités de sécurité.Il est parfois difficile de mettre à niveau une dépendance, car les dépendances interagissent entre elles et avec votre code.

Dépendances directes et indirectes

La correction des vulnérabilités dans les dépendances directes est généralement simple : mettez la dépendance à niveau vers la version minimale qui comprend le correctif.Pour corriger les vulnérabilités dans les dépendances indirectes, deux éléments sont nécessaires : une version corrigée de la dépendance indirecte et une version de la dépendance directe qui utilise cette version corrigée.Si ces deux conditions sont réunies, la mise à niveau de la dépendance directe concernée vers une version utilisant la version corrigée de la dépendance indirecte résoudra le problème.Si aucun correctif n’est disponible au niveau de la dépendance directe, les développeurs peuvent mettre à niveau la dépendance indirecte pour résoudre le problème. Cela risque toutefois de créer des problèmes de compatibilité entre les dépendances.

Conclusion

Dans l’écosystème .NET, le nombre de vulnérabilités par package est faible, mais celles-ci sont souvent très graves. Il faut donc probablement moins de temps pour résoudre les problèmes (investissement moindre), tout en traitant des risques de sécurité potentiellement dangereux (rendement élevé). Autrement dit, en corrigeant les vulnérabilités connues dans les packages .NET que vous utilisez, vous prenez une mesure de sécurité très rentable.Chez Snyk, notre objectif est d’aider chacun à utiliser l’open source en toute sécurité. Pour cela, nous développons notamment des outils qui permettent de détecter et de corriger automatiquement les vulnérabilités connues dans les dépendances. Mais il est également important d’identifier les nouvelles vulnérabilités et de les divulguer de manière responsable. L’écosystème .NET ne dispose pas actuellement d’un lieu centralisé pour signaler les vulnérabilités des bibliothèques open source. Snyk est une autorité de numérotation CVE (CNA), ce qui signifie que nous pouvons attribuer un numéro CVE à une nouvelle vulnérabilité (en quelque sorte, son identifiant) et l’ajouter aux bases de données concernées. En tant que CNA, Snyk peut vous aider à signaler des vulnérabilités de manière responsable.Vous pouvez en savoir plus sur ce processus ici : https://snyk.io/vulnerability-disclosure.

Merci !

Merci d’avoir lu notre nouveau rapport sur la sécurité de .NET. Nous espérons qu’il vous a plu. Nous voulons vous aider à utiliser l’open source en toute sécurité. Vous trouverez donc d’autres ressources de ce type prochainement.N’oubliez pas que vous pouvez télécharger gratuitement le rapport complet.

Téléchargez le rapport sur la sécurité de l’open source dans l’écosystème .NET.