Qu’est-ce que l’empoisonnement du cache Web ?

L'empoisonnement du cache Web est une attaque en ligne dans laquelle un attaquant exploite les vulnérabilités d'un serveur Web et de son serveur de mise en cache associé pour mettre en cache et transmettre une réponse HTTP malveillante aux autres utilisateurs du serveur Web. C’est certainement une bouchée, mais nous allons le déballer. Dans cet article, nous expliquerons ce qu'est l'empoisonnement du cache Web, comment il fonctionne et ce que vous pouvez faire pour y remédier.

Qu'est-ce qu'un cache Web ?

Pour comprendre les attaques par empoisonnement du Web, nous devons d’abord comprendre ce qu’est réellement un cache Web.

Chaque fois que vous faites une demande à un serveur Web, via votre navigateur, le serveur Web répond normalement avec une nouvelle réponse pour chaque demande. Et le serveur Web rechercherait et servirait la ressource demandée à l'utilisateur. Sans serveur de mise en cache intermédiaire entre l'appareil de l'utilisateur et le serveur, le serveur récupérerait la ressource demandée et la servirait à l'utilisateur dans une nouvelle réponse à chaque fois que cette ressource serait demandée. Sur un site Internet très fréquenté, cela deviendrait vite ingérable et surchargerait le serveur.

Mais avec un serveur de mise en cache placé entre l'utilisateur et le serveur, certaines réponses peuvent être mises en cache par le serveur de mise en cache et servies à l'utilisateur à partir de là (le serveur de mise en cache) plutôt que de laisser le serveur Web récupérer cette ressource encore et encore. Cela réduit considérablement la charge sur le serveur Web. En fait, les réponses fournies par le serveur de mise en cache ne nécessitent même pas d’interaction avec le serveur Web réel.

Clés de cache

Le serveur de mise en cache mettra en cache les réponses en fonction d'un certain nombre de facteurs, tels que l'extension de fichier de la ressource demandée, le type de contenu, l'itinéraire, le code d'état et l'en-tête de réponse. Ceci est déterminé par l'administrateur du site.

Lorsque le serveur de cache reçoit une requête HTTP, il doit déterminer si une réponse en cache est disponible ou s'il doit transmettre la requête au serveur backend. Le serveur de mise en cache comparera un sous-ensemble prédéfini de paramètres des en-têtes de requête pour identifier les requêtes équivalentes. Ce sous-ensemble de paramètres est appelé clé de cache. Et les parties de la requête qui ne sont pas incluses dans la clé de cache sont considérées comme des paramètres « sans clé ». Ces paramètres sans clé sont complètement ignorés par le serveur de mise en cache. Ce dernier point est crucial pour réussir une attaque par empoisonnement du cache, comme nous le verrons plus loin.

Si la clé de cache de deux requêtes entrantes correspond, le serveur de mise en cache considère ces requêtes comme étant équivalentes et fournira la même réponse aux deux requêtes du cache. Et cela continuera à se produire pour toutes les requêtes correspondantes jusqu’à l’expiration du cache de cette requête.

Que peut-il se passer si vous êtes victime d’une attaque d’empoisonnement du cache Web ?

L’impact d’une attaque par empoisonnement du cache Web est difficile à cerner. En effet, l’impact de l’attaque dépend essentiellement de deux facteurs :

Ce que l'attaquant a réussi à mettre en cache

En fonction de la configuration du serveur Web, un attaquant peut réussir à mettre en cache un fichier infecté, un script malveillant, un lien malveillant ou tout autre exploit. N’importe lequel de ces vecteurs d’attaque pourrait être utilisé pour compromettre vos informations personnelles, télécharger des logiciels malveillants sur votre ordinateur ou réaliser toute une série d’autres attaques.

Gardez également à l’esprit qu’une attaque par empoisonnement du Web peut être utilisée parallèlement à d’autres attaques et causer encore plus de dégâts que si elle était utilisée isolément.

Le volume de trafic sur la ou les pages concernées

Si personne ne visite la ou les pages compromises, rien ne se passera. La réponse empoisonnée sera servie aux utilisateurs effectuant des requêtes vers la ou les pages compromises pendant que le cache est empoisonné. En fonction de la popularité des pages en question, les conséquences peuvent aller de sans impact à désastreuses.

Et même si les caches expirent, un attaquant chevronné peut programmer son attaque pour empoisonner à nouveau le cache indéfiniment. Vous devez toujours vous assurer que votre cache Web expire après une durée déterminée, mais cela n’est pas garanti pour contrecarrer une attaque d’empoisonnement du cache Web. Nous verrons plus loin comment se protéger contre les attaques d’empoisonnement du cache Web.

