HTTP Connection Request Smuggling

यह पृष्ठ संक्षेप, विस्तार और अद्यतन करता है PortSwigger के Browser-Powered Desync Attacks पर मौलिक शोध और HTTP/2 कनेक्शन-स्टेट दुरुपयोग पर बाद के कार्यों का। यह उन कमजोरियों पर ध्यान केंद्रित करता है जहाँ एक मूल केवल एक बार प्रति TCP/TLS कनेक्शन पर निर्धारित होता है, जिससे एक हमलावर को चैनल स्थापित होने के बाद एक अलग आंतरिक होस्ट पर "स्मगल" करने के लिए अनुरोध भेजने की अनुमति मिलती है।

Connection-State Attacks

First-request Validation

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

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 जैसे पासवर्ड-रीसेट पॉइज़निंग या web cache poisoning के साथ मिलाकर अन्य वर्चुअल होस्ट्स तक SSRF-जैसी पहुंच प्राप्त की जा सकती है:

GET / HTTP/1.1
Host: public.example

POST /pwreset HTTP/1.1
Host: private.internal

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)

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

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 – अनुचित प्राधिकरण मान्यता