Quels sont les pièges liés à l’utilisation du Web Application Firewall (WAF) lors d’un Web Application Vulnerability Assessment (WAVA) ?

Avant de réaliser un test d'intrusion sur les applications web de nos clients, une réunion de lancement est organisée afin de discuter du test et de recueillir certaines informations sur les besoins du client. L'une de nos questions est : Le test sera-t-il effectué avec ou sans le WAF ?

Dans certains cas, il n'y as pas de WAF ➡️ Problème résolu : le test sera réalisé sans WAF. Cependant, lorsqu'un WAF est présent, il est important de savoir s'il sera en mode blocage ou si le consultant sera mis sur liste blanche. Cette question peut soulever certaines problématiques, mais finalement, la meilleure réponse dans la plupart des cas est : Sans le WAF. Valentin Giannini, Cybersecurity Pentest Expert chez Thales, va expliquer pourquoi.

Qu'est-ce que le WAF ?

Un WAF, ou Web Application Firewall (pare-feu applicatif Web), est un dispositif de sécurité placé devant l'application, qui bloque certains types de charges malveillantes (payloads) qu'un attaquant pourrait envoyer à l'application web. Pour simplifier, le WAF protège contre les failles d'injection, telles que l'injection SQL, le Cross Site Scripting (XSS), l'exécution de commandes, path traversal, etc.

Ce dispositif est formidable, car en cas d'absence de validation des entrées côté application, le WAF bloque les charges malveillantes pour empêcher leur exploitation et éviter que l'attaquant ne puisse aller plus loin.

Cependant, il y a des points importants à considérer lorsqu'un WAF est utilisé devant notre application...

Contournement physique du WAF

Certaines entreprises utilisent un WAF basé sur le cloud. Ce type de WAF fonctionne comme un CDN, mais avec des règles de sécurité supplémentaires. Ainsi, le domaine lié à l'application pointe vers l'adresse IP du WAF cloud, qui transmet ensuite la requête à l'application web hébergée en local, par exemple. Cependant, cette application web doit être accessible depuis Internet, puisque c'est là que se trouve le WAF. Si aucune restriction n'est appliquée sur les adresses IP sources provenant d'Internet, n'importe qui peut accéder au site en forçant l'association domaine/IP sur son ordinateur. Dans ce type de configuration, l'application web ne devrait être accessible que depuis l'IP du WAF, et non depuis l'ensemble d'Internet.

Un autre type de contournement consiste simplement à accéder à l'application web depuis le réseau interne. En général, le WAF est configuré uniquement pour les utilisateurs venant d'Internet. Si l'utilisateur se trouve sur le même réseau que l'application, le WAF ne sera pas utilisé. Ce scénario doit pete pris en compte. Les prérequis pour l'attaquant sont plus élevés, mais cela reste possible.

Ce type de contournement peut également être réalisé par une autre application. Par exemple, une application non protégée par un WAF peut envoyer des requêtes vers une autre application protégée par un WAF uniquement pour les utilisateurs externes. Ainsi, un type de pivot peut être effectué via cette application non protégée (ou mal protégée) par un WAF.

Contournement logique du WAF

Une autre menace liée au WAF est... le WAF lui-même. Si des failles ou des techniques de contournement sont découvertes, les attaquants peuvent les exploiter pour accéder à l'application web sans filtrage.

Le contournement peut être réalisé en encodant la charge malveillante dans un format particulier. Cela peut consister à encoder l’URL une ou plusieurs fois, à utiliser des caractères Unicode, ou encore à exploiter certaines spécificités du langage ciblé. Par exemple, dans le cas d’une injection SQL, le WAF peut détecter des requêtes comme SELECT * FROM XXX, mais certains langages SQL acceptent les commentaires comme dans : SELE/**/CT/**/*/**/FR/**/OM/**/XXX. En ajoutant des /* et */, interprétés comme des commentaires par le SGBD, la requête reste fonctionnelle, mais le WAF ne reconnaît plus les mots-clés "SELECT" et "FROM".

De plus, l'utilisation de certains en-têtes tels que X-Forwarded-For ou X-Forwarded-Host peut également permettre de contourner le WAF, par exemple en définissant une adresse IP interne ou une adresse IP de type localhost.

Les modes d'apprentissage et de blocage

