J’ai déjà expliqué en détail pourquoi la sécurité des applications repose sur un ensemble de couches. Je le répète, car il est parfois nécessaire de rappeler que les applications modernes ne sont jamais déployées seules. Jamais.
Toute application moderne est déployée sur un type de plateforme. Il peut s’agir d’Apache ou d’IIS, d’un serveur d’applications Oracle ou IBM, de node.js avec Express ou encore de Python avec toutes les bibliothèques nécessaires. Tout comme nous comptons sur les systèmes d’exploitation et la virtualisation ou les conteneurs pour assurer la connectivité réseau, les applications s’appuient sur des plateformes et des bibliothèques pour gérer des protocoles tels que TCP et HTTP.
En outre, les développeurs utilisent des bibliothèques pour bénéficier de certaines fonctionnalités. Il est inutile de réinventer la roue ; ils se tournent donc vers l’open source et d’autres solutions pour les analyseurs JSON, la gestion des fichiers, l’authentification et les autorisations, ainsi que la prise en charge des bases de données. Il en va de même pour la mise en page et la gestion de l’interface utilisateur. Aujourd’hui, la plupart des développeurs s’appuient sur des bibliothèques pour assurer ces fonctions, afin de pouvoir se concentrer sur ce qui apporte de la valeur : la logique métier et les services.
Une analyse d’applications réalisée en 2017 par Contrast Labs a révélé que « les bibliothèques logicielles tierces représentent 79 % du code d’une application ». Pour Java, la moyenne était de 107 bibliothèques différentes. Pour .NET ? 19. À titre personnel, j’utilise au moins cinq bibliothèques différentes avec node.js.
Mais ce qui devrait vous interpeller, c’est ce qu’ils ont découvert sur l’état de la sécurité au regard de cette répartition.
Bien que 79 % d’une application soit constitué de bibliothèques, celles-ci ne représentent que 2 % des vulnérabilités connues (c’est-à-dire les CVE). Le code personnalisé représente pratiquement tout le reste, soit 97,3 % des vulnérabilités.
Cette disproportion entre les risques liés à la sécurité des sources que présentent les bibliothèques et les vulnérabilités pourrait expliquer pourquoi une enquête du SANS a révélé que « même si 23 % des personnes interrogées dépendent fortement de produits et services logiciels tiers (logiciels sur étagère, services cloud et logiciels open source), elles n’assument pas suffisamment la responsabilité de garantir la sécurité des solutions tierces. Seuls 23 % des programmes de sécurité prennent en compte les logiciels sur étagère. »
Hum. Eh bien, cela pourrait expliquer le faible taux de résolution des vulnérabilités rapporté par Kenna Security. En 2015, Kenna Security a publié les résultats d’une étude menée auprès d’un échantillon de 50 000 organisations, portant sur 250 millions de vulnérabilités et plus d’un milliard (UN MILLIARD) d’incidents de sécurité, et en a tiré deux conclusions très intéressantes concernant la correction des vulnérabilités :
- En moyenne, les entreprises mettent entre 100 et 120 jours pour corriger les vulnérabilités.
- Au bout de 40 à 60 jours, la probabilité qu’une vulnérabilité CVE soit exploitée dépasse 90 %.
- Le délai entre le moment où une vulnérabilité est susceptible d’être exploitée et celui où elle est corrigée est d’environ 60 jours.
En d’autres termes, la plupart des organisations ne corrigent pas ces 2 % de vulnérabilités assez rapidement pour éviter que l’une d’elles ne soit exploitée à leurs dépens. Cela s’explique peut-être par le fait qu’elles se trouvent dans des bibliothèques qui ne sont pas couvertes par le programme de sécurité de l’organisation.
Quelle qu’en soit la raison that is, cela doit être la priorité absolue. Et laissez-moi vous expliquer pourquoi.
À l’époque, les attaquants devaient :
- Découvrir l’existence de la vulnérabilité
- Rechercher un site victime
- Tenter d’exécuter un exploit
Ce processus était manuel et chronophage. À moins que vous ne soyez une cible de premier plan, personne n’allait perdre son temps avec vous.
Aujourd’hui, les vulnérabilités se propagent à la vitesse d’Internet (c’est-à-dire à la vitesse de la lumière, au cas où vous vous poseriez la question. Grâce à la dorsale en fibre optique, vous savez) et la détection des cibles est automatisée. Les scripts et les bots sont capables de repérer et de signaler les sites à compromettre bien plus rapidement (et à moindre coût) que les humains. C’est de la même manière que des botnets de la taille de l’Étoile de la mort sont constitués à partir d’appareils IoT non sécurisés. L’automatisation n’améliore pas seulement la productivité des gentils.
Il s’agit d’attaques non ciblées : des attaques opportunistes, si vous préférez, qui ne sont pas planifiées. Vos données ne sont peut-être ni précieuses ni intéressantes, mais vous disposez de ressources. Et ces ressources peuvent servir à trouver d’autres victimes et à perpétrer d’autres attaques et… enfin, vous savez comment cela se termine.
Les attaques non ciblées sont particulièrement fréquentes après la publication d’une CVE. En effet, votre code personnalisé est unique : même s’il comporte de nombreuses vulnérabilités, les détecter demande du temps et des efforts. Exploiter une CVE présente dans une bibliothèque ou une plateforme couramment utilisée est un jeu d’enfant. L’occasion est trop belle pour la laisser passer, car le retour sur investissement est très, très, très élevé. Le rapport DBIR 2015 de Verizon indiquait que « 70 % des attaques exploitaient des vulnérabilités connues pour lesquelles des correctifs étaient disponibles ».
C’est pourquoi l’application de correctifs – que ce soit au moyen de véritables mises à jour logicielles ou virtuellement grâce à un pare-feu applicatif web – doit être la priorité absolue dès la divulgation d’une nouvelle CVE dans l’une des bibliothèques qui constituent 79 % de votre application. Si cette CVE concerne la plateforme (comme Apache Killer), elle doit devenir la priorité « Tout laisser tomber », car l’identification des serveurs web et applicatifs est encore plus facile que la recherche de vulnérabilités dans les bibliothèques.
En réalité, même si votre notoriété n’est pas suffisante pour faire de vous une cible, vous restez exposé. Vous utilisez probablement la même pile technologique que des organisations de premier plan, ce qui signifie que les attaques non ciblées risquent fort de vous atteindre. Si vous en doutez, sachez qu’il me suffit de consulter la base de données CVE pour trouver toutes les CVE publiées concernant node.js. Ensuite, je me rends sur builtwith.com et recherche les sites web conçus avec Express, un framework node.js. Je découvre alors que le site recense « 230 116 sites web actifs utilisant Express, ainsi que 263 872 autres sites qui l’ont utilisé par le passé », et qu’il fournit même un lien pratique permettant de télécharger leur liste.
Ce n’est pas tout à fait le shodan.io des applications web, mais il n’est guère plus difficile de faire le rapprochement et de mettre au point un exploit efficace.
Ne commettez donc pas l’erreur de penser que, sous prétexte que vous n’êtes pas « assez important », vous pouvez ignorer une CVE affectant une bibliothèque ou une plateforme web.
C’est comme ça qu’on finit en tendance sur Twitter. Et pas pour les bonnes raisons.
Soyez prudent. Traitez en priorité les CVE qui affectent l’ensemble de la pile de votre application, de haut en bas.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.