En quoi consistent les attaques via des API ? Pourquoi sont-elles différentes et comment les repousser ?

Les attaques à partir d'API font la une de l'actualité ces derniers temps.

Il y a quelques semaines à peine, un opérateur télécoms de premier plan en Australie a recensé un incident de sécurité orienté API, exposant les données de ses 10 millions d’abonnés. En mars 2022, un piratage d’API sur Hubspot a compromis les données confidentielles de 1,6 million d’utilisateurs. Et comment oublier la prolifération de failles de sécurité concernant des API en 2021 qui n’ont pas épargné Peloton, John Deere et Experian ? La prévision de Gartner selon laquelle « d’ici à 2022, les détournements d’API ne constitueront plus un vecteur d’attaque rare, mais extrêmement fréquent, se soldant par des piratages de données au sein des applications web d’entreprise » s’est indéniablement réalisée.

Pourquoi assistons nous à un tel flux ininterrompu d’attaques basées sur des API ? Tout simplement parce que ces API sont lucratives pour les cyberassaillants. À l’instar des agents de piste en aéroport, bâtons lumineux à bout de bras, elles guident les pirates jusqu’à leurs données les plus précieuses.

Or, un dilemme se pose car les API servent également aujourd’hui de moteur à l’économie digitale. Il serait inconcevable de s’en priver ou d’en limiter l’accès sans ralentir l’innovation d’entreprise. Le seul véritable choix dont vous disposez consiste à sécuriser vos API contre les attaques actuelles (et futures) afin de faire en sorte que votre entreprise puisse continuer à étoffer et déployer les services attendus par vos clients.

Nombre d’entreprises estiment, à tort, que le principe de « la sécurité par l’obscurité » suffit à les protéger : elles ne sont pas suffisamment connues, leurs données ne sont pas suffisamment intéressantes, leurs API sont suffisamment disparates, elles sont suffisamment sûres… Malheureusement, ce raisonnement n’a jamais été probant et ne le sera sans doute jamais dans l’univers « API-first », régi par l’omniprésence des données et les connexions numériques.

Qu’est-ce qu’une attaque via une API ?

Une attaque via une API est tout simplement une utilisation hostile d’une API (ou une tentative en ce sens). Les assaillants se servent du point de terminaison d’une API pour accéder aux données et les exploiter. Parfois, ces attaques sont perpétrées à cause d’un code foncièrement médiocre. Mais le plus souvent, elles ciblent des vulnérabilités inhérentes à la logique métier, s’efforçant d’associer aux API des comportements que leurs développeurs n’avaient pas prévus.

Pour compliquer encore la donne, chaque vulnérabilité d’une API représente, en substance, une vulnérabilité jour zéro. Étant donné que les API sont propres à chaque entreprise, leurs failles de sécurité diffèrent. Par conséquent, pour comprendre comment les exploiter efficacement, les pirates n’ont d’autre choix que de scruter (encore et encore) les API afin de mettre au jour les erreurs de logique métier et de se familiariser avec les vulnérabilités de chacune. Le repérage de ces attaques de type « low and slow » (basses et lentes), qui peuvent être menées plusieurs jours, semaines et même mois durant, nécessite une analyse comportementale dans la durée.

En quoi les attaques actuelles via des API sont-elles différentes ?

À mesure que les API se sont multipliées, les menaces elles-mêmes ont évolué. Ce nouveau modèle d’attaques a surgi car les API reposent sur la logique métier et la logique applicative sous-jacente. Ainsi qu’il est dit plus haut, les risques de sécurité les plus significatifs qui pèsent sur les API découlent de failles dans la logique métier.

Les attaques liées aux transactions, comme celles par injection SQL, englobent la majorité des atteintes à la sécurité opérées jusqu’ici. Les solutions de sécurité classiques basées sur un serveur proxy, comme un pare-feu applicatif web (WAF), se révèlent efficaces pour stopper des attaques de ce type ; ces solutions WAF isolent les profils connus et agissent comme un pare-feu, bloquant le trafic illégitime. Néanmoins, ces approches de sécurisation des API, qu’elles soient basées sur un serveur ou sur une machine virtuelle, ne s’appuient pas sur un jeu de données historiques suffisamment étoffé pour repérer les attaques sophistiquées à partir d’API.

