Pourquoi la sécurité des API est l'affaire de tous

Aug 20, 2023

La planète regorge d’API, les mécanismes utilisés par les ordinateurs pour échanger des informations, les éléments constitutifs de tous les logiciels. Les entreprises créent leurs propres API pour un usage interne ou pour permettre aux clients d'interagir avec leurs systèmes. Ils utilisent des API pour communiquer avec des partenaires sur des extranets et sur des cloud. Ils utilisent des API tierces pour accéder à des fonctionnalités prêtes à l'emploi – pour afficher Google Maps ou pour utiliser des tables de recherche de codes postaux dans des formulaires, par exemple.

Le nombre d’API augmente de façon exponentielle à mesure que les applications mobiles, Web et cloud prolifèrent. Quelques statistiques du secteur :

Il n’est pas surprenant que les API constituent également un vecteur d’attaque important et en croissance rapide. Selon Gartner : « La croissance explosive des API élargit la surface d’attaque des organisations, offrant aux acteurs malveillants de nouvelles opportunités de violation et d’exfiltration de données. »

Selon votre point de vue, il est soit très surprenant, soit très peu surprenant qu'environ 50 % des API utilisées ne soient pas gérées.

Surprenant car ils présentent un risque évident et croissant. Ce n’est pas surprenant, car l’explosion de l’utilisation des API est aggravée par un manque de conscience des risques – et parce que les API sont difficiles à gérer. Les développeurs publient fréquemment de nouvelles API ou de nouvelles versions sans prendre la peine de supprimer leurs prédécesseurs. Le cyberespace regorge d’API zombies, exposant les systèmes et les données back-end, mais non surveillées et n’apportant aucune valeur commerciale.

Une surface d'attaque en constante expansion et mal surveillée : c'est le rêve d'un hacker devenu réalité.

L'avertissement de Gartner met en évidence l'un des risques évidents liés à la sécurité des API : les API sont des points de passage pour un grand nombre de trafic sensible. Dans les applications bancaires ou de commerce électronique, ceux-ci peuvent inclure les détails du compte des clients ou les numéros de carte de crédit. Mais les API exposent non seulement les données d'une entreprise (et de ses clients), mais également la logique métier qui sous-tend les services. Les faiblesses de la logique métier offrent aux pirates informatiques de nouvelles façons de lancer des attaques qui risquent de passer inaperçues avant que de graves pertes ne surviennent.

Par exemple, nous avons travaillé pour une banque qui utilisait une routine pour arrondir de très petites sommes dans les transactions de change. L'algorithme était sans conséquence pour les transactions typiques car il signifiait une différence d'une fraction de centime. Mais le système n'appliquait aucune limite au nombre de transactions qu'un seul client pouvait effectuer au cours d'une journée, et en contournant les contrôles frontaux et en attaquant directement leur logique métier, il était possible d'effectuer un grand nombre de petites transactions qui permettraient à un attaquant de utiliser la fonction d'arrondi pour imprimer de l'argent sur notre propre compte. Nous avons obtenu des résultats similaires avec des clients du secteur de la cryptographie, où l'abus de la logique métier des API nous a également permis de voler de la cryptomonnaie.

Bien sûr, la banque disposait de contrôles qui l'auraient finalement alertée du problème, mais a reconnu qu'elle aurait pu effectuer des transactions anormales d'une valeur de plusieurs millions de dollars avant que des signaux d'alarme ne soient déclenchés. Cet exemple illustre quelques principes importants de la sécurité des API. Les API les plus utiles sont publiques. Ils sont destinés à être utilisés. Vous ne pouvez pas les cacher ou les rendre trop difficiles d'accès sans les empêcher de faire leur travail.

Des techniques telles que les tests d'intrusion peuvent aider, mais même les tests d'intrusion ne sont que des exercices ponctuels et les testeurs n'évaluent que la portée fournie. Les entreprises ayant des angles morts concernant les API ne savent pas comment définir la portée des API, et la plupart des testeurs d'intrusion ne seront pas invités à tester la logique métier ou ne manqueront pas de compétences spécifiques aux API pour évaluer ce qu'un attaquant d'API compétent pourrait faire avec leur accès. .

La deuxième leçon est qu’il n’est pas logique de se concentrer sur une seule partie du cycle de vie des API. Les principes du décalage vers la gauche se concentrent à juste titre sur l’intégration de la sécurité au moment de la conception et du codage, mais le cycle de vie de production du code est tout aussi important. Les choses changent. Le code original est modifié par un autre développeur. La documentation est médiocre, voire inexistante. L'entreprise est sous pression. Les mises à jour peuvent ne pas être testées de manière approfondie. Et même si le développement et les tests ont été impeccables et que les révisions sont méticuleuses, il se peut qu'il y ait quelque chose qui a manqué dans la conception originale et qui pourrait revenir vous hanter. Déplacez-vous vers la gauche, oui, mais arrêtez de regarder à droite, à vos risques et périls.