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

# HTTP Response Smuggling / Desync

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

**इस पोस्ट की तकनीक वीडियो से ली गई थी:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao&t=1343s)

## HTTP Request Queue Desynchronisation

सबसे पहले, यह तकनीक **HTTP Request Smuggling vulnerability** का **दुरुपयोग** करती है, इसलिए आपको यह जानना आवश्यक है कि यह क्या है:

इस तकनीक और सामान्य HTTP Request smuggling के बीच का **मुख्य** **अंतर** यह है कि **हम पीड़ित के **request** में **prefix** जोड़ने के बजाय**, हम **पीड़ित द्वारा प्राप्त प्रतिक्रिया को लीक या संशोधित** करने जा रहे हैं। यह इस प्रकार किया जाता है कि, HTTP Request smuggling का दुरुपयोग करने के लिए 1 और आधा request भेजने के बजाय, **प्रॉक्सी प्रतिक्रियाओं की कतार को असंक्रमित करने के लिए 2 पूर्ण requests भेजें**।

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

### HTTP Pipeline Desync

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

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

![](<../images/image (633).png>)

इसलिए, यह आवश्यक है कि **स्मगल्ड** **request** **प्रोसेस होने में अधिक समय ले**। इसलिए, जब तक स्मगल्ड request प्रोसेस होती है, तब तक हमलावर के साथ संचार समाप्त हो जाएगा।

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

इसके अलावा, यदि **हमलावर फिर एक request करता है** और **पीड़ित** की request का **वैध उत्तर** **हमलावर की request से पहले** **उत्तर दिया जाता है**। **पीड़ित के लिए प्रतिक्रिया हमलावर को भेजी जाएगी**, **पीड़ित की प्रतिक्रिया को चुराते हुए** (जिसमें उदाहरण के लिए **Set-Cookie** हेडर हो सकता है)।

![](<../images/image (1020).png>)

![](<../images/image (719).png>)

### Multiple Nested Injections

सामान्य **HTTP Request Smuggling** के साथ एक और **दिलचस्प अंतर** यह है कि, एक सामान्य स्मगलिंग हमले में, **लक्ष्य** **पीड़ित के request के प्रारंभ को संशोधित करना** है ताकि यह एक अप्रत्याशित क्रिया करे। एक **HTTP Response smuggling हमले** में, चूंकि आप **पूर्ण requests भेज रहे हैं**, आप **एक payload में दर्जनों प्रतिक्रियाएं इंजेक्ट कर सकते हैं** जो **दर्जनों उपयोगकर्ताओं को असंक्रमित** कर देंगी जो **इंजेक्ट की गई** **प्रतिक्रियाएं प्राप्त कर रहे हैं**।

वैध उपयोगकर्ताओं के बीच **दर्जनों exploits को अधिक आसानी से वितरित** करने के अलावा, इसका उपयोग सर्वर में **DoS** उत्पन्न करने के लिए भी किया जा सकता है।

### Exploit Organisation

जैसा कि पहले समझाया गया है, इस तकनीक का दुरुपयोग करने के लिए, यह आवश्यक है कि **सर्वर में पहला स्मगल्ड संदेश** **प्रोसेस होने में बहुत समय ले**।

यदि हम केवल **पीड़ित की प्रतिक्रिया चुराने** की कोशिश कर रहे हैं तो यह **समय लेने वाला request पर्याप्त है**। लेकिन यदि आप एक अधिक जटिल exploit करना चाहते हैं तो यह exploit के लिए एक सामान्य संरचना होगी।

सबसे पहले **HTTP** **Request** **smuggling** का दुरुपयोग करते हुए **प्रारंभिक** request, फिर **समय लेने वाला request** और फिर **1 या अधिक payload requests** जिनकी प्रतिक्रियाएं पीड़ितों को भेजी जाएंगी।

## Abusing HTTP Response Queue Desynchronisation

### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

