Ce qui passe encore par le WAF : techniques de contournement et comment les atténuer

La conviction selon laquelle disposer d’un WAF équivaut à disposer d’un périmètre de sécurité est l’une des dépenses les plus coûteuses qu’une équipe technique puisse soutenir. Les WAF fonctionnent sur des représentations de requêtes : reçoivent des octets, interprètent selon des règles, décident si le modèle correspond à une attaque connue. Le problème est qu’il existe un écart entre l’interprétation du WAF et l’interprétation de l’application. Les attaquants conscients de cette lacune l’exploitent avec des techniques qui existent depuis plus d’une décennie et qui restent efficaces car elles s’appuient sur les ambiguïtés des protocoles HTTP, et non sur des failles spécifiques du produit.

Comment le double encodage contourne l'inspection de la charge utile

L'encodage d'URL est un mécanisme HTTP légitime : ' (guillemets simples) peut être représenté par %27. La plupart des WAF décodent cet encodage avant d’appliquer les règles – comportement correct, puisque l’application le décodera également.

Le problème apparaît avec le double encodage. La chaîne %2527 se décode en deux étapes : d'abord en %27, puis en '. Un WAF qui effectue un seul cycle de décodage voit %27 et considère qu'il s'agit d'une représentation inoffensive de guillemets simples. L'application, lors du traitement de la requête, effectue son propre décodage et arrive au ' que l'attaquant a voulu introduire. La charge utile est arrivée intacte.

Les variantes incluent des espaces de codage comme %09 (tabulation au lieu d'espace, équivalent dans de nombreux contextes SQL) et le mélange d'encodages majuscules et minuscules que certains moteurs d'expressions régulières ne normalisent pas.

Cloudflare applique la normalisation des requêtes avant d'exécuter les règles — une canonisation qui annule plusieurs couches d'encodage. Cela atténue la plupart des techniques de double codage, mais l'efficacité dépend de l'exhaustivité de la normalisation appliquée à chaque champ inspecté.

Contrebande de requêtes HTTP : quand WAF et origin ne sont pas d'accord

HTTP/1.1 permet deux manières d'indiquer la taille du corps d'une requête : Content-Length, qui spécifie les octets exacts, et Transfer-Encoding: chunked, qui envoie le corps en plusieurs parties. Lorsque deux en-têtes sont présents avec des valeurs contradictoires, le comportement n'est pas défini par le protocole — il est défini par l'implémentation de chaque serveur.

Un WAF qui donne la priorité à Content-Length et un serveur d'origine qui donne la priorité à Transfer-Encoding ne seront pas d'accord sur l'endroit où aboutit une requête. Un attaquant contrôlant ce conflit fait voir au WAF une requête inoffensive tandis que le serveur en voit deux : la première légitime, la seconde avec un contenu malveillant qui n'a jamais passé l'inspection. La contrebande de requêtes HTTP a affecté plusieurs WAF commerciaux au fil des ans, nécessitant des correctifs spécifiques pour chacun.

Cloudflare normalise les requêtes avant de les transmettre à l'origine. Pour que l'attaque fonctionne sur une architecture Cloudflare, le serveur d'origine doit recevoir des connexions directes, ce qui nous amène à l'atténuation la plus importante et la moins appliquée.

Ce que Cloudflare ne peut réellement pas protéger

La logique métier est le cas le plus clair. Le WAF n'a aucun contexte pour son application : il ne sait pas qu'un transfert de 50 000 R$ dans une séquence rapide est suspect, que le point final /api/export ne doit être accessible qu'avec le rôle admin, ou que discount_percentage ne doit pas accepter de valeurs négatives. Les attaques IDOR, la manipulation des paramètres de prix et l'abus des flux d'authentification apparaissent comme des requêtes valides du point de vue du WAF, car elles le sont. Cette protection appartient à l'application.

Les jours zéro sont le deuxième cas. Lorsqu'un CVE critique est publié, Cloudflare a besoin de temps pour développer une signature. Cet intervalle peut durer des heures ou des jours, et pendant cet intervalle, l'application est exposée même avec des ensembles de règles gérés actifs. Les règles WAF ne remplacent pas les correctifs d'application.

Le contournement le plus simple : accéder directement à la source

L'ensemble du modèle de protection Cloudflare WAF dépend d'une condition : le trafic doit passer par le proxy pour être inspecté. Les enregistrements DNS en mode DNS uniquement (le nuage gris sur le tableau de bord) ne transitent pas par le proxy. Si le sous-domaine qui dessert l'application est uniquement DNS, le WAF n'existe tout simplement pas pour ce trafic.

La deuxième condition est l'adresse IP source. Si un attaquant découvre la véritable adresse IP du serveur, il peut se connecter directement au port 443 avec le bon en-tête Host et contourner complètement la périphérie. Cette IP peut avoir été exposée via un DNS historique indexé par SecurityTrails avant la migration, des journaux de transparence des certificats TLS émis directement sur l'IP ou des en-têtes de courrier électronique envoyés par le serveur.

L'atténuation consiste à configurer le serveur d'origine pour accepter uniquement les connexions à partir des plages IP Cloudflare publiées dans la version 16. Un groupe de sécurité ou une règle de pare-feu qui accepte uniquement ces plages élimine le contact direct avec la source. Pour ceux qui souhaitent éliminer complètement les ports ouverts vers Internet, Cloudflare Tunnel établit une connexion sortante du serveur vers la périphérie sans exposer aucune adresse IP.

Le modèle de menace qui doit être communiqué

Le WAF est efficace contre une catégorie spécifique d'attaquants : ceux qui utilisent des outils d'analyse automatisés, n'adaptent pas les charges utiles et recherchent des cibles faciles à grande échelle. Contre les scanners de vulnérabilités, les scripts d'exploitation génériques et les robots qui testent l'injection SQL et XSS sur chaque paramètre qu'ils trouvent, un WAF bien configuré bloque la grande majorité des tentatives sans effort manuel.

Contre un attaquant dédié qui étudie l’application, mappe les points de terminaison et adapte les charges utiles spécifiquement pour cette pile, la protection est différente. Des techniques de contournement existent, certaines fonctionnent en fonction de l'état de normalisation et de la spécificité des règles, et l'origine reste accessible directement en cas de fuite de l'IP. WAF fait gagner du temps, réduit la surface d'attaque automatisée et ajoute une couche de visibilité sur ce qui est tenté, mais il ne remplace pas l'authentification forte, la validation des entrées d'application, l'application de correctifs de dépendances et le contrôle d'accès granulaire au niveau de l'entreprise.