Comment fonctionnent les attaques par empoisonnement du cache Web ?

Une attaque typique par empoisonnement du cache Web comprend trois étapes de base :

1. Trouver les entrées sans clé
2. Générer une réponse malveillante depuis le serveur Web
3. Mettre la réponse malveillante en cache

Trouver des entrées sans clé

Les attaques d'empoisonnement du cache Web sont basées sur la manipulation d'entrées sans clé, telles que les en-têtes. Les caches Web ignoreront les entrées sans clé lors de l'évaluation de la diffusion ou non d'une réponse mise en cache. Cela signifie que vous pouvez utiliser des entrées sans clé pour injecter votre charge utile malveillante et générer une réponse « empoisonnée ». Cette réponse empoisonnée, si elle est mise en cache, sera servie à toutes les requêtes correspondant à la clé de cache. Ainsi, la première étape de toute attaque par empoisonnement du cache Web consiste à identifier les entrées sans clé prises en charge par le serveur.

Un attaquant peut identifier manuellement les entrées sans clé en ajoutant des entrées aléatoires aux requêtes, puis en attendant de voir si elles affectent la réponse du serveur. Mais cela sera fastidieux et prendra beaucoup de temps. Il existe des outils logiciels qui peuvent automatiser ce processus, et ce sont ces outils qui rendent cette attaque pratique.

Générer une réponse malveillante depuis le serveur Web

À partir de là, avec certaines entrées connues sans clé, l'attaquant doit comprendre comment le serveur Web les traite afin que le serveur Web génère une réponse malveillante. Ainsi, l'attaquant recherchera des vulnérabilités à exploiter, telles que le serveur Web reflétant les entrées de l'utilisateur dans la réponse du serveur sans qu'il soit correctement nettoyé ou générant dynamiquement du contenu basé sur les entrées de l'utilisateur. Ce sont ces types de mauvaises configurations qui permettent des attaques par empoisonnement du cache Web, parmi bien d’autres.

Mettre la réponse malveillante en cache

À partir de là, l’attaquant doit mettre en cache sa charge utile malveillante. À ce stade, ils savent comment générer une réponse malveillante de la part du serveur, mais ils doivent tromper le serveur de mise en cache pour qu'il accepte leur charge utile dans le cache.

L’attaquant tentera donc de comprendre la logique de la mise en cache par essais et erreurs, en notant le comportement du cache à chaque étape. Avec un peu de chance, ils pourront mettre en cache leur charge utile sur le serveur de cache. Nous fournirons un exemple détaillé ci-dessous. Et à partir de là, toute personne demandant la même ressource recevra la réponse du cache empoisonné.

Exemples détaillés d'attaques par empoisonnement du cache Web

Livraison d'une charge utile de script XSS à l'aide de l'empoisonnement du cache Web

Le moyen le plus simple de mener une attaque par empoisonnement du cache Web consiste à exploiter une entrée sans clé qui se reflète dans une réponse pouvant être mise en cache sans être correctement nettoyée.

Voyons à quoi pourrait ressembler une requête typique et la réponse correspondante :

|_+_| |_+_|

Dans l'exemple ci-dessus, la valeur d'en-tête X-Forwarded-Host est utilisée pour générer dynamiquement une URL d'image Open Graph, qui est reflétée dans la réponse. Dans de nombreux cas, les en-têtes X-Forwarded-Host sont considérés comme des valeurs sans clé. Dans notre exemple, le cache pourrait être empoisonné en générant une réponse contenant une simple charge utile XSS :

|_+_| |_+_|

Si cette réponse devait être mise en cache, tout utilisateur accédant à |_+_| recevrait cette charge utile XSS au lieu de la ressource légitime. Et puis des choses amusantes commencent à vous arriver…

Exploitation d'une gestion inappropriée des importations de ressources pour monter une attaque d'empoisonnement du cache Web

Certains sites Web utilisent des en-têtes sans clé pour générer dynamiquement des URL permettant d'importer des ressources, telles que des fichiers JavaScript, à partir d'un serveur externe. Dans ce scénario, si le serveur n'est pas correctement configuré, un attaquant peut modifier la valeur de l'en-tête approprié en un domaine sous son contrôle. Et ils pourraient manipuler l’URL pour pointer vers leur propre fichier JavaScript malveillant.

Supposons que l'attaquant parvienne à mettre en cache la réponse contenant cette URL malveillante. Dans ce cas, le JavaScript de l’attaquant sera importé et exécuté dans le navigateur de tout utilisateur effectuant une requête avec une clé de cache correspondante.

