Web Cache Poisoning

Fonctionnement technique

Le Web Cache Poisoning est une attaque qui manipule les entrées non-clés (unkeyed inputs) d'une requête HTTP pour injecter du contenu malveillant dans la réponse mise en cache par un CDN ou un reverse proxy. Une fois la réponse empoisonnée en cache, tous les utilisateurs subséquents reçoivent le contenu malveillant jusqu'à l'expiration du cache, transformant une vulnérabilité côté serveur en attaque à grande échelle.

Les entrées non-clés sont des éléments de la requête (headers HTTP, cookies, paramètres) qui influencent la réponse mais ne sont pas inclus dans la clé de cache. Par exemple, l'en-tête X-Forwarded-Host peut modifier les URL des ressources dans la page sans changer la clé de cache (basée uniquement sur l'URL et les paramètres standards). L'attaquant injecte un header malveillant, la réponse modifiée est mise en cache, et tous les visiteurs suivants reçoivent la version empoisonnée.

Les variantes incluent le cache poisoning via les paramètres non-clés (unkeyed query parameters), le web cache deception (forcer la mise en cache de réponses personnalisées contenant des données sensibles), et le response splitting via des headers injectés. Les CDN comme Cloudflare, Akamai et Fastly ont chacun des comportements de cache spécifiques exploitables.

Cas d'usage

James Kettle (PortSwigger) a démontré des attaques de cache poisoning contre des sites majeurs en exploitant les headers X-Forwarded-Host, X-Original-URL et X-Forwarded-Scheme. Un attaquant peut injecter du JavaScript malveillant dans les réponses cachées, provoquant un XSS stocké affectant tous les visiteurs du site sans compromettre le serveur.

Le Web Cache Deception, variante inverse, force la mise en cache de pages personnalisées (profil utilisateur, panier) en ajoutant une extension statique à l'URL (/account/settings/style.css). Le CDN cache la réponse personnalisée, et l'attaquant accède ensuite aux données de la victime en requêtant la même URL.

Outils et implémentation

Param Miner (extension Burp Suite) est l'outil de référence pour identifier les headers et paramètres non-clés influençant la réponse. Web Cache Vulnerability Scanner automatise la détection des configurations de cache vulnérables. Burp Suite Pro avec son scanner intégré détecte certaines variantes de cache poisoning.

Nuclei propose des templates spécifiques pour le cache poisoning. cURL est indispensable pour tester manuellement les comportements de cache avec des headers personnalisés. Les PortSwigger Web Security Academy labs fournissent des environnements d'entraînement pratiques couvrant toutes les variantes de l'attaque.

Défense / Bonnes pratiques

La défense principale consiste à minimiser l'influence des entrées non-clés sur les réponses. Ignorez les headers X-Forwarded-* provenant de sources non fiables et ne les utilisez que depuis vos propres reverse proxies. Configurez votre serveur web pour ne pas refléter les headers arbitraires dans les réponses.

Configurez votre CDN/cache pour inclure les headers influents dans la clé de cache, ou mieux, pour rejeter les requêtes contenant des headers non attendus. Utilisez le header Vary correctement pour que le cache différencie les réponses selon les entrées pertinentes. Implémentez des cache busters aléatoires pour les ressources sensibles.

Surveillez les anomalies dans les taux de hit/miss du cache et les réponses servies. Un pic soudain de cache hits sur une URL rarement accédée peut indiquer un empoisonnement. Configurez des TTL courts pour les pages dynamiques et validez le contenu des réponses cachées via des health checks automatisés qui détectent les injections de code.

Articles associés

Voir nos articles détaillés sur ce sujet.