Sécurité des API : les menaces basées sur la logique et la manière de les combattre

Quelles sont les difficultés auxquelles sont confrontés les RSSI pour sécuriser leurs API ?

Les API apportent une valeur considérable aux entreprises de tous les secteurs. Le trafic des API connaît une croissance exponentielle de 30 % par an. Cependant, le modèle de sécurité des API pose problème. Quelles sont les difficultés auxquelles sont confrontés les RSSI pour sécuriser leurs API ? Cet article vous présente les problématiques actuelles et la manière de les solutionner.

L’entreprise moderne se caractérise par l’abandon des anciennes méthodes de calcul monolithiques au profit d’environnements centrés sur les microservices et basés sur les API. La transformation numérique étant dans le viseur de toutes les entreprises, les API sont très souvent adoptées et ce pour de nombreuses raisons.

Les API offrent une valeur considérable aux entreprises de tous les secteurs. Elles sont idéales pour promouvoir la collaboration et le partenariat et permettent une sorte de « mentalité mosaïque » qui a permis de libérer le DevOps des modèles d’architecture classiques plus restrictifs. Le trafic des API connaît une croissance exponentielle de 30 % par an et représente aujourd’hui, selon les estimations, 83 % du trafic Web.

Le modèle de sécurité des API pose toutefois problème. En 2017, Gartner prévoyait que les API allaient devenir le vecteur d’attaque numéro un d’ici 2022, une prédiction qui a dû être revue fin 2021, lorsqu’on a vu le contexte exploser bien au-delà des attentes.

Les API : une nouvelle surface d’attaque

Quelles sont les difficultés auxquelles sont confrontés les RSSI pour sécuriser leurs API  ? Tout d’abord, le taux d’adoption est de loin supérieur à l’attention portée à la sécurité. La nature rapide et itérative du développement des API et des points d’accès entraîne la mise à jour du code plusieurs fois par semaine, voire plusieurs fois par jour. Cela rend les tests manuels de sécurité des API extraordinairement complexes.

Deuxièmement, les attaques actuelles contre les API sont principalement basées sur la logique. Elles ne peuvent pas être contrées par les systèmes traditionnels à base de règles comme les WAF (Web Application Firewalls), ou les passerelles mises en place pour surveiller les menaces traditionnelles. En outre, les outils d’analyse de code existants ne disposent pas du contexte nécessaire pour suivre les trajectoires empruntées par les attaques basées sur la logique. Les défenses traditionnelles ne peuvent donc pas protéger les entreprises contre ce nouveau vecteur d’attaque.

Quelle est l’ampleur de ce problème ? Environ 50 % des API des entreprises ne sont pas gérées. Il s’agit d’un gigantesque angle mort et d’un obstacle majeur pour les équipes de sécurité qui font face à une prolifération des environnements informatiques hautement distribués, accompagnée d’un manque de capacité à les sécuriser.

Il ne s’agit pas de piratage, mais d’exploitation des failles inhérentes.

On ne peut pas défendre ce que l’on ne voit pas, et lorsqu’on passe d’une architecture monolithique à une architecture basée sur les microservices, on s’attend naturellement à ce que les microservices soient plus performants que jamais, c’est-à-dire plus mobiles et plus évolutifs. Cela peut rendre les applications plus vulnérables et modifier considérablement la surface d’attaque exposée au monde extérieur. C’est pourquoi il est important de s’intéresser aux outils de gouvernance, comme les API gateways modernes, qui permettent d’appliquer des politiques uniformes à l’ensemble des API et du data mesh. Mais ce n’est pas tout : les API révèlent toujours la logique des applications, ce qui les rend vulnérables aux attaques.

La plupart des attaques d’API diffèrent du schéma classique basé sur l’injection, et beaucoup ne sont même pas des piratages. Un bon exemple est l’extraction de dizaines de millions de données utilisateurs via l’application mobile Facebook. Dans ce cas, l’agresseur n’a craqué aucune clé de chiffrement, n’a piraté aucun mot de passe et n’a tenté aucune injection SQL. La logique de l’API permettait de le faire et le tiers en a profité. Il s’agissait ainsi d’une utilisation non autorisée de l’API, mais pas vraiment d’un « piratage ».

