Les fuites d'API menacent d'entacher la réputation des entreprises.

Dans la vie, en général, la communication est une excellente chose. Il n'y a pas de moyen plus rapide de parvenir à une compréhension, d'apprendre quelque chose de nouveau ou de construire une relation. Dans l'espace logiciel, les API ont une fonction de communication qui permet aux applications de communiquer entre elles, ce qui améliore les fonctionnalités et la convivialité. Cette connectivité crée souvent une expérience plus riche que les utilisateurs finaux apprécient et, de plus en plus, attendent des logiciels dans leur vie quotidienne. 

Cependant, comme dans la vie réelle, il y a un gros problème lorsqu'ils parlent trop. Experian l'a récemment appris à ses dépens, lorsque l'une de ses interfaces de programmation (API), utilisée par un partenaire tiers, a potentiellement divulgué les scores de crédit de... eh bien, d'à peu près tous les citoyens américains.

Le problème a été corrigé rapidement, mais des questions subsistent quant à savoir si cette vulnérabilité a vraiment été stoppée dans son élan. Si un fournisseur a été touché, il y a de fortes chances que d'autres le soient également, et il est possible qu'il s'agisse d'un bogue systémique, affectant tous ceux qui utilisent cette API non sécurisée.

La sécurité des API est une question qui n'est pas loin de préoccuper la plupart des experts en sécurité, et c'est une chose que nous devons nous équiper des connaissances nécessaires pour la combattre. 

N'importe quel geek peut contourner une mauvaise authentification de l'API.

L'une des caractéristiques de nombreuses fuites de données, violations et incidents de sécurité est qu'il faut rarement un génie pour les réaliser. Les attaques complexes, insidieuses et préjudiciables comme celle de SolarWinds nécessitent des équipes de génies cybercriminels pour être menées à bien, et elles sont l'exception plutôt que la règle. 

Lorsqu'une API est construite avec une authentification faible, il est assez facile de l'exploiter. Bill Demirkapi, le chercheur en sécurité qui a découvert le bogue de l'API d'Experian, a déterminé qu'il était possible d'y accéder sans aucune authentification. En saisissant 00/00/0000 dans le champ de la date de naissance, il a pu accéder à la cote de crédit d'une personne, en utilisant uniquement des informations accessibles au public telles que le nom et l'adresse postale associée. Bien que cela n'ait pas été rapporté, il est tout à fait possible que ces enregistrements soient récupérés et contextualisés en tant que données de crédit (et donc utiles).

Des processus d'authentification propres et fonctionnels doivent être mis en place, quelle que soit la taille du cas d'utilisation ; une API bavarde qui n'est pas correctement sécurisée, et qui ouvre potentiellement l'accès à de multiples systèmes, est une responsabilité.

L'authentification brisée est le numéro deux de la liste des 10 principales vulnérabilités des API de l'OWASP. Pour en savoir plus sur la manière d'éviter ce bogue, cliquez ici et testez vos compétences sur notre plateforme une fois que vous aurez fini d'alimenter votre cerveau.

La faiblesse des contrôles de sécurité des API est un problème généralisé qui nécessite un changement de culture

Il n'est pas juste de pointer du doigt uniquement des organisations comme Experian, mais le manque de nuance et de diligence en matière de contrôle de la sécurité dont témoigne cette exposition particulière à l'API n'augure rien de bon pour les nombreuses entreprises qui utilisent des API dans le cadre de leurs systèmes informatiques et de leurs points de terminaison. 

En général, nous avons encore beaucoup de travail à faire, non seulement pour trouver et corriger les vulnérabilités des API, mais aussi pour les comprendre comme faisant partie de la surface d'attaque que nous sommes censés protéger. La visibilité sur les API - et la manière dont elles ont été construites - est une préoccupation majeure, et c'est quelque chose qui devrait être exigé dans le cadre des meilleures pratiques de sécurité. Même une organisation dotée des mesures de sécurité les plus strictes peut se retrouver à la merci d'une API publiée et fonctionnant en dehors des contrôles de sécurité de l'entreprise. Il est plus important que jamais de se demander d'où vient une API, qui la maintient (est-ce un fournisseur tiers ? Quelle est sa rigueur en matière de sécurité ?) et quelles sont les informations auxquelles elle accède. 

Les vulnérabilités liées aux injections restent un problème pour tous les RSSI.

La sécurité des API peut sembler être un module relativement nouveau à inclure dans un programme de sécurité, mais elle peut être exploitée par des astuces (très) anciennes que nous avons l'habitude de voir dans les logiciels web ordinaires.

Une attaque récemment divulguée contre Accellion a révélé que l'enchaînement d'attaques par injection SQL et par exécution de commandes du système d'exploitation a permis aux auteurs de la menace de manipuler les API et d'extraire un grand nombre de données sensibles, y compris des numéros de sécurité sociale. Les auteurs de l'attaque ont déterminé que les attaquants devaient avoir une connaissance approfondie du logiciel FTA d'Accellion pour réaliser le hold-up, ce qui aurait été possible grâce à une rétro-ingénierie importante.

La violation s'étant produite entre décembre 2020 et janvier 2021, les voleurs ont eu tout le temps de causer des dégâts. D'autres découvertes en février 2021 ont mis au jour une vulnérabilité XSS stockée, l'analyse médico-légale ayant révélé qu'un seul point d'extrémité de l'API dont l'entrée utilisateur n'était pas correctement assainie permettait d'injecter un argument lors de l'appel du script admin.pl.

Avec plus de 3 000 clients, dont de nombreux établissements d'enseignement prestigieux, cette violation pourrait avoir une grande portée. Malheureusement, ces exploits ont été rendus possibles par l'exploitation de vulnérabilités courantes, dont beaucoup auraient pu être corrigées au niveau du code, avant la production, par un développeur sensibilisé à la sécurité. Comme nous le constatons sans cesse, il suffit d'une petite fenêtre laissée ouverte pour créer de gros problèmes. Et une culture de la cyberdéfense dirigée par l'homme doit faire partie de la stratégie de résolution d'un problème très humain.

Vous voulez tester vos compétences en matière de sécurité des API ? Java Spring API, Kotlin Spring API, C# (.NET) Web API et bien d'autres encore ? Relevez quelques défis API sur notre site Learning Platform (consultez tous les langages:frameworks via le menu déroulant) :
‍

‍