Cloudflare pointe les dangers d’un déferlement d’API non sécurisées

Cloudflare a publié récemment un long rapport sur la sécurité des API. Bien que cette communication soit l’occasion de placer ses propres services de sécurité, elle permet aussi de rappeler les nombreuses problématiques liées à ces pivots du développement, souvent ignorés du grand public.

Une API, pour Application Programming Interface, est un pivot par lequel peuvent passer les demandes pour accéder à des informations. Elles sont omniprésentes, car leur création a permis de simplifier largement le travail des développeurs, qui n’avaient alors plus à réinventer la roue chaque fois qu’ils se lançaient dans un nouveau projet.

Un exemple connu et remontant aux années 90 est DirectX. Ce lot d’API, publié par Microsoft, a pour mission de rationaliser les demandes d’accès au matériel. Sur DOS et Windows, chaque jeu devait auparavant posséder un accès spécifique et prévoir de nombreux cas de figure. Exemple type : les cartes son. Avec DirectX, les studios se sont centrés sur les fonctions offertes par les API, qui se chargeaient alors de communiquer avec le matériel via les pilotes.

Il n’est donc pas étonnant qu’elles soient également très présentes dans le développement web. Si vous développez par exemple un site pour afficher la météo, vous n’allez pas créer tous les composants responsables de la collecte et la distribution des informations réunies par les capteurs disséminés en France (à moins d’en avoir l’envie et les moyens). Des API sont à disposition via divers services, notamment Météo France.

Ces interfaces de programmation ont fait l’objet très récemment d’une publication chez Cloudflare, qui en avertit des dangers. La multiplication des API peut en effet constituer autant de portes d’entrée pour des pirates.

Des portes dans la nuit

Cloudflare base ses constats (réunis dans une vaste présentation) sur les données collectées lors de l’utilisation de ses services ainsi que ses interventions chez ses clients. L’entreprise américaine estime qu’aujourd’hui, elle défend près de 20 % d’internet. Sur une proportion aussi vaste et sur le déluge de trafic qu’elle engendre, Cloudflare pointe que plus de la moitié de ce dernier est lié aux API, (57,7 % en Europe, 60,4 % au Moyen-Orient, 63,8 % en Afrique…). Les interfaces ont pris le pas sur les pages web.

Lors des Assises de la cybersécurité à Monaco, Akamai nous donnait des chiffres du même acabit, à plus de 50 % du trafic pour les API. La société nous expliquait aussi que les cyberattaques se déplaçaient de plus en plus vers celles-ci, justement car elles étaient de plus en plus nombreuses.

L’avertissement de Cloudflare est clair : « de nombreuses entreprises ne disposent pas d'un inventaire précis de leurs API, même lorsqu'elles pensent qu'elles peuvent correctement identifier le trafic lié à ces dernières ». Même son de cloche chez Akamai.

Sur la base des informations recueillies dans ses services, Cloudflare évoque deux méthodes pour référencer les API publiques. La première consiste à utiliser un outil pour chercher les jetons d’identification normalement présents dans le trafic des interfaces. L’autre fait appel au machine learning. Cloudflare possède un modèle analysant les appels aux API et l’ensemble des requêtes HTTP.

C’est dans l’écart dans les résultats entre ces deux méthodes que se situe le problème : la seconde trouve 30,7 % de résultats supplémentaires. En simplifiant un peu, on peut dire que « près d'un tiers des API sont des « API fantômes », qui ne peuvent être correctement inventoriées et sécurisées ».

Le grand bazar

Si les entreprises ne référencent pas correctement leurs API, elles peuvent jusqu’à en oublier l’existence, ou ne plus y prêter attention, selon Cloudflare. Le rapport avec la sécurité informatique est évident : plus il y a d’API, plus il y a de code, plus la surface d’attaque est importante. Le danger est donc que ces API « fantômes » servent de points d’entrée aux pirates, qui pourraient en exploiter les faiblesses, permettant l’obtention de données auxquelles personne n’est censé accéder.

Cette obtention se fait la plupart d’un temps à la suite d’un défaut de sécurisation dans les processus d’authentification et d’autorisation des API. C’est ce qui est arrivé à la société australienne de télécommunications Optus en septembre 2022 : des pirates ont profité des faiblesses dans les API exposées à internet pour récupérer dix millions de dossiers utilisateur, mis en vente peu après. Deux mois plus tard, l’Australie avait annoncé la création d’une unité composée de policiers et hackers d’État pour lutter contre la cybercriminalité.

Comme tout ce qui touche à du code développé dans une optique d’accès public, Cloudflare y voit un défaut de communication entre les développeurs responsables du produit et l’équipe de sécurité. Il peut s’agir également d’un problème dans la documentation des API, qui peut être soit incomplète, soit absente.

Idéalement, il faudrait que tout acteur concerné ait toujours à sa disposition un inventaire complet de ses API. Cependant, « même les clients avertis omettent des pans entiers de leur trafic d'API ». L’entreprise rappelle tout de même qu’il n’est pas nécessaire d’être client de ses services pour dresser un inventaire des API. Les catalogues sont souvent dans le format OpenAPI et des outils permettent de créer plus facilement des schémas.

Cependant, il peut être délicat et fastidieux de dresser un inventaire complet si le processus n’a pas été mis en place dès le départ.

Les risques

