Les failles dans la sécurité des applications web
Une sécurité disparate entraîne des compromis
L'histoire de l'entreprise A et l'entreprise B
Voici l'histoire de l'entreprise A et de l'entreprise B, dont les solutions de la sécurité des applications web et des API, en apparence différentes, ont en commun un défaut aussi subtil que crucial. Ce défaut a entraîné des violations de données (et à toutes les conséquences négatives associées) pour les deux entreprises.
L'entreprise A a mis en place une protection des API aussi sécurisée que possible. Elle bloque toutes les violations de schéma, limite les débits excessifs de requêtes et utilise les dernières informations sur les menaces pour établir une liste de blocage des adresses IP malveillantes connues. Sa méthode d'authentification des API à base de mots de passe pourrait être plus sécurisée si elle était remplacée par une authentification Mutual TLS, mais elle n'a encore jamais subi de violation.
Cependant, sa stratégie de sécurité des API, son flux d'informations sur les menaces et son pare-feu WAF proviennent de fournisseurs différents. Et au gré des mises à jour des différents fournisseurs, les informations sur les menaces utilisées pour informer sa stratégie de sécurité des API ont cessé d'être compatibles avec son pare-feu WAF, qui protège sa page de connexion aux comptes. En conséquence, un attaquant est en mesure d'exploiter une nouvelle vulnérabilité par injection SQL sur cette page, et ainsi, d'obtenir le nom d'utilisateur, ainsi que le mot de passe d'un utilisateur légitime. L'acteur malveillant transmet ensuite à son API des requêtes authentifiées, validées par schéma, et obtient une quantité importante de données sensibles.
Pendant ce temps, l'application web de l'entreprise B est entièrement sécurisée contre les attaques DDoS. L'entreprise B expose également une API aux utilisateurs payants qui souhaitent intégrer leur solution avec l'application de l'entreprise B.
L'acteur malveillant achète une clé d'API d'utilisateur payant légitime sur le Dark web. À l'aide de cette clé, l'attaquant lance une attaque DDoS lente, à faible intensité contre le serveur d'API de l'entreprise B. L'attaquant active un bot qui transmet des requêtes à intervalles irréguliers. Chaque appel d'API transmis par le bot est considéré comme légitime et accepté par le serveur d'API, car il provient d'une clé d'API légitime. Malheureusement pour l'entreprise B, son équipe backend a oublié de configurer le serveur d'API en proxy via le fournisseur de sa solution d'atténuation des attaques DDoS, bien que tous les autres serveurs soient protégés.
Tandis que les requêtes s'accumulent, le serveur d'API sature progressivement et finit par ne plus pouvoir servir les autres utilisateurs de l'entreprise B. Au comble de la frustration, nombre d'entre eux résilient leur compte payant.
Quel problème les entreprises A et B avaient-elles en commun ?
Les solutions disparates entraînent des omissions et des failles.
Dans ces exemples, les solutions de sécurité des applications web et des API des deux entreprises reposaient sur un amoncellement de solutions provenant de différents fournisseurs. Les solutions n'étaient pas intégrées et favorisaient les erreurs manuelles.
Pour comprendre en quoi cette situation est problématique, réfléchissez aux composantes classiques d'un cadre de sécurité des applications web et des API :
Pare-feu WAF : bloque les attaques contre les applications et propriétés web
Gestion des bots : vérifie ou bloque les bots vraisemblablement malveillants
Atténuation des attaques DDoS : protège la présence en ligne des propriétés malgré les attaques DDoS de toute sorte (qu'il s'agisse d'attaques volumétriques ou d'attaques lentes, à faible intensité)
Protection des API : comprend la limitation de débit, la validation de schéma, l'authentification et d'autres fonctions pour les API
L'entreprise A et l'entreprise B avaient adopté l'ensemble de ces protections. Cependant, la grande disparité de leurs solutions de sécurité des applications web, aussi perfectionnées soient-elles, avait entraîné des failles que les acteurs malveillants étaient en mesure d'exploiter.
Pour l'entreprise A, le pare-feu WAF et la protection API, qui étaient superposés, plutôt qu'intégrés, ont dû subir et bloquer l'attaque. Or, des attaques pouvant être déjouées par une solution peuvent tromper l'autre. La protection contre les attaques DDoS de l'entreprise B n'a pas permis de protéger son infrastructure d'API ; sa solution de gestion des bots n'a pas détecté les appels d'API provenant de bots, et son authentification était faible et facile à compromettre.
Il ne s'agit là que de quelques exemples de failles potentielles. Parmi les autres failles courantes dans la sécurité des applications web, citons les suivantes :
Informations limitées sur les menaces : les informations sur les menaces ne sont pas à jour, ne sont pas au bon endroit ou ne sont pas dans un format compatible. C'est ce qui s'est produit dans le cas de l'entreprise A.
Trop d'informations sur les menaces provenant de trop de sources : ce problème entraîne des faux positifs, de la redondance et d'autres manifestations d'inefficacité.
Faux positifs lors de l'identification de bots : ce problème peut être une source de frustration pour les utilisateurs, ralentir le service et nuire à l'application des mesures de protection.
Lassitude liée aux alertes : une entreprise utilise en moyenne 45 outils de cybersécurité provenant de différents fournisseurs, générant tous des alertes. Une trop grande disparité dans les produits peut inciter les employés à ignorer certaines menaces, afin de pouvoir se consacrer à leur travail.
Authentification insuffisante : les deux entreprises, A et B, étaient d'une façon ou d'une autre vulnérables au vol d'identifiants.
Absence d'évolutivité de la défense contre les menaces : les équipements physiques de sécurité provoquent un goulet d'étranglement du trafic et sont saturés lors d'attaques massives ou en cas d'attaques variées.
Ces failles représentent un risque grandissant à mesure que les cyberattaques gagnent en complexité et en sophistication. Selon McKinsey, parmi les acteurs malveillants « figurent [aujourd'hui] des organisations hautement sophistiquées, qui ont recours à des outils et des fonctions intégrés, ainsi qu'à l'intelligence artificielle et à l'apprentissage automatique. » Souvent, les acteurs malveillants modernes évoluent et améliorent leurs tactiques plus rapidement que leurs cibles.
Le risque ajouté des API
Les API deviennent de plus en plus importantes pour l'infrastructure des applications web des entreprises modernes. Aujourd'hui, 58 % de l'ensemble du trafic dynamique traité par Cloudflare est basé sur des API, et cette proportion ne cesse d'augmenter. En réalité, de nombreuses entreprises se décrivent comme « orientées API ». Qui plus est, Cloudflare bloque désormais un pourcentage plus élevé de trafic en lien avec les API que de trafic web, ce qui confirme que les acteurs malveillants ont bien les API en ligne de mire.
Les API étant très souvent profondément intégrées aux applications web, leur sécurité est primordiale. Les équipes internes, aussi bien intentionnées soient-elles, déploient souvent trop hâtivement les API, et il n'est pas rare qu'elles le fassent sans consulter les équipes responsables de la sécurité. C'est pourquoi, à l'examen de l'origine des violations d'applications web, c'est souvent le manque de sécurité des API qui est en cause.
Prenons l'exemple d'une violation en lien avec une API dont ont été victimes les services postaux américains (USPS, United States Postal Service) ; il s'est avéré qu'aucune autorisation de base n'était accordée à l'API assurant le suivi en temps réel des colis. Les utilisateurs connectés pouvaient interroger le compte de n'importe quel autre utilisateur en utilisant des paramètres de recherche contenant des caractères génériques, qui leur révélaient tous les enregistrements de jeux de données. Cette faille a exposé les données de 60 millions de détenteurs de comptes USPS.
Une solution consolidée
Et si, au lieu d'utiliser un amoncellement de produits de sécurité, l'entreprise A et l'entreprise B avaient regroupé tous leurs services de sécurité des applications web et des API sur une plateforme consolidée unique ? Et si les différents services étaient intégrés les uns avec les autres ? Et si les données concernant l'état de l'infrastructure de l'entreprise étaient toutes présentées dans une même interface, permettant aux entreprises d'évaluer rapidement les attaques et leur stratégie de sécurité ?
L'entreprise A aurait pu vérifier que tous les composants de son cadre de sécurité des applications web et des API disposaient des toutes dernières informations sur les menaces et arrêter l'attaque avant son lancement, puisque toutes les fonctionnalités auraient été regroupées sur une même plateforme. Il aurait été plus facile pour l'entreprise B d'étendre sa protection contre les attaques DDoS à l'ensemble de ses serveurs.
Le recours à une plateforme facilite la gestion et limite le nombre de failles.
Cette méthode consolidée de la sécurité des applications web exige une infrastructure hautement évolutive, capable d'assurer le traitement en proxy de tous les types de trafic. Au cours des dernières décennies, les organisations ont acheté des équipements lorsqu'elles avaient besoin de se défendre contre les nouvelles attaques ou qu'elles avaient besoin d'évoluer. Cependant, les services dans le cloud sont plus facilement évolutifs et doivent permettre le traitement en proxy de n'importe quel type d'infrastructure. Et quand bien même une plateforme consolidée ne constitue pas une garantie contre toutes les attaques, elle aurait certainement été d'une grande aide pour nos entreprises fictives.
Plus qu'une expérience imaginaire : l'importance croissante des plateformes WAAP
Il ne s'agit pas simplement d'une hypothèse dans le cadre d'une expérience imaginaire. Gartner définit ces services consolidés comme la « protection des API et applications web », ou WAAP (« Web Application and API Protection »). En 2022, Gartner prévoyait que « d'ici à 2024, 70 % des organisations mettant en œuvre des stratégies multicloud pour les applications web dans les environnements de production privilégieraient les services de plateformes de protection des applications web et des API (WAAP) dans le cloud par rapport aux équipements WAAP et aux solutions WAAP IaaS-native ».
WAAP n'est pas simplement un acronyme : la consolidation du pare-feu WAF, de la gestion des bots, de la protection contre les attaques DDoS, de la sécurité des API et d'autres services devient de plus en plus essentielle pour les entreprises modernes. La nature intrinsèquement mondiale d’Internet expose en permanence les applications web et les API aux attaques lancées depuis différents endroits, avec différents niveaux d’ampleur et de complexité. Il n'est donc pas étonnant qu'en 2022, IBM déclarait que 83 % des entreprises interrogées avaient été victimes d'une violation de données, pour un coût moyen de 4,35 millions de dollars dans le monde et de 9,44 millions de dollars aux États-Unis.
Un autre facteur à prendre en considération : l'hétérogénéité des infrastructures
Si l'entreprise A et l'entreprise B devaient créer intégralement leurs applications et leurs API aujourd'hui, elles pourraient les héberger entièrement dans le cloud, éventuellement auprès d'un fournisseur d'hébergement unique, afin d'en faciliter le déploiement. Dans la réalité, toutefois, la plupart des organisations ont déployé une infrastructure hybride avec des serveurs de base de données existants sur site, des API cloud de fournisseurs tiers et des services d'application hébergés dans différents clouds. Ces déploiements présentent de nombreux avantages, mais ils comportent également des difficultés qui leur sont propres en matière de sécurité.
Par exemple, la sécurité native proposée par un fournisseur de cloud donné ne s'étend pas forcément à l'ensemble de l'infrastructure. Pour commencer, l'identification et la cartographie de toute l'infrastructure afin d'être en mesure d'en assurer la défense peuvent s'avérer difficiles. Enfin, il existe un risque d'incompatibilité entre les produits de sécurité et les autres solutions de votre pile technologique.
Par conséquent, en plus de consolider les fonctionnalités essentielles de sécurité des applications web, la solution WAAP doit être indépendante de l'infrastructure, ce qui signifie qu'elle doit pouvoir être intégrée devant tout type d'infrastructure ou de déploiement dans le cloud.
Une sécurité web consolidée, indépendante de l'infrastructure
L'offre de Cloudflare est cloud-native et indépendante de l'infrastructure ; sa solution contribue à la sécurité des applications web depuis plus d'une décennie et réunit toutes ces fonctionnalités sur une plateforme consolidée, dans une interface unique. Cloudflare offre également l'avantage d'observer une importante proportion du trafic Internet, puisque son réseau sert plus de 63 millions de requêtes HTTP par seconde et bloque, en moyenne, ~165 milliards de cybermenaces chaque jour. Ceci confère à Cloudflare une visibilité unique sur les menaces zero-day et les nouvelles attaques.
Cet article fait partie de notre série consacrée aux nouvelles tendances et évolutions susceptibles d'affecter les décideurs en matière de technologies d'aujourd'hui.
Approfondir le sujet
Cloudflare a été reconnue Leader dans le rapport Gartner® Magic Quadrant™ de 2022 consacré à la protection des API et des applications web (« Web Application and API Protection », WAAP).
Points clés
Cet article vous permettra de comprendre les points suivants :
Les solutions de sécurité disparates peuvent créer des lacunes en matière de sécurité
Des exemples de la manière dont ces failles se manifestent
Gartner recommande d'opter pour la consolidation sur une plateforme de sécurité des applications web indépendante de l'infrastructure