mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
133 lines
9.0 KiB
Markdown
133 lines
9.0 KiB
Markdown
# HTTP Response Smuggling / Desync
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|
|
|
|
**Die tegniek van hierdie pos is geneem uit die video:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao&t=1343s)
|
|
|
|
## HTTP Versoek Queues Desynchronisasie
|
|
|
|
Eerstens, hierdie tegniek **misbruik 'n HTTP Versoek Smuggling kwesbaarheid**, so jy moet weet wat dit is:
|
|
|
|
Die **hoof** **verskil** tussen hierdie tegniek en 'n algemene HTTP Versoek smuggling is dat **in plaas van** om die **versoek** van die **slagoffer** **te aanval deur 'n voorvoegsel daaraan toe te voeg**, ons gaan **die respons wat die slagoffer ontvang, lek of wysig**. Dit word gedoen deur, in plaas van om 1 versoek en 'n halwe te stuur om die HTTP Versoek smuggling te misbruik, **2 volledige versoeke te stuur om die proxies se respons queue te desynchroniseer**.
|
|
|
|
Dit is omdat ons in staat gaan wees om die **respons queue te desynchroniseer** sodat die **respons** van die **legitieme** **versoek** van die **slagoffer na die aanvaller gestuur word**, of deur **aanvallers beheerde inhoud in die respons aan die slagoffer in te spuit**.
|
|
|
|
### HTTP Pyplyn Desync
|
|
|
|
HTTP/1.1 laat toe om **verskillende hulpbronne te vra sonder om te wag vir vorige**. Daarom, as daar 'n **proxy** in die **middel** is, is dit die proxies se taak om 'n **gesinkroniseerde ooreenstemming van versoeke wat na die agterkant gestuur is en respons wat daarvandaan kom, te handhaaf**.
|
|
|
|
Daar is egter 'n probleem om die respons queue te desynchroniseer. As 'n aanvaller 'n HTTP Respons smuggling aanval stuur en die respons op die **aanvanklike versoek en die gesmugde een onmiddellik beantwoord word**, sal die gesmugde respons nie in die queue van die slagoffer se respons ingevoeg word nie, maar sal **net as 'n fout weggegooi word**.
|
|
|
|
.png>)
|
|
|
|
Daarom is dit nodig dat die **gesmugde** **versoek** **meer tyd neem om verwerk te word** binne die agterkant bediener. Daarom, teen die tyd dat die gesmugde versoek verwerk word, sal die kommunikasie met die aanvaller verby wees.
|
|
|
|
As in hierdie spesifieke situasie 'n **slagoffer 'n versoek gestuur het** en die **gesmugde versoek voor** die legitieme versoek beantwoord word, sal die **gesmugde respons aan die slagoffer gestuur word**. Daarom sal die aanvaller die **versoek "uitgevoer" deur die slagoffer** **beheer**.
|
|
|
|
Boonop, as die **aanvaller dan 'n versoek uitvoer** en die **legitieme respons** op die **slagoffer** se versoek **beantwoord** **voor** die aanvaller se versoek. Die **respons aan die slagoffer gaan aan die aanvaller gestuur word**, **steel** die respons aan die slagoffer (wat byvoorbeeld die header **Set-Cookie** kan bevat).
|
|
|
|
.png>)
|
|
|
|
.png>)
|
|
|
|
### Meervoudige Geneste Inspuitings
|
|
|
|
Nog 'n **interessante verskil** met algemene **HTTP Versoek Smuggling** is dat, in 'n algemene smuggling aanval, die **doel** is om die **begin van die slagoffer se versoek te wysig** sodat dit 'n onverwagte aksie uitvoer. In 'n **HTTP Respons smuggling aanval**, aangesien jy **volledige versoeke stuur**, kan jy **in een payload tientalle responsies inspuit** wat **tientalle gebruikers gaan desynchroniseer** wat die **ingespuite** **responsies** gaan **ontvang**.
|
|
|
|
Afgesien van die vermoë om **tientalle exploits makliker te versprei** oor legitieme gebruikers, kan dit ook gebruik word om 'n **DoS** op die bediener te veroorsaak.
|
|
|
|
### Exploit Organisasie
|
|
|
|
Soos voorheen verduidelik, om hierdie tegniek te misbruik, is dit nodig dat die **eerste gesmugde boodskap** in die bediener **baie tyd neem om verwerk te word**.
|
|
|
|
Hierdie **tydrowende versoek is genoeg** as ons net die **slagoffer se respons wil probeer steel**. Maar as jy 'n meer komplekse exploit wil uitvoer, sal dit 'n algemene struktuur vir die exploit wees.
|
|
|
|
Eerstens die **aanvanklike** versoek wat **HTTP** **Versoek** **smuggling** misbruik, dan die **tydrowende versoek** en dan **1 of meer payload versoeke** waarvan die respons aan die slagoffers gestuur sal word.
|
|
|
|
## Misbruik van HTTP Respons Queue Desynchronisasie
|
|
|
|
### Vasvang van ander gebruikers se versoeke <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
|
|
|
Soos met bekende payloads van HTTP Versoek Smuggling, kan jy **die slagoffer se versoek steel** met een belangrike verskil: In hierdie geval het jy net die **gestuurde inhoud nodig om in die respons weerspieël te word**, **geen volgehoue berging** is nodig nie.
|
|
|
|
Eerstens, stuur die aanvaller 'n payload wat 'n **finale POST versoek met die weerspieëlde parameter** aan die einde en 'n groot Content-Length bevat.
|
|
|
|
.png>)
|
|
|
|
Dan, sodra die **aanvanklike versoek** (blou) verwerk is en **terwyl** die **slaapagtige** een verwerk word (geel), gaan die **volgende versoek wat van 'n slagoffer aankom** in die queue **net na die weerspieëlde parameter ingevoeg word**:
|
|
|
|
.png>)
|
|
|
|
Dan, die **slagoffer** sal die **respons** op die **slaapagtige** versoek ontvang en as intussen die **aanvaller** **nog 'n** **versoek gestuur het**, sal die **respons van die weerspieëlde inhoud versoek aan hom gestuur word**.
|
|
|
|
## Respons Desynchronisasie
|
|
|
|
Tot op hierdie punt, het ons geleer hoe om HTTP Versoek Smuggling aanvalle te misbruik om die **versoek** **waarvan** die **respons** 'n **klient** gaan **ontvang** te **beheer** en hoe jy dan die **respons kan steel wat bedoel was vir die slagoffer**.
|
|
|
|
Maar dit is steeds moontlik om die respons nog meer te **desynchroniseer**.
|
|
|
|
Daar is interessante versoeke soos **HEAD** versoeke wat gespesifiseer is om **geen inhoud binne die respons se liggaam** te hê nie en wat moet (moet) **die Content-Length** van die versoek bevat soos **as dit 'n GET versoek was**.
|
|
|
|
Daarom, as 'n aanvaller 'n **HEAD** versoek **inspuit**, soos in hierdie beelde:
|
|
|
|
.png>)
|
|
|
|
Dan, **sodra die blou een aan die aanvaller beantwoord word**, gaan die volgende slagoffer se versoek in die queue ingevoer word:
|
|
|
|
.png>)
|
|
|
|
Dan, die **slagoffer** sal die **respons** van die **HEAD** versoek ontvang, wat **'n Content-Length gaan bevat maar glad nie inhoud nie**. Daarom sal die proxy **nie hierdie respons aan die slagoffer stuur nie**, maar sal **wag** vir 'n **inhoud**, wat eintlik die **respons op die geel versoek** gaan wees (ook deur die aanvaller ingespuit):
|
|
|
|
.png>)
|
|
|
|
### Inhoud Verwarring
|
|
|
|
Volg die vorige voorbeeld, wetende dat jy die **liggaam** van die versoek kan **beheer** waarvan die respons aan die slagoffer gaan ontvang en dat 'n **HEAD** **respons** gewoonlik in sy headers die **Content-Type en die Content-Length** bevat, kan jy **'n versoek soos die volgende** stuur om **XSS** in die slagoffer te veroorsaak sonder dat die bladsy kwesbaar is vir XSS:
|
|
|
|
.png>)
|
|
|
|
### Cache Vergiftiging
|
|
|
|
Deur die voorheen bespreekte respons desynchronisasie Inhoud Verwarring aanval te misbruik, **as die cache die respons op die versoek wat deur die slagoffer uitgevoer is, stoor en hierdie respons 'n ingespuite een is wat 'n XSS veroorsaak, dan is die cache vergiftig**.
|
|
|
|
Kwaadwillige versoek wat die XSS payload bevat:
|
|
|
|
.png>)
|
|
|
|
Kwaadwillige respons aan die slagoffer wat die header bevat wat aan die cache aandui om die respons te stoor:
|
|
|
|
.png>)
|
|
|
|
> [!WARNING]
|
|
> Let daarop dat in hierdie geval as die **"slagoffer" die aanvaller is**, hy nou **cache vergiftiging in arbitrêre URL's** kan uitvoer aangesien hy die **URL wat ge-cache gaan word, met die kwaadwillige respons kan beheer**.
|
|
|
|
### Web Cache Misleiding
|
|
|
|
Hierdie aanval is soortgelyk aan die vorige een, maar **in plaas van om 'n payload binne die cache in te spuit, sal die aanvaller slagofferinligting binne die cache stoor:**
|
|
|
|
.png>)
|
|
|
|
### Respons Splitting
|
|
|
|
Die **doel** van hierdie aanval is om weer die **respons** **desynchronisasie** te misbruik om die **proxy 'n 100% aanvaller gegenereerde respons te laat stuur**.
|
|
|
|
Om dit te bereik, moet die aanvaller 'n eindpunt van die webtoepassing vind wat **sekere waardes binne die respons weerspieël** en **die inhoudsgrootte van die HEAD respons weet**.
|
|
|
|
Hy sal 'n **exploit** soos volg stuur:
|
|
|
|
.png>)
|
|
|
|
Nadat die eerste versoek opgelos is en aan die aanvaller teruggestuur is, word die **slagoffer se versoek in die queue ingevoeg**:
|
|
|
|
.png>)
|
|
|
|
Die slagoffer sal as respons die **HEAD respons + die inhoud van die tweede versoek se respons (wat 'n deel van die weerspieëlde data bevat):**
|
|
|
|
.png>)
|
|
|
|
Let egter op hoe die **weerspieëlde data 'n grootte gehad het volgens die Content-Length** van die **HEAD** respons wat **'n geldige HTTP respons in die respons queue gegenereer het**.
|
|
|
|
Daarom, die **volgende versoek van die tweede slagoffer** sal **ontvang** as **respons iets wat heeltemal deur die aanvaller saamgestel is**. Aangesien die respons heeltemal deur die aanvaller saamgestel is, kan hy ook **die proxy laat cache die respons**.
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|