* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Utilisez [**Trickest**](https://trickest.io/) pour créer et **automatiser facilement des workflows** alimentés par les outils communautaires les plus avancés au monde.\
> * 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, et l'attaquant récupère ensuite ce contenu à partir du cache.
L'objectif de l'empoisonnement de cache est de faire en sorte que les **clients chargent des ressources inattendues partiellement ou contrôlées par l'attaquant**.\
La réponse empoisonnée ne sera servie qu'aux utilisateurs qui visitent la page affectée pendant que le cache est empoisonné. Par conséquent, l'impact peut aller de nul à massif selon que la page est populaire ou non.
Pour effectuer une attaque d'empoisonnement de cache, vous devez d'abord **identifier les entrées non clés** (paramètres qui n'ont pas besoin d'apparaître sur la demande mise en cache mais qui modifient la page renvoyée), voir **comment abuser** de ce paramètre et **obtenir la réponse mise en cache**.
Généralement, lorsqu'une réponse a été **stockée dans le cache**, il y aura un **en-tête indiquant cela**, vous pouvez vérifier quels en-têtes vous devez surveiller dans ce post : [**En-têtes de cache HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Si vous pensez que la réponse est mise en cache, vous pouvez essayer d'**envoyer des demandes avec un en-tête incorrect**, qui devrait être répondu avec un **code d'état 400**. Ensuite, essayez d'accéder à la demande 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 DoS).\
Un en-tête mal configuré pourrait être simplement `\:` comme en-tête.\
Notez que parfois ces types de codes d'état ne sont pas mis en cache, donc ce test sera inutile.
Vous pouvez utiliser [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) pour **forcer les paramètres et les en-têtes** qui peuvent **modifier la réponse de la page**. Par exemple, une page peut utiliser l'en-tête `X-Forwarded-For` pour indiquer au client de charger le script à partir de là :
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 obtenir la page mise en cache. Selon la ressource que vous essayez de mettre en cache, cela peut prendre du temps, vous devrez peut-être essayer pendant plusieurs secondes.\
L'en-tête **`X-Cache`** dans la réponse peut être très utile car il peut avoir la valeur **`miss`** lorsque la requête n'a pas été 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 que la ressource sera mise en cache: `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 cet `User-Agent` spécifique.\
Un autre en-tête lié au cache est **`Age`**. Il définit les temps en secondes pendant lesquels 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 si cela fonctionne.
Les cookies peuvent également être reflétés dans la réponse d'une page. Si vous pouvez l'abuser pour causer une XSS par exemple, vous pourriez être en mesure d'exploiter la XSS dans plusieurs clients qui chargent la réponse de cache malveillante.
### Utilisation de plusieurs en-têtes pour exploiter les vulnérabilités de l'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 contrôlé par vous et `X-Forwarded-Scheme` sur `http`. **Si** le **serveur****redirige** toutes les demandes **HTTP** vers HTTPS et utilise l'en-tête `X-Forwarded-Scheme` comme nom de domaine pour la redirection. Vous pouvez contrôler où la page est dirigée par la redirection.
Si vous avez découvert 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`**, alors vous devez trouver un moyen d'exfiltrer le User-Agent de la victime et de contaminer le cache en utilisant cet User-Agent :
Le scanner de vulnérabilité de cache Web peut être utilisé pour tester automatiquement l'empoisonnement du cache Web. Il prend en charge de nombreuses techniques différentes et est hautement personnalisable.
Utilisez [**Trickest**](https://trickest.io/) pour créer et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde.\
ATS a transmis le fragment dans 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 la charge utile à l'intérieur, seulement l'hôte, le chemin et la requête.
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 utilise des compartiments GCP pour stocker le 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 contaminer le cache pour renvoyer un corps de réponse vide. Il pourrait également prendre en charge la méthode `PURGE`.
L'application Ruby on Rails est souvent déployée aux côtés du middleware Rack. Le code Rack ci-dessous prend la valeur de la valeur **`x-forwarded-scheme` et l'utilise comme schéma de la requête**.
L'envoi de l'en-tête `x-forwarded-scheme: http` entraînerait une redirection 301 vers le même emplacement, ce qui provoquerait un DoS sur cette ressource comme dans cet exemple :
L'application pourrait également prendre en charge l'en-tête `X-forwarded-host` et rediriger l'utilisateur vers cet hôte, ce qui permettrait de charger des fichiers JavaScript à partir du serveur de l'attaquant :
Auparavant, Cloudflare avait l'habitude de mettre en cache les réponses 403, donc l'envoi de mauvais en-têtes d'autorisation en essayant d'accéder à S3 ou Azure Storage Blobs exposés renverrait un 403 qui serait mis en cache. Cloudflare ne met plus en cache les réponses 403, mais cela pourrait fonctionner avec d'autres proxys.
Par exemple, Fastly utilisant Varnish **a mis en cache le paramètre `size`** dans la requête, mais si vous envoyez également le paramètre **`siz%65`** avec une mauvaise valeur, la **clé de cache** est construite avec le **paramètre de taille bien écrit**, mais le **backend** utilise la **valeur à l'intérieur du paramètre encodé dans l'URL**.
L'encodage d'URL du deuxième paramètre `size` a entraîné son ignorance par le cache, mais utilisé par le backend. Donner au paramètre une valeur de 0 entraînerait une demande incorrecte 400 mise en cache.
En raison du grand nombre de demandes générées par des outils tels que FFUF ou Nuclei, certains développeurs ont décidé de bloquer les demandes correspondant à leurs agents utilisateurs. Ironiquement, ces ajustements peuvent introduire des opportunités d'empoisonnement de cache et de DoS indésirables.
En théorie, si un nom d'en-tête contient des caractères autres que ceux répertoriés dans **tchar**, il devrait être rejeté avec une demande incorrecte 400. En pratique, cependant, les serveurs ne respectent pas toujours le RFC. La façon la plus simple d'exploiter cette nuance était de cibler Akamai qui ne rejette pas les en-têtes invalides, mais les transmet et met en cache toute erreur 400 tant que l'en-tête de contrôle de cache n'est pas présent.
