Dans un paysage des menaces en constante évolution, les cybercriminels font désormais des API leur nouvelle arme de prédilection pour commettre des fraudes par prise de contrôle de compte (ATO), car elles offrent un accès direct à des ressources et à des fonctionnalités précieuses. Les menaces liées aux API sont devenues si préoccupantes que l’OWASP vient de publier son nouveau classement des 10 principaux risques de sécurité des API en 2023 afin d’attirer l’attention sur les domaines auxquels les organisations doivent remédier.
Les cybercriminels ont réorienté leurs tactiques de prise de contrôle de comptes (ATO) vers les API, en utilisant des bots malveillants pour mener des attaques allant du bourrage d’identifiants et de l’exploitation abusive de la logique métier aux attaques DDoS, qui entraînent souvent des interruptions de service des applications, des usurpations d’identité et des fraudes. Ces attaques sont plus faciles que jamais à orchestrer grâce à des outils facilement accessibles et sont difficiles à détecter avec les techniques traditionnelles de défense contre les bots.
Selon les estimations du bureau du directeur technique de F5, le nombre d’API en production augmentera de manière exponentielle au cours des prochaines années. D’ici 2030, entre 500 millions et plus de 1,5 milliard d’API pourraient être en production. Malheureusement, c’est une excellente nouvelle pour les cybercriminels, qui cherchent constamment à élargir leurs cibles.
La prolifération des API crée de nombreux angles morts susceptibles d’entraîner des vulnérabilités
- Une conception ouverte et une structure prévisible créent de nombreuses portes ouvertes faciles à sonder.
Les développeurs ont tendance à créer des API flexibles aux structures prévisibles, conformes à des architectures logiques (telles que REST), ce qui permet aux cybercriminels de rechercher facilement d’autres données susceptibles d’avoir été exposées. - La visibilité réduite entre les différentes entités de l’organisation complique la surveillance de l’activité des API, surtout lorsque vous ignorez jusqu’à leur existence.
Les API sont souvent publiées avant même que les équipes SecOps en aient connaissance, ce qui crée un écosystème d’API fantômes ou zombies et empêche d’obtenir une visibilité de bout en bout sur le trafic des API. - La complexité accrue engendre des API non gérées et non sécurisées, ce qui élargit la surface d’attaque.
Les environnements distribués et la multiplication des services compliquent la détection, la gestion et la surveillance systématiques de toutes les API, ce qui entraîne une augmentation du nombre de menaces et une vulnérabilité accrue aux incidents de sécurité et de confidentialité.
Les contrôles de sécurité existants peuvent ne pas protéger les API contre les attaques par prise de contrôle de compte (ATO)
Les attaques modernes menées par des bots malveillants continuent d’évoluer, si bien que les outils traditionnels de prévention contre les bots ne parviennent plus à maintenir leur efficacité. Ce problème risque de s’aggraver pour les API, car les attaques de bots les ciblent de façons toujours plus nombreuses et inédites, allant de l’automatisation des analyses exploratoires à la manipulation des ressources et à l’exploitation des vulnérabilités de la logique métier, en passant par les attaques par bourrage d’identifiants et par injection.
Les attaques par bourrage d’identifiants visant les API illustrent parfaitement pourquoi les stratégies traditionnelles de lutte contre les bots ne suffisent pas à vous protéger. Certaines API fournissent des jetons d’authentification après la saisie d’un nom d’utilisateur et d’un mot de passe, comme lors de la connexion à un site web. Ce jeton est généralement utilisé pour toutes les autres requêtes adressées à l’API. Ce fonctionnement est courant dans les API, en particulier les plus anciennes, et les rend vulnérables aux attaques par bourrage d’identifiants et par pulvérisation de mots de passe.
Il est difficile de faire la distinction entre les attaquants et les véritables clients, car ces types d’attaques ciblées contournent la plupart des contrôles traditionnels. Les contrôles de sécurité traditionnels, tels que les pare-feu d’applications web (WAF) de base et les systèmes de gestion des informations et des événements de sécurité (SIEM), ne suffisent pas à détecter et à prévenir les attaques de bots contre les API, notamment en raison du volume élevé de trafic de machine à machine, ou d’API à API. En apparence, les attaques peuvent ressembler au comportement normal d’une application, mais en coulisses, les API peuvent être exploitées et utilisées de manière abusive, ce qui permet aux attaquants d’échapper à la détection jusqu’à ce qu’il soit trop tard.
Une stratégie efficace de sécurité des API contre les attaques par prise de contrôle de compte exige une vigilance sur plusieurs fronts
La sécurité des API est une responsabilité partagée à l’échelle de l’organisation. Il est donc d’autant plus important de se préoccuper des attaques automatisées par des bots qui entraînent des compromissions et des violations de données, ainsi que de celles qui affectent la disponibilité et la fiabilité, tant pour les applications web existantes que pour les architectures d’API modernes.
En matière de sécurité des API et de protection contre les accès non autorisés via les API, qu’il s’agisse de bourrage d’identifiants, d’attaques par force brute ou d’autres mécanismes de tentatives de connexion forcées, un moteur d’IA/ML sophistiqué peut aider à détecter les tentatives de connexion infructueuses ou les tentatives visant à découvrir les paramètres des API, puis à les signaler aux équipes opérationnelles afin qu’elles les examinent.
“Dans le rapport State of Application Strategy de l’année dernière, 68 % des personnes interrogées ont classé l’authentification et l’autorisation comme les composants les plus importants de la sécurité des API, suivis de près par l’analyse comportementale et la détection des anomalies pour surveiller les API en production (à l’exécution).”
Les organisations peuvent renforcer la sécurité de leurs API de plusieurs manières, notamment en validant les connexions et les accès, en surveillant les comportements au fil du temps et en générant des alertes, ainsi qu’en facilitant la détection des comportements inhabituels des clients afin d’identifier les éventuelles failles de sécurité.
- Surveillez et protégez en permanence les points de terminaison d’API afin d’identifier les évolutions des intégrations d’applications, de détecter les composants vulnérables et d’atténuer les attaques menées par le biais d’intégrations tierces.
- Mettez en œuvre un modèle de sécurité positive qui s’intègre à votre pipeline CI/CD et prend en charge les spécifications d’interface OpenAPI et Swagger afin de valider facilement les schémas, de garantir la conformité aux protocoles, d’établir automatiquement une référence des modèles de trafic normaux et de détecter les comportements anormaux.
- Adoptez le modèle Zero Trust et une sécurité fondée sur les risques en appliquant les principes d’accès selon le moindre privilège, en inspectant les charges utiles, en empêchant l’exposition non autorisée des données et en mettant en œuvre un contrôle des accès ainsi qu’une authentification fondée sur les risques pour les objets et les fonctions. Cela doit inclure la collecte de renseignements et l’établissement d’un profil de référence du comportement normal des bots vis-à-vis de vos API. Grâce à l’analyse des comportements et des schémas, à la validation des workflows et à la prise d’empreintes, vous pouvez distinguer l’activité humaine de celle des bons et des mauvais bots.
- Adaptez-vous à l’évolution du cycle de vie des applications en empêchant les erreurs de configuration de sécurité dans les environnements hétérogènes, en limitant les abus susceptibles d’entraîner une compromission ou un déni de service, et en corrigeant les menaces de manière cohérente dans les différents clouds et architectures. Continuez à analyser, tester et surveiller vos API afin de détecter les erreurs de configuration, les vulnérabilités et les failles de logique métier.
Vous devriez envisager de disposer d’une vue centralisée de la sécurité de vos API afin de permettre à votre organisation d’agir rapidement, d’identifier les problèmes potentiels au sein de votre environnement d’API, de les examiner en détail, d’enquêter et de prendre les mesures appropriées pour neutraliser toute anomalie ou menace susceptible d’affecter la connectivité, la disponibilité ou la sécurité des applications et des API.
Découvrez comment prévenir les attaques par prise de contrôle de compte dans ce webinaire à la demande.
Liste des ressources
- Livre blanc sur les bonnes pratiques en matière de sécurité des API
- Rapport de recherche 2022 de Google Cloud sur la sécurité des API : dernières analyses et tendances clés
- Livre blanc sur F5 Distributed Cloud WAAP avec une sécurité complète des API
- Maîtriser l’architecture des API — eBook O’Reilly
À propos de l’auteur
Articles 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.