|_+_| |_+_|

L'exemple Paypal

En 2017, un chercheur israélien en sécurité nommé Omer Gil a découvert que Paypal était vulnérable aux attaques d'empoisonnement du cache Web . Il a découvert qu’en tentant d’accéder à des ressources inexistantes du site Paypal – un fichier CSS ou JavaScript, par exemple – le serveur de cache fournirait des réponses incluant les informations personnelles des autres utilisateurs. Les informations utilisateur compromises allaient des adresses e-mail aux soldes de comptes, en passant par les quatre derniers chiffres de leur carte de crédit, etc.

Comment prévenir les attaques par empoisonnement du cache Web

Il existe un moyen infaillible de prévenir les attaques d’empoisonnement du cache Web : désactiver complètement la mise en cache. Cela ne sera probablement pas réalisable pour les grands sites Web, mais certains sites plus petits pourraient mettre en œuvre cette solution. Par exemple, si la mise en cache est activée uniquement parce que c'est la valeur par défaut pour le CDN que vous utilisez, vous voudrez peut-être vous demander si vous avez vraiment besoin d'activer la mise en cache ou non. Si ce n'est pas le cas, désactivez-le.

Si votre site Web/application nécessite effectivement une mise en cache, voici quelques directives à suivre :

Mettre en cache uniquement les fichiers statiques

Vous souhaitez activer la mise en cache uniquement pour les fichiers purement statiques qui ne changent jamais et qui ne dépendent d'aucune entrée utilisateur pour générer une réponse mise en cache. De cette façon, un attaquant ne pourra pas tromper votre serveur de mise en cache en lui faisant récupérer une version malveillante d’un fichier plutôt que le fichier légitime prévu.

Méfiez-vous des logiciels tiers

De nombreux sites/applications Web, sinon la plupart, sont aujourd'hui construits à l'aide de certains logiciel tiers . Votre équipe de développement interne peut se conformer à des normes élevées en ce qui concerne les pratiques de sécurité lors du codage. Mais dès que vous introduisez un logiciel tiers dans le mix, vous comptez implicitement sur la robustesse des pratiques de sécurité de cette équipe de développement tierce. S’ils sont plus faibles que le vôtre, ce code tiers devient votre maillon le plus faible et votre site/application Web est aussi vulnérable que ce code.

Ne vous fiez pas aux données trouvées dans les en-têtes HTTP

De nombreuses vulnérabilités côté client peuvent être exploitées via les en-têtes HTTP, ce qui peut conduire à reflété les attaques de cross-site scripting , entre autres attaques.

Une attaque XSS réfléchie est possible lorsqu'un site Web/une application accepte la saisie de l'utilisateur et renvoie les résultats à l'utilisateur (comme un champ de recherche) mais sans valider la saisie. Il reflète simplement tout ce qui a été saisi par l'utilisateur. Dans notre exemple ci-dessus, la préférence linguistique de l’utilisateur a été utilisée.

Ne vous fiez donc pas aux valeurs des en-têtes HTTP qui ne font pas partie de votre clé de cache. Et ne renvoyez jamais les en-têtes HTTP du cache Web.

Ne faites pas confiance aux requêtes GET

Vous devez considérer les corps de requête GET comme non fiables et vous devez vous assurer que les corps de requête GET ne peuvent pas modifier le contenu d'une réponse. Si le corps d'une requête GET est capable de modifier le contenu d'une réponse, envisagez plutôt d'utiliser une requête POST ou de contourner complètement le cache.

Effectuer régulièrement des tests de vulnérabilité

Exécutez une analyse de vulnérabilité sur votre site Web/application à intervalles réguliers pour vous assurer qu'il n'est pas vulnérable aux attaques de scripts intersites en particulier. Une analyse régulière des vulnérabilités vous protégera également contre d’autres menaces en ligne.

Conclure

Bien que seule la désactivation complète de la mise en cache puisse garantir que vous ne serez pas victime d’une attaque d’empoisonnement du cache Web, les mesures proposées ci-dessus fausseront considérablement les chances de ne pas être victime de cette attaque en votre faveur. Tout site/service qui vit en ligne vit dans un environnement hostile. Et sans défenses adéquates, il ne vivra pas très longtemps. Donc chaque petit geste compte.

Comme toujours, restez en sécurité.

Voir également:

• Statistiques sur les logiciels malveillants en 2022
• Prévenir les attaques de l'homme dans le navigateur
• Que sont les attaques CORS ?
• Comment prévenir les attaques d'exécution de code à distance