Dans les attaques orientées logique applicative, les pirates utilisent la reconnaissance sur une durée temporelle étendue aux fins de repérer les défauts de programmation dans la logique métier. Ils recherchent les domaines susceptibles d’être exploités, en se ménageant un accès non autorisé aux données ou fonctionnalités au sein de l’API, ou profitent des faiblesses de l’API pour lancer des attaques en déni de service (DoS) ciblées, ralentissant fortement le trafic légitime.

De ce fait, les attaques émanent rarement d’un seul appel API. Les assaillants passent plusieurs appels API dans le cadre de leurs actions de reconnaissance. Si les solutions de sécurité classiques permettent de se prémunir contre les vulnérabilités connues, elles ne permettent pas de mettre au jour ces vulnérabilités API basées sur la logique. Il leur manque la fonction et la logique métier nécessaires.

Afin de protéger les API, les entreprises doivent être en mesure de repérer les vulnérabilités basées sur la logique au sein des API. Pour ce faire, il leur faut un contexte pour la logique comme pour la fonction métier. Les équipes de sécurité doivent observer les points de terminaison des API à l’œuvre et cerner l’enjeu fonctionnel de chacun d’eux. Elles doivent également appréhender les caractéristiques comportementales de chacun des paramètres et éléments utilisés par ces points de terminaison. À un seul point de terminaison API peuvent correspondre plusieurs milliers de permutations possibles de la logique métier et applicative sous-jacente, qu’il convient de vérifier et de mettre en pratique pour déterminer si des comportements négatifs pourraient lui être incriminés.

Quels sont les types d’attaques via des API les plus fréquents ?

L’OWASP (Open Web Application Security Project), l’organisme qui a établi le « Top 10 » des vulnérabilités API, a fait l’essentiel du travail pour aider le marché à décrypter les attaques les plus courantes ciblant les API. Fin 2019, l’OWASP publiait sa toute première version de cette liste de vulnérabilités, API Security Top 10, répertoriant les dix premiers types d’attaques via des API suivants :

• API1 (2019) Violation de l’autorisation au niveau de l’objet – L’attaque de type BOLA (Broken Object Level Authorization) est la menace la plus fréquente côté API, représentant 40 % de toutes les attaques ciblant celles-ci.
• API2 (2019) Authentification utilisateur défaillante – Une authentification utilisateur défaillante permet aux pirates de recourir à des jetons d’authentification dérobés, au credential stuffing (ou « bourrage d’identifiants ») et à des attaques par force brute pour se ménager un accès non autorisé à des applications.
• API3 (2019) Exposition excessive de données – Lorsque des API génériques exposent davantage de données que nécessaire, un assaillant peut exploiter une application en se servant de celles-ci pour extraire quantité de données confidentielles.
• API4 (2019) Manque de ressources et limitation du débit – Les API qui ne mettent pas correctement en œuvre la limitation de débit ou ne l’implémentent pas sont extrêmement vulnérables aux attaques par force brute.
• API5 (2019) Violation de l’autorisation au niveau de la fonction – Si l’autorisation n’est pas correctement implémentée, des utilisateurs non autorisés peuvent exécuter des fonctions via l’API, comme l’ajout, la mise à jour ou la suppression d’une fiche client ou d’un rôle utilisateur.
• API6 (2019) Attribution de masse – Les API qui utilisent directement les demandes de saisie pour les assigner/écrire dans les magasins de données dédiés logique métier sont vulnérables à l’attribution de masse, laquelle permet à des pirates de modifier des propriétés de données critiques et d’exploiter l’élévation de privilèges.
• API7 (2019) Mauvaise configuration de sécurité – Cette appellation fourre-tout englobe un large éventail d’erreurs de configuration de sécurité qui portent souvent préjudice à la sécurisation des API dans son ensemble et introduisent malencontreusement des vulnérabilités.
• API8 (2019) Injection – Cette attaque demeure une menace depuis l’établissement de la première liste « Top 10 » de l’OWASP, les autres 90 % étant nouvelles et uniquement ciblées sur les API. Les assaillants exploitent des vulnérabilités par injection en adressant des données malveillantes à une API qui sont à leur tour traitées par un interpréteur ou analysées par le serveur d’applications avant d’être transférées à un quelconque service intégré.
• API9 (2019) Mauvaise gestion des ressources – Un parc obsolète ou incomplet donne lieu à des failles inconnues dans la surface d’attaque des API et complique l’identification des anciennes versions d’API à mettre hors service.
• API10 (2019) Journalisation et surveillance insuffisantes – Une journalisation et une surveillance insuffisantes, conjuguées à une intégration inexistante ou inefficace avec la réponse aux incidents, permettent aux pirates de se livrer à des opérations de reconnaissance, d’exploiter ou de détourner des API, de compromettre des systèmes, de cultiver la persistance, de perfectionner leurs attaques et de se déplacer latéralement entre environnements sans être détectés.

