Web Cache Poisoning / Deception
DerniĂšre mise Ă jour
Cet article vous a-t-il été utile ?
DerniĂšre mise Ă jour
Cet article vous a-t-il été utile ?
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).
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é.
