Le pôle de l’OWASP en charge du projet API a décidé dernièrement d’actualiser sa cartographie des vulnérabilités API répertoriées sur sa liste API Security Top 10. Bien que la version 2023 finale de cette dernière ne soit pas encore officiellement sortie, une première possible mouture a été publiée. Six des menaces recensées sur la liste de 2019 demeurent inchangées, tandis que quatre catégories sont mises à jour ou modifiées. Voici, dans l’ordre, les principales menaces qui devraient figurer dans la liste définitive.

API1 (2023) Violation de l’autorisation au niveau de l’objet

Le vecteur d’attaque de type BOLA (Broken Object Level Authorization) a conservé sa première place en raison de la complexité et de la diversité des mécanismes d’autorisation, tous types d’API confondus. Dans l’actuel environnement de développement où tout s’accélère, il est difficile en effet de contrôler toutes les autorisations et d’analyser chaque objet pour s’assurer que seuls les utilisateurs autorisés y ont accès.

Néanmoins, l’autorisation s’inscrivant au cœur de chaque système, une faille due à une implémentation incorrecte risque d’avoir des répercussions catastrophiques, comme en attestent les récentes vulnérabilités BOLA découvertes dans le secteur automobile, où des pirates auraient pu prendre le contrôle du compte en ligne de tout propriétaire d’un modèle Ferrari.

API2 (2023) Authentification défaillante 

Les problèmes d’authentification ont, eux aussi, conservé leur place, et constituent le deuxième vecteur d’attaque. Plusieurs options permettent de profiter d’une authentification défaillante. Compte tenu de la vulnérabilité du flux d’authentification, un souci même mineur risque de compromettre la sécurité. De plus, chaque méthode d’authentification amène son propre lot de problèmes possibles, compliquant encore la protection.

Une récente étude publiée par Salt Labs fournit un exemple de cette vulnérabilité, en expliquant comment une fonctionnalité incorrecte de « social login » (identification via un compte sur un réseau social) sur Booking.com a pu donner lieu à des attaques de type ATO (Account Takeover), autrement dit occasionner des prises de contrôle de comptes.

API3 (2023) Violation de l’autorisation au niveau des propriétés de l’objet

Nouvelle catégorie, API3 BOPLA (ou Broken Object Property Level Authorization) porte sur l’autorisation au niveau des propriétés de l’objet, et fusionne deux catégories présentes en 2019 : « Exposition excessive de données » et « Attribution de masse ». 

Même si une API spécifique permet de sécuriser l’autorisation au niveau des propriétés de l’objet, cette mesure risque de ne pas suffire. Souvent, l’autorisation se doit d’être encore plus précise pour englober les objets et leurs propriétés. Le récent exemple d’incident signalé par Twitter prouve que cette catégorie n’est pas exempte de risques même pour les services les plus importants et les plus scrutés. En l’occurrence, un pirate aurait pu recenser les utilisateurs de Twitter en saisissant leurs adresses e-mail ou numéros de téléphone, puis en analysant le message d’erreur en retour. 

API4 (2023) Consommation illimitée de ressources

Cette catégorie demeure globalement inchangée. La consommation de ressources peut très vite déboucher sur plusieurs variantes d’attaques par déni de service (DoS), selon que le serveur traite de gigantesques fichiers (et épuise ses ressources processeur), que le trafic est excessif (et consomme des ressources réseau) ou que tout autre type de consommation de ressources s’opère.

L’exécution d’une attaque de ce type s’avère relativement simple, autant que le transfert d’un fichier volumineux sur une plateforme de stockage. Sa menée à bonne fin peut très vite aboutir à un déni de service, comme dans le cas d’attaques DDoS ciblant des API. C’est ainsi que récemment par exemple, le portail des services fiscaux en Pologne a été rendu inaccessible aux contribuables polonais.

API5 (2023) Violation de l’autorisation au niveau de la fonction

Avec un classement identique à celui de 2019, cette catégorie représente l’une des méthodes d’attaque visant les API les plus en vogue. L’absence de documentation adaptée pour les API, au même titre que des cycles de développement accélérés, faisant appel à des technologies CI/CD d’intégration et de diffusion continues ainsi qu’à des méthodologies analogues, peuvent être à l’origine de ce genre de vulnérabilités.

Les attaques se produisent si un point de terminaison adjacent à celui d’une API utilise une méthode HTTP différente (REST), une mutation non documentée s’opère (GraphQL), ou un autre encodage est employé. Ces points de terminaison « occultes » intègrent des fonctionnalités spécifiques bien souvent non censées être exposées au public. Si celles-ci se révèlent utiles dans le cadre d’une attaque, les assaillants peuvent exécuter des actions inconnues ou exemptes de privilèges qui en faciliteront le déroulement.

