Comment éviter les attaques par empoisonnement du cache Web

L’empoisonnement du cache Web est une cyberattaque qui fait des ravages sur les sites Web sans méfiance. Elle exploite les failles des mécanismes de mise en cache utilisés par les serveurs Web, les proxys et les réseaux de diffusion de contenu (CDN), compromettant ainsi l’intégrité des données. Les acteurs malveillants peuvent recourir à l’empoisonnement du cache pour diffuser des charges utiles malveillantes, falsifier des informations sensibles ou rediriger les utilisateurs vers des sites frauduleux.

Dans cet article, nous examinons en détail les attaques par empoisonnement du cache Web et leur fonctionnement. Nous présentons également les stratégies d’atténuation les plus efficaces pour protéger nos applications Web.

Comprendre la mise en cache Web et son importance

La mise en cache Web est un processus essentiel pour améliorer les performances d’un site Web. Elle consiste à stocker du contenu Web, comme des fichiers HTML, des images, des scripts et des feuilles de style, dans des emplacements temporaires appelés caches. Ceux-ci permettent d’accéder plus rapidement et plus facilement à ce contenu lors des requêtes ultérieures des utilisateurs.

Il existe plusieurs types de mécanismes de mise en cache, selon l’endroit où les caches Web sont stockés. En voici quelques-uns :

• Mise en cache par le navigateur : Les navigateurs Web enregistrent des copies des ressources statiques sur l’appareil de l’utilisateur. Lorsque celui-ci revient sur un site Web, le navigateur vérifie si les fichiers précédemment téléchargés se trouvent dans son cache. S’ils sont toujours valides, il les récupère au lieu d’envoyer une nouvelle requête au serveur.

• Mise en cache côté serveur : Contrairement à la mise en cache par le navigateur, qui s’effectue côté client, la mise en cache côté serveur stocke le contenu sur le serveur lui-même afin de pouvoir le réutiliser ultérieurement. Lorsqu’un utilisateur envoie une requête au serveur d’origine, le cache enregistre une copie de la réponse générée. Pour les requêtes ultérieures portant sur le même contenu, le cache renvoie cette copie au lieu de solliciter le serveur d’origine.

• Mise en cache par un réseau de diffusion de contenu (CDN) : Les CDN sont des réseaux de serveurs répartis géographiquement qui mettent en cache et diffusent du contenu Web statique. Lorsqu’un utilisateur souhaite accéder à nouveau à ce contenu, le serveur périphérique le plus proche de sa position traite la requête. Le serveur d’origine n’a ainsi pas à traiter toutes les requêtes.

La mise en cache réduit le temps et les ressources nécessaires pour récupérer du contenu Web, ce qui accélère le chargement des pages et améliore l’expérience utilisateur. Elle réduit également la charge du serveur, qui peut ainsi traiter davantage de requêtes.

Toutefois, la mise en cache comporte aussi plusieurs risques potentiels, surtout lorsqu’elle n’est pas correctement mise en œuvre ou gérée. Si le contenu mis en cache n’est pas actualisé rapidement, il peut devenir obsolète ou erroné, ce qui entraîne des incohérences ou des failles de sécurité exploitables par des attaquants.

La mise en cache d’informations sensibles peut également poser des risques pour la confidentialité. Par exemple, si le cache contient des données personnelles ou des identifiants de compte, un accès non autorisé peut entraîner une fuite de données et une atteinte à la vie privée.

Fonctionnement des attaques par empoisonnement du cache Web

L’empoisonnement du cache Web vise à tromper l’infrastructure de mise en cache pour qu’elle diffuse du contenu compromis ou non autorisé aux utilisateurs. Le processus se déroule généralement en quatre étapes :

1. Repérer une cible vulnérable : L’attaquant recherche un site Web présentant des failles potentielles dans ses mécanismes de mise en cache, comme une mauvaise configuration ou une validation incorrecte des entrées.

2. Manipuler les requêtes HTTP : L’attaquant envoie au site Web cible des requêtes HTTP conçues pour exploiter ces failles.

3. Exploiter les mécanismes de mise en cache : L’attaquant recourt à différentes techniques pour injecter son propre contenu malveillant ou manipuler le contenu déjà présent dans le cache.

