Contexte

Le poisonnage de cache est une technique avancée utilisée par les attaquants pour exploiter le comportement d'un serveur web et de son cache, ce qui entraîne l'envoi de réponses HTTP nocives à des utilisateurs sans méfiance. Cette technique implique deux phases. Tout d'abord, l'attaquant doit trouver un moyen d'obtenir une réponse du serveur principal contenant un contenu dangereux. Une fois réussi, il doit s'assurer que sa réponse est mise en cache et servie à ses cibles prévues. Cette méthode d'attaque peut être utilisée pour distribuer divers types d'attaques, notamment des injections XSS, JavaScript, des redirections ouvertes, etc. Un cache web empoisonné a le potentiel de causer des dommages importants.

Comment

Pour comprendre l'origine des vulnérabilités de poisonnage de cache web, il est crucial d'avoir une compréhension fondamentale du fonctionnement des caches web. Le cache est utilisé pour réduire la charge sur les serveurs, qui devraient sinon envoyer une nouvelle réponse pour chaque demande HTTP séparée, entraînant des problèmes de latence et une mauvaise expérience utilisateur, surtout pendant les périodes de pointe.

Le cache, qui stocke (met en cache) des réponses à des demandes particulières pour une période prédéterminée, se situe entre le serveur et l'utilisateur. Si un autre utilisateur envoie une demande équivalente par la suite, le cache sert une copie de la réponse mise en cache directement à l'utilisateur, sans aucune interaction avec le back-end. Cela réduit le nombre de demandes en double que le serveur doit gérer, allégeant considérablement sa charge.

Lorsque le cache reçoit une demande HTTP, il doit déterminer s'il existe une réponse mise en cache qu'il peut servir directement ou s'il doit transférer la demande au serveur principal pour traitement. Les caches comparent un sous-ensemble prédéfini des composants de la demande, connu collectivement sous le nom de « clé de cache », pour identifier des demandes équivalentes. Cela comprend généralement la ligne de demande et l'en-tête Host. Les composants de demande non inclus dans la clé de cache sont considérés comme "aveugles au cache".

Si la clé de cache d'une demande entrante correspond à celle d'une demande précédente, le cache les considère comme équivalentes et sert une copie de la réponse mise en cache générée pour la demande originale. Cela s'applique à toutes les demandes ultérieures avec la clé de cache correspondante jusqu'à ce que la réponse mise en cache expire.

Il est essentiel de noter que d'autres composants de la demande sont entièrement ignorés par le cache, que nous examinerons plus en détail plus tard. L'impact de ce comportement dépend fortement de deux facteurs clés : la mise en cache précise qu'un attaquant peut réaliser et le volume de trafic vers la page affectée. Comme le cache empoisonné est plus une méthode de distribution qu'une attaque autonome, l'impact du poisonnage de cache web est lié à la nocivité de la charge utile injectée. De plus, le poisonnage de cache web peut être utilisé en combinaison avec d'autres attaques pour augmenter l'impact potentiel.

L'impact de la réponse empoisonnée servie aux utilisateurs qui visitent la page affectée pendant que le cache est empoisonné est déterminé par le nombre d'utilisateurs visitant la page. Ainsi, l'impact peut aller de nul à énorme, selon la popularité de la page. Par exemple, si un attaquant parvient à empoisonner une réponse mise en cache sur la page d'accueil d'un site Web majeur, l'attaque pourrait affecter des milliers d'utilisateurs sans aucune autre interaction de l'attaquant. Notez que la durée d'une entrée de cache n'affecte pas nécessairement l'impact de l'attaque de poisonnage de cache web, car une attaque peut être scriptée pour empoisonner le cache indéfiniment.

Construction d'une attaque

En général, la création d'une attaque de poisonnage de cache web de base implique plusieurs étapes :

Identification et évaluation des entrées aveugles au cache.

Pour mener une attaque de poisonnage de cache web, il faut manipuler des entrées aveugles au cache comme les en-têtes, que les caches web ignorent lorsqu'ils déterminent s'ils doivent servir une réponse mise en cache. Ces entrées peuvent être utilisées pour injecter une charge utile et obtenir une réponse « empoisonnée » qui, si elle est mise en cache, sera servie à tous les utilisateurs ayant la clé de cache correspondante. Pour construire une telle attaque, la première étape consiste à identifier les entrées aveugles au cache que le serveur prend en charge.

