Lorsque les API se connectent, les hackers entrent en action

Plus de 88 % des attaques Web observées par Akamai ont exploité des vulnérabilités d'API courantes. Une étude a même montré que chacune des 5 000 applications dépendantes d'API testées présentait au moins une vulnérabilité.

La sécurité des API devient à chaque instant un problème de plus en plus préoccupant. Les attaques contre les API ne sont pas suffisamment détectées, et ne sont pas assez signalées lorsqu’elles sont détectées, ce qui en fait l’une des plus grandes menaces auxquelles les organisations sont confrontées. Les attaques DDoS et les ransomware sont deux problèmes majeurs, et ils font tous les deux la une de l’actualité aujourd’hui en raison de leur impact immédiat et visible. Les attaques sur les API ne reçoivent pas le même niveau d’attention, en grande partie parce que les criminels n’utilisent pas les API d’une manière aussi spectaculaire qu’une attaque ransomware bien exécutée.

Akamai a donc publié un rapport (21 pages) qui s’intéresse aux API et à leur popularité croissante en tant que vecteur d’attaque. Vous découvrirez les erreurs courantes de codage et de mise en œuvre des API, les vulnérabilités majeures que les pirates tentent d’exploiter… Ce n’est pas tant que les techniques offensives se soient améliorées, mais plutôt que les adversaires se sont montrés plus capables que le secteur de la sécurité de l’information de recruter et de former des personnes de niveau débutant.

La première règle lors de l’écriture de logiciels sécurisés est de ne pas faire d’hypothèses sur la façon dont les personnes interagiront avec le produit fini. L’un des experts qui a aidé à la rédaction a démarré dans ce secteur il y a plus de vingt ans, en tant que testeur d’intrusion, quand presque tous les sites Web étaient facilement piratables en raison de mauvaises hypothèses : “on ne peut pas changer la valeur d’un menu déroulant”, “la validation côté client fonctionne bien”, “personne ne ferait jamais ça”. Les développeurs Web étaient déjà tellement éloignés de la technologie sous-jacente que la plupart d’entre eux ne comprenaient même pas le protocole HTTP — et c’est probablement pareil, voire pire, aujourd’hui.

Au fil du temps, les applications Web se sont lentement améliorées avec l’émergence d’outils de test plus sophistiqués et de SDLC plus robustes, mais avec les API, nous sommes de retour à la case départ. Par exemple, Lebin Cheng de CloudVector a recueilli une liste d’incidents liés aux API en 2020 de grandes marques comme Tesla, Waze, Cisco, Google, Mercedes-Benz, Apple… Bien sûr, la liste n’est pas exhaustive, mais elle illustre exactement les schémas répétés qu’on a pu observer au début du développement et des tests d’applications.

Mobile

Les API sont souvent masquées dans les applications pour mobile, ce qui conduit à croire qu’elles sont à l’abri de toute manipulation. Les développeurs partent du principe que les utilisateurs n’interagiront avec les API que via l’interface utilisateur mobile.

Un exemple, c’est une erreur de Google Firebase qui expose des données via environ 24 000 applications Android : une API non sécurisée a accédé au stockage en nuage Firebase utilisé par environ 24 000 applications Android. La vulnérabilité n’était pas vraiment une vulnérabilité dans Firebase lui-même, mais comment de nombreux développeurs Android ont configuré et utilisé Firebase. Comme Firebase est un outil multiplateforme, l’impact peut ne pas se limiter à Android. Parce que la plate-forme est basée sur le cloud, il y a malheureusement de la place pour des conséquences désastreuses si sa sécurité est mal configurée. Les déploiements fuyants ont exposé des API REST qui ont permis aux attaquants de télécharger des données d’utilisateur final via des requêtes GET, et même d’apporter des modifications aux données avec des requêtes PUT.

Une application tierce utilisée par les principaux commerçants de l’UE a dévoilé 8 millions de records de vente : Une base de données non protégée a divulgué 8 millions d’enregistrements d’achats de grands noms du commerce électronique européen, notamment Amazon UK, eBay, Shopify, PayPal et Stripe. La base de données divulguée appartenait à un fournisseur d’API qui aidait les commerçants à agréger les données de vente et de remboursement de plusieurs marchés et à calculer la taxe sur la valeur ajoutée (TVA) pour les ventes transfrontalières dans l’UE. Cet incident montre les dangers associés à l’exposition de vos données via des API à des tiers.

Une vulnérabilité de l’API du service de connexion Apple permet à un utilisateur de se faire passer pour quelqu’un d’autre : oui, c’est l’Apple Sign-in que chaque utilisateur Mac ou iPhone utilise. C’est un chercheur en sécurité qui a découvert la vulnérabilité zero-day dans la fonctionnalité “Se connecter avec Apple”. L’exploitation du bogue pouvait permettre à un adversaire de prendre le contrôle de n’importe quel compte sans que la victime ait un identifiant Apple valide. Le bogue existait dans la façon dont la fonction de connexion d’Apple fonctionnait avec des applications tierces. Habituellement, la fonctionnalité permet aux utilisateurs de partager leurs identifiants de messagerie Apple avec les applications.

5 meilleures pratiques pour la sécurité des API

1. Identifiez vos API et effectuez-en un suivi comme vous le feriez pour un inventaire. Il est donc essentiel de savoir où se trouvent les API et à quoi elles servent y compris les API externes utilisées par l’entreprise.
2. Testez-les et déterminez quelles sont leurs vulnérabilités.
3. Exploitez l’infrastructure WAF (web application firewall) existante, ainsi que toute solution de gestion des identités et de protection des données, parallèlement à tout outil spécialisé dans la sécurité des API, que ce soit pendant le développement ou lors du lancement.
4. En ce qui concerne les règles d’API, essayez d’éviter l’utilisation de règles uniques par API, en privilégiant plutôt un ensemble de règles générales pouvant être réutilisées. En outre, ne codez pas de règle directement dans les API qui doivent être protégées.
5. Le développement d’API doit, à certains niveaux, inclure diverses parties prenantes. Cela inclut les
   équipes de développement, les équipes d’opération du réseau et de la sécurité, les équipes chargées des identités, les responsables du risque, les architectes de sécurité et les équipes juridiques/de conformité (pour s’assurer que le produit respecte toutes les lois de gouvernance et de réglementation).