14 KiB
HTTP Connection Contamination
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- क्या आप साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करना चाहिए? SUBSCRIPTION PLANS की जांच करें!
- खोजें The PEASS Family, हमारा विशेष संग्रह NFTs
- प्राप्त करें official PEASS & HackTricks swag
- शामिल हों 💬 Discord समूह या telegram समूह या मुझे Twitter पर फ़ॉलो करें 🐦@carlospolopm.
- अपने हैकिंग ट्रिक्स साझा करें और PRs सबमिट करें hacktricks repo और hacktricks-cloud repo को.
इस पोस्ट की सामग्री ली गई है https://portswigger.net/research/http-3-connection-contamination****
वेब ब्राउज़र HTTP connection coalescing का उपयोग करते हैं, जिससे वे एक ही HTTP/2+ कनेक्शन का उपयोग कर सकते हैं जो अलग-अलग वेबसाइटों के लिए जाने वाले अनुरोधों के लिए होता है, जो एक ही IP पते को निर्धारित करते हैं और जो होस्टनाम के लिए मान्य TLS प्रमाणपत्र का उपयोग करते हैं।
पहले अनुरोध रूटिंग एक खतरनाक रिवर्स-प्रॉक्सी व्यवहार है जहां प्रॉक्सी पहले अनुरोध का विश्लेषण करता है ताकि वह यह निर्धारित कर सके कि उसे उसे किस बैक-एंड को रूट करना है, और फिर उसी कनेक्शन पर सभी आगामी अनुरोधों को एक ही बैक-एंड को भेजता है।
कनेक्शन कोलेसिंग और पहले अनुरोध रूटिंग मिलकर अच्छी तरह से काम नहीं करते हैं। उदाहरण के लिए, सोचें secure.example.com और wordpress.example.com दोनों एक रिवर्स प्रॉक्सी के पीछे बैठे हैं जो *.example.com के लिए मान्य प्रमाणपत्र का उपयोग करता है।
$ nslookup wordpress.example.com
52.16.179.7 // reverse proxy that supports HTTP/2 and does first-request routing
$ nslookup secure.example.com
52.16.179.7 // same reverse proxy
$ openssl s_client -connect x.portswigger-labs.net:443
subject=/CN=*.example.com // wildcard TLS certificate
यदि ब्राउज़र wordpress.example.com पर एक अनुरोध भेजने का प्रयास करता है और इसके बाद secure.example.com को, तो ब्राउज़र कनेक्शन संग्रहण द्वारा दोनों अनुरोधों को एक ही कनेक्शन पर भेजने के लिए मजबूर किया जाएगा। पहले अनुरोध रूटिंग के कारण secure.example.com पर किया गया अनुरोध गलती से WordPress बैक-एंड पर रूट हो जाएगा। इसका मतलब है कि यदि आपको wordpress.example.com पर XSS मिलता है, तो आप इसका उपयोग secure.example.com को कमरे में ले जाने के लिए कर सकते हैं!
// create HTTP/2+ connection
fetch('https://wordpress.example.com/', {credentials: 'include'})
// connection coalescing will force this down the same connection...
// ...leading to the front-end misrouting it to WordPress
// the browser thinks our injected JS is coming from secure.example.com
// exposing saved passwords, cookies, etc.
location='https://secure.example.com/plugin/x?q=<script>stealPasswords()'
आप खुद नेटवर्क टैब के तहत Chrome के डेवलपर टूल में समय ग्राफ का उपयोग करके कनेक्शन कोलेसिंग का अन्वेषण कर सकते हैं (या अगर आप मासोचिस्ट हैं तो WireShark का उपयोग करें)। fetch() का उपयोग करके अनुरोध जोड़ें और देखें कि क्या ग्राफ दूसरे अनुरोध के लिए 'आदिकारिक कनेक्शन' पर बिताया गया समय दिखाता है, और क्या कनेक्शन आईडी स्तंभ मेल खाता है:
{% code overflow="wrap" %}
fetch('//sub1.hackxor.net/', {mode: 'no-cors', credentials: 'include'}).then(()=>{ fetch('//sub2.hackxor.net/', {mode: 'no-cors', credentials: 'include'}) })
{% endcode %}
मैंने इस खतरे को गहनता से जांचने या इसे वाइल्ड में खोजने के लिए समय नहीं निवेश किया है क्योंकि मुझे लगता है कि यह वर्तमान में दो कारणों से द्विधा है। पहले, पहली अनुरोध मार्गनिर्देशन अप्रचलित है और HTTP/2 के कार्यान्वयन की जटिलता के कारण HTTP/1.1 के मुकाबले केवल थोड़े से अद्वितीय HTTP/2 सर्वरों का एक छोटा सा समूह है। दूसरे, कनेक्शन संग्रहण का मतलब है कि पहली अनुरोध मार्गनिर्देशन करने वाले HTTP/2 सर्वरों में अंतराल से तोड़ देने के कारण, वास्तविक आगंतुकों के लिए तो उनके मालिक इस कमजोरी को ठीक कर देंगे, इसलिए हमलावर प्रोत्साहन के बिना ही इसे ठीक कर देंगे।
फिर भी, हैकरों के लिए सब बुरा नहीं है। HTTP/3 प्रस्तावित करता है एक आईपी पते मिलाने की आवश्यकता को हटाने के लिए, जो पहली अनुरोध मार्गनिर्देशन का उपयोग करने वाले फ्रंट-एंड वाले सभी लोगों को उजागर करेगा और जिनके पास एक सर्टिफिकेट है जो कई होस्ट के लिए मान्य है।
इससे एक दूसरा जोखिम भी उत्पन्न होता है जो पहली अनुरोध मार्गनिर्देशन से संबंधित नहीं है - इसका मतलब है कि एक संक्रमित सर्वर के पास वाइल्डकार्ड सर्टिफिकेट के बिना अब एक MITM की आवश्यकता नहीं होती है। सामरिक रूप से, इससे इसका अर्थ है कि इससे लाभ उठा सकने वाले खतरनाक कारकों का समूह बड़ा हो जाता है।
इन खतरों से बचने के लिए, सुनिश्चित करें कि आपके रिवर्स प्रॉक्सी पहली अनुरोध मार्गनिर्देशन नहीं करते हैं। आप इसे रिपीटर में मैन्युअल रूप से टेस्ट कर सकते हैं, HTTP/1 और HTTP/2 कनेक्शन पुनःउपयोग सक्षम करके, और इसे HTTP Request Smuggler में 'Connection-State' हमले का उपयोग करके खोज सकते हैं। इसके अलावा, ध्यान दें कि वाइल्डकार्ड TLS सर्टिफिकेट कभी भी आदर्श नहीं रहे हैं, HTTP/3 का मतलब है कि एक संक्रमित सर्वर के पास वाइल्डकार्ड सर्टिफिकेट के साथ अब बिना सक्रिय MITM के साथ बच्ची डोमेनों को हमला करने के लिए उपयोग किया जा सकता है।
ये नए खतरे वेब इंफ्रास्ट्रक्चर के लगातार घिरे हुए जंग में जारी रहते हैं, जहां किसी व्यक्तिगत साइट में कमजोरी का एक बहुत सारे गैर-स्पष्ट प्रभाव सुरक्षा पर होता है। देखने में दिलचस्प होगा कि ये खतरे व्यावहारिक रूप में कैसे खेलते हैं।
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- क्या आप साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को हैकट्रिक्स में विज्ञापित देखना चाहते हैं? या क्या आप PEASS के नवीनतम संस्करण का उपयोग करना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं? सदस्यता योजनाएं की जांच करें!
- खोजें The PEASS Family, हमारा विशेष NFT संग्रह
- प्राप्त करें आधिकारिक PEASS और HackTricks swag
- शामिल हों 💬 Discord समूह या टेलीग्राम समूह या मुझे ट्विटर 🐦@carlospolopm** का** अनुसरण करें।**
- अपने हैकिंग ट्रिक्स साझा करें, PRs के माध्यम से hacktricks repo और hacktricks-cloud repo को सबमिट करके।