Translated ['src/pentesting-web/http-request-smuggling/README.md'] to hi

2025-10-10 18:36:50 +00:00 · 2025-08-20 19:28:56 +00:00 · 2025-08-20 19:28:56 +00:00 · 7cdf212a1d
commit 7cdf212a1d
parent e9b4177fa3
1 changed files with 59 additions and 59 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -4,7 +4,7 @@

 ## What is

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

 ### Theory
@ -24,15 +24,15 @@

 ### 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
@ -40,7 +40,7 @@
 > [!TIP]
 > जब 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

@ -79,7 +79,7 @@ Foo: x
 - **बैक-एंड (CL):** `Content-Length` हेडर के आधार पर अनुरोध को प्रोसेस करता है।
 - **हमला परिदृश्य:**

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

 - हमलावर एक अनुरोध भेजता है जिसमें धोखे में `Transfer-Encoding` हेडर होते हैं।
- जिस सर्वर (फ्रंट-एंड या बैक-एंड) को धोखे को पहचानने में विफलता होती है, वहाँ CL.TE या TE.CL कमजोरी का लाभ उठाया जा सकता है।
- अनुरोध का अनप्रोसेस्ड भाग, जैसा कि एक सर्वर द्वारा देखा जाता है, एक अगला अनुरोध बन जाता है, जिससे स्मगलिंग होती है।
+- जिस सर्वर (फ्रंट-एंड या बैक-एंड) को धोखे को पहचानने में विफलता होती है, वहाँ 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` हेडर के आधार पर अनुरोध को प्रोसेस करते हैं।
- यह परिदृश्य आमतौर पर स्मगलिंग की ओर नहीं ले जाता है, क्योंकि दोनों सर्वरों के बीच अनुरोध की लंबाई की व्याख्या में संरेखण होता है।
+- यह परिदृश्य आमतौर पर स्मगलिंग की ओर नहीं ले जाता है, क्योंकि दोनों सर्वर अनुरोध की लंबाई को व्याख्यायित करने में संरेखित होते हैं।
 - **उदाहरण:**

 ```
