# HTTP Connection Request Smuggling

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

**यह पृष्ठ संक्षेप, विस्तार और अद्यतन करता है** PortSwigger के [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) पर मौलिक शोध और HTTP/2 कनेक्शन-स्टेट दुरुपयोग पर बाद के कार्यों का। यह उन कमजोरियों पर ध्यान केंद्रित करता है जहाँ **एक मूल केवल एक बार प्रति TCP/TLS कनेक्शन पर निर्धारित होता है**, जिससे एक हमलावर को चैनल स्थापित होने के बाद एक अलग आंतरिक होस्ट पर "स्मगल" करने के लिए अनुरोध भेजने की अनुमति मिलती है।

## Connection-State Attacks <a href="#state" id="state"></a>

### First-request Validation

जब अनुरोधों को रूट किया जाता है, तो रिवर्स प्रॉक्सी **Host** (या HTTP/2 में **:authority**) हेडर पर निर्भर हो सकते हैं ताकि गंतव्य बैक-एंड सर्वर का निर्धारण किया जा सके, अक्सर उन होस्टों की एक व्हाइटलिस्ट पर निर्भर करते हैं जिन्हें पहुंच की अनुमति है। हालाँकि, कई प्रॉक्सियों में एक कमजोरी है जहाँ व्हाइटलिस्ट **केवल कनेक्शन में पहले अनुरोध पर लागू होती है**। परिणामस्वरूप, हमलावर पहले एक अनुमत अनुरोध भेजकर और फिर उसी अंतर्निहित कनेक्शन का पुनः उपयोग करके आंतरिक वर्चुअल होस्टों तक पहुँच सकते हैं:
```http
GET / HTTP/1.1
Host: allowed-external-host.example

GET /admin HTTP/1.1
Host: internal-only.example
```
### First-request Routing

कई HTTP/1.1 रिवर्स प्रॉक्सी एक आउटबाउंड कनेक्शन को एक बैक-एंड पूल से **केवल पहले अनुरोध के आधार पर मैप करती हैं जो वे फॉरवर्ड करती हैं**। उसी फ्रंट-एंड सॉकेट के माध्यम से भेजे गए सभी बाद के अनुरोध चुपचाप फिर से उपयोग किए जाते हैं, उनके होस्ट हेडर की परवाह किए बिना। इसे क्लासिक [Host header attacks](https://portswigger.net/web-security/host-header) जैसे पासवर्ड-रीसेट पॉइज़निंग या [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning) के साथ मिलाकर अन्य वर्चुअल होस्ट्स तक SSRF-जैसी पहुंच प्राप्त की जा सकती है:
```http
GET / HTTP/1.1
Host: public.example

POST /pwreset HTTP/1.1
Host: private.internal
```
> [!TIP]
> Burp Suite Professional ≥2022.10 में आप **HTTP Request Smuggler → Connection-state probe** को सक्षम कर सकते हैं ताकि इन कमजोरियों का स्वचालित रूप से पता लगाया जा सके।

---

## 2023-2025 में नया – HTTP/2/3 कनेक्शन कोलेसिंग दुरुपयोग

आधुनिक ब्राउज़र नियमित रूप से **कोलेस** HTTP/2 और HTTP/3 अनुरोधों को एकल TLS कनेक्शन पर तब करते हैं जब प्रमाणपत्र, ALPN प्रोटोकॉल और IP पता मेल खाते हैं। यदि एक फ्रंट-एंड केवल पहले अनुरोध को अधिकृत करता है, तो हर बाद का कोलेस्ड अनुरोध उस अधिकृतता को विरासत में लेता है – **भले ही Host/:authority बदल जाए**।

### शोषण परिदृश्य
1. हमलावर `evil.com` को नियंत्रित करता है जो लक्ष्य `internal.company` के समान CDN एज नोड पर हल करता है।
2. पीड़ित का ब्राउज़र पहले से ही `evil.com` के लिए एक खुला HTTP/2 कनेक्शन रखता है।
3. हमलावर अपने पृष्ठ में एक छिपा हुआ `<img src="https://internal.company/…">` एम्बेड करता है।
4. चूंकि कनेक्शन पैरामीटर मेल खाते हैं, ब्राउज़र **मौजूदा** TLS कनेक्शन का पुनः उपयोग करता है और `internal.company` के लिए अनुरोध को मल्टीप्लेक्स करता है।
5. यदि CDN/राउटर ने केवल पहले अनुरोध को मान्य किया, तो आंतरिक होस्ट उजागर हो जाता है।

Chrome/Edge/Firefox के लिए PoCs James Kettle के टॉक *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023) में उपलब्ध हैं।

### उपकरण
* **Burp Suite 2023.12** ने एक प्रयोगात्मक **HTTP/2 Smuggler** इन्सर्शन पॉइंट पेश किया है जो स्वचालित रूप से कोलेसिंग और TE/CL तकनीकों का प्रयास करता है।
* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) – एक Python ढांचा जो 2024 में HTTP/2 और HTTP/3 पर फ्रंट-एंड/बैक-एंड डीसिंक वेक्टर को ब्रूट-फोर्स करने के लिए जारी किया गया।

### शमन
* हर अनुरोध पर **Host/:authority को फिर से मान्य करें**, केवल कनेक्शन निर्माण पर नहीं।
* CDN/लोड-बैलेंसर पर **उत्पत्ति कोलेसिंग** को अक्षम करें या सख्ती से स्कोप करें (जैसे NGINX में `http2_origin_cn` बंद)।
* आंतरिक और बाहरी होस्टनाम के लिए अलग प्रमाणपत्र या IP पते लागू करें ताकि ब्राउज़र उन्हें कानूनी रूप से कोलेस न कर सके।
* जहां व्यावहारिक हो, हर अनुरोध के बाद **connection: close** या `proxy_next_upstream` को प्राथमिकता दें।

---

## वास्तविक दुनिया के मामले (2022-2025)

| वर्ष | घटक | CVE | नोट्स |
|------|-----------|-----|-------|
| 2022 | AWS Application Load Balancer | – | होस्ट हेडर केवल पहले अनुरोध पर मान्य किया गया; नियम इंजन को पैच करके ठीक किया गया (SecurityLabs द्वारा प्रकट)। |
| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | जब `CONFIG proxy.config.http.parent_proxy_routing_enable` सेट किया गया था, तब HTTP/2 कनेक्शन पुन: उपयोग के माध्यम से अनुरोध स्मगलिंग की अनुमति दी। |
| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | पहले स्ट्रीम के बाद :authority की अनुचित मान्यता ने साझा मेषों में क्रॉस-टेनेंट अनुरोध स्मगलिंग को सक्षम किया। |

---

## पहचान चिट-शीट

1. **एक ही** TCP/TLS कनेक्शन में विभिन्न Host या :authority हेडर के साथ दो अनुरोध भेजें।
2. देखें कि क्या दूसरा उत्तर पहले होस्ट (सुरक्षित) या दूसरे होस्ट (कमजोर) से उत्पन्न होता है।
3. Burp में: `Repeat → keep-alive → Send → Follow`।
4. HTTP/2 का परीक्षण करते समय, एक **विशिष्ट** स्ट्रीम (ID 1) एक बेनिग होस्ट के लिए खोलें, फिर एक आंतरिक होस्ट के लिए एक दूसरा स्ट्रीम (ID 3) मल्टीप्लेक्स करें और एक उत्तर की तलाश करें।

---

## संदर्भ

* PortSwigger Research – *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023)
* Envoy Security Advisory CVE-2024-2470 – अनुचित प्राधिकरण मान्यता

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