# HTTP Response Smuggling / Desync

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

**Teknolojia ya posti hii ilichukuliwa kutoka kwenye video:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao&t=1343s)

## HTTP Request Queue Desynchronisation

Kwanza kabisa, teknolojia hii **inatumia udhaifu wa HTTP Request Smuggling**, hivyo unahitaji kujua ni nini hicho:

**Tofauti** **kuu** kati ya teknolojia hii na HTTP Request smuggling ya kawaida ni kwamba **badala** ya **kushambulia** **ombile** la **mhasiriwa** **kwa kuongeza kiambatisho** kwake, tutakuwa **tukivuja au kubadilisha jibu ambalo mhasiriwa anapata**. Hii inafanywa kwa, badala ya kutuma ombi 1 na nusu ili kutumia HTTP Request smuggling, **tutatumia maombi 2 kamili ili kuondoa usawa wa majibu ya proxies**.

Hii ni kwa sababu tutakuwa na uwezo wa **kuondoa usawa wa foleni ya majibu** ili **jibu** kutoka kwa **ombile** la **halali** la **mhasiriwa litumwe kwa mshambuliaji**, au kwa **kuingiza maudhui yanayodhibitiwa na mshambuliaji katika jibu kwa mhasiriwa**.

### HTTP Pipeline Desync

HTTP/1.1 inaruhusu kuomba **rasilimali tofauti bila kuhitaji kusubiri zilizopita**. Hivyo, ikiwa kuna **proxy** katikati, ni jukumu la proxies **kuweka usawa wa maombi yaliyotumwa kwa backend na majibu yanayotoka huko**.

Hata hivyo, kuna tatizo la kuondoa usawa wa foleni ya majibu. Ikiwa mshambuliaji atatuma shambulio la HTTP Response smuggling na majibu kwa **ombile la awali na lile lililovuja yanajibiwa mara moja**, jibu lililovuja halitaingizwa ndani ya foleni ya jibu la mhasiriwa bali litakataliwa kama kosa.

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

Hivyo, inahitajika kwamba **ombile lililovuja** **lichukue muda mrefu zaidi kutekelezwa** ndani ya seva ya nyuma. Hivyo, wakati ombi lililovuja linaposhughulikiwa, mawasiliano na mshambuliaji yatakuwa yameisha.

Ikiwa katika hali hii maalum **mhasiriwa ametuma ombi** na **ombile lililovuja linajibiwa kabla** ya ombi halali, **jibu lililovuja litatumwa kwa mhasiriwa**. Hivyo, mshambuliaji atakuwa **akidhibiti ombi "lililofanywa" na mhasiriwa**.

Zaidi ya hayo, ikiwa **mshambuliaji kisha atafanya ombi** na **jibu halali** kwa **ombile** la **mhasiriwa linajibiwa** **kabla** ya ombi la mshambuliaji. **Jibu kwa mhasiriwa litatumwa kwa mshambuliaji**, **kuchukua** jibu kwa mhasiriwa (ambalo linaweza kuwa na mfano wa kichwa **Set-Cookie**).

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

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

### Multiple Nested Injections

Tofauti nyingine **ya kuvutia** na **HTTP Request Smuggling** ya kawaida ni kwamba, katika shambulio la kawaida la smuggling, **lengo** ni **kubadilisha mwanzo wa ombi la mhasiriwa** ili lifanye kitendo kisichotarajiwa. Katika **shambulio la HTTP Response smuggling**, kwa kuwa unatumia **maombi kamili**, unaweza **kuingiza katika payload moja majibu kumi** ambayo yatakuwa **yakiondoa usawa wa watumiaji kumi** ambao watakuwa **wakipokea** **majibu yaliyoingizwa**.

Mbali na kuwa na uwezo wa **kusambaza kwa urahisi majibu kumi** kati ya watumiaji halali, hii pia inaweza kutumika kusababisha **DoS** katika seva.

### Exploit Organisation

Kama ilivyoelezwa hapo awali, ili kutumia teknolojia hii, inahitajika kwamba **ujumbe wa kwanza ulioingizwa** ndani ya seva **uchukue muda mwingi kutekelezwa**.

Hii **ombile linalochukua muda** ni ya kutosha ikiwa tunataka tu **kujaribu kuiba jibu la mhasiriwa.** Lakini ikiwa unataka kufanya exploit ngumu zaidi hii itakuwa muundo wa kawaida kwa exploit.

Kwanza kabisa **ombile la awali** likitumia **HTTP** **Request** **smuggling**, kisha **ombile linalochukua muda** na kisha **ombile 1 au zaidi** ambayo majibu yake yatatumwa kwa mhasiriwa.

## Abusing HTTP Response Queue Desynchronisation

### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

Kama ilivyo na payloads za HTTP Request Smuggling zinazojulikana, unaweza **kuiba ombi la mhasiriwa** kwa tofauti moja muhimu: Katika kesi hii unahitaji tu **maudhui ya kutumwa kuakisi katika jibu**, **hakuna hifadhi ya kudumu** inahitajika.