@ -147,7 +147,7 @@ Normal Request
 #### **CL.0 Scenario**

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

 ```
@ -187,9 +187,9 @@ EMPTY_LINE_HERE

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

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

-हॉप-बाय-हॉप हेडर का दुरुपयोग करते हुए आप प्रॉक्सी को **हेडर Content-Length या Transfer-Encoding को हटाने के लिए संकेत दे सकते हैं ताकि HTTP अनुरोध स्मगलिंग का दुरुपयोग संभव हो सके**।
+हॉप-बाय-हॉप हेडर्स का दुरुपयोग करते हुए आप प्रॉक्सी को **हेडर Content-Length या Transfer-Encoding को हटाने के लिए संकेत दे सकते हैं ताकि HTTP अनुरोध स्मगलिंग का दुरुपयोग संभव हो सके**।
 ```
 Connection: Content-Length
 ```
@ -252,14 +252,14 @@ X
 - फ्रंट-एंड सर्वर `Transfer-Encoding` के आधार पर अनुरोध को संसाधित करता है और पूरे संदेश को अग्रेषित करता है।
 - बैक-एंड सर्वर, जो `Content-Length` के आधार पर एक संदेश की अपेक्षा करता है, अतिरिक्त डेटा की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।

-### कमजोरियों को खोजने के अन्य तरीके
+### कमजोरियों को खोजने के लिए अन्य तरीके

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

@ -271,19 +271,19 @@ X

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

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

-## HTTP/1.1 पाइपलाइनिंग कलाकृतियों और वास्तविक अनुरोध स्मगलिंग के बीच अंतर
+## HTTP/1.1 पाइपलाइनिंग आर्टिफैक्ट्स और असली अनुरोध स्मगलिंग के बीच अंतर

-कनेक्शन पुन: उपयोग (कीप-एलाइव) और पाइपलाइनिंग परीक्षण उपकरणों में "स्मगलिंग" का भ्रम पैदा कर सकते हैं जो एक ही सॉकेट पर कई अनुरोध भेजते हैं। हानिरहित क्लाइंट-साइड कलाकृतियों को वास्तविक सर्वर-साइड डीसिंक से अलग करना सीखें।
+कनेक्शन पुन: उपयोग (कीप-एलाइव) और पाइपलाइनिंग परीक्षण उपकरणों में "स्मगलिंग" का भ्रम पैदा कर सकते हैं जो एक ही सॉकेट पर कई अनुरोध भेजते हैं। हानिरहित क्लाइंट-साइड आर्टिफैक्ट्स को असली सर्वर-साइड डीसिंक से अलग करना सीखें।

 ### क्यों पाइपलाइनिंग क्लासिक झूठे सकारात्मक बनाती है

-HTTP/1.1 एकल TCP/TLS कनेक्शन का पुन: उपयोग करता है और एक ही स्ट्रीम पर अनुरोधों और प्रतिक्रियाओं को जोड़ता है। पाइपलाइनिंग में, क्लाइंट एक के बाद एक कई अनुरोध भेजता है और क्रम में प्रतिक्रियाओं पर निर्भर करता है। एक सामान्य झूठा सकारात्मक एक गलत CL.0-शैली का पेलोड एक ही कनेक्शन पर दो बार भेजना है:
+HTTP/1.1 एकल TCP/TLS कनेक्शन का पुन: उपयोग करता है और एक ही स्ट्रीम पर अनुरोधों और प्रतिक्रियाओं को जोड़ता है। पाइपलाइनिंग में, क्लाइंट कई अनुरोधों को एक के बाद एक भेजता है और क्रम में प्रतिक्रियाओं पर निर्भर करता है। एक सामान्य झूठा सकारात्मक यह है कि एक गलत CL.0-शैली का पेलोड एक ही कनेक्शन पर दो बार भेजा जाता है:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -334,20 +334,20 @@ Impact: कोई नहीं। आपने बस अपने क्ला
 2. HTTP/2 नेस्टेड-रिस्पॉन्स जांच
 - एक HTTP/2 अनुरोध भेजें। यदि प्रतिक्रिया शरीर में एक पूर्ण नेस्टेड HTTP/1 प्रतिक्रिया है, तो आपने एक बैकएंड पार्सिंग/असंगति बग साबित किया है, न कि एक शुद्ध क्लाइंट आर्टिफैक्ट।
 3. कनेक्शन-लॉक्ड फ्रंट-एंड के लिए आंशिक-अनुरोध जांच
- कुछ FEs केवल तब ही अपस्ट्रीम BE कनेक्शन का पुन: उपयोग करते हैं जब क्लाइंट अपने कनेक्शन का पुन: उपयोग करता है। FE व्यवहार का पता लगाने के लिए आंशिक-अनुरोधों का उपयोग करें जो क्लाइंट पुन: उपयोग को दर्शाता है।
+- कुछ FE केवल तब ही अपस्ट्रीम BE कनेक्शन का पुन: उपयोग करते हैं जब क्लाइंट अपने कनेक्शन का पुन: उपयोग करता है। FE व्यवहार का पता लगाने के लिए आंशिक-अनुरोधों का उपयोग करें जो क्लाइंट पुन: उपयोग को दर्शाता है।
 - कनेक्शन-लॉक्ड तकनीक के लिए PortSwigger "Browser‑Powered Desync Attacks" देखें।
 4. स्टेट प्रॉब्स
- एक ही TCP कनेक्शन पर पहले और बाद के अनुरोधों के बीच के अंतर की तलाश करें (पहले-अनुरोध रूटिंग/मान्यता)।
+- एक ही TCP कनेक्शन पर पहले और बाद के अनुरोधों के बीच के अंतर की तलाश करें (पहले अनुरोध का रूटिंग/मान्यता)।
 - Burp "HTTP Request Smuggler" में एक कनेक्शन-स्टेट प्रॉब शामिल है जो इसे स्वचालित करता है।
 5. वायर का दृश्य
 - पुन: उपयोग और आंशिक अनुरोधों के साथ प्रयोग करते समय सीधे संयोजन और संदेश फ्रेमिंग का निरीक्षण करने के लिए Burp "HTTP Hacker" एक्सटेंशन का उपयोग करें।

 ### कनेक्शन-लॉक्ड अनुरोध स्मगलिंग (पुन: उपयोग आवश्यक)

-कुछ फ्रंट-एंड केवल तब अपस्ट्रीम कनेक्शन का पुन: उपयोग करते हैं जब क्लाइंट अपने कनेक्शन का पुन: उपयोग करता है। वास्तविक स्मगलिंग मौजूद है लेकिन यह क्लाइंट-साइड पुन: उपयोग पर निर्भर है। प्रभाव को अलग करने और साबित करने के लिए:
+कुछ फ्रंट-एंड केवल तब ही अपस्ट्रीम कनेक्शन का पुन: उपयोग करते हैं जब क्लाइंट अपने कनेक्शन का पुन: उपयोग करता है। वास्तविक स्मगलिंग मौजूद है लेकिन यह क्लाइंट-साइड पुन: उपयोग पर निर्भर है। प्रभाव को अलग करने और साबित करने के लिए:
 - सर्वर-साइड बग साबित करें
 - HTTP/2 नेस्टेड-रिस्पॉन्स जांच का उपयोग करें, या
- दिखाएं कि FE केवल तब अपस्ट्रीम का पुन: उपयोग करता है जब क्लाइंट करता है।
+- दिखाने के लिए आंशिक-अनुरोधों का उपयोग करें कि FE केवल तब ही अपस्ट्रीम का पुन: उपयोग करता है जब क्लाइंट करता है।
 - वास्तविक प्रभाव दिखाएं भले ही प्रत्यक्ष क्रॉस-यूजर सॉकेट दुरुपयोग अवरुद्ध हो:
 - कैश विषाक्तता: असंगति के माध्यम से साझा कैश को विषाक्त करें ताकि प्रतिक्रियाएँ अन्य उपयोगकर्ताओं को प्रभावित करें।
 - आंतरिक हेडर प्रकटीकरण: FE-इंजेक्टेड हेडर (जैसे, auth/trust हेडर) को दर्शाएं और प्रमाणीकरण बायपास के लिए पिवट करें।
@ -365,12 +365,12 @@ Impact: कोई नहीं। आपने बस अपने क्ला

 ### क्लाइंट-साइड असंगति प्रतिबंध

-यदि आप ब्राउज़र-पावर्ड/क्लाइंट-साइड असंगति को लक्षित कर रहे हैं, तो दुर्भावनापूर्ण अनुरोध को क्रॉस-ओरिजिन द्वारा ब्राउज़र द्वारा भेजा जाना चाहिए। हेडर ओबफस्केशन ट्रिक्स काम नहीं करेंगी। नेविगेशन/फेच के माध्यम से पहुंच योग्य प्राइमिटिव्स पर ध्यान केंद्रित करें, और फिर कैश विषाक्तता, हेडर प्रकटीकरण, या फ्रंट-एंड नियंत्रण बायपास पर पिवट करें जहां डाउनस्ट्रीम घटक प्रतिक्रियाओं को दर्शाते या कैश करते हैं।
+यदि आप ब्राउज़र-पावर्ड/क्लाइंट-साइड असंगति को लक्षित कर रहे हैं, तो दुर्भावनापूर्ण अनुरोध को क्रॉस-ओरिजिन द्वारा ब्राउज़र द्वारा भेजा जाना चाहिए। हेडर ओबफस्केशन ट्रिक्स काम नहीं करेंगी। नेविगेशन/फेच के माध्यम से पहुंच योग्य प्राइमिटिव्स पर ध्यान केंद्रित करें, और फिर कैश विषाक्तता, हेडर प्रकटीकरण, या फ्रंट-एंड नियंत्रण बायपास पर पिवट करें जहां डाउनस्ट्रीम घटक प्रतिक्रियाओं को दर्शाते हैं या कैश करते हैं।

 पृष्ठभूमि और एंड-टू-एंड कार्यप्रवाह के लिए:

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

 ### निर्णय लेने में मदद करने के लिए उपकरण
@ -378,10 +378,10 @@ Impact: कोई नहीं। आपने बस अपने क्ला
 - 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: पहले-अनुरोध रूटिंग/मान्यता को स्पॉट करने के लिए एक कनेक्शन-स्टेट प्रॉब शामिल है।
+- Burp HTTP Request Smuggler: पहले अनुरोध के रूटिंग/मान्यता को स्पॉट करने के लिए एक कनेक्शन-स्टेट प्रॉब शामिल है।

 > [!NOTE]
-> पुन: उपयोग-केवल प्रभावों को गैर-मुद्दों के रूप में मानें जब तक कि आप सर्वर-साइड असंगति साबित नहीं कर सकते और ठोस प्रभाव (विषाक्त कैश आर्टिफैक्ट, लीक किया गया आंतरिक हेडर जो विशेषाधिकार बायपास सक्षम करता है, बायपास किया गया FE नियंत्रण, आदि) संलग्न नहीं कर सकते।
+> पुन: उपयोग-केवल प्रभावों को गैर-मुद्दों के रूप में मानें जब तक कि आप सर्वर-साइड असंगति साबित नहीं कर सकते और ठोस प्रभाव (विषाक्त कैश आर्टिफैक्ट, लीक हुए आंतरिक हेडर जो विशेषाधिकार बायपास सक्षम करते हैं, बायपास किए गए FE नियंत्रण, आदि) संलग्न नहीं कर सकते।

 ## HTTP Request Smuggling का दुरुपयोग

@ -428,11 +428,11 @@ a=x
 ```
 इसके विपरीत, 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>
