Les flux d’appels d’API sont en train d’exploser sur Internet… tout comme le nombre d’attaques dont elles font l’objet. Le WAF ne suffit plus et il faut rapidement muscler leur protection alors que les IA génératives vont rebattre les cartes de la cyber. Par Alain Clapaud
En 2022, Cloudflare publiait une statistique étonnante : 54 % du trafic sur son réseau mondial provenait d’appels d’API, soit plus que la navigation Web et que les flux audiovisuels ! En évolution du trafic, là encore les API représentent celui qui croît le plus rapidement, avec une augmentation de 21 % contre 10 % pour le Web. Ce trafic considérable ne pouvait qu’attirer les pirates informatiques qui s’intéressent de plus en plus aux API. Lors de l’année 2022, le nombre d’attaquants détectés par l’éditeur spécialisé Salt Security est passé de 123 à 4 842, soit une croissance de 400 % en 12 mois… Une augmentation qui doit interpeller les RSSI des entreprises. Illustration de ce risque accru sur les API : la fuite massive de données dont fut victime T-Mobile en tout début d’année 2023, avec des données de 37 millions de ses clients exfiltrées via une API. Initiée en novembre 2022, cette attaque ne fut détectée que le 5 janvier 2023 par l’équipe de sécurité.
De multiples solutions de sécurité cherchent à protéger les API. En première ligne, on pense forcément au Web Application Firewall : « Le WAF est presque devenu une commodité, estime Gérald Delplace, AVP EMEA South chez Imperva. Notre WAF intègre une protection anti-DDoS Web et nous nous engageons sur un SLA de 3 secondes pour détecter et bloquer une attaque. Néanmoins, sur la partie API, les investissements restent faibles en France. » En évoluant vers les WAAP, les firewalls applicatifs ont intégré les particularités techniques liées aux API.
Juan Plans, architecte solution chez Radware, souligne que si les risques portent essentiellement sur l’authentification et les autorisations dans le top 10 de l’OWASP relatif aux API, il faut aussi traiter le risque d’attaque DDoS ou encore la sur-utilisation d’API, dont il faut se prémunir puisque chaque appel d’API a un coût. « Viennent s’ajouter aux vulnérabilités des API toutes les vulnérabilités Web classiques, d’où la nécessité de protéger cette surface d’attaque avec un WAAP, en quelque sorte le successeur du WAF. Le Web Application and API Protection contient un WAF mais aussi des modules qui viennent apporter une sécurité aux API sur la partie flux. »
« Il faut avoir une solution qui soit capable d’apprendre ce qui est un comportement normal pour ensuite détecter les transactions suspectes. »
Elimane Prud’hom, directeur commercial de Salt Security France
Le recours à une API Gateway va permettre d’industrialiser la gestion des API exposées par l’entreprise et d’uniformiser les règles de sécurité. « Nous avons capitalisé l’expérience de la protection de nos propres API Google Maps, YouTube et autres. Nous réutilisons les modèles de machine learning qui ont réalisé leur apprentissage sur les attaques auxquelles nous avons déjà fait face pour les déployer sur notre plateforme d’API Management d’Apigee, au travers du module de sécurité avancée Google Apigee Advanced API Security », explique Christophe Lalevée, Customer Engineer Apigee chez Google Cloud.
Chaque brique de sécurité va filtrer un certain nombre d’attaquants, mais les plus opiniâtres finissent toujours par contourner ces protections. Les récentes attaques sur les API ont montré que celles-ci n’avaient pas été bloquées par les solutions de sécurité en place, estime Elimane Prud’hom, directeur commercial de Salt Security en France. Il argumente sa position : « Les WAF, les API Gateway et les process DevSecOps n’ont pas toujours la capacité de détecter ces attaques, ce qui a poussé le Gartner a affirmer qu’il faut désormais avoir une approche de sécurité spécifiquement dédiée aux API, car il manquait à ces solutions l’analyse comportementale du trafic des API. » Si les attaques DDoS peuvent aujourd’hui être traitées par les services spécialisés, si une injection SQL peut être repérée et filtrée par un WAF, détecter une attaque applicative peut être très complexe car, chaque API étant spécifique, l’application de règles globales peut difficilement repousser toutes les attaques qui s’intéressent à la logique applicative de l’API. C’est notamment le cas si on utilise un compte valide pour se connecter à l’API puis si on tente d’accéder à d’autres comptes ou de modifier au dernier moment le numéro de compte à l’origine d’un transfert financier. « Toute la complexité est de pouvoir détecter ces comportements anormaux. Chaque API étant unique, on ne peut se baser sur des signatures ou des seuils pour définir ce qui est anormal. Il faut avoir une solution qui soit capable d’apprendre ce qui est un comportement normal pour ensuite détecter les transactions suspectes. » L’éditeur revendique une période d’apprentissage très courte. Sur des API présentant un fort volume d’appels, le modèle peut avoir constitué sa baseline (comportement par défaut) et délivré ses premières alertes en quatre heures.
Autre éditeur de service mettant en œuvre des modèles de machine learning pour protéger les applications Web et les API : le français DataDome. La start-up protège les API contre un vaste panel de types d’attaques comme le credential stuffing, le scratching de données, les scans de vulnérabilité, les attaques DDoS et les fraudes aux paiements. Antoine Vastel, responsable de la recherche chez DataDome, explique comment la plateforme détecte toutes ces attaques : « Nous offrons une couverture large, car nous protégeons des API publiques et nous cherchons à détecter si la personne qui accède à l’API est véritablement humaine. De cette manière, nous sommes capables de détecter différents types d’attaques. Nous vérifions que celui qui accède à l’API le fait depuis l’application ou le navigateur auquel on s’attend. Le finger printing nous permet de vérifier les attributs du client. Nous vérifions aussi le comportement de l’utilisateur pour nous assurer qu’il s’agit bien d’un humain. » Outre le finger printing, les algorithmes de DataDome tiennent compte des signaux comportementaux avec le graphe de navigation, les séquences de requêtes et le comportement de l’utilisateur côté client. Une troisième catégorie de signaux est liée à la réputation et au contexte. Le comportement de l’adresse IP chez d’autres clients du service est suivi, de même que la durée des sessions et le contexte géographique pour vérifier si le pays est cohérent avec la langue. Tous ces signaux faibles viennent enrichir une détection qui doit être réalisée en temps réel : « Nous traitons tous ces signaux en temps réel dès l’arrivée de la requête, en moins de 2 millisecondes. C’est un temps de traitement très restreint et chaque requête est analysée et vient ajouter des métadonnées sur l’utilisateur. Nous appliquons différentes règles et différents modèles de machine learning qui travaillent sur ces attributs. »
L’IA générative, une nouvelle arme pour les attaquants
Si le camp de la défense est monté en puissance, les attaquants ne restent pas l’arme au pied. Beaucoup évoquent les atouts de l’IA pour déjouer les modèles de détection comportementaux, avec des IA capables de singer les comportements humains et de mettre en œuvre le polymorphisme pour modifier leur attaque si celle-ci vient à être détectée… Au-delà des fantasmes, Antoine Vastel souligne : « Nous commençons à voir arriver les IA génératives, mais pas partout. On ne dispose pas de preuves formelles, mais on peut identifier des schémas qui laissent penser que l’on a affaire à ChatGTP ou à des LLM pour spammer les utilisateurs de manière plus réaliste ou s’adapter au contexte du site. On sait que des attaquants ont développé des frameworks pour imiter les mouvements de souris des humains, en utilisant les GAN (Generative Adversarial Networks) pour déplacer la souris entre deux points de manière plus réaliste. » Enfin, les IA ont définitivement prouvé leur supériorité sur l’humain pour déjouer les Captcha les plus simples. Certaines fermes de Captcha ont remplacé leurs employés humains par des algorithmes bien plus rapides…
La problématique des IA génératives est bien plus complexe qu’un détournement de l’IA par prompt injection ou qu’une attaque réalisée sur une API avec un code généré par une IA. Dans un avenir très proche, il faudra être capable de vérifier qu’une IA appelée par une application d’entreprise va réellement fournir ce que l’on attend d’elle. « On va retrouver cette problématique à chaque point de l’architecture cloud, explique Christophe Lalevée. Est-ce qu’un bot ne va pas demander de la donnée à laquelle il n’a pas le droit d’accéder et exploiter l’IA pour se livrer à une exfiltration de données ? De même au niveau des backends : est ce qu’un backend généré par IA passe tous les tests de la chaîne CI/CD ? » L’expert souligne qu’une université américaine a déjà testé un modèle de génération de code qui peut ajouter un backdoor dans l’application qu’il génère…