4. Diffuser du contenu compromis : Une fois l’attaque terminée, les requêtes suivantes adressées au cache récupèrent le contenu empoisonné plutôt que le contenu légitime.

Les attaques par empoisonnement du cache Web réussies peuvent exposer des informations sensibles ou confidentielles. Les attaquants peuvent ensuite modifier le contenu mis en cache pour défigurer le site Web ciblé, propager de fausses informations ou diffuser des liens malveillants.

Pire encore, les attaquants combinent souvent l’empoisonnement du cache Web à d’autres cyberattaques pour amplifier les dégâts. Par exemple, en 2018, des attaquants ont réussi à empoisonner le cache du site Web de British Airways. Ils y ont injecté une charge utile malveillante qui redirigeait les utilisateurs vers un site frauduleux. Ils ont ainsi pu dérober les adresses e-mail et les informations de carte bancaire de plus de 40 000 utilisateurs britanniques.

Vecteurs courants d’attaque par empoisonnement du cache Web

Pour nous protéger des attaques par empoisonnement du cache, nous devons repérer et corriger les éventuelles vulnérabilités des sites Web. Voici quelques-uns des vecteurs d’attaque les plus courants et la façon dont les acteurs malveillants peuvent les exploiter :

• Manipulation des en-têtes HTTP : Les attaquants modifient souvent les en-têtes HTTP pour associer leur contenu malveillant à des URL ou à des clés de cache légitimes. Ils peuvent, par exemple, manipuler l’en-tête HTTP Cache-Control pour demander au système de mise en cache d’enregistrer leur contenu. Ils peuvent alors diffuser leur charge utile malveillante aux utilisateurs suivants qui demandent la même ressource, même si le contenu légitime a changé.

• Manipulation de la chaîne de requête : Les attaquants peuvent exploiter la façon dont les applications Web gèrent les chaînes de requête. Ils modifient les paramètres de requête ajoutés à l’URL afin de créer plusieurs variantes en cache pour une même ressource, auxquelles ils peuvent éventuellement ajouter une charge utile malveillante.

• Manipulation des cookies : Les attaquants peuvent également empoisonner le cache en modifiant les valeurs et les attributs des cookies. Ils trompent ainsi le système de mise en cache pour qu’il enregistre leur contenu dans le cache dans le contexte de la session d’un utilisateur légitime.

Gardez toutefois à l’esprit qu’il ne s’agit que de quelques exemples. Les attaquants recherchent sans cesse de nouvelles techniques et vulnérabilités pour parvenir à leurs fins. Se contenter de surveiller ces vecteurs courants ne suffit pas à protéger les données Web.

Attaque par empoisonnement du cache via la manipulation des en-têtes HTTP

Examinons un cas d’empoisonnement du cache Web où un attaquant exploite une vulnérabilité d’un site Web au moyen d’en-têtes HTTP. L’en-tête X-Forwarded-Host (XFH) est une cible fréquente. Cet en-tête, devenu de facto un standard, sert à identifier l’hôte d’origine demandé par le client dans la requête HTTP/HTTPS adressée à votre application ou à votre API. Sa valeur est généralement un nom d’hôte représentant la cible initiale de la requête du client.

Bien que cet en-tête soit utile dans les environnements qui utilisent un proxy inverse ou un répartiteur de charge, un attaquant peut l’exploiter s’il n’est pas correctement validé. Notez toutefois qu’un attaquant peut potentiellement utiliser de nombreux autres en-têtes pour mener une attaque similaire.

Passons à présent à notre exemple, qui met en évidence une vulnérabilité potentielle dans du code JavaScript utilisant un service de mise en cache. Pour cette démonstration, nous utiliserons Redis.

1const express = require('express');
2const app = express();
3const redis = require('redis');
4const client = redis.createClient();
5
6// Middleware to handle caching
7app.use((req, res, next) => {
8    const key = req.originalUrl; // use request url as a key
9
10    client.get(key, (err, data) => {
11        if (err) throw err;
12
13        if (data !== null) {
14            res.send(data);
15        } else {
16            next();
17        }
18    });
19});
20
21app.get('/user', (req, res, next) => {
22    const host = req.headers['x-forwarded-host'] || 'unknown host';
23    const response = `Welcome, user ${req.query.userId}! You're accessing from ${host}`;
24
25    // Cache the response using the URL as a key
26    client.set(req.originalUrl, response, 'EX', 3600); // Cache for 1 hour
27
28    res.send(response);
29    next();
30});
31
32app.listen(3000, () => {
33  console.log('Server running on port 3000');
34});