+### Revealing front-end request rewriting <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

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

-यह जांचने के लिए कि प्रॉक्सी एक अनुरोध को कैसे बदलती है, एक POST पैरामीटर खोजें जिसे बैक-एंड प्रतिक्रिया में प्रतिध्वनित करता है। फिर, इस पैरामीटर का उपयोग करते हुए एक अनुरोध तैयार करें, इसे अंतिम स्थान पर रखते हुए, निम्नलिखित के समान:
+यह जांचने के लिए कि प्रॉक्सी एक अनुरोध को कैसे बदलती है, एक POST पैरामीटर खोजें जिसे बैक-एंड प्रतिक्रिया में दर्शाता है। फिर, इस पैरामीटर का उपयोग करते हुए एक अनुरोध तैयार करें, इसे अंतिम स्थान पर रखते हुए, निम्नलिखित के समान:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -449,7 +449,7 @@ Content-Length: 100

 search=
 ```
-इस संरचना में, बाद के अनुरोध घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परामर्शित किया गया पैरामीटर है। यह परावर्तन बाद के अनुरोध के हेडर को उजागर करेगा।
+इस संरचना में, बाद के अनुरोध घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परिलक्षित पैरामीटर है। यह परावर्तन बाद के अनुरोध के हेडर को उजागर करेगा।

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

@ -459,9 +459,9 @@ search=

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

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

-निम्नलिखित अनुरोध को एक पैरामीटर के मान के रूप में जोड़कर, आप अगले क्लाइंट के अनुरोध को स्टोर कर सकते हैं:
+एक पैरामीटर के मान के रूप में निम्नलिखित अनुरोध को जोड़कर, आप अगले ग्राहक के अनुरोध को स्टोर कर सकते हैं:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -481,9 +481,9 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-इस परिदृश्य में, **comment parameter** का उद्देश्य एक सार्वजनिक रूप से सुलभ पृष्ठ पर एक पोस्ट की टिप्पणी अनुभाग में सामग्री को संग्रहीत करना है। परिणामस्वरूप, अगले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।
+इस परिदृश्य में, **comment parameter** का उद्देश्य एक सार्वजनिक रूप से सुलभ पृष्ठ पर एक पोस्ट की टिप्पणी अनुभाग के भीतर सामग्री को संग्रहीत करना है। परिणामस्वरूप, अगले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।

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

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

@ -532,9 +532,9 @@ A=

 [**इस लेख**](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 Request Smuggling के साथ ऑन-साइट रीडायरेक्ट्स का लाभ उठाना <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 जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर रीडायरेक्ट होता है ताकि स्लैश शामिल किया जा सके:
+ऐप्लिकेशन अक्सर `Host` हेडर से होस्टनेम का उपयोग करके एक URL से दूसरे URL पर रीडायरेक्ट करते हैं। यह Apache और IIS जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर रीडायरेक्ट होता है ताकि स्लैश शामिल किया जा सके:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
@ -576,11 +576,11 @@ Location: https://attacker-website.com/home/

 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
@ -598,17 +598,17 @@ 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 हमले को लॉन्च करेगा।
+इसके बाद, `/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>

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

 हमलावर एक स्मगल्ड अनुरोध तैयार करता है जो संवेदनशील उपयोगकर्ता-विशिष्ट सामग्री लाता है। निम्नलिखित उदाहरण पर विचार करें:
