La menace persistante : pourquoi les vulnérabilités majeures comme Logell et Springell restent importantes

En tant que développeurs, nous jonglons constamment avec les fonctionnalités, les correctifs et les délais. Pourtant, un problème caché a été étonnamment négligé : l’utilisation continue des versions vulnérables de Log4j et Spring Framework dans de nombreux projets. Malgré l’exposition très médiatisée des vulnérabilités Log4Shell et Spring4Shell, un nombre choquant d’applications fonctionnent toujours sur ces bombes à retardement. Il ne s’agit pas seulement d’un oubli mineur : c’est un risque majeur. Nous sommes des constructeurs dans l'âme, mais une partie de la construction consiste à garantir la sécurité de nos structures.

Le dilemme du développeur

En tant que développeurs, nous équilibrons constamment la création de nouvelles fonctionnalités et la maintenance des projets et fonctionnalités existants. C'est un exercice d'équilibre qui exige notre temps et toute notre bande passante cognitive. Garder une trace des dépendances de chaque projet tout en s'assurant qu'elles sont à jour peut sembler une bataille difficile, surtout lorsque la pression est forte pour fournir de nouvelles fonctionnalités. Au milieu de cet acte de jonglerie, des vulnérabilités critiques telles que Log4Shell et Spring4Shell peuvent parfois passer entre les mailles du filet, non pas par négligence mais en raison du volume considérable de tâches que nous gérons quotidiennement. Cependant, il est essentiel de reconnaître que la sûreté et la sécurité d'applications passionnantes sont aujourd'hui des aspects cruciaux du développement de logiciels.

L'état actuel de Log4shell

Vous vous souvenez de Log4Shell ? Cette vilaine vulnérabilité dans Apache Log4j découverte en 2021 qui pourrait permettre aux attaquants d’exécuter du code sur votre serveur en enregistrant une chaîne spéciale ? Un attaquant pourrait utiliser une recherche JNDI avec le protocole LDAP pour injecter un fichier de classe précompilé et exécuter du code malveillant. Même dans les versions les plus récentes de Java, cette vulnérabilité pourrait entraîner des dommages dus à des attaques de désérialisation. La complexité de l’attaque de cette vulnérabilité critique est considérée comme très faible, ce qui rend la menace encore plus élevée que d’habitude. Consultez notre article de blog pour une description complète du problème.

Plus de 20% des entreprises sont encore vulnérables à Log4shell.

Aujourd'hui, de nombreuses entreprises disposent encore d'une version obsolète et vulnérable de la bibliothèque Log4j dans l'un de leurs projets. Parmi tous les clients Snyk qui analysent leur code de production à la recherche de vulnérabilités,21 %ont encore des projets vulnérables à Log4Shell. Cela signifie que plus de60 000projets risquent toujours d'être piratés par une vulnérabilité divulguée et corrigée il y a plus de 2 ans. C'est énorme ! Sachant que ces entreprises utilisent déjà des outils de sécurité et atténuent activement les problèmes de sécurité qu'elles rencontrent, le nombre réel de versions vulnérables de log4j dans la nature sera bien plus élevé que cela. Cette seule pensée est non seulement effrayante mais aussi très dérangeante.

Spring4Shell à l'état sauvage

Un autre exemple tristement célèbre est Spring4Shell, qui a été divulgué en mars 2022. La vulnérabilité des spring-beans pourrait également conduire à l'exécution de code malveillant à distance. Même si la complexité de l’attaque était faible et qu’il y avait des exploits dans des cas spécifiques, l’impact était moins important que celui de Log4Shell. Consultez l'article de blog dédié pour plus de détails.

En étendant cette vulnérabilité à Glassfish avec un nouvel exploit en avril 2022, l'équipe Snyk a prouvé que cette vulnérabilité est très importante et pourrait être utilisée à mauvais escient dans de nombreux autres cas en dehors du premier exploit pour Tomcat.

Semblable à Log4Shell, nous avons constaté que Spring4Shell est toujours applicable dans la nature. Environ35%de nos clients ont encore la vulnérabilité dans l'un de leurs projets. Même si le risque de violation de Spring4Shell n'était pas aussi important que celui de Log4Shell, l'équipe Snyk a démontré une gamme d'exploits potentiels en identifiant et en développant une preuve de concept (POC) d'exploit pour Glassfish. Cela prouve que des dangers apparemment moindres peuvent néanmoins conduire à d’importantes vulnérabilités en matière de sécurité. Le fait qu’aucun exploit n’ait encore été publié n’implique pas qu’une application ne puisse pas être piratée par une vulnérabilité !

De plus, cela montre que de nombreuses applications Spring dépendent de versions de framework plus anciennes et obsolètes, et que la mise à jour et la maintenance des applications existantes sont considérées comme sans importance. Cependant, au fond, nous savons qu’il s’agit d’une bombe à retardement qui peut exploser à tout moment.

Réveil à tous ceux qui maintiennent les applications

Gardons cela simple et précis. Nous connaissons tous ce sentiment de fierté lorsque notre code s'exécute enfin sans accroc, et la dernière chose que nous voulons faire est de revenir en arrière et de le manipuler, surtout pour quelque chose d'aussi stupide que la mise à jour des bibliothèques. Mais voici le problème : ces vulnérabilités Log4Shell et Spring4Shell ne vont pas se réparer d'elles-mêmes. Et honnêtement, ce ne sont pas de simples bugs que nous pouvons ignorer. Ce sont des trous béants dans les murs de notre application. Si vous avez encore des vulnérabilités comme Log4Shell ou Spring4Shell dans votre environnement, vous êtes inutilement vulnérable aux attaques de haute gravité !

Snyk peut vous aider en détectant et en aidant à résoudre les vulnérabilités de sécurité dans les applications. Il s'intègre aux flux de développement de plusieurs manières, par exemple via les référentiels Git, son interface de ligne de commande (CLI) ou les pipelines d'intégration continue (CI) existants, permettant aux développeurs d'identifier les risques de sécurité dès le début du cycle de développement avant qu'ils ne se transforment en problèmes plus importants. L'inscription est gratuite, permettant un accès immédiat à ses fonctionnalités. Cependant, la véritable valeur réside dans la manière dont les vulnérabilités découvertes sont gérées et résolues après identification.

Nous devons prendre nos responsabilités ici. Il ne s’agit pas seulement de trouver un correctif rapide ou d’espérer qu’une simple mise à jour fera l’affaire. Parfois, nous devons prendre la décision difficile de supprimer ou de remplacer une bibliothèque vulnérable. Oui, cela pourrait nous ralentir un peu, et ce n'est pas la partie la plus excitante de notre travail, mais c'est crucial. Il s'agit de garantir la solidité de notre code, pas seulement pour aujourd'hui mais pour le long terme.

Alors, n'attendons pas que quelqu'un d'autre résolve ces problèmes. Avec les outils appropriés, nous pouvons détecter ces vulnérabilités à un stade précoce, mais nous devons être ceux qui doivent agir. Il nous appartient de renforcer nos défenses, de corriger ces vulnérabilités et de garantir la sécurité de nos applications. Allons-y, pas seulement en tant que codeurs, mais en tant que personnes qui soutiennent leur travail, veillant à ce qu'il soit aussi sécurisé que possible.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!