Ceci arrive souvent : les attaquants analysent l’API et détectent des failles inhérentes à la logique de l’entreprise. En exploitant des failles telles que la « broken object level authorization » (BOLA) et la « broken functional level authorisation » (BFLA), ils n’ont pas besoin de pirater les API elles-mêmes. Par conséquent, nos défenses doivent être différentes. Nos WAF et nos passerelles ne peuvent pas (à elles seules) protéger des menaces basées sur la logique.

Adopter une vision holistique de la sécurité des API

Comment pouvons-nous protéger les API et éviter les attaques à l’encontre de notre secteur d’activité ? Le problème est généralisé et encore relativement nouveau. Le marché évolue si rapidement que Gartner a récemment modifié son architecture de référence pour inclure la sécurité des API en tant que couche dédiée dans la pile. Pour donner une idée du nombre d’entreprises qui maîtrisent ce problème, seules 11 % d’entre elles disposent d’un programme complet de sécurité des API au sein de leur organisation. Il s’agit donc d’un enjeu relativement nouveau pour tout le monde.

Plusieurs éléments doivent se combiner pour résoudre les problèmes de sécurité des API. Il s’agit tout d’abord d’obtenir une bonne visibilité du trafic circulant dans la pile. Commencer par l’analyse et l’inspection du trafic pour observer ce qui se passe dans la pile est essentiel. Mais il ne suffit pas d’observer le trafic : il faut aller au-delà du simple contrôle de suivi pour entrer réellement dans le code.

L’analyse du code permet non seulement d’effectuer les tests SAS standard pour détecter les vulnérabilités des API, mais aussi d’examiner les API tierces et les points de terminaison appelés à partir du code de base. L’analyseur de code de Wib crée également un diagramme de flux de données logique pour comprendre comment les composants logiciels interagissent les uns avec les autres, ce qui échappe aux outils SAST classiques. C’est particulièrement important dans les grandes entreprises où les équipes sont dispersées et travaillent sur des produits différents ; il est alors essentiel d’éliminer les zones d’ombre et de considérer les données sous différents angles. Ainsi, Wib propose une fonctionnalité au bas de l’analyseur de conformité VCR (engagement de conformité volontaire) permettant de visualiser les obligations de conformité de l’entreprise. Les responsables ont une vue directe sur les API qui fournissent des PII et sur celles qui sont concernées par la conformité aux normes PCI et de cartes de crédit.

La troisième pièce du puzzle est la simulation d’attaque permettant d’identifier les attaques réelles contre les API et les points de terminaison, et ce pour deux raisons. Premièrement, elle permet de déceler les failles et risques d’exposition qui auraient pu passer inaperçus. Deuxièmement, elle permet d’éliminer les fausses alertes avant que l’équipe de sécurité ou l’équipe DevOps ne lance une série de demandes de correction. Mais comment y parvenir ?

Quelques mesures pratiques

Dans un framework de microservices, les équipes responsables des applications veulent pallier le casse-tête que représentent l’authentification et l’autorisation inhérentes au modèle. Ces dernières années, les API gateways ont connu une période d’évolution notamment avec l’adoption accélérée de Kubernetes. Les API gateways, telles que Gloo Gateway de Solo.io, permettent aux entreprises de déployer tous ces mécanismes au niveau de la passerelle.

Dans une API gateway moderne, les équipes peuvent sécuriser les applications Web avec des clés API ou des jetons d’accès et peuvent mettre en place des défenses supplémentaires pour contrer les violations d’API et bloquer les menaces courantes. Les gateways peuvent également être utilisées pour révéler les failles des VM et du bare metal existants, ce qui est particulièrement utile pour les principaux datacenters sur lesquels s’appuient encore les grandes entreprises.

Enfin, avant de choisir une API gateway, il convient de se demander si l’ajout d’un service mesh s’inscrit dans un projet à long terme. Le choix d’une gateway basée sur Envoy facilite considérablement l’adoption d’un service mesh (basé sur Envoy la plupart du temps) et permet de gérer les aspects complexes des entreprises modernes, centrées sur les API. L’adoption de Kubernetes et d’Istio dans les entreprises en particulier participe à la simplification de la transformation numérique pour un grand nombre d’organisations.