Les API, qui existent depuis près de 20 ans, ont considérablement évolué depuis leurs débuts. Alors utilisées par un nombre limité d’entreprises, elles satisfaisaient un nombre limité de besoins. Ces dernières années, leur usage s’est intensifié, ces API deviennent de plus en plus répandues au sein des environnements applicatifs des entreprises de toutes tailles où elles adressent une variété inépuisable de scénarios d’utilisation. Gare, elles sont devenues des cibles de choix pour les attaques selon Nico Wagemans, VP EMEA de Salt Security. Ses conseils pour les lecteurs de Solutions-Numériques.
À l’heure actuelle, les API sont indissociables des environnements applicatifs dont elles accélèrent le développement et dynamisent les initiatives de transformation digitale. Elles mettent clients et partenaires en relation avec un grand nombre de services. Les API d’aujourd’hui dévoilent davantage de données confidentielles qu’auparavant, faisant d’elles des cibles de choix pour les attaques. Puisque les API sont devenues à la fois omniprésentes et cibles privilégiées des hackers, les entreprises se révèlent plus sensibles à la nécessité d’une sécurisation adaptée mais, comme pour l’adoption de toute technologie nouvelle, des idées fausses subsistent sur la manière d’y parvenir.
Le constat en 3 points
1- Méconnaissance
Nombre d’entreprises n’ont pas pris conscience des risques présentés par les API, faute d’informations et de visibilité suffisantes sur leur surface d’attaque. Jusqu’ici, la visibilité sur les API était tributaire d’interventions manuelles incapables de restituer une vue d’ensemble et les changements constants compliquent encore la visibilité. Lorsqu’il s’agit de prendre en considération les risques que présentent les API dans leur environnement, les entreprises se classent souvent dans une ou plusieurs des catégories ci-après.
-Nous n’avons pas d’API…
Certains acteurs estiment être dépourvus d’API. Or, en réalité, les API sont partout, et la plupart des entreprises aujourd’hui y ont recours d’une manière ou d’une autre dans leur environnement. Ces API sont intégrées aux applications clients, à l’écosystème des partenaires, et aux environnements cloud et microservices.
-Nous n’avons pas énormément d’API
Même les clients qui savent qu’ils possèdent des API connaissent rarement leur nombre total. Les API shadow (fantômes) inconnues et les API zombies oubliées présentent un risque latent non négligeable.
Même lorsque la composition totale du parc d’API semble être connue, ce n’est guère suffisant. Une étude Salt met en évidence des écarts de l’ordre de 40 % dès lors que l’on compare la documentation fournie par le client à la réalité du trafic API en production. Ces écarts s’expliquent par une documentation incomplète et imprécise qui fait l’impasse sur certains éléments, tels que des fonctions (GET, POST, ..), des fonctionnalités inconnues et des données sensibles exposées mais non documentées. En l’absence de précisions et de détails, les équipes sécurité sont incapables de mesurer les véritables risques encourus par leurs API.
-Toutes nos API sont à l’abri derrière le pare-feu
Quantité d’acteurs pensent que la totalité de leurs API réside derrière un pare-feu, protégées dans leurs environnements de développement. En réalité, les API sont davantage exposées qu’ils ne le croient. Les développeurs pourraient les exposer en externe pour divers motifs : à des fins de tests, pour ménager un accès à des développeurs tiers ou proposer des démonstrations à des partenaires. La totalité de ces scénarios présentent un risque significatif si les API sont exposées à l’insu des équipes de sécurité.
-Le trafic transitant par nos API n’est pas énorme
C’est moins du volume de trafic que de la criticité du service et des données dont il est question. Le volume de trafic transitant par une API a beau être faible, celle-ci n’en demeure pas moins une composante essentielle de l’activité pour booster le chiffre d’affaires ou accompagner les partenaires. Ces API sont aussi susceptibles d’exposer des données sensibles, d’en accroître l’intérêt en tant que cibles. Les hackers ne se soucient guère de la quantité de trafic transitant par les API ; c’est la valeur de cette cible qui les intéresse.
-Nos API n’exposent rien d’important
La réalité, c’est que, par nature, les API constituent une voie d’accès à un large éventail de services et de données sensibles. Les hackers sont d’ailleurs souvent bien mieux informés que les développeurs qui créent ces API, et c’est l’une des nombreuses raisons pour lesquelles Gartner affirme ce qui suit : « En 2022, les API deviendront le 1er vecteur de cyber attaque, entraînant des failles de sécurité pour les applications des entreprises. » Cerner les données sensibles exposées par les API est aussi un élément essentiel pour mesurer les risques et respecter les obligations de conformité.
-Personne ne risque de s’intéresser à nos API
Ce n’est pas parce qu’une entreprise est de petite taille qu’elle ne constitue pas une cible de choix pour une attaque. Parfois les API pilotent des services qui ne sont ni connus, ni couramment utilisés. Mais ce n’est pas parce que l’entreprise et les API n’attirent pas l’attention qu’elles ne constituent pas des cibles pour autant. Certains hackers préféreront des structures plus modestes à des entreprises de renom, convaincus qu’il sera plus facile d’infiltrer les premières que les secondes.
-Il est difficile de s’attaquer à des API
Nombreux sont ceux qui estiment que, tapies en coulisses, les API bénéficient de ce fait d’un relatif niveau de sécurité. Mais en réalité, les API, par nature, exposent votre logique applicative et nettement plus de données que les applications web traditionnelles. Les hackers peuvent facilement sonder ces API en se servant des mêmes outils que ceux utilisés par des développeurs ; ils peuvent ainsi recourir à des méthodes subtiles pour cartographier l’API, cerner sa logique et traquer les vulnérabilités.
2- Dépendance excessive aux équipes de développement pour s’atteler à la sécurisation
Le shift-left, ou virage à gauche, est une tendance qui a le vent en poupe ces dernières années. Les entreprises qui ont adopté des pratiques DevOps ont gagné en efficacité dans le cycle de développement grâce à cette approche et entendent l’appliquer dans le domaine de la sécurité.
Cette tendance a gagné la sécurisation des API, partant du principe que les développeurs t devraient être en charge de la sécurité des API Les développeurs ne cessent de se perfectionner sur l’intégration de bonnes pratiques et le développement de code sécurisé ; pour autant, les développeurs ne raisonnent pas comme les hackers. Ils se concentrent sur les fonctionnalités et le bon fonctionnement des applications. En revanche, les hackers eux visent les cas d’usage imprévus pour détecter les failles de conception. Les développeurs qui s’efforcent de produire du code le plus rapidement possible ne peuvent pas tester tous les cas d’usage et ne peuvent donc pas éradiquer la totalité des vulnérabilités potentielles.
Les équipes de développement savent également qu’un code sans failles n’existe pas. Raison pour laquelle elles utilisent des outils d’analyse de code et recourent à des tests de pénétration pour compléter leurs efforts et identifier de possibles vulnérabilités. Ces outils et pratiques ont leurs limites et, pour des questions de coûts et de complexité, tous les aspects de l’application sont rarement testés.
Le temps est un autre facteur majeur. La publication de code s’opérant toujours plus vite, les initiatives de sécurité au stade de la pré production ont du mal à suivre et, pour respecter les délais, certaines étapes sont parfois sacrifiées. Souvent, la priorité consiste à tester uniquement les applications principales ou certaines catégories de fonctionnalités.
Autre facteur : la plupart des vulnérabilités API sont inhérentes à la logique propre à chaque API. Alors que nombre d’outils d’analyse sont tributaires de bonnes pratiques génériques et de signatures pour le repérage des vulnérabilités, aucune de ces méthodes ne détectera les failles logiques. Même en misant sur la personnalisation et sur des opérations manuelles de type tests de pénétration, il est difficile, si ce n’est impossible, de détecter ces failles logiques qui ne se révèlent pour la plupart qu’à l’exécution.
3- Confiance excessive dans les outils de sécurité et mécanismes de protection traditionnels
Les API et leurs vulnérabilités sont tout sauf ordinaires ; pourtant, nombre d’entreprises continuent à s’en remettre à des outils traditionnels tels que les API Gateways et les pare-feu applicatifs web (WAF) ainsi qu’à des méthodes de protection classiques dans le domaine de la sécurité. Fin 2019, l’OWASP a publié son « Top 10 » des vulnérabilités API, liste composée à 70 % de nouvelles menaces en comparaison du célèbre « OWASP Top 10 » des applications web, soulignant ainsi la particularité des API par rapport aux applications web traditionnelles.
->Nombre d’API Gateways utilisent des mécanismes de protection traditionnels de type authentification, autorisation, chiffrement et limitation de débit (rate-limiting). Ces éléments essentiels dans la protection de tout type d’application sont pourtant loin d’être suffisants pour se prémunir contre les menaces répertoriées dans le « Top 10 » des vulnérabilités API. La majorité des menaces ciblant les API, en particulier les plus perfectionnées, se jouent de ces protections.
->L’authentification protège peu les applications orientées clients. Avec nombre de ces applications, l’ouverture d’un compte ne prend que quelques minutes, et un hacker dispose alors d’un accès pour sonder l’API. L’authentification seule ne protège pas davantage les applications plus restrictives. La médiocrité des pratiques en matière de mots de passe, les fuites d’authentifiants et l’hameçonnage sont autant de réalités qui aggravent le risque posé par une dépendance exclusive vis-à-vis de l’authentification.
->L’autorisation est également essentielle, mais il est difficile, si ce n’est impossible, de garantir sa fiabilité en permanence. Première menace citée dans le « Top 10 » des vulnérabilités API de l’OWASP et vulnérabilité la plus fréquemment constatée, la faille BOLA (Broken Object Level Authorization) tire avantage d’une erreur de configuration de cette autorisation. La complexité des API et de leur logique, encore aggravée par le rythme des changements, rend l’autorisation difficile à élaborer et à gérer.
->Le chiffrement est indispensable pour protéger les données en circulation et au repos. Malgré tout, les hackers peuvent aisément lire les activités API sur leurs propres appareils en se servant des mêmes outils que ceux utilisés par les développeurs. Par leur biais, ils peuvent visualiser l’API et les données non chiffrées sans avoir à se livrer à un parcours d’obstacles jusqu’au chiffrement de leurs attaques MTM (Man-in-the-Middle).
->La limitation de débit (« rate limiting ») peut contribuer à stopper des attaques volumétriques, telles que les attaques par déni de service (DDoS), le credential stuffing et les activités de bots. Cependant, les hackers se soustraient à ces limitations de diverses manières, notamment en se servant de téléphones prépayés (burner phones), en changeant leurs adresses IP et en lançant des attaques à partir de charges de travail éphémères dans le cloud. Ils savent qu’avec ces méthodes, ils resteront en-deçà des limites ou garderont une longueur d’avance sur la création et l’actualisation des règles correspondantes. La limitation de débit ne protège en rien contre la majorité des menaces recensées dans le « Top 10 » des vulnérabilités API de l’OWASP, qui sont des attaques de faible volumétrie et lentes dans le temps (“low and slow”) au cours desquelles les hackers sondent et manipulent les API en usant de méthodes subtiles ne déclenchant aucune limitation de débit.
Certains acteurs sont convaincus que les API sont des applications comme les autres, et qu’il suffit donc d’étendre des outils tels que des pare-feu applicatifs web (WAF) pour offrir une protection suffisante. Semant encore davantage la confusion, nombre d’éditeurs de pare-feu applicatifs web citent les API dans leur documentation marketing. Si les pare-feu applicatifs web sont capables de prémunir les API contre les menaces traditionnelles (Injection SQLI, XSS), ils font totalement l’impasse, en revanche, sur les attaques ciblant la logique des API (OWASP API top 10). Ces attaques “low and slow” visent une multitude de transactions plusieurs heures ou jours durant et les outils reposant sur un serveur proxy comme les pare-feu applicatifs web pâtissent de contraintes architecturales et sont incapables de collecter et d’analyser les énormes quantités de données nécessaires à la mise en contexte et à l’identification de ces attaques discrètes.
Les systèmes de gestion des événements et des informations de sécurité (SIEM) relèvent, eux aussi, de la catégorie des outils traditionnels qui jouent un rôle essentiel dans tout environnement de sécurité, mais qui se révèlent incapables de repérer et de prévenir les attaques API. À supposer que les outils de sécurité en place les détectent et envoient une alerte à un système SIEM, les équipes en charge de la résolution des incidents devront encore reconstituer l’activité, éliminer les faux positifs et comprendre les intentions des hackers. Pour cerner ces dernières, il faut parfaitement connaître l’application, notamment la logique API, et savoir à quoi ressemble une activité normale, ce qui donnera du fil à retordre même à une équipe des plus confirmées, qui devra gérer en parallèle le phénomène de lassitude lié aux alertes.
La marche à suivre
Un excellent point de départ pour cerner votre surface d’attaque API consiste à vous rapprocher des équipes de développement qui se servent probablement de celles-ci pour créer leurs applications. Ces équipes pourront aussi vous éclairer sur les types d’applications créées avec les API, sur l’importance de ces dernières pour l’activité ainsi que sur les types de données que ces API risquent d’exposer. Les équipes réseau, infrastructure et opérations, autres sources d’informations précieuses, pourront renseigner sur l’utilisation des API dans leur environnement.
Il est essentiel d’aborder la sécurisation des API comme une activité s’opérant tout au long de leur cycle de vie. En ajoutant une protection en continu en production (runtime protection), il est possible de faire en sorte que les vulnérabilités qui ont éventuellement échappé au développement ne soient pas exploitables en production. Cette protection permet aussi aux équipes de développement d’avancer au rythme requis pour respecter les délais sans être ralenties par les efforts irréalistes pour produire du code totalement exempt de vulnérabilités.
L’authentification, l’autorisation, l’encryption et le rate-limiting jouent bien évidemment un rôle dans la sécurité des API mais ils ne suffisent plus. Les équipes de développeurs et les outils traditionnels, tels que les pare-feu applicatifs web (WAF) et les API Gateways, sont incapables d’assurer seuls une défense efficace contre les attaques API et les vulnérabilités. Il est temps de réfléchir autrement.
