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

![](<../images/image (633).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).

![](<../images/image (1020).png>)

![](<../images/image (719).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.

![](<../images/image (1053).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**:

![](<../images/image (794).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:

![](<../images/image (1107).png>)

Dan, **sodra die blou een aan die aanvaller beantwoord word**, gaan die volgende slagoffer se versoek in die queue ingevoer word:

![](<../images/image (999).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):

![](<../images/image (735).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:

![](<../images/image (688).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:

![](<../images/image (614).png>)

Kwaadwillige respons aan die slagoffer wat die header bevat wat aan die cache aandui om die respons te stoor:

![](<../images/image (566).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:**

![](<../images/image (991).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:

![](<../images/image (911).png>)

Nadat die eerste versoek opgelos is en aan die aanvaller teruggestuur is, word die **slagoffer se versoek in die queue ingevoeg**:

![](<../images/image (737).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):**

![](<../images/image (356).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}}