Elad Amit, directeur de la gestion des produits, PerimeterX
Vous craignez peut-être que des attaquants ne défoncent la porte d’entrée de votre vitrine numérique, mais ils se concentrent de plus en plus sur la porte latérale : vos interfaces de programmation d’applications (API).
Selon le cabinet de conseil en recherche et d’analyse Gartner, d’ici 2021, 90 % des applications Web auront une surface d’attaque plus exposée sous forme d’API plutôt que d’interfaces utilisateur directes sur un site Web ou dans une application mobile. Malheureusement, de nombreux opérateurs d’applications Web n’ont pas encore rattrapé cette réflexion. Des vulnérabilités et des attaques d’API récentes ont été signalées sur des applications exécutées par la société d’exercices Peloton, le fournisseur de rapports de crédit Experian et la startup de chat audio enflammée Clubhouse.
Les attaquants de l’API suivent les tendances des achats en ligne. Le commerce électronique moderne s’appuie sur des API pour exposer des fonctionnalités essentielles, telles que des paniers d’achat, sur plusieurs plateformes. Les cybercriminels ont reconnu que les attaques d’API pilotées par des robots sont plus faciles que les prises de contrôle de compte (ATO) ou d’autres formes d’attaques.
Les criminels peuvent lancer des attaques d’API avec moins d’infrastructure que d’autres types d’attaques. Étant donné que les API sont des connexions de machine à machine, il est plus facile pour un attaquant de masquer son identité car les communications API contiennent beaucoup moins d’informations pour identifier les modèles d’attaques. Pour les détaillants qui souhaitent protéger leurs clients, leur réputation et leurs marques, il est essentiel de protéger correctement leurs API pour faire des affaires à l’ère connectée.
Que sont les attaques d’API ?
Une API est un moyen de permettre des connexions directes, des communications et un partage de données entre les applications d’une manière indépendante de la plate-forme et de la technologie. Les API permettent à tous les types d’appareils ou aux services partenaires et affiliés de poser une question ou d’envoyer des informations à une application en toute sécurité. Les API sont devenues un ciment crucial qui permet au labyrinthe de services internes et externes qui composent les applications modernes de communiquer entre eux de manière automatisée. Une attaque d’API est une utilisation hostile ou une tentative d’utilisation hostile d’une API.
Étant donné que les API sont de nature programmatique, les criminels aiment utiliser des attaques automatisées contre elles. Il existe de nombreux types d’attaques d’API, notamment le déni de service distribué (DDoS), les attaques par injection, le détournement d’authentification et l’abus d’applications. Parmi ces types d’attaques, l’abus d’applications est la principale préoccupation des opérateurs de commerce électronique.
Pour le contexte, les attaques par prise de contrôle de compte (ATO) sont une forme d’abus d’application. La plupart des ATO n’essayent en aucun cas de casser la logique de l’application ; ils essaient simplement de brancher de nombreuses combinaisons de nom d’utilisateur ou d’e-mail et de mot de passe pour valider un compte en totale conformité avec la logique de l’application. Une autre forme d’abus d’applications ciblant régulièrement les API est le refus d’inventaire et la thésaurisation. Dans ces attaques, des acteurs malveillants utilisent des appels d’API pour remplir continuellement les paniers d’articles qu’ils n’ont jamais l’intention d’acheter afin d’empêcher les acheteurs légitimes d’acheter les articles.
Pourquoi les attaques d’API sont-elles si dangereuses ?
De nombreux facteurs rendent les attaques d’API encore plus dangereuses que les attaques traditionnelles sur les interfaces utilisateur telles que les sites Web ou les applications mobiles. Les appels d’API contiennent moins d’informations d’identification sur l’utilisateur ou l’appareil qui demande les informations. Cela donne à la technologie de blocage des attaques automatisées moins d’indices pour identifier les mauvais appels d’API envoyés par des robots malveillants.
Par exemple, dans un appel d’API, il n’y a aucune information sur la façon dont un utilisateur se déplace sur une page ou sur le temps qu’il lui faut pour passer d’une page à une autre. Ces points de données aident à détecter les robots à l’aide de JavaScript qui automatise la navigation humaine. Les API interrogent directement une application, sans avoir à naviguer dans une application ou une page Web.
De plus, les API ne sont souvent pas aussi sécurisées que les applications Web. Les appels d’API bien déguisés peuvent échapper aux contrôles de sécurité hérités tels que les pare-feu d’applications Web ou les passerelles d’API lorsque les attaquants conçoivent ces appels pour qu’ils soient presque identiques aux appels d’API légitimes d’acheteurs réels. Encore plus troublant, les API exposées permettent aux attaquants de contourner entièrement le côté client des applications et d’atteindre directement les bases de données et les niveaux d’application. Cela crée beaucoup plus d’exposition et de risque, car ces actifs peuvent avoir un accès constant à des informations sensibles ou la capacité de modifier le comportement des applications de manière malveillante.
De nombreux e-commerçants n’optimisent pas la sécurité
Même si les risques liés aux API augmentent, de nombreuses équipes de développement d’applications de commerce électronique n’optimisent toujours pas correctement leur code et leur architecture pour une sécurité améliorée des API.
Par exemple, de nombreuses applications de commerce électronique utilisent la même API pour recevoir et répondre aux requêtes acheminées depuis leur site Web, leurs applications mobiles, leurs sociétés affiliées ou leurs partenaires. L’utilisation d’une seule API permet aux attaquants de cacher plus facilement leur identité et d’éviter la détection. Les mesures de détection standard sont plus faciles à régler si l’API a un usage unique plutôt que plusieurs usages. Ce problème est multiplié par la nouvelle génération d’API unifiées alimentées par un langage de requête appelé GraphQL. GrapQL peut utiliser les API plus efficacement, mais les API GraphQL sont plus difficiles à verrouiller en raison de la façon dont elles structurent leurs appels et leurs communications avec des parties externes.
Un autre oubli fréquent est de ne pas traiter les API internes et externes avec les mêmes mesures de sécurité. En théorie, les API internes ne sont pas censées recevoir de trafic externe. Dans la pratique, les criminels intelligents savent mieux comment trouver et compromettre les API internes. Par exemple, un nombre croissant d’attaques ciblent le service de stockage Amazon Web Services S3. Les applications de commerce électronique accèdent souvent à S3 en tant qu’API interne, destinée à être isolée du monde extérieur.
Les équipes de développement d’applications ne déploient souvent pas de pratiques de sécurité standard telles que Transport Layer Security (TLS), qui crypte les données pour protéger les informations de paiement et personnelles, sur les API internes. Plus généralement, les équipes de développement d’applications ne consacrent pas autant de temps et d’efforts à l’audit et à la sécurisation de leurs API, car elles considèrent toujours les attaques directes sur leurs applications Web comme la plus grande menace à laquelle elles sont confrontées. En outre, ils ont tendance à être moins familiarisés avec les détails des attaques d’API. Pour ces raisons, ils sont moins susceptibles d’examiner les comportements de requête d’API et sont moins conscients des modèles d’anomalies.
Comment renforcer la sécurité des API pour empêcher les attaques automatisées
Les équipes de développement d’applications de commerce électronique qui souhaitent renforcer leurs défenses API peuvent commencer par adopter les meilleures pratiques établies. Pour commencer, les équipes de développement d’applications avec des API unifiées doivent envisager de les séparer en API individuelles pour le trafic externe afin de traiter les applications Web, les applications mobiles, les partenaires tiers, les fournisseurs et les sociétés affiliées. Étant donné que les détaillants peuvent exposer par inadvertance des API internes à l’Internet public, tout le trafic API, y compris le trafic interne, doit être chiffré avec TLS.
Une autre pratique de sécurité intelligente consiste à limiter le débit des appels d’API. Cette pratique peut réduire l’impact des attaques automatisées par force brute par des armées de bots. Cela peut également aider à identifier les attaques de manière plus définitive. Les limites de débit peuvent également être variables, en fonction du niveau de confiance de la partie externe accédant à l’API et des éventuels identifiants attachés à ces appels. Une troisième étape intelligente consiste à créer un compartiment pour les appels d’API dans les fichiers journaux et à créer des tableaux de bord d’API ou des rapports réguliers pour aider les équipes de sécurité à détecter les anomalies et les valeurs aberrantes. Plus précisément, les équipes de sécurité doivent surveiller régulièrement le pourcentage de tentatives de fraude via l’API par rapport aux autres canaux.
La pratique la plus avancée et la plus puissante que les équipes de sécurité ou de développement d’applications puissent adopter consiste à tirer parti de l’apprentissage automatique pour identifier les modèles et les comportements des appels d’API malveillants. Étant donné que l’apprentissage automatique peut analyser beaucoup plus de points de données que les humains et beaucoup plus rapidement, cette technologie peut déterminer quels appels d’API sont susceptibles de provenir de robots attaquants. Pour ce faire, ils analysent des centaines de points de données différents, notamment le réseau ou l’hôte cloud d’origine, la structure et le type d’appel, ainsi qu’une page ou un article ciblé sur le site d’un détaillant. Il existe des services tiers qui peuvent le faire, ou l’équipe de sécurité peut utiliser les outils d’apprentissage automatique existants pour doter, développer et maintenir les capacités en interne.
Il est difficile d’exagérer l’urgence d’élaborer une stratégie d’API et d’améliorer les défenses des API. Alors que les attaques d’API continuent d’augmenter en fréquence et en gravité, cela deviendra probablement le vecteur d’attaque préféré des criminels cherchant à frauder vos clients. Heureusement, il existe un chemin bien tracé vers une meilleure sécurité des API qui protégera votre vitrine numérique maintenant et à l’avenir.
PerimeterX fournit des services de sécurité pour les sites Web et les applications mobiles.
Préféré
