mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t
This commit is contained in:
Translator
parent
fa00eeea6e
commit
8472088c86
@ -1,34 +1,83 @@
|
||||
# HTTP कनेक्शन अनुरोध स्मगलिंग
|
||||
# HTTP Connection Request Smuggling
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
**यह पोस्ट का सारांश है** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
**यह पृष्ठ संक्षेप, विस्तार और अद्यतन करता है** PortSwigger के [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) पर मौलिक शोध और HTTP/2 कनेक्शन-स्टेट दुरुपयोग पर बाद के कार्यों का। यह उन कमजोरियों पर ध्यान केंद्रित करता है जहाँ **एक मूल केवल एक बार प्रति TCP/TLS कनेक्शन पर निर्धारित होता है**, जिससे एक हमलावर को चैनल स्थापित होने के बाद एक अलग आंतरिक होस्ट पर "स्मगल" करने के लिए अनुरोध भेजने की अनुमति मिलती है।
|
||||
|
||||
## कनेक्शन स्थिति हमले <a href="#state" id="state"></a>
|
||||
## 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]
|
||||
Host: allowed-external-host.example
|
||||
|
||||
GET / HTTP/1.1
|
||||
Host: [internal-host]
|
||||
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: example.com
|
||||
Host: public.example
|
||||
|
||||
POST /pwreset HTTP/1.1
|
||||
Host: psres.net
|
||||
Host: private.internal
|
||||
```
|
||||
यह समस्या [Host header attacks](https://portswigger.net/web-security/host-header) के साथ मिलाई जा सकती है, जैसे कि पासवर्ड रीसेट पॉइज़निंग या [web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning), अन्य कमजोरियों का शोषण करने या अतिरिक्त वर्चुअल होस्टों तक अनधिकृत पहुंच प्राप्त करने के लिए।
|
||||
> [!TIP]
|
||||
> Burp Suite Professional ≥2022.10 में आप **HTTP Request Smuggler → Connection-state probe** को सक्षम कर सकते हैं ताकि इन कमजोरियों का स्वचालित रूप से पता लगाया जा सके।
|
||||
|
||||
> [!NOTE]
|
||||
> इन कमजोरियों की पहचान करने के लिए, 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}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user