* क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड** करने का उपयोग करने की आवश्यकता है? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFT संग्रह**](https://opensea.io/collection/the-peass-family)
* [**आधिकारिक PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में **शामिल** हों या मुझे **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)** का पालन करें**.
* **अपने हैकिंग ट्रिक्स को** [**hacktricks रेपो**](https://github.com/carlospolop/hacktricks) **और** [**hacktricks-cloud रेपो**](https://github.com/carlospolop/hacktricks-cloud) **में PR जमा करके अपनी ट्रिक्स साझा करें।**
यह सुरक्षा कमजोरी उत्पन्न होती है जब **बैकएंड सर्वर** द्वारा **Content Length** (CL) हैडर को पूरी तरह से **अनदेखा** किया जाता है। फिर, बैकएंड बॉडी को **दूसरे अनुरोध के विधि की शुरुआत** के रूप में व्यवहार करता है। CL को अनदेखा करना उसे 0 की मान के रूप में व्यवहार करने के समान है, इसलिए यह एक CL.0 डीसिंक है - एक [ज्ञात](https://i.blackhat.com/USA-20/Wednesday/us-20-Klein-HTTP-Request-Smuggling-In-2020-New-Variants-New-Defenses-And-New-Challenges.pdf) लेकिन कम प्रयोग की जाने वाली हमला वर्ग है।
ध्यान दें कि यह सुरक्षा कमजोरी पूरी तरह से **मान्य**, विनिर्देश-अनुरूप **HTTP अनुरोध** द्वारा **ट्रिगर** हो रही है। इसका मतलब है कि **फ्रंट-एंड को कोई सुरक्षा नहीं है** और यह ब्राउज़र द्वारा भी ट्रिगर किया जा सकता है।
**CL.0** और **H2.0** के बीच केवल एक **अंतर** है कि दूसरा वाला **HTTP2** का उपयोग कर रहा है (जिसमें एक निहित सामग्री-लंबाई हैडर होता है) लेकिन **बैकएंड उसे भी उपयोग नहीं कर रहा है**।
पारंपरिक डीसिंक हमले एक **फ्रंट-एंड और बैकएंड** सर्वर के बीच की **कनेक्शन** को **पॉइज़न** करते हैं, और इसलिए वे उन वेबसाइट्स पर असंभव हैं जो एक फ्रंट-एंड/बैकएंड संरचना का उपयोग नहीं करती हैं। ये अब से **सर्वर-साइड डीसिंक** हैं। अधिकांश **सर्वर-साइड डीसिंक** केवल एक **कस्टम HTTP क्लाइंट** द्वारा एक अवैध अनुरोध जारी करने से ट्रिगर किए जा सकते हैं।
ब्राउज़र को एक डीसिंक को कारण बनाने की क्षमता एक पूरी नई श्रेणी के संकट को संभव करती है जिसे **क्लाइंट-साइड डीसिंक** (CSD) कहा जाता है।
CSD हमला उस **पीड़ित के वेबसाइट पर जाने के बाद शुरू होता है**, जिसके बाद उसका ब्राउज़र उस वेबसाइट को **दो क्रॉस-डोमेन अनुरोध** भेजता है। **पहला** अनुरोध ब्राउज़र की कनेक्शन को **डीसिंक करने** और **दूसरे अनुरोध को ट्रिगर** करने के लिए तैयार किया जाता है, जो आमतौर पर हानिकारक प्रतिक्रिया देता है,
सबसे पहले, हमें हमला शुरू करने के लिए एक साइट का चयन करना होगा। यह साइट **HTTPS के माध्यम से पहुंची जानी चाहिए** और लक्ष्य से **अलग डोमेन पर स्थित होनी चाहिए**।
अगले, सुनिश्चित करें कि आपके पास **प्रॉक्सी कॉन्फ़िगर नहीं है**, फिर अपनी हमला साइट पर ब्राउज़ करें। **डेवलपर टूल्स** खोलें और **नेटवर्क टैब** पर स्विच करें। पोटेंशियल समस्याओं के बाद में बग दुरुस्त करने में मदद करने के लिए, मैं निम्नलिखित समायोजनों की सिफारिश करता हूँ:
डेवलपर कंसोल पर स्विच करें और fetch() का उपयोग करके अपने हमला क्रम को प्रतिरूपित करने के लिए जावास्क्रिप्ट को निष्पादित करें। यह कुछ इस तरह दिख सकता है:
मैंने फेच मोड **'no-cors'** सेट किया है ताकि Chrome **नेटवर्क टैब में कनेक्शन आईडी दिखाएं**। मैंने भी **credentials: 'include'** सेट किया है क्योंकि Chrome में [**दो अलग कनेक्शन पूल**](https://www.chromium.org/developers/design-documents/network-stack/preconnect) होते हैं - कुकीज़ के साथ अनुरोधों के लिए एक और कुकीज़ के बिना अनुरोधों के लिए एक। आप आमतौर पर **नेविगेशन का उपयोग करना चाहेंगे**, और वे **'with-cookies' पूल का उपयोग करते हैं**, इसलिए इस पूल को हमेशा पॉइज़न करने की आदत डालने में लायक है।
जब आप इसे निष्पादित करते हैं, तो आपको नेटवर्क टैब में **दो अनुरोध** दिखाई देंगे जिनमें **समान कनेक्शन आईडी** होगी, और **दूसरा** अनुरोध एक **404** ट्रिगर करेगा:
एक विकल्प है कि आप लक्षित साइट पर ऐसी कार्यक्षमता की पहचान करें जो आपको **पाठ डेटा संग्रहित करने** की अनुमति देती है, और प्रीफिक्स को ऐसे तैयार करें कि आपके पीड़ित कुकीज़, प्रमाणीकरण हैडर्स, या पासवर्ड **ऐसे स्थान पर संग्रहीत हों** जहां से आप उन्हें पुनः प्राप्त कर सकते हैं। यह हमला फ्लो [सर्वर-साइड अनुरोध डीसिंक करने](https://portswigger.net/web-security/request-smuggling/exploiting#capturing-other-users-requests) के लिए लगभग एक ही तरीके से काम करता है, इसलिए मैं इस पर ज्यादा विचार नहीं करूंगा।
सामान्य परिस्थितियों में, कई प्रकार के **सर्वर-साइड हमले** केवल उस हमलावर के द्वारा शुरू किए जा सकते हैं जिसके पास लक्षित वेबसाइट तक सीधा पहुंच होती है क्योंकि वे **HTTP अनुरोधों पर निर्माण करते हैं जिन्हें ब्राउज़र भेजने से इनकार करते हैं**, जैसे कि **HTTP हेडर्स** के साथ **छेड़छाड़** करना - वेब कैश पॉइज़निंग, सबसे अधिक सर्वर-साइड अनुरोध डीसिंक, होस्ट-हेडर हमले, यूज़र-एजेंट आधारित [SQLi](https://portswigger.net/web-security/sql-injection), CSRF JSON सामग्री प्रकार और अनेक अन्य।
सफल हमले के लिए सबसे सरल मार्ग दो मुख्य तकनीकों से आया जो सामान्यतः सर्वर-साइड डीसिंक हमलों के लिए उपयोग किए जाते हैं: [**होस्ट-हेडर रीडायरेक्ट के माध्यम से जावास्क्रिप्ट संसाधन पॉइज़निंग**](https://portswigger.net/web-security/request-smuggling/exploiting#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect), और हानिकारक HTML के साथ एक प्रतिक्रिया को स्प्लाइस करने के लिए [**HEAD विधि**](https://portswigger.net/web-security/request-smuggling/advanced/request-tunnelling#non-blind-request-tunnelling-using-head) का उपयोग करना। दोनों तकनीकों को **अनुकूलित** करने के लिए कुछ नवीनतम चुनौतियों को पार करने की आवश्यकता थी जो **पीड़ित के ब्राउज़र में कार्य करने** से जुड़ी थीं।
* /assets में CL.0 का दुरुपयोग करें (यह /assets/ पर रीडायरेक्ट करता है और CL की जांच नहीं करता है)
* HEAD अनुरोध को अपमानित करें (क्योंकि HEAD प्रतिक्रियाएं अभी भी एक सामग्री-लंबाई को संबोधित करती हैं)
* प्रतिक्रिया में प्रतिबिंबित होने वाले GET अनुरोध को अपमानित करें, जिसकी सामग्री प्रतिक्रिया में प्रतिबिंबित होगी।
* HEAD अनुरोध की सामग्री-लंबाई के कारण, इस अनुरोध की प्रतिक्रिया HEAD अनुरोध के शरीर की होगी।
* कॉर्स मोड सेट करें। सामान्यतः यह नहीं किया जाता है, लेकिन इस मामले में सर्वर की प्रारंभिक POST की प्रतिक्रिया एक रीडायरेक्ट है जो अगर अनुसरण किया जाएगा तो उत्पादन कार्य नहीं करेगा। इसलिए, कॉर्स मोड का उपयोग एक त्रुटि को उत्पन्न करने और पीड़ित को रीडायरेक्ट करने के लिए किया जाता है।
*`/+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` पर वापस रीडायरेक्ट करेगा और दूसरे में वह जावास्क्रिप्ट कोड की **उम्मीद** करेगा (पेलोड)। एक पॉलिग्लॉट का उपयोग किया जा सकता है ताकि दोनों प्रतिक्रियाएँ केवल एक में सेव की जा सकें:
* पृष्ठ **`/%2f`** तक पहुंचा जाता है ताकि **CL.0** कमजोरी का शोध लगाया जा सके।
* एक **HEAD** अनुरोध को एक **`Transfer-Encoding: chunked` हैडर** का उपयोग करके चोरी किया जाता है।
* इस स्थिति में यह हैडर आवश्यक है क्योंकि अन्यथा **सर्वर एक शरीर वाले HEAD अनुरोध को स्वीकार करने से इनकार करता है**।
* फिर, उपयोगकर्ता एक POST भेजता है जिसके शरीर में **पिछले HEAD अनुरोध का अंत चंक** और एक **नया अनुरोध जो चोरी किया गया है** शामिल होता है जिसमें **सामग्री** (JS पेलोड) होती है जो प्रतिक्रिया में **प्रतिबिंबित** होगी।
* इसलिए ब्राउज़र **HEAD** अनुरोध को **POST अनुरोध के रूप में प्रतिक्रिया** के रूप में देखेगा जिसमें उपयोगकर्ता के इनपुट को प्रतिबिंबित करने वाली **शरीर** प्रतिक्रिया भी होगी।
इस मामले में, फिर से, एक **होस्ट हैडर****रीडायरेक्ट** है जिसका उपयोग **JS इम्पोर्ट** को **हाइजैक** करने के लिए किया जा सकता है। हालांकि, इस बार **रीडायरेक्ट को कैश नहीं किया जा सकता**, इसलिए क्लाइंट-साइड **कैश पॉइज़निंग** कोई विकल्प नहीं है।
इसलिए, हमारे द्वारा किया जाने वाला हमला यह होगा कि **पीड़ित पृष्ठ** को एक टैब में एक्सेस करें और फिर, जब पृष्ठ **JS फ़ाइल लोड करने की कोशिश करे**, सॉकेट **स्मगलिंग कनेक्शन** (इस मामले में 3) को **पॉइज़न** करें।
क्योंकि **समयबद्धता** बहुत **सटीक** होनी चाहिए, हमला हर बार एक **नई टैब पर करें** जब तक यह काम नहीं करता है।
ध्यान दें कि इस मामले में `/meeting_testjs.cgi` को हमला किया गया क्योंकि यह एक **404** के साथ जवास्क्रिप्ट लोड करता है, इसलिए इसे कैश नहीं किया जाता है। अन्य स्थितियों में जहां आप एक **कैश किए गए JS** को हमला करने की कोशिश करते हैं, आपको इसे **कैश से हटने** का इंतजार करना होगा और फिर एक नया हमला शुरू करना होगा।
* लक्ष्य को एक ताजगी कनेक्शन स्थापित करने के लिए एक अहानिकारक अनुरोध जारी करें, जिससे समयबद्धता और सुस्ती बढ़े।
* विंडो को लक्ष्य पृष्ठ /meeting\_testjs.cgi पर नेविगेट करें।
* 120ms बाद, रीडायरेक्ट गैजेट का उपयोग करके तीन पॉइज़न कनेक्शन बनाएं।
* 5ms बाद, /meeting\_testjs.cgi को रेंडर करते समय पीड़ित व्यक्ति उम्मीदवारता से /appletRedirect.js इम्पोर्ट करने का प्रयास करेगा और उसे x.psres.net पर रीडायरेक्ट किया जाएगा, जो दुष्ट JS सर्व करेगा।
इसलिए, एक हमलावर एक अनुरोध को भेज सकता है **हैडर इंगित करते हुए कि एक बॉडी है**, और फिर **बॉडी भेजने से पहले फ्रंट-एंड का समय-आउट इंतजार करें**। यदि फ्रंट-एंड समय-आउट हो जाता है लेकिन **कनेक्शन खुली छोड़ देता है**, तो उस अनुरोध का **बॉडी** एक नए अनुरोध के रूप में **व्यवहारिक** होगा।
वार्निश कैश में `synth()` नामक एक सुविधा होती है, जिसके द्वारा आप एक अनुरोध को **बैक-एंड को फ़ॉरवर्ड किए बिना** एक **प्रतिक्रिया जारी** कर सकते हैं। यहां एक उदाहरण नियम दिया गया है जिसका उपयोग एक फ़ोल्डर तक पहुंच को ब्लॉक करने के लिए किया जा रहा है:
एक **आंशिक अनुरोध** को प्रोसेस करते समय जब वर्निश एक सिंथ नियम के साथ मेल खाता है, तो अगर यह **15 सेकंड** तक कोई डेटा प्राप्त नहीं करता है तो टाइमआउट हो जाता है। जब ऐसा होता है, तो यह **कनेक्शन खोले रखता है** ताकि इसे पुनः उपयोग के लिए उपयोग किया जा सके, हालांकि इसने सिर्फ सोकेट से अर्धांश अनुरोध पढ़ा है। इसका मतलब है कि अगर **क्लाइंट दूसरा अर्धांश** HTTP अनुरोध के साथ आगे बढ़ता है, तो यह एक **नया अनुरोध** के रूप में व्याख्या किया जाएगा।
एक संकटापन्न फ्रंट-एंड पर एक पॉज-आधारित डिसिंक को ट्रिगर करने के लिए, अपने हेडर भेजकर शुरू करें, एक बॉडी का वादा करें और फिर बस इंतजार करें। अंततः आपको एक प्रतिक्रिया प्राप्त होगी और जब आप अपना अनुरोध बॉडी भेजेंगे, यह एक नया अनुरोध के रूप में व्याख्या किया जाएगा:
वर्निश की तरह, यह **सर्वर आवेदन को संभालने की बजाय स्वयं प्रतिक्रिया उत्पन्न करने वाले संदर्भों** पर संकटापन्न होता है। इसका एक तरीका सर्वर स्तरीय पुनर्निर्देशन के साथ होता है: `Redirect 301 / /en`
यदि संकटापन्न सर्वर (एपाची या वर्निश इस मामले में) बैक-एंड में है, तो एक **फ्रंट-एंड** की आवश्यकता होती है जो अनुरोध को बैक-एंड सर्वर (इस मामले में HTTP हेडर) को **बफरिंग किए बिना** स्ट्रीम करता है।
इस मामले में हमलावर **जब तक वह बॉडी नहीं भेजता है, तब तक उत्तर टाइमआउट नहीं प्राप्त होगा**। लेकिन यदि उसे टाइमआउट का पता है तो यह कोई समस्या नहीं होनी चाहिए।
अमेज़न का एप्लीकेशन लोड बैलेंसर (ALB) डेटा कनेक्शन को **आवश्यकतानुसार स्ट्रीम करेगा**, लेकिन यदि वह **अर्धांश अनुरोध (टाइमआउट)** प्राप्त करने से पहले **बॉडी (अनुरोध)** प्राप्त करता है, तो वह **बॉडी नहीं भेजेगा**, इसलिए यहां एक **रेस कंडीशन** का शोषण किया जाना चाहिए:
**एपाची ALB के पीछे शोषण करने** के मामले में एक अतिशय छोटी समय-खिड़की होती है - **दोनों सर्वरों** का डिफ़ॉल्ट **टाइमआउट 60 सेकंड** होता है। इससे अनुरोध के दूसरे हिस्से को भेजने के लिए एक अत्यंत संकीर्ण समय-खिड़की बचती है। RC हमला अंततः 66 घंटे के बाद सफल रहा।
एक पॉज-डिसिंक संकटापन्नता को शोषण करने के लिए ब्राउज़र से एक अनुरोध को रोकना **संभव नहीं है** लेकिन आप हमेशा एक MITM हमला करके ब्राउज़र द्वारा भेजे गए एक अनुरोध को रोक सकते हैं। ध्यान दें कि इस हमले में किसी भी ट्रैफिक को डिक्रिप्ट करने की आवश्यकता नहीं होती है।
हमला फ्लो एक नियमित क्लाइंट-साइड डिसिंक हमले के बहुत **समान होता है**। उपयोगकर्ता एक हमलावर नियंत्रित पृष्ठ पर जाता है, जो लक्षित एप्लिकेशन को एक श्रृंखला के **क्रॉस-डोमेन अनुरोध** जारी करता है। **पहला HTTP** अनुरोध इतना **बड़ा** होता है कि ऑपरेटिंग सिस्टम इसे **एकाधिक TCP पैकेटों में विभाजित** करता है, जिससे एक सक्रिय **MITM अंतिम पैकेट को विलंबित** कर सकता है, जो एक पॉज-आधारित डिसिंक को ट्रिगर करता है। पैडिंग के कारण, **हमलावर** यह निर्धारित कर सकता है कि **कौन सा पैकेट विलंबित करें** आकार के आधार पर।
* इस पोस्ट की सभी जानकारी [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks) से ली गई है।
* क्या आप **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग** करने की इच्छा है? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
* खोजें [**The PEASS Family**](https://opensea.io/collection/the-peass-family), हमारा विशेष [**NFT**](https://opensea.io/collection/the-peass-family) संग्रह।
* प्राप्त करें [**आधिकारिक PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **शामिल हों** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में या मुझे **Twitter** पर **फ़ॉलो** करें [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **अपने हैकिंग ट्रिक्स को** [**hacktricks रेपो**](https://github.com/carlospolop/hacktricks) **और** [**hacktricks-cloud रेपो**](https://github.com/carlospolop/hacktricks-cloud) **में पीआर जमा करके अपना योगदान दें।**