Les pare-feu applicatifs web (Web Application Firewall / WAF) constituent un mécanisme de protection destiné à bloquer les requêtes potentiellement malveillantes avant qu’elles n’atteignent directement l’application. Dans la plupart des cas, ils fonctionnent comme un proxy, intercep tant les requêtes HTTP, les analysant, puis décidant de l’action à entreprendre.

S’ils se révèlent efficaces dans de nombreux scénarios, une dépendance excessive à ce type de solution peut toutefois engendrer un faux sentiment de sécurité, laissant aux attaquants la possibilité d’exploiter des vulnérabilités internes non corrigées. Dans cet article, nous proposons une vision de pentester sur l’implémentation des WAF : les limites que nous avons constatées, les techniques générales de contournement, ainsi que d’autres problèmes rencontrés au cours de nos analyses.

Comment les WAF perturbent un test d’intrusion fiable

Les pare-feu applicatifs web (WAF) sont souvent perçus comme le pire ennemi du pentester, car ils bloquent de nombreuses requêtes couramment utilisées lors d’une évaluation de sécurité. Si, du point de vue d’un non-spécialiste, cela peut sembler être un simple désagrément, pour les praticiens, il s’agit d’un véritable problème.

Lors d’un audit de sécurité, il est essentiel de couvrir le plus grand périmètre possible. Or, la présence d’un WAF rend certains tests difficiles, empêchant parfois le professionnel d’identifier des vulnérabilités bien réelles.

 Par exemple, un WAF peut bloquer une tentative de cross-site scripting (XSS) sur un champ de saisie. Pourtant, si l’application ne filtre pas correctement les entrées, l’attaque resterait exploitable en cas de contournement du WAF. Cette faille aurait pu être identifiée lors d’un test sans interférence du dispositif de protection.

Contournement des Web Application Firewalls

Comme tout produit de sécurité applicative, les WAF présentent des failles que chercheurs et attaquants s’efforcent d’exploiter, et leur large diffusion en fait une cible privilégiée. Une pratique courante consiste à mettre en liste blanche les réseaux internes pour éviter que des services ou utilisateurs légitimes ne soient bloqués. Cela devient problématique si un attaquant parvient à usurper une adresse IP, souvent à cause d’une mauvaise configuration ou d’un mauvais traitement des en-têtes HTTP. L’ajout d’en-têtes contenant des adresses IP peut amener le WAF (ou un proxy intermédiaire) à considérer la requête comme provenant d’une ressource interne.

Autre vecteur d’évasion fréquent : la limite de taille des requêtes que certains WAF peuvent analyser. Lorsqu’une requête dépasse ce seuil, elle devrait être traitée comme suspecte, mais ce n’est pas toujours le cas… Un attaquant peut alors envoyer une requête volumineuse contenant du contenu malveillant pour contourner l’inspection.

Enfin, les contournements par encodage ou obfuscation (variantes d’URL-encoding, UTF-7, encodages imbriqués, etc.) sont particulièrement difficiles à combler et exigent non seulement une configuration rigoureuse du WAF, mais surtout une sécurité applicative solide. En résumé : une configuration robuste du WAF réduit les vecteurs d’évasion connus, mais la remédiation durable passe par une application capable de résister seule, sans dépendre exclusivement du WAF.e dans les SLA doivent préciser qui est responsable lorsqu’un scan piloté par l’IA omet ou rapporte mal une vulnérabilité critique. Les pentesters devront également suivre l’évolution des législations, comme l’AI Act européen, qui pourrait classer certains modèles de tests de sécurité comme « à haut risque ».

Toutes les vulnérabilités ne peuvent pas être stoppées

Bien que les WAF soient conçus pour bloquer des requêtes malveillantes, ils ne tiennent pas compte des vulnérabilités qui exploitent des actions parfaitement légitimes. Les attaques ciblant la logique métier de l’application ne reposent généralement pas sur des charges utiles suspectes, mais sur la manipulation du système afin de provoquer des comportements inattendus. L’envoi de requêtes dans le désordre, la répétition de transactions ou encore l’abus de cartes-cadeaux sont autant d’actions vues comme « normales » par le WAF. Résultat : ces manipulations logiques passent inaperçues et ne sont pas bloquées.

De la même manière, les problèmes d’autorisation échappent totalement au périmètre de protection d’un WAF. Comme pour les failles de logique, il s’agit de défauts de configuration interne, en l’occurrence dans la gestion des droits d’accès. Pour le WAF, il ne s’agit que d’un utilisateur légitime tentant d’accéder à une ressource qu’il est censé pouvoir consulter.

Vous souhaitez en savoir plus sur les vulnérabilités liées à la logique métier ? Consultez notre article récent : « Business Logic Attacks : The Silent Future of Cyberattacks ».

Les problèmes liés aux WAF personnalisés

La majorité des WAF sont fournis par des éditeurs spécialisés, mais certaines applications ou services de moindre envergure implémentent leur propre solution maison. Pour qu’un WAF soit réellement efficace, une configuration rigoureuse est indispensable, et cela s’avère encore plus critique dans le cas d’implémentations personnalisées. Dans bien des cas, les méthodes classiques de contournement fonctionnent tout aussi bien sur ces WAF, auxquels s’ajoute la possibilité de les manipuler afin de provoquer des comportements inattendus.

Ces problèmes surviennent fréquemment lorsque le WAF personnalisé est combiné avec d’autres proxies (services de cache, équilibreurs de charge, etc.). L’interaction entre ces composants peut engendrer des effets indésirables. Lors d’une évaluation, par exemple, un WAF maison intégré au service réagissait de façon anormale avec les équilibreurs de charge : les adresses IP bloquées par le WAF ne correspondaient pas à celles des testeurs, et progressivement, certaines fonctionnalités du site cessaient de fonctionner. L’enquête a révélé que le WAF interdisait l’accès… aux équilibreurs de charge eux-mêmes, plutôt qu’à la véritable source des requêtes. Ce n’est là qu’un exemple parmi d’autres des nombreux effets imprévus qui peuvent survenir avec des implémentations de WAF personnalisées.

Les WAF ont leur utilité, mais ils ne suffisent pas

Certes, les WAF jouent un rôle important dans l’écosystème sécuritaire d’une application, mais ils ne doivent pas être considérés comme la solution ultime à toutes les problématiques de sécurité. La sécurité sous-jacente de l’application doit également être robuste pour que le pare-feu et les autres moyens de protection externes soient les plus efficaces possible.

Pour ce faire, il faut effectuer des audits de sécurité en désactivant le WAF pour vérifier que les niveaux de l’application sont satisfaisants. Cela permet de s’assurer que même dans les pires cas de figure, en cas de contournement du WAF, l’application pourra tout de même gérer correctement les requêtes malveillantes.

Avec la solution SWAT d’Outpost24, vous pouvez surveiller automatiquement et en continu vos applications web pour contrôler les vulnérabilités les plus récentes. Les résultats sont vérifiés par nos testeurs d’intrusion certifiés afin d’éviter la frustration associée à des faux positifs. La solution est entièrement personnalisable selon vos besoins, minimisant les charges et les risques superflus dans vos environnements sensibles.

Vous pouvez également interagir directement avec nos experts en sécurité pour obtenir une assistance et une validation, le tout via un portail facile à utiliser. Demandez une démo en direct dès aujourd’hui.