Malheureusement, le rapport « State of API Security » de Salt Security pour le 3e trimestre 2022 indique que 55 % seulement des participants s’en remettent à la liste « Top 10 » des vulnérabilités API établie par l’OWASP. Étant donné que 62 % des tentatives d’attaques dirigées contre les entreprises mettent à profit au moins une des méthodes exposées, autant dire qu’ils se privent là d’un outil précieux.

Mes outils sont-ils actuellement suffisants pour protéger la surface d’attaque de nos API ?

Comme indiqué précédemment, les API exigent une nouvelle approche de sécurisation avec des solutions dédiées reposant sur une architecture plus évoluée que celle des outils traditionnels qui se contentent d’analyser individuellement des transactions hors de leur contexte.

Dans une récente note de recherche, Gartner reconnaît que des solutions dédiées sont nécessaires et ajoute un palier distinct à son architecture de sécurité de référence : la sécurisation des API. Ce nouveau palier s’intercale entre les outils traditionnels de type pare-feu applicatifs web (WAF), protection des applications web et des API (WAAP), passerelles API et réseaux de diffusion de contenu (CDN) qui assurent une protection en périphérie, et les outils qui protègent les données et le plan de contrôle. Malgré cette nouvelle architecture, Gartner affirme que ces outils traditionnels ne colmatent pas toutes les failles liées à la protection des API.

Pour protéger les API, les entreprises ont besoin d’une plateforme spécifiquement créée pour répondre aux actuels impératifs de sécurisation les concernant, à savoir :

• Visibilité – La prolifération des API se poursuivant à un rythme effréné, il est pratiquement impossible de demeurer au fait des nouveautés et des modifications dans ce domaine. Les entreprises ont également besoin d’éclaircissements sur les endroits précis auxquels leurs API exposent des données névralgiques.
• Prévention des attaques – Chaque API étant unique, les attaques les concernant le sont aussi, et les entreprises doivent être en mesure de détecter les comportements de type « low and slow » (bas et lent) des pirates sondant les API à la recherche de faille dans la logique métier.
• Sécurité anticipative – Les enseignements des mesures correctrices, tirés des tests de préproduction ainsi qu’à l’exécution, aident les développeurs à renforcer leurs API. Les entreprises ne doivent pas tabler à l’excès sur les tactiques « shift-left » (correspondant à un virage à gauche de la sécurité). Néanmoins, les tests de préproduction ne mettront pas au jour les failles de la logique métier : la création d’API sécurisées ne sera donc pas systématiquement au rendez-vous côté développeurs.

Pour empêcher les attaques via des API, vous devez d’abord connaître le type d’API dont vous disposez.

Si une vue précise de la surface d’attaque est essentielle pour éclairer votre stratégie de sécurisation, son obtention se révèle parfois particulièrement complexe du fait de l’évolution incessante des API. De fait, une récente étude réalisée par Salt Security établit que 11 % des participants font un point quotidien sur leurs API et que 31 % d’entre eux en dressent un bilan hebdomadaire.

