maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

Browse Source
This commit is contained in:
Translator 2025-08-20 16:35:22 +00:00
parent 0036aa9107
commit 9cd5ee2802
2 changed files with 201 additions and 73 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

254
src/pentesting-web/http-request-smuggling/README.md
View File

@ -4,7 +4,7 @@
## What is
यह सुरक्षा कमी तब होती है जब **फ्रंट-एंड प्रॉक्सी** और **बैक-एंड** सर्वर के बीच **डिसिंक्रोनाइजेशन** एक **हमलावर** को एक HTTP **अनुरोध** **भेजने** की अनुमति देता है जिसे **फ्रंट-एंड** प्रॉक्सी (लोड बैलेंस/रिवर्स-प्रॉक्सी) द्वारा **एकल अनुरोध** के रूप में और **बैक-एंड** सर्वर द्वारा **2 अनुरोध** के रूप में **व्याख्यायित** किया जाएगा।\
यह सुरक्षा कमजोरी तब होती है जब **फ्रंट-एंड प्रॉक्सी** और **बैक-एंड** सर्वर के बीच **डिसिंक्रोनाइजेशन** एक **हमलावर** को एक HTTP **अनुरोध** **भेजने** की अनुमति देता है जिसे **फ्रंट-एंड** प्रॉक्सी (लोड बैलेंस/रिवर्स-प्रॉक्सी) द्वारा **एकल अनुरोध** के रूप में और **बैक-एंड** सर्वर द्वारा **2 अनुरोध** के रूप में **व्याख्यायित** किया जाएगा।\
यह एक उपयोगकर्ता को **उसके बाद बैक-एंड सर्वर पर आने वाले अगले अनुरोध को संशोधित** करने की अनुमति देता है।
### Theory
@ -24,29 +24,29 @@
### Reality
**फ्रंट-एंड** (एक लोड-बैलेंस / रिवर्स प्रॉक्सी) _**content-length**_ या _**transfer-encoding**_ हेडर को प्रोसेस करता है और **बैक-एंड** सर्वर **दूसरे** को प्रोसेस करता है जिससे 2 सिस्टमों के बीच **डिसिंक्रोनाइजेशन** उत्पन्न होता है।\
यह बहुत महत्वपूर्ण हो सकता है क्योंकि **एक हमलावर एक अनुरोध भेजने में सक्षम होगा** जो रिवर्स प्रॉक्सी को **व्याख्यायित** किया जाएगा **बैक-एंड** सर्वर द्वारा **2 अलग-अलग अनुरोधों** के रूप में। इस तकनीक का **खतरा** इस तथ्य में निहित है कि **बैक-एंड** सर्वर **2nd अनुरोध को इंजेक्ट किया गया** के रूप में **व्याख्यायित** करेगा जैसे कि यह **अगले क्लाइंट** से आया हो और उस क्लाइंट का **वास्तविक अनुरोध** **इंजेक्टेड अनुरोध** का **भाग** होगा।
**फ्रंट-एंड** (एक लोड-बैलेंस / रिवर्स प्रॉक्सी) _**content-length**_ या _**transfer-encoding**_ हेडर को **प्रोसेस** करता है और **बैक-एंड** सर्वर **दूसरे** को प्रोसेस करता है जिससे 2 सिस्टमों के बीच **डिसिंक्रोनाइजेशन** उत्पन्न होता है।\
यह बहुत महत्वपूर्ण हो सकता है क्योंकि **एक हमलावर एक अनुरोध** रिवर्स प्रॉक्सी को **भेजने में सक्षम होगा** जिसे **बैक-एंड** सर्वर द्वारा **2 अलग-अलग अनुरोधों** के रूप में **व्याख्यायित** किया जाएगा। इस तकनीक का **खतरा** इस तथ्य में निहित है कि **बैक-एंड** सर्वर **2nd अनुरोध** को इस तरह **व्याख्यायित करेगा** जैसे कि यह **अगले क्लाइंट** से आया हो और उस क्लाइंट का **वास्तविक अनुरोध** **इंजेक्टेड अनुरोध** का **भाग** होगा।
### Particularities
याद रखें कि HTTP में **एक नई पंक्ति का वर्ण 2 बाइट्स से बना होता है:**
- **Content-Length**: यह हेडर **अनुरोध के शरीर** के **बाइट्स** की **संख्या** को इंगित करने के लिए **दशमलव संख्या** का उपयोग करता है। शरीर को अंतिम वर्ण में समाप्त होने की उम्मीद है, **अनुरोध के अंत में नई पंक्ति की आवश्यकता नहीं है**।
- **Transfer-Encoding:** यह हेडर **शरीर** में **अंकित संख्या** का उपयोग करता है जो **अगले टुकड़े** के **बाइट्स** की **संख्या** को इंगित करता है। **टुकड़ा** को **नई पंक्ति** के साथ **समाप्त** होना चाहिए लेकिन यह नई पंक्ति **लंबाई संकेतक** द्वारा **गिनी नहीं जाती**। इस ट्रांसफर विधि को **0 आकार के टुकड़े के साथ समाप्त होना चाहिए जिसके बाद 2 नई पंक्तियाँ** हों: `0`
- **Content-Length**: यह हेडर **बाइट्स** की **संख्या** को इंगित करने के लिए **दशमलव संख्या** का उपयोग करता है। अनुरोध के **शरीर** की संख्या। शरीर को अंतिम वर्ण में समाप्त होने की उम्मीद है, **अनुरोध के अंत में एक नई पंक्ति की आवश्यकता नहीं है**।
- **Transfer-Encoding:** यह हेडर **शरीर** में **हैक्साडेसिमल संख्या** का उपयोग करता है ताकि **अगले टुकड़े** के **बाइट्स** की **संख्या** को इंगित किया जा सके। **टुकड़ा** **नई पंक्ति** के साथ **समाप्त** होना चाहिए लेकिन यह नई पंक्ति **लंबाई संकेतक** द्वारा **गिनी नहीं जाती**। इस ट्रांसफर विधि को **0 आकार के टुकड़े के साथ समाप्त होना चाहिए जिसके बाद 2 नई पंक्तियाँ** हों: `0`
- **Connection**: मेरे अनुभव के आधार पर, अनुरोध स्मगलिंग के पहले अनुरोध पर **`Connection: keep-alive`** का उपयोग करने की सिफारिश की जाती है।
## Basic Examples
> [!TIP]
> जब Burp Suite के साथ इसका शोषण करने की कोशिश कर रहे हों तो **`Update Content-Length` और `Normalize HTTP/1 line endings`** को रिपीटर में बंद करें क्योंकि कुछ गैजेट नई पंक्तियों, कैरिज रिटर्न और गलत सामग्री-लंबाई का दुरुपयोग करते हैं।
> जब Burp Suite के साथ इसका शोषण करने की कोशिश कर रहे हों, तो **`Update Content-Length` और `Normalize HTTP/1 line endings`** को रिपीटर में बंद करें क्योंकि कुछ गैजेट नई पंक्तियों, कैरिज रिटर्न और गलत सामग्री-लंबाई का दुरुपयोग करते हैं।
HTTP अनुरोध स्मगलिंग हमलों को अस्पष्ट अनुरोध भेजकर तैयार किया जाता है जो `Content-Length` (CL) और `Transfer-Encoding` (TE) हेडरों की व्याख्या में फ्रंट-एंड और बैक-एंड सर्वरों के बीच असंगतियों का लाभ उठाते हैं। ये हमले विभिन्न रूपों में प्रकट हो सकते हैं, मुख्य रूप से **CL.TE**, **TE.CL**, और **TE.TE** के रूप में। प्रत्येक प्रकार उन हेडरों को प्राथमिकता देने के तरीके का एक अद्वितीय संयोजन दर्शाता है। कमजोरियाँ तब उत्पन्न होती हैं जब सर्वर एक ही अनुरोध को विभिन्न तरीकों से प्रोसेस करते हैं, जिससे अप्रत्याशित और संभावित रूप से दुर्भावनापूर्ण परिणाम होते हैं।
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]
> [!TIP]
> पिछले तालिका में आपको TE.0 तकनीक जोड़नी चाहिए, जैसे CL.0 तकनीक लेकिन Transfer Encoding का उपयोग करते हुए।
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
@ -79,7 +79,7 @@ Foo: x
- **बैक-एंड (CL):** `Content-Length` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
- **हमला परिदृश्य:**
- हमलावर एक टुकड़ा अनुरोध भेजता है जहाँ टुकड़े का आकार (`7b`) और वास्तविक सामग्री की लंबाई (`Content-Length: 4`) मेल नहीं खाती।
- हमलावर एक टुकड़ा अनुरोध भेजता है जहाँ टुकड़े का आकार (`7b`) और वास्तविक सामग्री की लंबाई (`Content-Length: 4`) मेल नहीं खाते।
- फ्रंट-एंड सर्वर, `Transfer-Encoding` का सम्मान करते हुए, पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
- बैक-एंड सर्वर, `Content-Length` का सम्मान करते हुए, केवल अनुरोध के प्रारंभिक भाग (`7b` बाइट्स) को प्रोसेस करता है, शेष को एक अनपेक्षित अगला अनुरोध के भाग के रूप में छोड़ देता है।
- **उदाहरण:**
@ -104,12 +104,12 @@ x=
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
- **सर्वर:** दोनों `Transfer-Encoding` का समर्थन करते हैं, लेकिन एक को धोखे के माध्यम से अनदेखा करने के लिए धोखा दिया जा सकता है।
- **सर्वर:** दोनों `Transfer-Encoding` का समर्थन करते हैं, लेकिन एक को धोखे में रखा जा सकता है कि वह इसे अनदेखा कर दे।
- **हमला परिदृश्य:**
- हमलावर एक अनुरोध भेजता है जिसमें धोखे के `Transfer-Encoding` हेडर होते हैं।
- जिस सर्वर (फ्रंट-एंड या बैक-एंड) को धोखे को पहचानने में विफलता होती है, उस पर CL.TE या TE.CL कमजोरी का लाभ उठाया जा सकता है।
- अनुरोध का अप्रसंस्कृत भाग, जैसा कि एक सर्वर द्वारा देखा जाता है, एक अगला अनुरोध का भाग बन जाता है, जिससे स्मगलिंग होती है।
- हमलावर एक अनुरोध भेजता है जिसमें धोखे में `Transfer-Encoding` हेडर होते हैं।
- जिस सर्वर (फ्रंट-एंड या बैक-एंड) को धोखे को पहचानने में विफलता होती है, वहाँ CL.TE या TE.CL कमजोरी का लाभ उठाया जा सकता है।
- अनुरोध का अनप्रोसेस्ड भाग, जैसा कि एक सर्वर द्वारा देखा जाता है, एक अगला अनुरोध बन जाता है, जिससे स्मगलिंग होती है।
- **उदाहरण:**
```
@ -132,7 +132,7 @@ Transfer-Encoding
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
- दोनों सर्वर केवल `Content-Length` हेडर के आधार पर अनुरोध को प्रोसेस करते हैं।
- यह परिदृश्य आमतौर पर स्मगलिंग की ओर नहीं ले जाता है, क्योंकि दोनों सर्वर अनुरोध की लंबाई की व्याख्या में संरेखित होते हैं।
- यह परिदृश्य आमतौर पर स्मगलिंग की ओर नहीं ले जाता है, क्योंकि दोनों सर्वरों के बीच अनुरोध की लंबाई की व्याख्या में संरेखण होता है।
- **उदाहरण:**
```
@ -185,7 +185,7 @@ EMPTY_LINE_HERE
यह तकनीक उन परिदृश्यों में भी उपयोगी है जहाँ **प्रारंभिक HTTP डेटा पढ़ते समय एक वेब सर्वर को तोड़ना संभव है** लेकिन **कनेक्शन को बंद किए बिना**। इस तरह, HTTP अनुरोध का **शरीर** **अगले HTTP अनुरोध** के रूप में माना जाएगा।
उदाहरण के लिए, जैसा कि [**इस लेख**](https://mizu.re/post/twisty-python) में समझाया गया है, Werkzeug में कुछ **Unicode** वर्ण भेजना संभव था और इससे सर्वर **टूट** जाएगा। हालाँकि, यदि HTTP कनेक्शन **`Connection: keep-alive`** हेडर के साथ बनाया गया था, तो अनुरोध का शरीर नहीं पढ़ा जाएगा और कनेक्शन अभी भी खुला रहेगा, इसलिए अनुरोध का **शरीर** **अगले HTTP अनुरोध** के रूप में माना जाएगा।
उदाहरण के लिए, जैसा कि [**इस लेख**](https://mizu.re/post/twisty-python) में समझाया गया है, Werkzeug में कुछ **Unicode** वर्ण भेजना संभव था और इससे सर्वर **टूट** जाएगा। हालाँकि, यदि HTTP कनेक्शन को **`Connection: keep-alive`** हेडर के साथ बनाया गया था, तो अनुरोध का शरीर नहीं पढ़ा जाएगा और कनेक्शन अभी भी खुला रहेगा, इसलिए अनुरोध का **शरीर** **अगले HTTP अनुरोध** के रूप में माना जाएगा।
#### हॉप-बाय-हॉप हेडर के माध्यम से मजबूर करना
@ -199,16 +199,16 @@ For **more information about hop-by-hop headers** visit:
../abusing-hop-by-hop-headers.md
{{#endref}}
## Finding HTTP Request Smuggling
## HTTP Request Smuggling ढूंढना
HTTP request smuggling कमजोरियों की पहचान अक्सर समय तकनीकों का उपयोग करके की जा सकती है, जो यह देखने पर निर्भर करती हैं कि सर्वर को हेरफेर किए गए अनुरोधों का जवाब देने में कितना समय लगता है। ये तकनीकें CL.TE और TE.CL कमजोरियों का पता लगाने के लिए विशेष रूप से उपयोगी हैं। इन तरीकों के अलावा, ऐसी कमजोरियों को खोजने के लिए अन्य रणनीतियाँ और उपकरण भी हैं:
### Finding CL.TE Vulnerabilities Using Timing Techniques
### समय तकनीकों का उपयोग करके CL.TE कमजोरियों को ढूंढना
- **Method:**
- **विधि:**
- एक अनुरोध भेजें जो, यदि एप्लिकेशन कमजोर है, तो बैक-एंड सर्वर को अतिरिक्त डेटा की प्रतीक्षा करने के लिए मजबूर करेगा।
- **Example:**
- **उदाहरण:**
```
POST / HTTP/1.1
@ -222,20 +222,20 @@ A
0
```
- **Observation:**
- **अवलोकन:**
- फ्रंट-एंड सर्वर `Content-Length` के आधार पर अनुरोध को संसाधित करता है और संदेश को समय से पहले काट देता है।
- बैक-एंड सर्वर, जो एक चंक्ड संदेश की अपेक्षा करता है, अगले चंक की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
- **Indicators:**
- **संकेत:**
- प्रतिक्रिया में टाइमआउट या लंबी देरी।
- बैक-एंड सर्वर से 400 Bad Request त्रुटि प्राप्त करना, कभी-कभी विस्तृत सर्वर जानकारी के साथ।
### Finding TE.CL Vulnerabilities Using Timing Techniques
### समय तकनीकों का उपयोग करके TE.CL कमजोरियों को ढूंढना
- **Method:**
- **विधि:**
- एक अनुरोध भेजें जो, यदि एप्लिकेशन कमजोर है, तो बैक-एंड सर्वर को अतिरिक्त डेटा की प्रतीक्षा करने के लिए मजबूर करेगा।
- **Example:**
- **उदाहरण:**
```
POST / HTTP/1.1
@ -248,44 +248,150 @@ Content-Length: 6
X
```
- **Observation:**
- फ्रंट-एंड सर्वर `Transfer-Encoding` के आधार पर अनुरोध को संसाधित करता है और पूरे संदेश को आगे बढ़ाता है।
- **अवलोकन:**
- फ्रंट-एंड सर्वर `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 वैरिएंस परीक्षण:**
- ऐसे अनुरोध भेजें जिनमें भिन्न `Content-Length` मान हों जो वास्तविक सामग्री की लंबाई के साथ मेल नहीं खाते और देखें कि सर्वर ऐसे असंगतियों को कैसे संभालता है।
- **Transfer-Encoding Variance Tests:**
- **Transfer-Encoding वैरिएंस परीक्षण:**
- अस्पष्ट या गलत `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:** यदि आपका हमला अनजाने में किसी अन्य उपयोगकर्ता के अनुरोध (जो "सामान्य" अनुरोध नहीं है जिसे आपने पहचान के लिए भेजा था) को प्रभावित करता है, तो यह इंगित करता है कि आपका हमला किसी अन्य एप्लिकेशन उपयोगकर्ता को प्रभावित करता है। निरंतर परीक्षण अन्य उपयोगकर्ताओं को बाधित कर सकता है, जिससे एक सतर्क दृष्टिकोण की आवश्यकता होती है।
- **विशिष्ट नेटवर्क कनेक्शन:** "हमला" और "सामान्य" अनुरोधों को अलग-अलग नेटवर्क कनेक्शनों के माध्यम से भेजा जाना चाहिए। दोनों के लिए एक ही कनेक्शन का उपयोग करना कमजोरियों की उपस्थिति को मान्य नहीं करता है।
- **संगत URL और पैरामीटर:** दोनों अनुरोधों के लिए समान URLs और पैरामीटर नामों का उपयोग करने का प्रयास करें। आधुनिक एप्लिकेशन अक्सर URL और पैरामीटर के आधार पर अनुरोधों को विशिष्ट बैक-एंड सर्वरों पर रूट करते हैं। इनका मेल खाना यह सुनिश्चित करता है कि दोनों अनुरोधों को एक ही सर्वर द्वारा संसाधित किया जाए, जो सफल हमले के लिए एक पूर्वापेक्षा है।
- **समय और रेसिंग स्थितियाँ:** "सामान्य" अनुरोध, जो "हमला" अनुरोध से हस्तक्षेप का पता लगाने के लिए है, अन्य समवर्ती एप्लिकेशन अनुरोधों के खिलाफ प्रतिस्पर्धा करता है। इसलिए, "हमला" अनुरोध के तुरंत बाद "सामान्य" अनुरोध भेजें। व्यस्त एप्लिकेशन में कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है।
- **लोड बैलेंसिंग चुनौतियाँ:** फ्रंट-एंड सर्वर जो लोड बैलेंसर के रूप में कार्य करते हैं, अनुरोधों को विभिन्न बैक-एंड सिस्टमों में वितरित कर सकते हैं। यदि "हमला" और "सामान्य" अनुरोध अलग-अलग सिस्टम पर पहुँचते हैं, तो हमला सफल नहीं होगा। यह लोड बैलेंसिंग पहलू कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता कर सकता है।
- **अनजाने में उपयोगकर्ता प्रभाव:** यदि आपका हमला अनजाने में किसी अन्य उपयोगकर्ता के अनुरोध (जो "सामान्य" अनुरोध नहीं है जिसे आपने पहचान के लिए भेजा था) को प्रभावित करता है, तो यह संकेत करता है कि आपका हमला किसी अन्य एप्लिकेशन उपयोगकर्ता को प्रभावित करता है। निरंतर परीक्षण अन्य उपयोगकर्ताओं को बाधित कर सकता है, इसलिए एक सतर्क दृष्टिकोण की आवश्यकता होती है।
## Abusing HTTP Request Smuggling
## HTTP/1.1 पाइपलाइनिंग कलाकृतियों और वास्तविक अनुरोध स्मगलिंग के बीच अंतर
### Circumventing Front-End Security via HTTP Request Smuggling
कनेक्शन पुन: उपयोग (कीप-एलाइव) और पाइपलाइनिंग परीक्षण उपकरणों में "स्मगलिंग" का भ्रम पैदा कर सकते हैं जो एक ही सॉकेट पर कई अनुरोध भेजते हैं। हानिरहित क्लाइंट-साइड कलाकृतियों को वास्तविक सर्वर-साइड डीसिंक से अलग करना सीखें।
कभी-कभी, फ्रंट-एंड प्रॉक्सी सुरक्षा उपाय लागू करते हैं, आने वाले अनुरोधों की जांच करते हैं। हालाँकि, इन उपायों को HTTP Request Smuggling का उपयोग करके दरकिनार किया जा सकता है, जिससे प्रतिबंधित एंडपॉइंट्स तक अनधिकृत पहुँच प्राप्त होती है। उदाहरण के लिए, `/admin` तक पहुँच बाहरी रूप से प्रतिबंधित हो सकती है, फ्रंट-एंड प्रॉक्सी सक्रिय रूप से ऐसे प्रयासों को रोकती है। फिर भी, यह प्रॉक्सी एक स्मगल्ड HTTP अनुरोध के भीतर एम्बेडेड अनुरोधों की जांच करने में विफल हो सकती है, जिससे इन प्रतिबंधों को दरकिनार करने के लिए एक छिद्र खुलता है।
### क्यों पाइपलाइनिंग क्लासिक झूठे सकारात्मक बनाती है
HTTP Request Smuggling का उपयोग करके फ्रंट-एंड सुरक्षा नियंत्रणों को दरकिनार करने के तरीके को दर्शाने वाले निम्नलिखित उदाहरणों पर विचार करें, विशेष रूप से `/admin` पथ को लक्षित करते हुए जो आमतौर पर फ्रंट-एंड प्रॉक्सी द्वारा संरक्षित होता है:
HTTP/1.1 एकल TCP/TLS कनेक्शन का पुन: उपयोग करता है और एक ही स्ट्रीम पर अनुरोधों और प्रतिक्रियाओं को जोड़ता है। पाइपलाइनिंग में, क्लाइंट एक के बाद एक कई अनुरोध भेजता है और क्रम में प्रतिक्रियाओं पर निर्भर करता है। एक सामान्य झूठा सकारात्मक एक गलत CL.0-शैली का पेलोड एक ही कनेक्शन पर दो बार भेजना है:
```
POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
**CL.TE Example**
GET /robots.txt HTTP/1.1
X: Y
```
प्रतिक्रियाएँ इस तरह दिख सकती हैं:
```
HTTP/1.1 200 OK
Content-Type: text/html
```
```
HTTP/1.1 200 OK
Content-Type: text/plain
User-agent: *
Disallow: /settings
```
यदि सर्वर ने गलत `Content_Length` की अनदेखी की, तो कोई FE↔BE desync नहीं है। पुनः उपयोग के साथ, आपका क्लाइंट वास्तव में इस बाइट-स्ट्रीम को भेजता है, जिसे सर्वर ने दो स्वतंत्र अनुरोधों के रूप में पार्स किया:
```
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: कोई नहीं। आपने बस अपने क्लाइंट को सर्वर फ्रेमिंग से असंगत कर दिया।
> [!TIP]
> Burp मॉड्यूल जो पुन: उपयोग/पाइपलाइनिंग पर निर्भर करते हैं: Turbo Intruder के साथ `requestsPerConnection>1`, Intruder के साथ "HTTP/1 कनेक्शन पुन: उपयोग", Repeater "समूह को अनुक्रम में भेजें (एकल कनेक्शन)" या "कनेक्शन पुन: उपयोग सक्षम करें"।
### लिटमस परीक्षण: पाइपलाइनिंग या वास्तविक असंगति?
1. पुन: उपयोग बंद करें और फिर से परीक्षण करें
- Burp Intruder/Repeater में, HTTP/1 पुन: उपयोग बंद करें और "समूह को अनुक्रम में भेजें" से बचें।
- Turbo Intruder में, `requestsPerConnection=1` सेट करें और `pipeline=False` करें।
- यदि व्यवहार गायब हो जाता है, तो यह संभवतः क्लाइंट-साइड पाइपलाइनिंग थी, जब तक कि आप कनेक्शन-लॉक्ड/स्टेटफुल लक्ष्यों या क्लाइंट-साइड असंगति से न निपट रहे हों।
2. HTTP/2 नेस्टेड-रिस्पॉन्स जांच
- एक HTTP/2 अनुरोध भेजें। यदि प्रतिक्रिया शरीर में एक पूर्ण नेस्टेड HTTP/1 प्रतिक्रिया है, तो आपने एक बैकएंड पार्सिंग/असंगति बग साबित किया है, न कि एक शुद्ध क्लाइंट आर्टिफैक्ट।
3. कनेक्शन-लॉक्ड फ्रंट-एंड के लिए आंशिक-अनुरोध जांच
- कुछ FEs केवल तब ही अपस्ट्रीम BE कनेक्शन का पुन: उपयोग करते हैं जब क्लाइंट अपने कनेक्शन का पुन: उपयोग करता है। FE व्यवहार का पता लगाने के लिए आंशिक-अनुरोधों का उपयोग करें जो क्लाइंट पुन: उपयोग को दर्शाता है।
- कनेक्शन-लॉक्ड तकनीक के लिए PortSwigger "Browser‑Powered Desync Attacks" देखें।
4. स्टेट प्रॉब्स
- एक ही TCP कनेक्शन पर पहले और बाद के अनुरोधों के बीच के अंतर की तलाश करें (पहले-अनुरोध रूटिंग/मान्यता)।
- Burp "HTTP Request Smuggler" में एक कनेक्शन-स्टेट प्रॉब शामिल है जो इसे स्वचालित करता है।
5. वायर का दृश्य
- पुन: उपयोग और आंशिक अनुरोधों के साथ प्रयोग करते समय सीधे संयोजन और संदेश फ्रेमिंग का निरीक्षण करने के लिए Burp "HTTP Hacker" एक्सटेंशन का उपयोग करें।
### कनेक्शन-लॉक्ड अनुरोध स्मगलिंग (पुन: उपयोग आवश्यक)
कुछ फ्रंट-एंड केवल तब अपस्ट्रीम कनेक्शन का पुन: उपयोग करते हैं जब क्लाइंट अपने कनेक्शन का पुन: उपयोग करता है। वास्तविक स्मगलिंग मौजूद है लेकिन यह क्लाइंट-साइड पुन: उपयोग पर निर्भर है। प्रभाव को अलग करने और साबित करने के लिए:
- सर्वर-साइड बग साबित करें
- HTTP/2 नेस्टेड-रिस्पॉन्स जांच का उपयोग करें, या
- दिखाएं कि FE केवल तब अपस्ट्रीम का पुन: उपयोग करता है जब क्लाइंट करता है।
- वास्तविक प्रभाव दिखाएं भले ही प्रत्यक्ष क्रॉस-यूजर सॉकेट दुरुपयोग अवरुद्ध हो:
- कैश विषाक्तता: असंगति के माध्यम से साझा कैश को विषाक्त करें ताकि प्रतिक्रियाएँ अन्य उपयोगकर्ताओं को प्रभावित करें।
- आंतरिक हेडर प्रकटीकरण: FE-इंजेक्टेड हेडर (जैसे, auth/trust हेडर) को दर्शाएं और प्रमाणीकरण बायपास के लिए पिवट करें।
- FE नियंत्रणों को बायपास करें: फ्रंट-एंड के पार प्रतिबंधित पथ/विधियों को स्मगल करें।
- होस्ट-हेडर दुरुपयोग: आंतरिक vhosts पर पिवट करने के लिए होस्ट रूटिंग विचलनों के साथ संयोजन करें।
- ऑपरेटर कार्यप्रवाह
- नियंत्रित पुन: उपयोग के साथ पुन: उत्पन्न करें (Turbo Intruder `requestsPerConnection=2`, या Burp Repeater टैब समूह → "समूह को अनुक्रम में भेजें (एकल कनेक्शन)")।
- फिर कैश/हेडर-लीक/नियंत्रण-बायपास प्राइमिटिव्स से जोड़ें और क्रॉस-यूजर या प्रमाणीकरण प्रभाव प्रदर्शित करें।
> कनेक्शन-स्टेट हमलों को भी देखें, जो निकटता से संबंधित हैं लेकिन तकनीकी रूप से स्मगलिंग नहीं हैं:
>
>{{#ref}}
>../http-connection-request-smuggling.md
>{{#endref}}
### क्लाइंट-साइड असंगति प्रतिबंध
यदि आप ब्राउज़र-पावर्ड/क्लाइंट-साइड असंगति को लक्षित कर रहे हैं, तो दुर्भावनापूर्ण अनुरोध को क्रॉस-ओरिजिन द्वारा ब्राउज़र द्वारा भेजा जाना चाहिए। हेडर ओबफस्केशन ट्रिक्स काम नहीं करेंगी। नेविगेशन/फेच के माध्यम से पहुंच योग्य प्राइमिटिव्स पर ध्यान केंद्रित करें, और फिर कैश विषाक्तता, हेडर प्रकटीकरण, या फ्रंट-एंड नियंत्रण बायपास पर पिवट करें जहां डाउनस्ट्रीम घटक प्रतिक्रियाओं को दर्शाते या कैश करते हैं।
पृष्ठभूमि और एंड-टू-एंड कार्यप्रवाह के लिए:
{{#ref}}
-browser-http-request-smuggling.md
{{#endref}}
### निर्णय लेने में मदद करने के लिए उपकरण
- HTTP Hacker (Burp BApp Store): निम्न-स्तरीय HTTP व्यवहार और सॉकेट संयोजन को उजागर करता है।
- "स्मगलिंग या पाइपलाइनिंग?" Burp Repeater कस्टम क्रिया: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: `requestsPerConnection` के माध्यम से कनेक्शन पुन: उपयोग पर सटीक नियंत्रण।
- Burp HTTP Request Smuggler: पहले-अनुरोध रूटिंग/मान्यता को स्पॉट करने के लिए एक कनेक्शन-स्टेट प्रॉब शामिल है।
> [!NOTE]
> पुन: उपयोग-केवल प्रभावों को गैर-मुद्दों के रूप में मानें जब तक कि आप सर्वर-साइड असंगति साबित नहीं कर सकते और ठोस प्रभाव (विषाक्त कैश आर्टिफैक्ट, लीक किया गया आंतरिक हेडर जो विशेषाधिकार बायपास सक्षम करता है, बायपास किया गया FE नियंत्रण, आदि) संलग्न नहीं कर सकते।
## HTTP Request Smuggling का दुरुपयोग
### HTTP Request Smuggling के माध्यम से फ्रंट-एंड सुरक्षा को दरकिनार करना
कभी-कभी, फ्रंट-एंड प्रॉक्सी सुरक्षा उपायों को लागू करते हैं, आने वाले अनुरोधों की जांच करते हैं। हालाँकि, इन उपायों को HTTP Request Smuggling का लाभ उठाकर दरकिनार किया जा सकता है, जिससे प्रतिबंधित एंडपॉइंट्स तक अनधिकृत पहुंच मिलती है। उदाहरण के लिए, `/admin` तक पहुंच बाहरी रूप से प्रतिबंधित हो सकती है, फ्रंट-एंड प्रॉक्सी सक्रिय रूप से ऐसे प्रयासों को अवरुद्ध कर रही है। फिर भी, यह प्रॉक्सी एक स्मगल्ड HTTP अनुरोध के भीतर एम्बेडेड अनुरोधों की जांच करने में विफल हो सकती है, जिससे इन प्रतिबंधों को बायपास करने के लिए एक छिद्र छोड़ दिया जाता है।
HTTP Request Smuggling का उपयोग करके फ्रंट-एंड सुरक्षा नियंत्रणों को बायपास करने के तरीके को दर्शाने वाले निम्नलिखित उदाहरणों पर विचार करें, विशेष रूप से `/admin` पथ को लक्षित करते हुए जो आमतौर पर फ्रंट-एंड प्रॉक्सी द्वारा संरक्षित होता है:
**CL.TE उदाहरण**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
@ -320,7 +426,7 @@ a=x
0
```
इसके विपरीत, TE.CL हमले में, प्रारंभिक `POST` अनुरोध `Transfer-Encoding: chunked` का उपयोग करता है, और इसके बाद का अंतर्निहित अनुरोध `Content-Length` हेडर के आधार पर संसाधित किया जाता है। CL.TE हमले के समान, फ्रंट-एंड प्रॉक्सी स्मगल्ड `GET /admin` अनुरोध को नजरअंदाज कर देती है, अनजाने में प्रतिबंधित `/admin` पथ तक पहुंच प्रदान करती है।
इसके विपरीत, 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>
@ -343,19 +449,19 @@ Content-Length: 100
search=
```
इस संरचना में, बाद के अनुरोध घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परामर्शित पैरामीटर है। यह परावर्तन बाद के अनुरोध के हेडर को उजागर करेगा।
इस संरचना में, बाद के अनुरोध घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परामर्शित किया गया पैरामीटर है। यह परावर्तन बाद के अनुरोध के हेडर को उजागर करेगा।
यह महत्वपूर्ण है कि नेस्टेड अनुरोध के `Content-Length` हेडर को वास्तविक सामग्री की लंबाई के साथ संरेखित किया जाए। एक छोटे मान से शुरू करना और धीरे-धीरे बढ़ाना सलाहकार है, क्योंकि बहुत कम मान परावर्तित डेटा को काट देगा, जबकि बहुत उच्च मान अनुरोध को त्रुटि में डाल सकता है।
यह तकनीक TE.CL भेद्यता के संदर्भ में भी लागू होती है, लेकिन अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। नई लाइन के वर्णों की परवाह किए बिना, मान खोज पैरामीटर में जोड़े जाएंगे।
यह विधि मुख्य रूप से फ्रंट-एंड प्रॉक्सी द्वारा किए गए अनुरोध संशोधनों को समझने के लिए है, मूल रूप से एक आत्म-निर्देशित जांच करते हुए।
यह विधि मुख्य रूप से फ्रंट-एंड प्रॉक्सी द्वारा किए गए अनुरोध संशोधनों को समझने के लिए है, जो मूल रूप से एक आत्म-निर्देशित जांच कर रही है।
### अन्य उपयोगकर्ताओं के अनुरोधों को कैप्चर करना <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
यह संभव है कि अगले उपयोगकर्ता के अनुरोधों को एक विशेष अनुरोध को POST ऑपरेशन के दौरान एक पैरामीटर के मान के रूप में जोड़कर कैप्चर किया जाए। इसे कैसे किया जा सकता है, यहाँ है:
यह संभव है कि अगले उपयोगकर्ता के अनुरोधों को कैप्चर किया जाए, एक POST ऑपरेशन के दौरान एक पैरामीटर के मान के रूप में एक विशिष्ट अनुरोध को जोड़कर। इसे कैसे किया जा सकता है, यहाँ है:
निम्नलिखित अनुरोध को एक पैरामीटर के मान के रूप में जोड़कर, आप अगले ग्राहक के अनुरोध को स्टोर कर सकते हैं:
निम्नलिखित अनुरोध को एक पैरामीटर के मान के रूप में जोड़कर, आप अगले क्लाइंट के अनुरोध को स्टोर कर सकते हैं:
```
POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -377,9 +483,9 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
```
इस परिदृश्य में, **comment parameter** का उद्देश्य एक सार्वजनिक रूप से सुलभ पृष्ठ पर एक पोस्ट की टिप्पणी अनुभाग में सामग्री को संग्रहीत करना है। परिणामस्वरूप, अगले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।
हालांकि, इस तकनीक की सीमाएँ हैं। सामान्यतः, यह केवल उस पैरामीटर डेलिमिटर तक डेटा कैप्चर करता है जो स्मगल किए गए अनुरोध में उपयोग किया गया है। URL-encoded फॉर्म सबमिशन के लिए, यह डेलिमिटर `&` अक्षर है। इसका मतलब है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले `&` पर रुक जाएगी, जो कि क्वेरी स्ट्रिंग का हिस्सा भी हो सकती है।
हालांकि, इस तकनीक की सीमाएँ हैं। सामान्यतः, यह केवल उस पैरामीटर डेलिमिटर तक डेटा कैप्चर करता है जो स्मगल्ड अनुरोध में उपयोग किया जाता है। URL-encoded फॉर्म सबमिशन के लिए, यह डेलिमिटर `&` वर्ण है। इसका मतलब है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले `&` पर रुक जाएगी, जो कि क्वेरी स्ट्रिंग का हिस्सा भी हो सकती है।
इसके अतिरिक्त, यह ध्यान देने योग्य है कि यह दृष्टिकोण TE.CL भेद्यता के साथ भी व्यवहार्य है। ऐसे मामलों में, अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। नई लाइन अक्षरों की परवाह किए बिना, मानों को खोज पैरामीटर में जोड़ा जाएगा।
इसके अतिरिक्त, यह ध्यान देने योग्य है कि यह दृष्टिकोण TE.CL भेद्यता के साथ भी व्यवहार्य है। ऐसे मामलों में, अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। नई लाइन वर्णों की परवाह किए बिना, मानों को खोज पैरामीटर में जोड़ा जाएगा।
### HTTP अनुरोध स्मगलिंग का उपयोग करके परावर्तित XSS का शोषण करना
@ -420,15 +526,15 @@ A=
#### HTTP/0.9
> [!CAUTION]
> यदि उपयोगकर्ता की सामग्री एक **`Content-type`** के साथ प्रतिक्रिया में परिलक्षित होती है जैसे कि **`text/plain`**, तो XSS के निष्पादन को रोकता है। यदि सर्वर **HTTP/0.9 का समर्थन करता है तो इसे बायपास करना संभव हो सकता है**!
> यदि उपयोगकर्ता की सामग्री एक **`Content-type`** के साथ प्रतिक्रिया में परिलक्षित होती है जैसे कि **`text/plain`**, तो XSS के निष्पादन को रोकता है। यदि सर्वर **HTTP/0.9** का समर्थन करता है तो इसे बायपास करना संभव हो सकता है!
संस्करण HTTP/0.9 पहले 1.0 से था और केवल **GET** क्रियाओं का उपयोग करता है और **हेडर** के साथ प्रतिक्रिया नहीं करता है, केवल शरीर के साथ।
संस्करण HTTP/0.9 पहले 1.0 से था और केवल **GET** क्रियाओं का उपयोग करता है और **हेडर** के साथ प्रतिक्रिया नहीं करता, केवल शरीर के साथ।
[**इस लेख**](https://mizu.re/post/twisty-python) में, इसका दुरुपयोग एक अनुरोध स्मगलिंग और एक **कमजोर एंडपॉइंट के साथ किया गया जो उपयोगकर्ता के इनपुट के साथ प्रतिक्रिया देगा** ताकि HTTP/0.9 के साथ एक अनुरोध को स्मगल किया जा सके। प्रतिक्रिया में परिलक्षित होने वाला पैरामीटर एक **नकली HTTP/1.1 प्रतिक्रिया (हेडर और शरीर के साथ)** था ताकि प्रतिक्रिया में एक वैध निष्पादन योग्य JS कोड हो जिसमें `Content-Type` `text/html` हो।
[**इस लेख**](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>
### HTTP अनुरोध स्मगलिंग के साथ ऑन-साइट रीडायरेक्ट्स का लाभ उठाना <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
ऐप्लिकेशन अक्सर एक URL से दूसरे URL पर रीडायरेक्ट करते हैं, रीडायरेक्ट URL में `Host` हेडर से होस्टनेम का उपयोग करके। यह Apache और IIS जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर रीडायरेक्ट होता है ताकि स्लैश शामिल किया जा सके:
ऐप्लिकेशन अक्सर `Host` हेडर से होस्टनाम का उपयोग करके एक URL से दूसरे URL पर रीडायरेक्ट करते हैं। यह Apache और IIS जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर रीडायरेक्ट होता है ताकि स्लैश शामिल किया जा सके:
```
GET /home HTTP/1.1
Host: normal-website.com
@ -464,17 +570,17 @@ Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
इस परिदृश्य में, एक उपयोगकर्ता की JavaScript फ़ाइल के लिए अनुरोध को हाईजैक किया जाता है। हमलावर संभावित रूप से उपयोगकर्ता को दुर्भावनापूर्ण JavaScript को प्रतिक्रिया में सर्व करके समझौता कर सकता है।
इस परिदृश्य में, एक उपयोगकर्ता की 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 को निष्पादित किया जा सकता है यदि **फ्रंट-एंड इन्फ्रास्ट्रक्चर के किसी भी घटक ने सामग्री को कैश किया है**, आमतौर पर प्रदर्शन को बढ़ाने के लिए। सर्वर की प्रतिक्रिया को हेरफेर करके, **कैश को ज़हरीला** बनाना संभव है।
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) का कारण बन सकता है।
पहले, हमने देखा कि सर्वर की प्रतिक्रियाओं को 404 त्रुटि लौटाने के लिए कैसे बदला जा सकता है (देखें [Basic Examples](#basic-examples))। इसी तरह, सर्वर को `/static/include.js` के लिए अनुरोध के जवाब में `/index.html` सामग्री प्रदान करने के लिए धोखा देना संभव है। परिणामस्वरूप, `/static/include.js` की सामग्री को कैश में `/index.html` की सामग्री से बदल दिया जाता है, जिससे `/static/include.js` उपयोगकर्ताओं के लिए अनुपलब्ध हो जाता है, जो संभावित रूप से Denial of Service (DoS) का कारण बन सकता है।
यह तकनीक विशेष रूप से शक्तिशाली हो जाती है यदि **Open Redirect भेद्यता** का पता लगाया जाता है या यदि **एक ओपन रीडायरेक्ट के लिए ऑन-साइट रीडायरेक्ट** होता है। ऐसी भेद्यताओं का उपयोग `/static/include.js` की कैश की गई सामग्री को हमलावर के नियंत्रण में एक स्क्रिप्ट के साथ बदलने के लिए किया जा सकता है, जिससे सभी क्लाइंट्स के खिलाफ एक व्यापक Cross-Site Scripting (XSS) हमले की अनुमति मिलती है जो अपडेटेड `/static/include.js` का अनुरोध कर रहे हैं।
यह तकनीक विशेष रूप से प्रभावी हो जाती है यदि **Open Redirect भेद्यता** का पता लगाया जाता है या यदि **एक ओपन रीडायरेक्ट के लिए ऑन-साइट रीडायरेक्ट** होता है। ऐसी भेद्यताओं का उपयोग करके `/static/include.js` की कैश की गई सामग्री को हमलावर के नियंत्रण में एक स्क्रिप्ट के साथ बदलने के लिए शोषण किया जा सकता है, जिससे सभी क्लाइंट्स के खिलाफ एक व्यापक Cross-Site Scripting (XSS) हमले की अनुमति मिलती है जो अपडेटेड `/static/include.js` का अनुरोध करते हैं।
नीचे **कैश ज़हरीला बनाने और ओपन रीडायरेक्ट के लिए ऑन-साइट रीडायरेक्ट** के संयोजन के शोषण का एक चित्रण है। उद्देश्य है `/static/include.js` की कैश सामग्री को हमलावर द्वारा नियंत्रित JavaScript कोड सर्व करने के लिए बदलना:
नीचे **कैश ज़हर देने के साथ-साथ ओपन रीडायरेक्ट के लिए ऑन-साइट रीडायरेक्ट** के शोषण का एक चित्रण है। उद्देश्य है `/static/include.js` की कैश सामग्री को हमलावर द्वारा नियंत्रित JavaScript कोड प्रदान करने के लिए बदलना:
```
POST / HTTP/1.1
Host: vulnerable.net
@ -492,9 +598,9 @@ Content-Length: 10
x=1
```
ध्यान दें कि एम्बेडेड अनुरोध `/post/next?postId=3` को लक्षित कर रहा है। यह अनुरोध `/post?postId=4` पर पुनर्निर्देशित किया जाएगा, **Host header value** का उपयोग करके डोमेन निर्धारित किया जाएगा। **Host header** को बदलकर, हमलावर अनुरोध को अपने डोमेन पर पुनर्निर्देशित कर सकता है (**on-site redirect to open redirect**)।
नोट करें कि एम्बेडेड अनुरोध `/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** अनुरोध द्वारा संदूषित होगा और हमलावर द्वारा नियंत्रित स्क्रिप्ट की सामग्री लाएगा।
सफल **socket poisoning** के बाद, `/static/include.js` के लिए एक **GET request** शुरू की जानी चाहिए। यह अनुरोध पूर्व के **on-site redirect to open redirect** अनुरोध द्वारा दूषित किया जाएगा और हमलावर द्वारा नियंत्रित स्क्रिप्ट की सामग्री लाएगा।
इसके बाद, `/static/include.js` के लिए कोई भी अनुरोध हमलावर की स्क्रिप्ट की कैश की गई सामग्री को प्रदान करेगा, प्रभावी रूप से एक व्यापक XSS हमले को लॉन्च करेगा।
@ -516,11 +622,11 @@ x=1
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
यदि यह स्मगल्ड अनुरोध स्थिर सामग्री के लिए अभिप्रेत कैश प्रविष्टि को विषाक्त करता है (जैसे, `/someimage.png`), तो पीड़ित का संवेदनशील डेटा `/private/messages` से स्थिर सामग्री के कैश प्रविष्टि के तहत कैश किया जा सकता है। परिणामस्वरूप, हमलावर संभावित रूप से इन कैश किए गए संवेदनशील डेटा को पुनः प्राप्त कर सकता है।
यदि यह स्मगल्ड अनुरोध स्थिर सामग्री (जैसे, `/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>
### HTTP Request Smuggling के माध्यम से 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 अनुरोध स्मगलिंग के साथ दुरुपयोग करना संभव हो सकता है। इसका कारण यह है कि यह विधि सर्वर को भेजे गए किसी भी हेडर को प्रतिक्रिया के शरीर के भाग के रूप में परावर्तित करेगी। उदाहरण के लिए:
[**इस पोस्ट में**](https://portswigger.net/research/trace-desync-attack) सुझाव दिया गया है कि यदि सर्वर में TRACE विधि सक्षम है, तो इसे HTTP Request Smuggling के साथ दुरुपयोग करना संभव हो सकता है। इसका कारण यह है कि यह विधि सर्वर को भेजे गए किसी भी हेडर को प्रतिक्रिया के शरीर के भाग के रूप में परावर्तित करेगी। उदाहरण के लिए:
```
TRACE / HTTP/1.1
Host: example.com
@ -537,15 +643,15 @@ 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 कोड इंजेक्ट करने के लिए उपयोग किया जा सकता है**।
एक उदाहरण कि इस व्यवहार का कैसे दुरुपयोग किया जा सकता है, वह है **पहले एक 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 अनुरोध की प्रतिक्रिया द्वारा बनाई गई है।
[**इस पोस्ट**](https://portswigger.net/research/trace-desync-attack) का पालन करना TRACE विधि के दुरुपयोग का एक और तरीका सुझाता है। जैसा कि टिप्पणी की गई है, एक HEAD अनुरोध और एक TRACE अनुरोध को स्मगल करके, HEAD अनुरोध की प्रतिक्रिया में **कुछ दर्शाए गए डेटा को नियंत्रित करना संभव है**। HEAD अनुरोध के शरीर की लंबाई मूल रूप से Content-Length हेडर में संकेतित होती है और यह TRACE अनुरोध की प्रतिक्रिया द्वारा बनाई जाती है।
इसलिए, नया विचार यह होगा कि, इस Content-Length और TRACE प्रतिक्रिया में दिए गए डेटा को जानते हुए, TRACE प्रतिक्रिया को Content-Length के अंतिम बाइट के बाद एक मान्य HTTP प्रतिक्रिया शामिल करने के लिए बनाया जा सकता है, जिससे एक हमलावर को अगले प्रतिक्रिया के अनुरोध को पूरी तरह से नियंत्रित करने की अनुमति मिलती है (जिसका उपयोग कैश विषाक्तता करने के लिए किया जा सकता है)।
इसलिए, नया विचार यह होगा कि, इस Content-Length और TRACE प्रतिक्रिया में दिए गए डेटा को जानकर, TRACE प्रतिक्रिया को Content-Length के अंतिम बाइट के बाद एक मान्य HTTP प्रतिक्रिया शामिल करने की अनुमति दी जा सकती है, जिससे एक हमलावर को अगले प्रतिक्रिया के अनुरोध को पूरी तरह से नियंत्रित करने की अनुमति मिलती है (जिसका उपयोग कैश विषाक्तता करने के लिए किया जा सकता है)।
उदाहरण:
```
@ -698,6 +804,8 @@ table.add(req)
```
## Tools
- HTTP Hacker (Burp BApp Store) – संयोजन/फ्रेमिंग और निम्न-स्तरीय HTTP व्यवहार को दृश्य बनाना
- 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/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)
@ -716,6 +824,10 @@ table.add(req)
- [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/)
- झूठे झूठे सकारात्मक से सावधान रहें: HTTP पाइपलाइनिंग और अनुरोध स्मगलिंग के बीच अंतर कैसे करें – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
- [https://http1mustdie.com/](https://http1mustdie.com/)
- ब्राउज़र-शक्ति वाले डीसिंक हमले – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- PortSwigger Academy – क्लाइंट-साइड डीसिंक – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
{{#include ../../banners/hacktricks-training.md}}

20
src/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md
View File

@ -1,7 +1,23 @@
# ब्राउज़र HTTP अनुरोध स्मगलिंग
# Browser HTTP Request Smuggling
{{#include ../../banners/hacktricks-training.md}}
**पोस्ट की जांच करें [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
Browser-powered desync (या client-side request smuggling) पीड़ित के ब्राउज़र का दुरुपयोग करता है ताकि एक गलत-फ्रेम वाला अनुरोध एक साझा कनेक्शन पर एंकीट किया जा सके, ताकि बाद के अनुरोधों को एक डाउनस्ट्रीम घटक द्वारा असंगत रूप से पार्स किया जा सके। क्लासिक FE↔BE smuggling के विपरीत, पेलोड्स उस परिधि द्वारा सीमित होते हैं जो एक ब्राउज़र कानूनी रूप से क्रॉस-ओरिजिन भेज सकता है।
मुख्य सीमाएँ और सुझाव
- केवल उन हेडर और सिंटैक्स का उपयोग करें जो एक ब्राउज़र नेविगेशन, फेच, या फॉर्म सबमिशन के माध्यम से उत्पन्न कर सकता है। हेडर ओबफस्केशन्स (LWS ट्रिक्स, डुप्लिकेट TE, अवैध CL) सामान्यतः नहीं भेजे जाएंगे।
- उन अंत बिंदुओं और मध्यवर्ती को लक्षित करें जो इनपुट को दर्शाते हैं या प्रतिक्रियाओं को कैश करते हैं। उपयोगी प्रभावों में कैश पॉइज़निंग, फ्रंट-एंड इंजेक्टेड हेडर का लीक होना, या फ्रंट-एंड पथ/विधि नियंत्रणों को बायपास करना शामिल है।
- पुन: उपयोग महत्वपूर्ण है: तैयार किए गए अनुरोध को इस तरह से संरेखित करें कि यह एक उच्च-मूल्य वाले पीड़ित अनुरोध के समान HTTP/1.1 या H2 कनेक्शन को साझा करे। कनेक्शन-लॉक्ड/स्टेटफुल व्यवहार प्रभाव को बढ़ाते हैं।
- उन प्राइमिटिव्स को प्राथमिकता दें जिन्हें कस्टम हेडर की आवश्यकता नहीं होती: पथ भ्रम, क्वेरी-स्ट्रिंग इंजेक्शन, और फॉर्म-कोडेड POST के माध्यम से बॉडी शेपिंग।
- वास्तविक सर्वर-साइड डीसिंक की पुष्टि करें बनाम केवल पाइपलाइनिंग आर्टिफैक्ट्स द्वारा पुन: परीक्षण करके, या HTTP/2 नेस्टेड-रिस्पॉन्स चेक का उपयोग करके।
अंत-से-अंत तकनीकों और PoCs के लिए देखें:
- PortSwigger Research – 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
## References
- [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
- पाइपलाइनिंग बनाम स्मगलिंग का अंतर (पुन: उपयोग झूठे सकारात्मक पर पृष्ठभूमि): https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
{{#include ../../banners/hacktricks-training.md}}