Kwanza, mshambuliaji anatumia payload inayojumuisha **ombile la mwisho la POST lenye kiambatisho kilichoakisiwa** mwishoni na Content-Length kubwa.

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

Kisha, mara tu **ombile la awali** (bluu) liliposhughulikiwa na **wakati** **ombile la usingizi** linaposhughulikiwa (njano) **ombile linalofika kutoka kwa mhasiriwa** litakuwa **limeongezwa kwenye foleni mara tu baada ya kiambatisho kilichoakisiwa**:

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

Kisha, **mhasiriwa** atapokea **jibu** kwa **ombile la usingizi** na ikiwa wakati huo **mshambuliaji** **alituma** **ombile** **lingine**, **jibu kutoka kwa ombi la maudhui yaliyoakisiwa litatumwa kwake**.

## Response Desynchronisation

Hadi sasa, tumefundishwa jinsi ya kutumia shambulio la HTTP Request Smuggling ili **kudhibiti** **ombile** **ambalo** **jibu** ambalo **mteja** atakuwa **akipokea** na jinsi unaweza kisha **kuiba jibu ambalo lilikuwa limetengwa kwa mhasiriwa**.

Lakini bado inawezekana **kuondoa usawa hata** zaidi majibu.

Kuna maombi ya kuvutia kama **HEAD** ambayo yameainishwa kutokuwa na **maudhui yoyote ndani ya mwili wa majibu** na ambayo yanapaswa (lazima) **kujumuisha Content-Length** ya ombi kama **kama ingekuwa ombi la GET**.

Hivyo, ikiwa mshambuliaji **anaingiza** ombi la **HEAD**, kama katika picha hizi:

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

Kisha, **mara tu ombi la buluu linapojibiwa kwa mshambuliaji**, ombi linalofuata la mhasiriwa litakuwa limeingizwa kwenye foleni:

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

Kisha, **mhasiriwa** atapokea **jibu** kutoka kwa **HEAD** ombi, ambalo **litakuwa na Content-Length lakini hakuna maudhui kabisa**. Hivyo, proxy **haitatuma jibu hili** kwa mhasiriwa, bali itasubiri **maudhui**, ambayo kwa kweli yatakuwa **jibu kwa ombi la njano** (pia lililoingizwa na mshambuliaji):

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

### Content Confusion

Kufuata mfano wa awali, ukijua kwamba unaweza **kudhibiti mwili** wa ombi ambalo jibu litapokea mhasiriwa na kwamba **HEAD** **jibu** kawaida lina **Content-Type na Content-Length** katika vichwa vyake, unaweza **kutuma ombi kama ifuatavyo** ili **kusababisha XSS** kwa mhasiriwa bila ukurasa kuwa na udhaifu wa XSS:

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

### Cache Poisoning

Kutumia shambulio la Content Confusion lililozungumziwa hapo awali, **ikiwa cache inahifadhi jibu kwa ombi lililofanywa na mhasiriwa na jibu hili ni la kuingizwa linalosababisha XSS, basi cache inakuwa na sumu**.

Ombi la uhalifu likijumuisha payload ya XSS:

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

Jibu la uhalifu kwa mhasiriwa ambalo lina kichwa kinachoelekeza kwenye cache kuhifadhi jibu:

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

> [!WARNING]
> Kumbuka kwamba katika kesi hii ikiwa **"mhasiriwa" ni mshambuliaji** anaweza sasa kufanya **kuweka sumu kwenye cache katika URLs za kiholela** kwani anaweza **kudhibiti URL ambayo itahifadhiwa** na jibu la uhalifu.

### Web Cache Deception

Shambulio hili ni sawa na la awali, lakini **badala ya kuingiza payload ndani ya cache, mshambuliaji atakuwa akihifadhi taarifa za mhasiriwa ndani ya cache:**

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

### Response Splitting

**Lengo** la shambulio hili ni kutumia tena **kuondoa usawa wa majibu** ili **kufanya proxy itume jibu 100% lililotengenezwa na mshambuliaji**.

Ili kufikia hili, mshambuliaji anahitaji kupata mwisho wa programu ya wavuti ambayo **inaakisi baadhi ya thamani ndani ya jibu** na **ajue urefu wa maudhui ya jibu la HEAD**.

Atatuma **exploit** kama:

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

Baada ya ombi la kwanza kutatuliwa na kutumwa kwa mshambuliaji, **ombile la mhasiriwa linaongezwa kwenye foleni**:

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

Mhasiriwa atapokea kama jibu **jibu la HEAD + maudhui ya jibu la ombi la pili (linalojumuisha sehemu ya data iliyoakisiwa):**

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

Hata hivyo, angalia jinsi **data iliyoakisiwa ilikuwa na ukubwa kulingana na Content-Length** ya **HEAD** jibu ambayo **ilijenga jibu halali la HTTP katika foleni ya majibu**.

Hivyo, **ombile linalofuata la mhasiriwa wa pili** litakuwa **likipokea** kama **jibu kitu kilichotengenezwa kabisa na mshambuliaji**. Kwa kuwa jibu limeundwa kabisa na mshambuliaji anaweza pia **kufanya proxy ihifadhi jibu**.

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