HTTP Request Smuggling के ज्ञात payloads के साथ, आप **पीड़ित के request को चुरा सकते हैं** जिसमें एक महत्वपूर्ण अंतर है: इस मामले में आपको केवल **प्रतिक्रिया में परावर्तित सामग्री भेजने की आवश्यकता है**, **कोई स्थायी भंडारण** आवश्यक नहीं है।

पहले, हमलावर एक payload भेजता है जिसमें **परावर्तित पैरामीटर** के साथ एक **अंतिम POST request** और एक बड़ा Content-Length होता है।

![](<../images/image (1053).png>)

फिर, एक बार जब **प्रारंभिक request** (नीला) को **प्रोसेस** किया गया और **जब** **नींद वाली** request को प्रोसेस किया जा रहा है (पीला) तो **एक पीड़ित से आने वाली अगली request** को **परावर्तित पैरामीटर के ठीक बाद कतार में जोड़ा जाएगा**:

![](<../images/image (794).png>)

फिर, **पीड़ित** को **नींद वाली** request की **प्रतिक्रिया प्राप्त होगी** और यदि इस बीच **हमलावर ने** **एक और** **request भेजी**, तो **परावर्तित सामग्री request से प्रतिक्रिया उसे भेजी जाएगी**।

## Response Desynchronisation

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

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

कुछ दिलचस्प requests हैं जैसे **HEAD** request जो निर्दिष्ट करते हैं कि प्रतिक्रिया के शरीर में **कोई सामग्री नहीं होनी चाहिए** और जो **Content-Length** को **GET request** की तरह **शामिल करना चाहिए**।

इसलिए, यदि एक हमलावर **HEAD** request इंजेक्ट करता है, जैसे कि इन छवियों में:

![](<../images/image (1107).png>)

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

![](<../images/image (999).png>)

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

![](<../images/image (735).png>)

### Content Confusion

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

![](<../images/image (688).png>)

### Cache Poisoning

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

XSS payload वाली दुर्भावनापूर्ण request:

![](<../images/image (614).png>)

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

![](<../images/image (566).png>)

> [!WARNING]
> ध्यान दें कि इस मामले में यदि **"पीड़ित" हमलावर है** तो वह अब **मनमाने URLs में कैश विषाक्त** कर सकता है क्योंकि वह **दुर्भावनापूर्ण प्रतिक्रिया के साथ कैश की जाने वाली URL को नियंत्रित कर सकता है**।

### Web Cache Deception

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

![](<../images/image (991).png>)

### Response Splitting

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

इस लक्ष्य को प्राप्त करने के लिए, हमलावर को एक वेब एप्लिकेशन के एक एंडपॉइंट को खोजने की आवश्यकता है जो **प्रतिक्रिया के अंदर कुछ मानों को परावर्तित कर रहा है** और **HEAD प्रतिक्रिया की सामग्री की लंबाई को जानता है**।

वह एक **exploit** भेजेगा जैसे:

![](<../images/image (911).png>)

पहली request के हल होने और हमलावर को वापस भेजे जाने के बाद, **पीड़ित की request कतार में जोड़ी जाती है**:

![](<../images/image (737).png>)

पीड़ित को प्रतिक्रिया के रूप में **HEAD प्रतिक्रिया + दूसरी request की प्रतिक्रिया (जिसमें परावर्तित डेटा का एक भाग शामिल है) प्राप्त होगी:**

![](<../images/image (356).png>)

हालांकि, ध्यान दें कि **परावर्तित डेटा का आकार HEAD** प्रतिक्रिया की **Content-Length** के अनुसार था जिसने **प्रतिक्रिया कतार में एक वैध HTTP प्रतिक्रिया उत्पन्न की**।

इसलिए, **दूसरे पीड़ित की अगली request** को **प्रतिक्रिया के रूप में कुछ पूरी तरह से हमलावर द्वारा तैयार किया गया प्राप्त होगा**। चूंकि प्रतिक्रिया पूरी तरह से हमलावर द्वारा तैयार की गई है, वह **प्रॉक्सी को प्रतिक्रिया को कैश करने** के लिए भी **बना सकता है**।

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