Il est impératif d’identifier la totalité des API dans votre environnement, y compris les API shadow ignorées, comme dans l’exemple ci-avant, et les API zombie qu’il convient de désactiver. Leur découverte doit être automatique et continue pour ne pas se laisser distancer par les publications constantes de nouveautés et de mises à jour, et doit englober toutes les API orientées clients, orientées partenaires (mises à disposition et exploitées) et internes.

Il ne suffit pas de savoir qu’une API existe. Il est primordial de cerner très précisément chacune d’elles pour appréhender la fonctionnalité visée, évaluer les risques et déterminer si l’API en question expose des données confidentielles telles que des informations nominatives. La découverte automatique et continue garantit que la vue de la surface d’attaque et de l’exposition des données névralgiques demeure actualisée en permanence.

L’utilisation de mégadonnées à l’échelle du cloud et la maturité des modèles IA contribuent à mettre obstacle aux attaques via des API.

Les pirates ciblant les API recourent à des méthodes subtiles pour mettre au jour les vulnérabilités et les exploiter. Prenons le cas d’escrocs s’efforçant de détourner des transferts ACH au profit de comptes illégitimes. Ces escrocs pourraient exploiter une vulnérabilité API courante et manipuler les numéros de comptes en modifiant uniquement quelques paramètres d’API.

Pour repérer leur manège, il vous faut une solution conjuguant mégadonnées, IA et ML afin de prendre en compte la totalité du trafic API, de définir un cadre de référence correspondant à l’activité normale, et de rechercher les écarts. Dans l’exemple ci-avant, ce type de solution permettrait de repérer la manipulation des numéros de comptes et le subtil changement de bénéficiaire, et de signaler l’activité.

Seule une architecture de mégadonnées à l’échelle du cloud, assortie d’outils d’intelligence artificielle (IA) et de machine learning (ML), est capable de prendre en compte et d’analyser en continu de gros volumes de trafic API. L’analyse continue du trafic API est le seul moyen de prendre la juste mesure du comportement normal de chaque API et de disposer du contexte nécessaire pour repérer les écarts difficilement perceptibles et localiser les assaillants.

La protection des API passe également par une analyse du trafic API dans la durée. De par leur nature, les API exposent la logique applicative. Les pirates multiplient les essais pour tenter d’identifier les failles susceptibles d’être exploitées dans la logique métier. Les opérations de reconnaissance indispensables à la multiplication d’attaques de ce type prennent énormément de temps. Le déploiement d’une seule attaque via une API peut prendre des heures, des jours, voire des semaines.

Une fois la fuite colmatée, l’heure est à l’éradication des futures failles.

Les équipes DevOps ont beau jouer un rôle essentiel dans la sécurité, malgré les bonnes pratiques et les outils d’analyse mis en œuvre, leurs publications logicielles contiendront inévitablement des failles. Les API ne font pas exception. Prises à la gorge par les pratiques de développement agile et les cycles de lancement serrés, les équipes de développement risquent de faire l’impasse sur la sécurité pour tenir des délais extrêmement justes.

La protection à l’exécution est fondamentale pour empêcher l’exploitation de toute vulnérabilité jusqu’à la production. Pour autant, s’en remettre exclusivement à celle-ci revient à jouer virtuellement au chat et à la souris. Pour améliorer la sécurité des API, les failles doivent être perpétuellement identifiées et éliminées.

À l’heure actuelle, les solutions de premier plan en matière de sécurisation des API permettent de faire barrage aux escrocs et d’en apprendre davantage sur leurs activités à mesure qu’ils sondent et manipulent les API. Ces connaissances éclairent sur les vulnérabilités propres à chacune et aident les équipes de développement à hiérarchiser les priorités et à éradiquer les failles rapidement.

Il s’agit d’une course permanente ! Les solutions de sécurisation des API doivent analyser les API pour repérer les failles avant qu’un pirate ne les découvre, et permettre ainsi aux développeurs de prendre les devants en éradiquant de possibles vulnérabilités tout en aiguisant leurs bonnes pratiques au profit de la sécurité des API.