La cause est acquise. De plus en plus d’entreprises prennent conscience de l’incroyable potentiel des interfaces de programmation (API) comme générateur de revenus (plutôt que comme gadget pour faire plaisir à leurs geeks !)
Ce n’est pourtant pas une nouveauté. En 2015 déjà, le Harvard Business Review indiquait que 90 % du chiffre d’affaires d’Expedia était généré par les API. eBay et Salesforce ont également réalisé respectivement 60 % et 50 % de leur chiffre d’affaires grâce aux API. Bref, c’est rentable !
Pour ceux qui n’auraient pas suivi l’évolution des architectures applicatives, si un tableau de bord est une interface utilisateur pour les humains, une API est alors une interface utilisateur pour d’autres applications ! Il s’agit de logiciels légers fonctionnant sur un serveur d’application et chargés de gérer les connexions d’autres services applicatifs ou d’applications mobiles venus pousser ou extraire des données.
Cela permet aux entreprises d’offrir le service original (celui qui crée de la valeur, par exemple la réservation de vols aériens ou la comparaison de prix) sous de nouvelles formes ou à de nouveaux partenaires : en plus des êtres humains, les résultats peuvent ainsi être consommés directement par d’autres applications, et ainsi adresser de nouveaux marchés (une chaîne hôtelière qui offre une API pour la réservation de ses chambres s’ouvre ainsi le marché des comparateurs de prix). C’est une approche importante pour tous ceux qui cherchent à tirer parti des infrastructures existantes avec un minimum de modifications.
L’influence et la diffusion des API n’ont cessé de croître ces dernières années. Le portail et le forum communautaire programmableweb.com en répertoriait 12 000 en 2015. En octobre 2019, ce nombre s’élevait à près de 23 000.
Mais naturellement, dès qu’une technologie s’impose et permet de gagner de l’argent, cela ne passe pas inaperçu aux yeux des cybercriminels…
Des APIs très ciblées
L’un des problèmes de sécurité récurrents que l’on rencontre avec les API est le fait que leurs permissions sont trop lâches. Cela signifie qu’une fois l’application qui fournit l’API compromise, les pirates pourront s’en servir pour obtenir une visibilité sur tout ce qui se trouve dans l’infrastructure, et dans certains cas, l’utiliser pour pivoter sur le reste de l’architecture.
Les appels d’API sont également sujets aux pièges habituels qui ciblent les requêtes Web, tels que les injections, la casse d’identifiants faibles, la falsification des paramètres et le vol de session.
Le manque de visibilité est un autre problème majeur. Des entreprises de toutes tailles et de tous horizons — y compris des fournisseurs informatiques — ont des antécédents tout à fait médiocres lorsqu’il s’agit de superviser leurs API et savoir ce qu’il s’y passe !
2019 : l’année du contrôle d’accès mal configuré
Dans son rapport 2019 sur la protection des applications, le F5 Labs a découvert que les brèches d’API détectées jusqu’en novembre 2018 étaient concentrées sur de grandes plates-formes qui offraient un nombre important d’API, et que bon nombre d’applications mobiles dépendaient fortement de quelques-unes seulement d’entre elles pour fonctionner.
Et comment ces APIs sont-elles compromises ? Chaque brèche découverte par F5 Labs depuis novembre 2018 est le résultat d’une mauvaise configuration des contrôles d’accès. En d’autres termes, les propriétaires des systèmes concernés ne se rendaient pas compte que leur API était grande ouverte.
La bonne nouvelle, c’est que ces APIs exposées ont été détectées par des chercheurs en sécurité, plus avides de gloire que de richesse, et qui n’avaient donc pas l’intention d’exploiter ces données. Mais la prochaine fois, ces entreprises pourraient ne pas être aussi chanceuses…
Et même lorsque les APIs sont bien configurées, cela n’exclut pas que quiconque ne puisse y accéder malgré tout. Ainsi une étude de la North Carolina State University a révélé que plus de 100 000 dépôts de code sur GitHub avaient des jetons API et des clés cryptographiques — autrement dit tout le nécessaire pour accéder aux API — stockés en clair dans le code source et donc visibles à l’œil nu !
Comment cela est-il possible ? Tout simplement parce que les développeurs cherchent parfois à se faciliter la vie pendant le développement (cela peut simplifier les tests), et qu’ils oublient de retirer ces informations lorsque le projet est mis en production…
Cette pratique a toujours existé, mais avec l’avènement des systèmes de gestion de version en ligne, elle est devenue extrêmement problématique.
Alors pour exploiter des API en toute sécurité, le rapport F5 sur la protection des applications invite les entreprises à :
- Tenir un inventaire à jour. Il est important de comprendre où ses APIs se trouvent et comment elles contribuent au métier de l’entreprise. Les scans périmétriques (pour avoir une vue d’ensemble) et les entretiens approfondis avec les équipes de développement et d’exploitation sont essentiels. Cela permettra également d’inclure les APIs dans les analyses de risque
- Authentifier les accès. Le State of Application Services Report de F5 Networks révèle que 25 % des entreprises interrogées n’utilisent pas d’authentification pour leurs API. 38 % ont déclaré qu’elles le faisaient « parfois » et 37 % « la plupart du temps ». Ce n’est évidemment pas une bonne pratique.
- Valider les entrées. Aucune API ne doit transmettre aux applications des données non assainies ou non validées. Faire l’impasse sur la validation des entrées est la voie royale vers une attaque par injection. Par ailleurs, les API devraient à minima limiter les méthodes HTTP que des rôles spécifiques peuvent mettre en œuvre, et plus globalement mettre en œuvre une logique par rôle (à chaque rôle ses actions métier autorisées)
- Journaliser. Consigner et passer en revue toutes les connexions à l’API, quelles qu’elles soient. Il est également recommandé de surveiller les actifs que les API servent
- Chiffrer. Le trafic des utilisateurs sur le Web est de plus en plus souvent chiffré, et les API ne sont pas différentes. Chiffrer les connexions et valider les certificats devraient faire partie des premières mesures de sécurité pour une API
- Superviser. À l’aide d’un proxy « API-aware » ou d’un pare-feu capable d’inspecter le trafic, il est important de valider et limiter les requêtes adressées à l’API. Certains services de sécurité de l’API peuvent analyser le client à l’origine des requêtes et tenter de déterminer si une requête est légitime ou malveillante. Ils peuvent également s’assurer que les requêtes API restent là où elles sont censées être
- Tester en continu. La prévalence des API n’a d’égal que leur obscurité ! Des tests constants sont donc nécessaires pour rester à jour des nouvelles vulnérabilités et éviter que l’API ne soit considérée comme une boîte noire, que l’on ne touche pas du moment qu’elle fonctionne. Et c’est également une bonne idée que de tenter un « Bug Bounty » sur le périmètre de l’API, afin de motiver la communauté des chercheurs en sécurité à l’étudier et remonter ses faiblesses éventuelles
Les API n’ont rien de nouveau, mais elles sont de plus incontournables dans le paysage applicatif. À bien des égards, elles réintroduisent des risques existants sous de nouvelles formes, parfois plus susceptibles d’être exploitées, plus percutantes et plus difficiles à reconnaître. On citera par exemple le cas de Cambridge Analytica et des failles de l’API d’un réseau social qui lui ont permis de collecter des millions de données utilisateurs.
Pour autant, les API s’imposent comme un composant incontournable dans les architectures IT contemporaines, ce qui signifie qu’il n’est plus possible de les éviter… et donc d’ignorer les problèmes de sécurité connexes !