☣️Web Cache Poisoning / Deception
Dernière mise à jour
Dernière mise à jour
Identifier et évaluer les entrées sans clé
En-tête / Cookie
Paramètre
Chaîne de caractère
Ajouter un cache buster à la requête (exp: cb=1)
Essayer de faire refléter un "canary" dans la requête avec une entrée sans clé.
Envoyer la requête jusqu'à ce qu'elle soit mise en cache.
Supprimer le cache buster puis renvoyer la requête.
Obtenir la réponse mise en cache
La mise en cache ou non d'une réponse peut dépendre de toutes sortes de facteurs, tels que l'extension de fichier (exp: .js), le type de contenu, la route, le code d'état (exp: 200 OK) et les en-têtes de réponse (exp: X-Forwarded-Host).
Poisoning vs. Deception:
Poisoning vise mettre en cache une réponse contenant du code malveillant pour impacter les autres utilisateurs, Deception vise à mettre en cache une page contenant des informations sensibles d'un autre utilisateur pour pouvoir les récupérer.
La plupart des serveurs Web et des proxys fournissent une limite de taille d'en-tête de requête d'environ 8,192 bytes. Cependant, il existe certaines exceptions telles que les CDN CloudFront par exemple qui autorisent jusqu'à 20,480 bytes.
Les attaques CPDoS HHO fonctionnent dans des scénarios où une application Web utilise un cache qui accepte une limite de taille d'en-tête supérieure à celle du serveur d'origine. Pour attaquer une telle application Web, un client malveillant envoie une requête HTTP GET comprenant un en-tête supérieur à la taille prise en charge par le serveur d'origine mais inférieur à la taille prise en charge par le cache. Pour ce faire, un attaquant a deux options. Soit il utilise plusieurs en-têtes volumineux dans une même requête, soit il ne créer qu'une seule en-tête mais avec un contenu suffisamment volumineux pour générer l'erreur.
Exemple:
Le principe cette fois est de générer une erreur en envoyant des en-têtes contenant des méta-caractères tels que \n, \r, \a...
Exemple:
De nombreux systèmes intermédiaires tels que les proxys, les équilibreurs de charge, les caches et les pare-feu ne prennent en charge que les méthodes GET et POST. Cela signifie que les requêtes HTTP utilisant DELETE , PUT etc sont simplement bloquées. Pour contourner cette restriction, de nombreuses API REST et frameworks fournissent des en-têtes tels que X-HTTP-Method-Override, X-HTTP-Method ou X-Method-Override pour les méthodes HTTP bloquées par tunnel. Une fois que la requête atteint le serveur, l'en-tête demande à l'application Web de remplacer la méthode HTTP dans la ligne de requête par celle de la valeur d'en-tête correspondante.
Le principe de cette variante est donc de tenter de générer une erreur 404 Not Found depuis une requête légitime (exp: GET /index.html) en remplaçant la méthode HTTP via une de ces en-têtes.
De ce fait, si GET /index.html est mise en cache, il sera possible de mettre en cache la réponse comme si il s'agissait d'un POST /index.html par exemple.
Exemple:
Selon la RFC 4343, les noms de domaine complets (FQDN) doivent toujours être insensibles à la casse. Cependant, pour une raison quelconque, cette règle n'est pas toujours respectée par les frameworks. Il est intéressant de noter que, comme la valeur de l'hôte doit être insensible à la casse, certains développeurs supposent qu'il est prudent de mettre en minuscules la valeur de l'en-tête de l'hôte lors de son introduction dans la clé de cache, sans modifier la requête réelle envoyée au serveur principal.
De ce fait, il est parfois possible de générer des erreurs 404 mises en cache en ajoutant une majuscule dans l'en-tête Host de la requête.
Exemple:
Un en-tête hop-by-hop est un en-tête conçu pour être traité et consommé par le proxy qui gère la requête, par opposition à un en-tête end-to-end, qui est conçu pour être présent dans la requête jusqu'à la fin de la requête. Selon la RFC 2612, la spécification HTTP/1.1 traite les en-têtes suivants comme hop-by-hop par défaut : Keep-Alive, Transfer-Encoding, TE, Connection, Trailer, Upgrade, Proxy-Authorization et Proxy-Authenticate. Lorsqu'il rencontre ces en-têtes dans une requête, un proxy conforme doit traiter ou agir sur ce que ces en-têtes indiquent, et ne pas les transmettre au saut suivant.
Outre ces valeurs par défaut, une requête peut également définir un ensemble personnalisé d'en-têtes à traiter comme un en-tête hop-by-hop en les ajoutant à l'en-tête de connexion, comme ceci :
Dans cet exemple, nous demandons au proxy de traiter X-Foo et X-Bar comme une en-tête hop-by-hop, ce qui signifie que nous voulons qu'un proxy les supprime de la requête avant de la transmettre. C'est ce fonctionnement qui permet l'exploitation de cette variante de CPDoS.
Certains frameworks et serveurs web utilisent des délimiteurs qui peuvent permettre de tromper les serveurs de cache.
Wordlist utile:
Par exemple, Spring permet d'utiliser des semicolon comme paramètres:
/user;params/home sera traité comme /user/home
MyAccount;a.js sera traité comme /MyAccount
Or, si le serveur met en cache les ressources en .js, le contenu sensible de MyAccount sera mis en cache.
De la même manière, Rails utilise le . (point) pour afficher les vues, mais toutes les extensions ne sont pas prises en charge par le framework.
Par exemple:
/MyAccount affichera la vue myaccount.html.erb
/MyAccount.css affichera la vue myaccount.css.erb
Cependant,
/MyAccount.aaa ne sera pas reconnu et affichera la vue par défaut qui est myaccount.html.erb
Cela signifie que si le serveur de cache est configuré pour mettre en cache des extensions n'étant pas reconnues par le framework, il est possible de mettre en cache le contenu de /MyAccount.
Exemple: MyAccount.ico pourrait être mis en cache et afficher la vue myaccount.html.erb
même chose avec %0A:
/MyAccount%0A.js => /MyAccount
Param Miner est une extension de Burp Suite permettant d'automatiser la recherche d'entrées sans clé.
Utilisation: clic droit sur la requête > "Extensions" > "Param Miner" > ...
Résultats visible dans l'onglet "Extender" > "Extensions" > "Param Miner" > "Output"
