Mort par mille fuites de données : comment les API submergent la sécurité

Les surfaces d'attaque d'aujourd'hui sont plus larges que jamais, les vulnérabilités s'infiltrant des applications et habitant les interfaces de programmation d'applications flexibles qui font tourner le monde de la technologie.

Malheureusement, alors que la plupart sont conscients des menaces traditionnelles des applications Web, les API restent un domaine de sécurité trouble. Le paysage gargantuesque des menaces d'aujourd'hui exige un WAF cloud compétent et même un investissement dans le WAAP.

Qu'est-ce qu'une API ?

Les API sont le ciment qui maintient l'expérience de navigation moderne ensemble. Les API simplifient l'utilisation et le développement de logiciels en permettant à des applications Web individuelles d'échanger des données. Faire une requête à un serveur via une application est aujourd'hui géré par une API pertinente, grâce au fait que les API correctement implémentées sont très sécurisées.

Au lieu que le serveur soit directement exposé à vos informations, votre appareil et l'API correspondante doivent partager de petits paquets de données, ne communiquant que ce qui est nécessaire.

Agile et API : double problème de sécurité

Agile est le mot à la mode des affaires d'antan - il décrit une forme de production qui amplifie l'idée entrepreneuriale de « produit minimum viable ». L'objectif d'Agile est de pousser le produit minimum à chaque étape ; au lieu d'appeler un produit « fini », il est simplement intégré dans une autre série de corrections de bogues et d'améliorations.

Bien que ce patching perpétuel semble fantastique pour la sécurité (support logiciel constant ? Sympa !) La réalité économique de la production logicielle fait que la quantité d'API devient rapidement incontrôlable.

Comme les équipes de développement évoluent rapidement, les API sont rarement documentées de manière exhaustive. Il est donc extrêmement difficile de scruter les mécanismes internes d'une application et de comprendre quelles API font quoi. Cela rend également la sécurité infiniment plus difficile, car les équipes de développement elles-mêmes ne connaissent pas la taille réelle de leur inventaire d'API. Cela place la cybersécurité au second rang des priorités ; toujours réactif et jamais proactif.

API négligées

Lorsque la sécurité des applications est mentionnée, la première chose qui vient à l'esprit sont les poids lourds de la sécurité. Attaques telles que cross-site-scripting ; L'injection SQL et les attaques DDoS sont toutes incroyablement connues. Les applications elles-mêmes sont souvent bien protégées par des solutions plug-and-play telles que les pare-feu d'applications Web de surveillance du périmètre.

Peu d'attention est jamais accordée aux API, au détriment des organisations inconscientes et de leurs clients. Prenons l'exemple d'une vulnérabilité d'API apparue dans le système d'Uber.

Lorsqu'un chauffeur Uber rejoint Uber via un lien de parrainage, il démarre l'application et saisit le code de parrainage. En appuyant sur le bouton Entrée, le navigateur de l'application communique avec l'hôte API "bonjour.uber.com". À partir de là, bonjour.uber reçoit le paramètre ID utilisateur et renvoie les détails du conducteur à l'application de l'utilisateur, prêts à être saisis dans l'écran de consentement suivant.

Cependant, cette API a été reconnue coupable de deux failles de sécurité majeures. Le premier était l'autorisation au niveau de l'objet interrompu (BOLA). L'API n'a pas vérifié que l'ID de l'utilisateur correspondait à son paramètre d'ID ; il était donc possible d'accéder aux données d'autres utilisateurs en changeant simplement l'identifiant de l'utilisateur.

Le deuxième problème était l'exposition excessive aux données. La réponse de l'API - pour renvoyer les détails de l'utilisateur - a regroupé toutes ces informations en un seul lot, contenant chacun des détails de l'utilisateur. Cela signifiait que l'API renvoyait des informations dont le client n'avait pas explicitement besoin, violant un pilier majeur des meilleures pratiques de cybersécurité.

Considérez maintenant qu'une organisation moyenne s'appuie sur plus de 15 500 API et que l'ampleur du risque commence à apparaître. Heureusement, l'API Uber a été branchée avant qu'un dommage majeur ne se produise ; l'entreprise suivante n'a pas été aussi chanceuse.

Le problème du peloton

La marque de fitness à domicile de Peloton est appréciée par plus de 3 millions d'abonnés. Les cours de fitness en direct sont un argument de vente majeur, mais si vous ne souhaitez pas partager vos données médicales avec d'autres participants au cours, il est possible de définir votre compte peloton sur privé.

Malheureusement, un certain nombre de vulnérabilités de l'API ont vu l'exposition de ces données à des utilisateurs non autorisés. Les informations des participants aux cours pourraient être récupérées à grande échelle, car un point de terminaison d'API n'a pas réussi à valider un utilisateur demandeur. Cela a permis à des attaquants non autorisés d'obtenir le nom d'utilisateur, l'emplacement, l'ID d'entraînement, le sexe et l'âge des utilisateurs de Peloton.

Les API sont à l'origine de fuites de données très médiatisées depuis des années. Les scandales de données constants de Facebook tout au long de 2018 et 2019 ont vu une violation se produire après l'autre, principalement via des API de développeurs tiers. Un exemple était l'API Groups ; les développeurs travaillant sur une application de gestion de médias sociaux B2B pouvaient accéder librement aux noms et aux informations plus personnelles des membres du groupe. Bien que cette application de gestion des médias sociaux ait été conçue pour aider les administrateurs de groupe à gérer leurs groupes plus efficacement, Facebook a dû la supprimer ainsi que son API.

Ces scandales de données ont culminé en 2021, lorsqu'une base de données du marché noir de plus de 533 millions d'utilisateurs de Facebook a vu leurs noms, numéros de téléphone et identifiants d'utilisateur Facebook divulgués.

Prévention des fuites d'API

L'Open Web Application Security Project (OWASP) publie régulièrement les vulnérabilités des applications Web les plus graves et les plus répandues à surveiller. La menace de sécurité croissante représentée par les API est suffisamment grave pour justifier sa propre liste des dix premiers OWASP, qui est systématiquement dominée par l'autorisation au niveau de l'objet cassé.

Heureusement, la protection de vos API - en dehors de l'exigence d'un cycle de développement plus lent - suit de près la sécurisation de votre organisation globale dans son ensemble. Votre premier point d'appel serait un pare-feu d'application Web (WAF) décent. Cette solution surveille les périmètres de vos applications, empêchant les passerelles API d'être exploitées par des vulnérabilités majeures.

La protection des applications Web et des API (WAAP) va encore plus loin. Il se trouve entièrement à la limite publique d'une application, analysant tout le trafic entrant. En surveillant les modèles de trafic et de demandes légitimes, les WAAP sont des outils de sécurité hautement spécialisés spécialement conçus pour protéger les API.

Alors que WAAP est un système défensif au niveau des terminaux, les solutions RASP (Runtime Application Self Protection) s'articulent autour d'applications Web spécifiques. Une solution RASP - distincte de WAF - a également un aperçu du fonctionnement interne et des comportements de son application. De cette façon, si une API est utilisée comme point d'ancrage dans une attaque, et interrogée pour plus d'informations qu'il ne devrait l'être, un RASP peut arrêter une attaque de manière proactive.

Avec une myriade d'options de protection d'API disponibles, la sécurisation de vos applications et de votre organisation n'a jamais été aussi simple.