Une façon d'identifier ces entrées est d'ajouter manuellement des entrées aléatoires aux demandes et de vérifier si elles affectent la réponse. Les effets peuvent être évidents, comme la réflexion directe de l'entrée dans la réponse ou le déclenchement d'une réponse complètement différente, mais parfois, ils sont plus subtils et nécessitent une enquête. Bien que des outils comme Burp Comparer puissent aider à comparer les réponses avec et sans l'entrée injectée, l'identification des entrées aveugles au cache demande encore un effort manuel important.

Obtention d'une réponse nocive du serveur principal.

Après avoir identifié une entrée aveugle au cache, l'étape cruciale suivante consiste à évaluer comment le site web la traite. Cela est essentiel pour déclencher efficacement une réponse nocive. Si l'entrée n'est pas filtrée correctement et est réfléchie dans la réponse du serveur ou est utilisée pour générer d'autres données dynamiquement, elle peut devenir un point d'entrée pour le poisonnage de cache web.

Obtention de la réponse mise en cache.

Manipuler des entrées pour provoquer une réponse nocive ne suffit que pour moitié, car cela n'a pas d'utilité si la réponse ne peut pas être mise en cache. La mise en cache de la réponse peut parfois être difficile car elle dépend de divers facteurs tels que l'extension de fichier, le type de contenu, l'itinéraire, le code d'état et les en-têtes de réponse. Il est donc nécessaire de passer du temps à expérimenter avec des demandes sur différentes pages et à étudier le comportement du cache pour identifier comment obtenir une réponse mise en cache contenant l'entrée malveillante. Une fois cela accompli, on peut fournir l'exploit aux victimes potentielles.

Exploiter les vulnérabilités

Le processus décrit est applicable pour identifier et exploiter diverses vulnérabilités de poisonnage de cache web. De telles vulnérabilités peuvent provenir de défauts généraux dans la conception de cache ou de particularités inattendues introduites par la mise en œuvre du cache d'un site web spécifique.

Les sections suivantes couvriront les exemples les plus courants de ces scénarios, ainsi que des laboratoires interactifs qui illustrent ces vulnérabilités et comment les exploiter.

Comment prévenir

Le poisonnage de cache web peut être évité en désactivant la mise en cache, qui est la méthode la plus efficace, mais qui peut ne pas toujours être faisable pour tous les sites web. Par exemple, si vous avez adopté un réseau de diffusion de contenu (CDN) qui a la mise en cache activée par défaut, vous pouvez envisager d'évaluer si cette option convient aux besoins de votre site web.

La limitation de la mise en cache aux seules réponses statiques peut être une autre approche efficace pour éviter le poisonnage de cache web. Cependant, vous devez être prudent quant à ce que vous définissez comme statique et vous assurer que les attaquants ne peuvent pas tromper le serveur principal pour récupérer leur version malveillante d'une ressource statique plutôt que l'authentique.

Les technologies tierces sont courantes dans le développement web, et même si vous avez une posture de sécurité interne solide, vous comptez toujours sur la sécurité des développeurs de technologies tierces. Il est donc crucial de comprendre les implications de sécurité de toute technologie tierce avant de l'intégrer, car elle peut exposer des vulnérabilités que les attaquants peuvent exploiter.

Dans le cas du poisonnage de cache web, vous devriez évaluer les en-têtes pris en charge par votre CDN et désactiver ceux qui ne sont pas nécessaires, car les attaquants peuvent manipuler des en-têtes de demande obscurs pour exposer des vulnérabilités. L'exclusion de quelque chose de la clé de cache pour des raisons de performances n'est pas recommandée, et vous devriez plutôt réécrire la demande. Vous devriez également éviter d'accepter de grandes demandes GET et corriger les vulnérabilités côté client, car elles peuvent devenir exploitables en raison de particularités imprévisibles dans le comportement du cache.

Dans l'ensemble, la prévention du poisonnage de cache web nécessite une compréhension approfondie des vulnérabilités potentielles et une évaluation minutieuse des options de mise en cache et des technologies tierces utilisées sur votre site web.