Ce scénario s’est vérifié, par exemple, avec une vulnérabilité Reddit, permettant aux utilisateurs de contourner toutes les restrictions de contenus publicitaires au moyen d’un point de terminaison PATCH « occulte » validant les publicités sans le consentement de Reddit.

API6 (2023) Falsification de requête côté serveur (SSRF)

La falsification de requête côté serveur (SSRF) représente une nouvelle catégorie, dont l’entrée dans ce classement est indispensable. 

Une faille SSRF se produit lorsqu’une URL saisie de l’utilisateur est passée par une API pour être traitée par le serveur back-end. Si le serveur back-end tente de se connecter à l’URL fournie par l’utilisateur, c’est aussitôt une porte ouverte à l’exploitation de cette vulnérabilité. Les failles SSRF peuvent revêtir différents types et différentes variantes. 

Une récente étude publiée par Salt Labs met en évidence les risques inhérents aux attaques SSRF. Dans cet exemple, les chercheurs de Salt Lab sont parvenus à accéder aux ressources du réseau interne d’une méga-plateforme de revente en ligne détenue par Lego, compromettant potentiellement les mécanismes de défense sur l’ensemble du périmètre.

API7 (2023) Mauvaise configuration de sécurité

Les erreurs de configuration de sécurité demeurent le septième vecteur d’attaque ciblant le plus fréquemment les API. Les API venant souvent se superposer, en termes de conception, à l’infrastructure sous-jacente, les composants de cette dernière doivent être configurés correctement. Une erreur de configuration risque de compromettre l’API toute entière et la totalité de ses points de terminaison.

Scénario très simple, mais courant : l’absence de définition SSL correcte pour une API occasionne la transmission de l’ensemble des requêtes via le protocole HTTP plutôt que HTTPS, créant des vecteurs d’attaque MitM (Man-in-the-Middle). Une récente vulnérabilité découverte par l’équipe de chercheurs en sécurité Wiz met en lumière le degré de gravité de ces problématiques de sécurité. 

API8 (2023) Absence de protection vis-à-vis des menaces automatisées

Cette nouvelle catégorie s’intéresse à la prédominance d’un type d’attaque ciblant les API, s’articulant autour de scénarios consistant à détourner des flux de logique applicative pour autoriser des comportements malveillants.

La détection de ces attaques n’est possible qu’en analysant l’ensemble des flux utilisateurs/requêtes, l’examen individuel de chacune des requêtes ne permettant pas de les déceler. Une étude publiée récemment révèle que des chercheurs pourraient pirater des URL abrégées et détourner leur logique applicative en déclenchant une attaque automatisée. 

API9 (2023) Mauvaise gestion du parc

Parmi les scénarios d’attaques en lien avec cette catégorie figurent ceux dans lesquels un assaillant profite de la « fragilité » d’un point de terminaison ou d’une API pour les pirater. Cette fragilité des points de terminaison peut se manifester, entre autres, lors de tests ou lors du développement d’API exposées par inadvertance au public, et qui risquent de ne pas intégrer la totalité des mesures de sécurité des API de production.

Le piratage d’Optus entre dans cette catégorie : deuxième opérateur télécoms en Australie, Optus a laissé fuiter plus de 11,2 millions de dossiers clients contenant plusieurs dizaines d’informations nominatives en raison d’une API « oubliée » accessible au public. L’opérateur a provisionné 140 M AUD pour couvrir les coûts de ce piratage.

API10 (2023) Exploitation peu sûre des API

Cette nouvelle catégorie réunit deux problématiques courantes liées aux API. L’une d’elles concerne l’exploitation des données API elles-mêmes, largement inspirées de la rubrique API8 (2019) de l’OWASP - Injection.

En 2023, cette catégorie élargit ce type d’attaques pour englober celles qui ne sont pas explicitement en rapport avec des manœuvres par injection, comme les questions de désérialisation, certaines variantes d’attaques par désynchronisation, etc. La cause première commune à toutes ces attaques tient au fait que le service back-end se montre trop laxiste en acceptant les commandes des utilisateurs transmises via les API quitte, parfois, à les utiliser aveuglément sans appliquer les validations qui s’imposent. L’exemple le plus judicieux, dans cette catégorie, est sans doute celui de la tristement célèbre faille Log4Shell.

La seconde problématique a trait à une autre attaque profitant d’un maillon faible inhérent à la conception de la quasi-totalité des systèmes actuels : l’intégration. Les intégrations peuvent comporter des fonctionnalités ou services tiers incorporés à l’implémentation de l’API ou à ses services back-end. Les attaques à partir d’API visant la chaîne logistique illustrent parfaitement le danger que représente cette catégorie. Dans cette récente étude, des chercheurs en sécurité ont mis au jour l’exécution d’une campagne malveillante reposant sur la compromission de modules externes WordPress et Magento tiers.