hacktricks/pentesting-web/http-response-smuggling-desync.md

# HTTP Response Smuggling / Desync

<details>

<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>

* क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग** करने की आवश्यकता है? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFT**](https://opensea.io/collection/the-peass-family) संग्रह
* [**आधिकारिक PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में **शामिल हों** या मुझे **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)** का** **अनुसरण** करें।**
* **अपने हैकिंग ट्रिक्स को** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **और** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **में PR जमा करके साझा करें।**

</details>

## HTTP Request Queue Desynchronisation

सबसे पहले, यह तकनीक एक HTTP Request Smuggling की कमजोरी का उपयोग करती है, इसलिए आपको जानना चाहिए कि यह क्या है:

इस तकनीक और सामान्य HTTP Request smuggling के मुख्य अंतर का मुख्य अंतर यह है कि इसके बजाय कि पीड़ित के अनुरोध में एक प्रीफिक्स जोड़कर हम उसके अनुरोध को हमला कर रहे हैं, हम पीड़ित को मिलने वाले प्रतिक्रिया को लीक या संशोधित करने जा रहे हैं। इसे करने के लिए, HTTP Request smuggling का दुरुपयोग करने के बजाय, हम प्रोक्सी प्रतिक्रिया कतार को असमयित करने के लिए 2 पूर्ण अनुरोध भेजेंगे।

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

### HTTP Pipeline Desync

HTTP/1.1 को पिछले वाले को इंतजार किए बिना **विभिन्न संसाधनों के लिए पूछा जा सकता है**। इसलिए, यदि किसी **प्रोक्सी** में है, तो यह प्रोक्सी का कार्य होता है कि वह पीछे की ओर भेजे गए अनुरोधों की और उनसे आने वाली प्रतिक्रियाओं की समकक्ष मिलान बनाए रखें।

हालांकि, प्रतिक्रिया कतार को असमयित करने में एक समस्या है। यदि एक हमलावर एक HTTP Response smuggling हमला भेजता है और प्रारंभिक अनुरोध और smuggled अनुरोध की प्रतिक्रियाएं तत्काल उत्तर देती हैं, तो smuggled प्रतिक्रिया पीड़ित प्रतिक्रिया कतार में सम्मिलित नहीं की जाएगी, बल्कि यह एक त्रुटि के रूप में छोड़ दी जाएगी।

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

इसलिए, इसे आवश्यक है कि smuggled अनुरोध को प्रोसेस करने में अधिक समय लगे। इसलिए, जब तक smuggled अनुरोध प्रोसेस होता है, हमलावर के साथ संवाद समाप्त हो जाएगा।

यदि इस विशेष स्थिति में किसी पीड़ित ने एक अनुरोध भेजा है और smuggled अनुरोध उससे पहले प्रतिक्रिया देता है, तो smuggled प्रतिक्रिया पीड़ित को भेजी जाएगी। इसलिए, हमलावर पीड़ित द्वारा "किया गया" अनुरोध नियंत्रित कर रहा होगा।

इसके अलावा, यदि हमलावर एक अनुरोध करता है और पीड़ित
## प्रतिक्रिया असमंजसीकरण

इस बात तक, हमने सीखा है कि कैसे HTTP रिक्वेस्ट स्मगलिंग हमलों का दुरुपयोग करके उस रिक्वेस्ट को नियंत्रित कर सकते हैं जिसकी प्रतिक्रिया कोई क्लाइंट प्राप्त करेगा और आप फिर उस प्रतिक्रिया को चोरी कर सकते हैं जो पीड़ित के लिए थी।

लेकिन इसके अलावा भी प्रतिक्रियाओं को और असमंजित किया जा सकता है।

ऐसे रिक्वेस्ट्स हैं जैसे कि HEAD रिक्वेस्ट जिनमें यह निर्दिष्ट किया गया है कि प्रतिक्रिया के भीतर कोई सामग्री नहीं होनी चाहिए और इसमें (जरूरी है) रिक्वेस्ट की Content-Length को शामिल करना चाहिए जैसे कि यह एक GET रिक्वेस्ट हो।

इसलिए, यदि कोई हमलावर एक HEAD रिक्वेस्ट डालता है, जैसे कि इस चित्र में:

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

तो, एक बार जब नीला रिक्ति हमलावर को प्रतिक्रिया दी जाती है, तो अगले पीड़ित की रिक्वेस्ट कतार में डाली जाती है:

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

फिर, पीड़ित को HEAD रिक्वेस्ट से प्रतिक्रिया मिलेगी, जिसमें कोई सामग्री नहीं होगी लेकिन इसमें एक Content-Length होगा। इसलिए, प्रॉक्सी इस प्रतिक्रिया को पीड़ित को नहीं भेजेगी, बल्कि कुछ सामग्री की प्रतीक्षा करेगी, जो वास्तव में हमलावर द्वारा डाली गई पीली रिक्वेस्ट की प्रतिक्रिया होगी:

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

### सामग्री भ्रम

पिछले उदाहरण का पालन करते हुए, जानते हुए कि आप पीड़ित को प्रतिक्रिया प्राप्त करने वाले रिक्वेस्ट के बॉडी को नियंत्रित कर सकते हैं और HEAD प्रतिक्रिया में आमतौर पर इसके हेडर में Content-Type और Content-Length होते हैं, आप निम्नलिखित रिक्वेस्ट को भेजकर पीड़ित में XSS को उत्पन्न कर सकते हैं बिना पृष्ठ XSS के लिए संक्रमित होने के लिए:

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

### कैश पॉइज़निंग

पहले ही टिप्पणी की गई प्रतिक्रिया असमंजसीकरण सामग्री भ्रम हमले का दुरुपयोग करके, यदि कैश पीड़ित द्वारा किए गए रिक्वेस्ट की प्रतिक्रिया को संग्रहीत करता है और यह प्रतिक्रिया XSS का कारण बनाने वाली एक डाली गई है, तो कैश में विषाक्त हो जाता है।

XSS पेलोड को शामिल करने वाला दुष्ट रिक्वेस्ट:

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

पीड़ित को विषाक्त करने वाली दुष्ट प्रतिक्रिया जो कैश को प्रतिक्रिया संग्रहीत करने के लिए संकेत देती है:

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

{% hint style="warning" %}
ध्यान दें कि इस मामले में यदि "पीड़ित" हमलावर है तो वह अब "कैश पॉइज़निंग" कर सकता है क्योंकि उसे दुष्ट प्रतिक्रिया द्वारा कैश किया जाने वाला URL नियंत्रित कर सकता है।
{% endhint %}

### वेब कैश भ्रम

यह हमला पिछले हमले की तुलना में समान है, लेकिन इसमें हमलावर विक्टिम की जानकारी को कैश में संग्रहीत कर रहा है:

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

### प्रतिक्रिया विभाजन

इस हमले का उद्देश्य फिर से प्रतिक्रिया असमंजित करके प्रॉक्सी को 100% हमलावर द्वारा उत्पन्न प्रतिक्रिया भेजना है।

इसे प्राप्त करने के लिए, हमलावर को वेब एप्लिकेशन के एक एंडपॉइंट को खोजना होगा जो प्रतिक्रिया में कुछ मानों को प्रतिबिंबित कर रहा है और HEAD प्रतिक्रिया की Content-Length को जानना होगा।

वह एक ऐसा शोध भेजेगा:

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

पहले रिक्वेस्ट को हल करने और हमलावर को वापस भेजने के बाद, पीड़ित की रिक्वेस्ट कत