Le middleware de mise en cache utilise l’URL d’origine comme clé pour mettre les réponses en cache dans Redis. originalURL désigne tout ce qui suit le nom d’hôte (par exemple, /user?userId=1 dans http://example.com/user?userId=1). Si la réponse associée à cette URL se trouve dans le cache, elle est envoyée immédiatement. Sinon, la requête est transmise au gestionnaire de route approprié qui, dans notre cas, génère un message d’accueil personnalisé et le met en cache.

Cette implémentation peut toutefois entraîner des attaques par empoisonnement du cache. Un attaquant pourrait tirer parti du fait que les réponses sont mises en cache en fonction des URL. Imaginons que l’en-tête X-Forwarded-Host, une entrée contrôlée par l’utilisateur, soit utilisé pour générer la réponse. Le code génère un message d’accueil à partir de la valeur de X-Forwarded-Host (par exemple, « Bienvenue, utilisateur ${req.query.userId}, vous vous connectez depuis ${req.headers['x-forwarded-host']} ! »). Si cette valeur n’est pas correctement validée, un attaquant peut inclure des scripts malveillants dans cet en-tête, qui seront ensuite mis en cache et diffusés à d’autres utilisateurs.

Voici comment cela pourrait se dérouler :

• L’attaquant envoie une requête GET à /user?userId=1 avec l’en-tête X-Forwarded-Host défini sur foo."><script>alert(document.cookie)</script>.

• Le serveur génère un message d’accueil qui inclut la valeur de l’en-tête, le met en cache sous la clé /user?userId=1, puis le renvoie à l’attaquant.

• Dès lors, chaque requête ultérieure à /user?userId=1 renvoie depuis le cache un message d’accueil malveillant.

Pour renforcer la sécurité du code ci-dessus, vous pouvez notamment assainir l’URL utilisée comme clé de cache. Voici comment implémenter une fonction d’assainissement de base qui utilise la méthode escape du module validator :

1const validator = require('validator');
2
3function sanitize(url) {
4    let parsedUrl;
5
6    try {
7        parsedUrl = new URL(url);
8    } catch (err) {
9        throw new Error('Invalid URL');
10    }
11
12    parsedUrl.searchParams.forEach((val, param) => {
13        // Escaping potentially harmful characters in the query parameters
14        parsedUrl.searchParams.set(param, validator.escape(val));
15    });
16
17    return parsedUrl.toString();
18}

La fonction sanitize que nous avons implémentée permet de supprimer efficacement de req.originalUrl tous les caractères susceptibles de présenter un risque :

1const key = sanitize(req.originalUrl);

Il est également possible de vérifier la validité des entrées utilisateur en exécutant une fonction middleware sur notre serveur Express. L’exemple ci-dessous présente une méthode de base pour valider les en-têtes :

1const validator = require('validator');
2
3app.use((req, res, next) => {
4    const forwardedHostHeader = req.headers['x-forwarded-host'];
5    if (forwardedHostHeader) {
6        const isFQDN = validator.isFQDN(forwardedHostHeader);
7        if (!isFQDN) {
8            // If the header does not represent a fully qualified domain name, the request is rejected
9            return res.status(400).send('Invalid X-Forwarded-Host header');
10        }
11    }
12
13    next();
14});

Ici, nous utilisons la fonction isFQDN du module validator pour vérifier que l’en-tête X-Forwarded-Host contient un nom de domaine valide. Si ce n’est pas le cas, la fonction middleware rejette la requête et renvoie le statut 400 Bad Request.

Cette étape de validation est essentielle pour empêcher l’injection de scripts malveillants via l’en-tête X-Forwarded-Host header. Comme nous l’avons vu, cela pourrait entraîner une attaque par empoisonnement du cache.

Bonnes pratiques pour atténuer les attaques par empoisonnement du cache Web

La méthode la plus efficace pour empêcher l’empoisonnement du cache Web consiste à définir une politique de mise en cache rigoureuse. Celle-ci précise clairement le contenu à mettre en cache, la durée de conservation et les conditions à respecter. Pour définir cette politique, nous devons tenir compte de facteurs tels que le type de données, les exigences d’authentification et le contenu dynamique qui ne doit pas être mis en cache.

D’autres techniques peuvent contribuer à sécuriser les mécanismes de mise en cache :

• Normalisation des clés de cache : La normalisation des clés de cache peut éviter les variantes dues au format des entrées ou à la distinction entre majuscules et minuscules.

• Valider les entrées utilisateur : Des techniques rigoureuses de validation et d’assainissement des entrées peuvent prévenir les attaques par injection susceptibles d’entraîner un empoisonnement du cache. Elles comprennent le filtrage des entrées, la liste d’autorisation des paramètres et les vérifications par expressions régulières.

• En-têtes de contrôle du cache : Les en-têtes de contrôle du cache permettent d’imposer le comportement de mise en cache et d’atténuer les risques. Par exemple, l’utilisation d’en-têtes tels que « no-store » et « no-cache » peut empêcher la mise en cache de données sensibles.

• Ne faites pas confiance aux entrées de tiers : Faites preuve de prudence lorsque vous vous appuyez sur des entrées provenant de tiers, comme des en-têtes, des cookies ou des chaînes de requête. Validez et assainissez soigneusement toutes les entrées externes avant de les utiliser pour des opérations liées au cache. Considérez toutes les données fournies par les utilisateurs comme potentiellement malveillantes et appliquez une validation et un filtrage rigoureux afin d’empêcher les attaquants d’injecter du contenu spécialement conçu dans le cache.

• Utiliser des pare-feu applicatifs Web (WAF) : Le déploiement d’un WAF robuste peut aider à détecter et à bloquer les tentatives d’empoisonnement du cache. Les WAF analysent les requêtes entrantes et repèrent les schémas suspects qui signalent un empoisonnement du cache. Vous pouvez configurer le WAF pour qu’il signale ou bloque ces requêtes et ajoute ainsi une couche de protection contre ces attaques.

Surveillance et détection des attaques par empoisonnement du cache Web

Même avec des stratégies d’atténuation adaptées, un empoisonnement du cache Web peut toujours se produire. Il est donc essentiel de surveiller régulièrement le trafic Web et d’analyser les journaux pour détecter les attaques potentielles. Repérez les activités inhabituelles ou suspectes, comme des anomalies dans les schémas de requête, des variantes de cache inattendues ou du contenu inhabituel diffusé par le cache.

Une autre bonne pratique consiste à effectuer régulièrement des tests de sécurité et des tests d’intrusion. Ces évaluations permettent d’identifier les faiblesses susceptibles de conduire à des attaques par empoisonnement du cache. Les tests de sécurité comprennent des analyses de vulnérabilités et des audits de sécurité. Les tests d’intrusion vont plus loin en simulant des scénarios d’attaque réels. Ils reproduisent les techniques et l’état d’esprit d’un attaquant pour détecter des faiblesses spécifiques que les tests de sécurité classiques pourraient ne pas repérer.

De nombreux outils et ressources peuvent contribuer à détecter et à prévenir les attaques par empoisonnement du cache Web. Par exemple, nous pouvons mettre en œuvre :

• Des scanners de vulnérabilités, comme Snyk, qui permettent de détecter automatiquement les vulnérabilités courantes liées à l’empoisonnement du cache.

• Des outils de diagnostic et d’analyse du cache, qui aident à examiner les configurations de mise en cache, à surveiller le comportement du cache et à détecter les anomalies.

En résumé

Les attaques par empoisonnement du cache Web contraignent les caches à diffuser, à l’insu des utilisateurs, du contenu obsolète ou manipulé. Elles peuvent entraîner des fuites de données et des atteintes à la vie privée, et nuire ainsi à la réputation d’un site Web.

La meilleure défense contre ces attaques consiste à mettre en place une politique de mise en cache rigoureuse et à se tenir informé des dernières tendances en matière de sécurité des applications Web. Nous devons également suivre les bonnes pratiques de sécurité, comme valider correctement les entrées et normaliser les clés de cache.

En appliquant ces pratiques de développement sécurisé, nous pouvons tirer parti des avantages de la mise en cache Web tout en réduisant le risque d’empoisonnement du cache.