Cloudflare a testé son pare-feu applicatif web (WAF) à l’aide de modèles d’intelligence artificielle avancés capables de modifier les requêtes offensives après chaque tentative, au lieu de se limiter à un ensemble fixe de tests. L’entreprise a mené l’expérience dans un environnement de staging propre à un client, avec son accord préalable, et a enregistré 1 107 tentatives dans le cadre de 45 scénarios.
L’idée principale consiste à simuler une partie du comportement d’un attaquant capable d’essayer différents encodages, de déplacer la charge utile vers d’autres emplacements au sein d’une requête HTTP ou de modifier la manière dont la destination est représentée, puis d’utiliser la réponse pour choisir la tentative suivante. Le modèle n’a reçu ni le code de l’application, ni les règles internes du WAF, ni les numéros des règles, mais a uniquement traité le contexte de la requête et certaines données de réponse HTTP.
Comment le test adaptatif a-t-il fonctionné ?
Chaque scénario a commencé par une requête connue pour être bloquée par le WAF, puis le modèle a proposé une nouvelle modification. Après l’envoi de la requête, un autre modèle ou un appel de revue du modèle a examiné la réponse, avant que le système ne détermine l’étape suivante dans une limite maximale de tentatives. Le code s’est chargé d’exécuter les requêtes et d’enregistrer les éléments de preuve. Avant chaque tentative, il vérifiait également le nom de domaine au moyen d’une liste autorisée, désactivait les redirections et empêchait le système de modifier ou de déployer les règles de protection.
Quarante-quatre des scénarios couvraient six catégories : le cross-site scripting (XSS), l’injection SQL, l’injection de commandes, la falsification de requêtes côté serveur (SSRF), la traversée de chemins ou l’inclusion de fichiers locaux (LFI), ainsi que les attaques Log4j. Le quarante-cinquième scénario portait séparément sur l’injection de journaux.
De 1 107 tentatives à 49 résultats pouvant faire l’objet d’une investigation
Les performances du WAF ont globalement été solides, avec une couverture quasi complète des catégories XSS, LFI, SQLi et Log4j. Après la revue humaine, 49 résultats sont restés dignes d’une investigation, dont 48 relevaient des catégories de l’injection de commandes et de la SSRF. Le nombre de requêtes bloquées s’est élevé à 558, tandis que d’autres tentatives ont été écartées parce qu’elles étaient invalides, bénignes, dupliquées ou n’avaient pas atteint la cible.
Cloudflare n’a pas considéré une requête non bloquée comme une vulnérabilité confirmée. Elle a exigé que la requête soit valide et atteigne la cible, qu’elle demeure clairement malveillante, que le comportement soit attribuable au WAF et que les ingénieurs puissent la reproduire en toute sécurité. Cette distinction est importante, car le contournement du WAF ne prouve pas à lui seul que l’exploitation de l’application a réussi ou que des données sensibles ont été consultées.
Exemple de lacune dans la détection de la SSRF
Dans l’un des scénarios, le système a modifié la manière d’écrire l’adresse du service de métadonnées cloud, utilisé différentes représentations numériques et placé l’adresse dans plusieurs parties de la requête. La plupart des tentatives ont été bloquées, mais l’une d’elles, qui utilisait une représentation avec un point final, a entraîné une redirection au lieu d’un blocage par le WAF. Cloudflare a considéré cela comme un signal méritant une investigation, et non comme une preuve de l’accès aux identifiants ou de la réussite de l’exploitation.
Qu’est-ce qui a changé concrètement ?
Cloudflare a examiné les résultats afin de déterminer s’il fallait ajouter une nouvelle règle, améliorer la normalisation des requêtes ou faire intervenir une autre couche de sécurité. Les résultats ont contribué à trois changements au sein du Managed Ruleset : l’ajout des détections SSRF - Obfuscated Host et SSRF - Restricted Protocol dans la version du 21 juillet, ainsi que l’amélioration de la détection SSRF - Cloud. La détection de l’hôte obfusqué provenait directement de requêtes utilisant des formats numériques inhabituels pour des adresses internes.
L’expérience montre que l’intelligence artificielle constitue ici un outil permettant d’élargir l’espace de test, et non un substitut au jugement technique. Deux modèles de la même famille ont produit des variantes différentes, mais les problèmes fondamentaux sont apparus dans les deux cas. De même, l’augmentation du nombre de tentatives au sein d’un même scénario n’a pas garanti la découverte de résultats supplémentaires : certaines séquences ont commencé à répéter les mêmes idées, tandis que l’augmentation du nombre de points de départ, des catégories d’attaques et des emplacements d’injection a offert une couverture plus large.
Les limites du WAF restent présentes : une charge utile qui franchit le pare-feu ne réussit que si l’application elle-même est exploitable, raison pour laquelle la mise à jour des logiciels et la correction des vulnérabilités demeurent nécessaires. Cloudflare recommande également d’activer d’abord les règles en mode journalisation, d’examiner les requêtes correspondantes et les événements de sécurité, puis de passer au blocage après avoir vérifié que le trafic légitime n’est pas affecté. L’entreprise prévoit par la suite de présenter un test en white-box dans lequel le modèle connaîtrait à la fois les vulnérabilités de l’application et les règles du WAF.