La plupart des WAF disposent d’un mode d’apprentissage. Ce mode doit être activé avant la mise en production, et les testeurs doivent utiliser toutes les fonctionnalités afin de simuler chacune des actions qu’un utilisateur réel pourrait effectuer. Une fois l’apprentissage jugé suffisant, le WAF passe en mode blocage. Si le WAF détecte une requête qui ne semble pas légitime, car elle n’a jamais été observée lors des tests d’apprentissage, cette requête est bloquée, ce qui permet d’éviter l’attaque.

Mais toute cette sécurité repose sur le mode d’apprentissage et sur les tests effectués durant cette période. Par exemple, si le testeur a utilisé des caractères spéciaux dans certains champs, comme le champ commentaire, le WAF les apprendra et les acceptera. Cependant, ces caractères pourraient faire partie d’un payload ; si celui-ci ne correspond pas aux signatures, il pourrait passer, et l’application pourrait être compromise.

Un autre point important est de s'assurer que le mode d'apprentissage est désactivé lors d'un test d'intrusion. Sinon, le WAF pourrait apprendre les payloads utilisés par l'attaquant, ce qui compromettrait la liste des entrées autorisées.

Enfin, et ce n'est pas le moindre, le mode d'apprentissage ne doit jamais être activé sur une application exposée à Internet, car de nombreux scanners automatisés envoient des requêtes qui viendraient corrompre la liste des entrées autorisées.

Gestion du WAF

Si le WAF est correctement configuré, avec une correspondance parfaite des entrées attendues, il reste néanmoins possible que sa gestion présente des failles.

Premièrement, si la marque du WAF doit être changée, toutes les règles doivent être traduites vers le nouveau système, ce qui nécessite des tests en mode apprentissage. Ainsi, lors de la migration d’applications vers un autre WAF, le besoin en ressources humaines peut être considérable. Cela implique que certains tests ne seront pas réalisés ou que certaines règles seront trop permissives ou manquantes, par exemple.

Un autre problème possible est l’oubli de renouveler la licence. Pour certains types de WAF, il continuera à bloquer les modèles connus, mais ne recevra plus de nouvelles signatures. Par conséquent, un nouveau payload pourrait ne pas être détecté, permettant à un attaquant d’exploiter une nouvelle méthode de contournement.

Enfin, le cycle de vie des règles du WAF doit être considéré comme un point essentiel. Si une application modifie ses entrées, ajoute ou supprime des pages, les règles doivent être mises à jour afin de limiter la surface d’attaque. Si certaines règles restent trop permissives, même si l’application ne l’exige pas, le niveau de risque augmente.

Retour sur le WAVA

Chez Thales, le test d’intrusion Web appelé WAVA vise principalement à évaluer l’application elle-même et non l’infrastructure. Le WAVA se concentre sur les fonctionnalités implémentées par l’application, et le consultant cherchera à exploiter les failles propres à la technologie utilisée. Le contournement du WAF ne s’inscrit pas dans cette logique, car il relève d’un autre type de compétence.

After a WAVA, the consultant should be able to say, "the SQL query that allows retrieving the list of users is vulnerable to an SQL injection." The recommendation will be adapted to that context. With a WAF blocking some effects of the injection, the consultant could only be able to say “That feature is potentially vulnerable,” or, in the worst case-scenario, “Didn’t find the issue.”

Alors, avec ou sans le WAF ?

Du point de vue de la sécurité applicative, la meilleure approche consiste à effectuer le test sans WAF.

En principe, le pentester doit pouvoir évaluer toutes les fonctionnalités de l’application et chaque saisie utilisateur sans aucune restriction. Si une faille d’injection existe, elle sera plus facilement détectée sans WAF.

Ensuite, si une vulnérabilité est identifiée, un test rapide peut être réalisé avec le WAF activé afin de vérifier si le client est protégé pendant le délai nécessaire à l’équipe de développement ou au fournisseur pour corriger le problème.

Enfin, un test du WAF doit également être effectué pour s’assurer que le mode blocage est activé, que le WAF bloque les charges malveillantes les plus courantes, les requêtes qui ne correspondent pas au format d’une requête légitime, et qu’il génère des alertes si une adresse IP déclenche trop d’événements suspects.

Verdict ?

Cette initiative est pertinente, car elle reprend un excellent concept comme security.txt et le pousse encore plus loin. Tout le monde connaît le DNS, tout le monde utilise le DNS, tout le monde fait du DNS. Le manque d’implémentation globale ne devrait pas être un frein, tant que l’idée est bonne, et elle l’est. Alors pourquoi ne pas faire partie des premiers à l’implémenter ?