@ -622,11 +622,11 @@ x=1
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-यदि यह स्मगल्ड अनुरोध स्थिर सामग्री (जैसे, `/someimage.png`) के लिए अभिप्रेत कैश प्रविष्टि को विषाक्त करता है, तो पीड़ित का संवेदनशील डेटा `/private/messages` से स्थिर सामग्री के कैश प्रविष्टि के तहत कैश किया जा सकता है। परिणामस्वरूप, हमलावर संभवतः इन कैश किए गए संवेदनशील डेटा को पुनः प्राप्त कर सकता है।
+यदि यह स्मगल्ड अनुरोध स्थिर सामग्री के लिए अभिप्रेत कैश प्रविष्टि को विषाक्त करता है (जैसे, `/someimage.png`), तो पीड़ित का संवेदनशील डेटा `/private/messages` से स्थिर सामग्री की कैश प्रविष्टि के तहत कैश किया जा सकता है। परिणामस्वरूप, हमलावर संभवतः इन कैश किए गए संवेदनशील डेटा को पुनः प्राप्त कर सकता है।

-### HTTP Request Smuggling के माध्यम से TRACE का दुरुपयोग <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### 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 Request Smuggling के साथ दुरुपयोग करना संभव हो सकता है। इसका कारण यह है कि यह विधि सर्वर को भेजे गए किसी भी हेडर को प्रतिक्रिया के शरीर के भाग के रूप में परावर्तित करेगी। उदाहरण के लिए:
+[**इस पोस्ट में**](https://portswigger.net/research/trace-desync-attack) सुझाव दिया गया है कि यदि सर्वर में TRACE विधि सक्षम है, तो इसे HTTP अनुरोध स्मगलिंग के साथ दुरुपयोग करना संभव हो सकता है। इसका कारण यह है कि यह विधि सर्वर को भेजे गए किसी भी हेडर को प्रतिक्रिया के शरीर के भाग के रूप में परावर्तित करेगी। उदाहरण के लिए:
 ```
 TRACE / HTTP/1.1
 Host: example.com
@ -643,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 प्रतिक्रिया शामिल करने के लिए बनाया जा सकता है, जिससे एक हमलावर को अगले प्रतिक्रिया के अनुरोध को पूरी तरह से नियंत्रित करने की अनुमति मिलती है (जिसका उपयोग कैश विषाक्तता करने के लिए किया जा सकता है)।

 उदाहरण:
 ```
@ -695,7 +695,7 @@ Content-Length: 50
 ```
 ### HTTP Request Smuggling को HTTP Response Desynchronisation के साथ हथियार बनाना

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

 {{#ref}}
 ../http-response-smuggling-desync.md
@ -824,10 +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)
+- Beware the false false‑positive: how to distinguish HTTP pipelining from request smuggling – [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)
+- Browser‑Powered Desync Attacks – [https://portswigger.net/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](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)


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