Les API ont leurs propres problèmes de sécurité. Leurs défauts de sécurisation peuvent conduire à la fuite d’informations. Comme dans le cas d’Optus, ces informations peuvent devenir personnelles, quand il s’agit de données appartenant aux clients. Avec tous les risques que l’on connait, notamment l’exploitation de ces informations dans de vastes campagnes de phishing.

Les interfaces de programmation peuvent également être sensibles aux attaques plus classiques, notamment du Top 10 établi par la fondation OWASP (Open Worldwide Application Security Project). Les anomalies HTTP sont ainsi de loin les attaques les plus fréquentes avec 60,7 % de l’ensemble. « Les noms de méthodes mal formés, les caractères nuls, les ports non standard ou une longueur de contenu de zéro dans une requête POST constituent de bons exemples d'anomalies HTTP ».

Les attaques par injection (SQL, XSS…) arrivent secondes avec 26,3 %. Viennent ensuite les attaques par inclusion de fichier (5,5 %), celles liées à des logiciels spécifiques (failles non corrigées par exemple) et ainsi de suite.

Comme le note l’entreprise, certains types d’attaques ne sont pas présents dans le classement de l’OWASP. Par exemples, celles liées à la violation de l’authentification et de l’autorisation. Dans ces cas, les API ne parviennent pas « à vérifier si l'entité qui lui envoie des requêtes d'informations a bien l'autorisation de demander ces données ou non ». Les deux catégories les plus courantes dans ce cas sont se font aux niveaux de l’objet (Broken Object Level Authorization, BOLA) et de la fonction (Broken Function Level Authorization, BFLA).

Dans ce domaine, Cloudflare donne quatre conseils : appliquer une authentification à toutes les API publiquement accessibles (via mTLSv, Web Tokens JSON ou autre), limiter la vitesse des requêtes d’API pour ralentir les pirates potentiels, bloquer les volumes anormaux de données sensibles sortantes, et empêcher les acteurs malveillants d'ignorer les séquences légitimes de requêtes d'API.

Atténuer les risques et la force des attaques

L’entreprise donne une série de recommandations dont la plupart ne sont pas liées à ses propres produits. La principale est de définir un plan de contrôle unifié pour les API, avec un inventaire constamment mis à jour, qu’il faudra associer au développement d’applications. La visibilité, les performances et la sécurité des interfaces devront y être consignées.

La société recommande également d’utiliser des outils de sécurité reposant sur l’apprentissage automatique (machine learning) pour « libérer des ressources humaines et réduire les coûts ».

Ensuite, adopter un modèle de sécurité positive pour les API. Contrairement au modèle de sécurité négative classique, qui cherche à reconnaitre les modèles connus d’attaque pour les bloquer, la sécurité positive fait l’inverse. Elle cherche ainsi à reconnaitre les requêtes connues pour être légitimes, afin de bloquer tout le reste. Ce type de sécurité se marie bien à la validation de schéma d’API, les règles étant – en théorie – soigneusement établies.

Enfin, mesurer et améliorer le niveau de maturité des API dans l’entreprise. Cette maturité se mesure notamment via la manière dont est géré l’inventaire. La production de ce catalogue commencera par être statique, puis gagnera en automatisation : inventaire plus précis couplé à des mises à jour automatiques, puis application de mesures actives de contrôle de sécurité, contrôle des comportements à la recherche d’abus, etc.

Quand l’ensemble des points de terminaison sont considérés comme connus, l’étape suivante est de se pencher sur les erreurs renvoyées par les API. Elles peuvent cacher en effet des attaques. Les codes de statuts HTTP peuvent recéler de précieuses informations. Les codes 2xx signalent que la requête client a été reçue, comprise et acceptée. Les codes 3xx, 4xx et 5xx renvoient vers des erreurs :  redirection pour les 3xx, erreur client pour les 4xx et erreur serveur pour les 5xx.

Cloudflare recommande de se pencher notamment sur les erreurs 429, qui constituent d’ailleurs presque 52 % de celles constatées par ses services. Courante, elle signifie « Too Many Request » et survient quand le client a émis trop de requêtes en un temps défini.

Cependant, elle peut faire l’objet d’erreurs de diagnostic, notamment quand la limite a été définie manuellement. Dans ce cas, il faut faire attention à ne pas confondre un afflux légitime. Cloudflare donne l’exemple d’une campagne publicitaire réussie, mais le problème s’accentue durant les périodes de fêtes.

Des prévisions pas franchement optimistes

La société dit avoir interrogé de nombreux « utilisateurs confirmés » sur ces sujets. La réponse obtenue n’est guère surprenante : 73 % ont estimé que les exigences en matière de sécurité « interféraient avec leur productivité et leur capacité d’innovation ». Une thématique que l’on retrouve continuellement, quelles que soient les technologies. C’est un point que l’on retrouve souvent par exemple avec l’intelligence artificielle.

L’entreprise prévoit en conséquence une « accélération de la perte de contrôle et de la complexité ». L’essor de l’IA générative est justement abordé, car il augmenterait le risque que les API correspondantes soient vulnérables aux attaques. Nous avons d’ailleurs abordé ce sujet dans un récent article.

• • Les dangers guettant les déploiements rapides des IA

Enfin, Cloudflare prévoit deux autres tendances pour 2024. D’une part, une augmentation des fraudes basées sur la logique métier, avec notamment un déferlement de bots fraudeurs plus efficaces contre les API. D’autre part, une « inflation de la gouvernance ». La société cite le cas de la norme PCI DSS, qui nécessite des travaux d’adaptation et entrera en vigueur en mars.