* क्या आप एक **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग** करने की आवश्यकता है? [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop) की जांच करें!
* खोजें [**The PEASS Family**](https://opensea.io/collection/the-peass-family), हमारा विशेष संग्रह [**NFTs**](https://opensea.io/collection/the-peass-family)
* प्राप्त करें [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **शामिल हों** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**telegram समूह**](https://t.me/peass) या **फॉलो** करें मुझे **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
यह सुरक्षा दुर्बलता उत्पन्न होती है जब **फ्रंट-एंड प्रॉक्सी** और **बैक-एंड** सर्वर के बीच एक **असमयीकरण** होता है जो एक **हमलावर** को एक HTTP **अनुरोध** भेजने की अनुमति देता है जो **फ्रंट-एंड** प्रॉक्सी (लोड बैलेंस / प्रतिरोध-प्रॉक्सी) द्वारा **एकल अनुरोध** के रूप में **व्याख्या** किया जाएगा और **बैक-एंड** सर्वर द्वारा **2 अनुरोध** के रूप में **व्याख्या** किया जाएगा।\
इससे उपयोगकर्ता को अपने के बाद बैक-एंड सर्वर तक पहुंचने वाले अगले अनुरोध को **संशोधित** करने की अनुमति मिलती है।
> यदि एक संदेश को एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संद
यहाँ, फ्रंट-एंड सर्वर `Transfer-Encoding` हैडर का उपयोग करता है और बैक-एंड सर्वर `Content-Length` हैडर का उपयोग करता है। हम निम्नलिखित तरीके से एक सरल HTTP अनुरोध धारणा हमला कर सकते हैं:
इस मामले में **रिवर्स-प्रॉक्सी** बैक-एंड को **`Transfer-encoding`** के रूप में निर्दिष्ट करने के कारण **पूरा अनुरोध** भेजेगा। लेकिन, **बैक-एंड** केवल **`7b`** (4 बाइट) को ही **प्रोसेस** करेगा जैसा कि `Content-Length` में निर्दिष्ट है। इसलिए, अगला अनुरोध `GET /404 HTTP/1.1` से शुरू होगा।
_ध्यान दें कि हालांकि हमला एक `0` के साथ समाप्त होना चाहिए, अगला अनुरोध **x** पैरामीटर के अतिरिक्त मानों के रूप में जोड़ा जाएगा।_\
_इसके अलावा, एम्बेडेड अनुरोध की Content-Length अगले अनुरोध की लंबाई को निर्दिष्ट करेगी जो **x** पैरामीटर में जोड़ा जाएगा। यदि यह बहुत छोटा है, तो कुछ बाइट ही जोड़े जाएंगे, और यदि यह बहुत बड़ा है (अगले अनुरोध की लंबाई से बड़ा है) तो अगले अनुरोध के लिए त्रुटि उठेगी।_
यहाँ, फ्रंट-एंड और बैक-एंड सर्वर दोनों `Transfer-Encoding` हैडर का समर्थन करते हैं, लेकिन इनमें से कोई एक सर्वर हेडर को किसी तरीके से अवरोधित करके इसे प्रोसेस नहीं कर सकता है।\
`Transfer-Encoding` हैडर को अवरोधित करने के लिए असीमित तरीके हो सकते हैं। उदाहरण के लिए:
**TE** हेडर को प्रोसेस नहीं करने वाले सर्वर (रिवर्स-प्रॉक्सी या बैक-एंड) के आधार पर, आपको एक **CL.TE ग़ैरसुरक्षितता** या **TE.CL ग़ैरसुरक्षितता** मिलेगी।
यदि कोई एप्लिकेशन CL.TE वेरिएंट के अनुरोध धारणा के लिए सुरक्षितता के प्रति विकल्पशील है, तो निम्नलिखित तरह का एक अनुरोध भेजने से अक्सर समय में देरी होगी:
यदि फ्रंट-एंड सर्वर `Content-Length` हैडर का उपयोग करता है, तो यह केवल इस अनुरोध का एक हिस्सा आगे भेजेगा, `0` को छोड़ देता है। बैक-एंड सर्वर `Transfer-Encoding` हैडर का उपयोग करता है, पहले चंक को प्रोसेस करता है, और फिर अगले चंक की प्रतीक्षा करता है। इससे एक दृश्यमान समय देरी होगी।
कभी-कभी, टाइमआउट प्राप्त करने की बजाय, आपको अंतिम होस्ट से 400 बेड रिक्वेस्ट प्राप्त होता है, जैसे निम्नलिखित स्थिति में, जहां एक CL.TE पेलोड भेजा जाता है:
### प्रथम-अंत सर्वर `Transfer-Encoding` हैडर का उपयोग करता है, इसलिए यह केवल इस अनुरोध का एक हिस्सा आगे भेजेगा, `X` को छोड़ देता है। बैक-एंड सर्वर `Content-Length` हैडर का उपयोग करता है, संदेश शरीर में अधिक सामग्री की उम्मीद करता है, और शेष सामग्री की पहुंच के लिए प्रतीक्षा करता है। इससे एक दृश्यमान समय देरी होगी।
जब आपने पाया है कि **समय तकनीक काम कर रही हैं**, तो आपको यह प्रोब करना होगा कि आप अन्य क्लाइंट के अनुरोधों को **संशोधित कर सकते हैं**।\
इसे करने का सबसे आसान तरीका यह है कि आप अपने अनुरोधों को दूषित करने की कोशिश करें, **उदाहरण के लिए `/` के लिए एक 404 लौटाएं**।\
[मूल उदाहरणों](./#basic-examples) में हमने पहले ही `CL.TE` और `TE.CL` उदाहरण देखे हैं, जहां एक क्लाइंट के अनुरोध को दूषित करने के लिए `/404` के लिए पूछताछ करने के लिए एक 404 प्रतिक्रिया उत्पन्न की गई थी जब क्लाइंट किसी अन्य संसाधन के लिए पूछ रहा था।
* "हमला" अनुरोध और "सामान्य" अनुरोध को सर्वर को अलग नेटवर्क कनेक्शन का उपयोग करके भेजा जाना चाहिए। दोनों अनुरोधों को एक ही कनेक्शन के माध्यम से भेजने से यह सिद्ध नहीं होगा कि दुर्गमता मौजूद है।
* "हमला" अनुरोध और "सामान्य" अनुरोध को यथासंभव समान URL और पैरामीटर नामों का उपयोग करना चाहिए। इसलिए कि कई आधुनिक एप्लिकेशन URL और पैरामीटर के आधार पर फ्रंट-एंड अनुरोधों को विभिन्न बैक-एंड सर्वरों को मार्गनिर्देशित करते हैं। समान URL और पैरामीटर का उपयोग करने से यह संभावना बढ़ जाती है कि अनुरोधों को एक ही बैक-एंड सर्वर द्वारा प्रसंस्कृत किया जाएगा, जो हमले के लिए आवश्यक है।
* "सामान्य" अनुरोध की जांच करने के लिए "हमला" अनुरोध से किसी भी हस्तक्षेप की प्रभावित होने के साथ, आप उस अनुरोध को तुरंत "हमला" अनुरोध के बाद भेजना चाहिए। यदि एप्लिकेशन व्यस्त है, तो आपको दुर्गमता की पुष्टि करने के लिए कई प्रयास करने की आवश्यकता हो सकती है।
* कुछ एप्लिकेशनों में, फ्रंट-एंड सर्वर लोड बैलेंसर की तरह कार्य करता है, और URL और पैरामीटर के आधार पर विभिन्न बैक-एंड सिस्टमों को अनुरोध भेजता है। यदि आपका "हमला" और "सामान्य" अनुरोध विभिन्न बैक-एंड सिस्टमों को प्रेषित किए जाते हैं, तो हमला असफल होगा। यह एक अतिरिक्त कारण है कि आपको दुर्गमता की पुष्टि करने के लिए कई बार प्रयास करने की आवश्यकता हो सकती है।
* यदि आपका हमला किसी भविष्यवाणी अनुरोध के साथ हस्तक्षेप करने में सफल होता है, लेकिन यह "सामान्य" अनुरोध नहीं था जिसे आपने हस्तक्षेप की पुष्टि करने के लिए भेजा था, तो इसका अर्थ है कि दूसरे एप्लिकेशन उपयोगकर्ता को आपके हमले का प्रभाव पड़ा। यदि आप परीक्षण जारी रखते हैं, तो इससे अन्य उपयोगकर्ताओं पर अस्थिर प्रभाव पड़ सकता है, और आपको सतर्कता बरतनी चाहिए।
हॉप-बाय-हॉप हेडर का दुरुपयोग करके आप प्रॉक्सी को संकेत कर सकते हैं कि **Content-Length या Transfer-Encoding हैडर को हटा दें ताकि HTTP अनुरोध स्मगलिंग का दुरुपयोग किया जा सके**।
कभी-कभी **फ्रंट-एंड प्रॉक्सी सुरक्षा जांचें करेंगे**। आप HTTP रिक्ति का दुरुपयोग करके इन्हें टाल सकते हैं क्योंकि आपको **सुरक्षा को टालने की अनुमति मिलेगी**। उदाहरण के लिए, इस उदाहरण में आप **बाहर से `/admin` तक पहुंच नहीं पा रहे हैं** और फ्रंट-एंड प्रॉक्सी इसे जांच रही है, लेकिन यह **प्रॉक्सी एम्बेडेड अनुरोध की जांच नहीं कर रही है**:
बहुत सारे एप्लिकेशनों में, **फ्रंट-एंड सर्वर अनुरोधों को पुनर्लेखित करता है** जो कि उन्हें बैक-एंड सर्वर को आगे भेजने से पहले, सामान्यतः कुछ अतिरिक्त अनुरोध हेडर जोड़कर करता है।\
एक सामान्य कार्य है कि अनुरोध में **हेडर जोड़ें**`X-Forwarded-For: <ग्राहक का IP>` या कुछ ऐसा हेडर ताकि बैक-एंड को ग्राहक का IP पता चले।\
कभी-कभी, यदि आप **पता लगा सकते हैं कि अनुरोध में कौन से नए मान जोड़े गए हैं**, तो आप सुरक्षा को टाल सकते हैं और **छिपी हुई जानकारी**/**एंडपॉइंट** तक पहुंच सकते हैं।
अनुरोध को पुनर्लेखित करने के लिए, आपको एक POST पैरामीटर ढूंढ़ना होगा जिसका वैल्यू बैक-एंड उत्तर में प्रतिबिंबित होगा। फिर, इस पैरामीटर का उपयोग अंतिम करें और इस तरह के एक एक्सप्लॉइट का उपयोग करें:
इस मामले में, अगला अनुरोध `search=` के बाद जोड़ा जाएगा जो कि भी **पैरामीटर है जिसका मान प्रतिबिंबित होगा** उत्तर में, इसलिए यह **अगले अनुरोध के हेडर प्रतिबिंबित करेगा**।
ध्यान दें कि **केवल एम्बेडेड अनुरोध के `Content-Length` हेडर में दिखाए गए लंबाई को प्रतिबिंबित किया जाएगा**। यदि आप कम संख्या का उपयोग करते हैं, तो केवल कुछ बाइट प्रतिबिंबित होंगे, यदि आप सभी हेडरों की लंबाई से बड़ी संख्या का उपयोग करते हैं, तो एम्बेडेड अनुरोध में त्रुटि होगी। फिर, आपको **एक छोटी संख्या** से **शुरू** करनी चाहिए और इसे **बढ़ाते** जाना चाहिए जब तक आपको देखना नहीं होता कि आपको क्या देखना है।\
ध्यान दें कि यह **तकनीक एक TE.CL** संक्रमण के साथ भी शोषणीय है लेकिन अनुरोध को `search=\r\n0` के साथ समाप्त होना चाहिए। हालांकि, नई पंक्ति वर्णों के बावजूद मानों को खोज पैरामीटर में जोड़ा जाएगा।
यदि वेब पृष्ठ भी **प्रतिबिंबित XSS के लिए संकटग्रस्त** है, तो आप HTTP अनुरोध स्मगलिंग का दुरुपयोग करके वेब के ग्राहकों को हमला कर सकते हैं। HTTP अनुरोध स्मगलिंग से प्रतिबिंबित XSS का शोषण कुछ लाभ हैं:
* **यह पीड़ित उपयोगकर्ता के साथ कोई संवाद नहीं आवश्यक है**
* यह उन अनुरोध के भागों में XSS व्यवहार का दुरुपयोग करने के लिए उपयोग किया जा सकता है जिन्हें एक साधारित प्रतिबिंबित XSS हमले में सरलतापूर्वक नियंत्रित नहीं किया जा सकता है, जैसे कि HTTP अनुरोध हेडर।
### HTTP अनुरोध स्मगलिंग का उपयोग करके एक साइट पुनर्निर्देश को खोले निर्देश में बदलने के लिए <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>
कई अनुप्रयोग एक URL से दूसरे URL पर साइट पुनर्निर्देश करते हैं और अनुरोध के `Host` हेडर में से होस्टनाम को पुनर्निर्देश URL में रखते हैं। इसका एक उदाहरण अपाचे और IIS वेब सर्वरों के डिफ़ॉल्ट व्यवहार है, जहां एक ट्रेलिंग स्लैश के बिना एक फ़ोल्डर के लिए एक अनुरोध एक पुनर्निर्देश प्राप्त करता है:
यह व्यवहार सामान्यतः अहानिकारक माना जाता है, लेकिन इसे एक अनुरोध स्मगलिंग हमले में दुरुपयोग किया जा सकता है ताकि अन्य उपयोगकर्ताओं को एक बाहरी डोमेन पर पुनर्निर्देशित किया जा सके। उदाहरण के लिए:
स्मगलिंग अनुरोध एक अपराधी की वेबसाइट पर पुनर्निर्देश को सक्रिय करेगा, जो पीछे की ओर संचालित किए जाने वाले सर्वर द्वारा प्रसंस्कृत किए जाने वाले अगले उपयोगकर्ता के अनुरोध पर प्रभाव डालेगा। उदाहरण के लिए:
यहां, उपयोगकर्ता का अनुरोध वेबसाइट पर एक पृष्ठ द्वारा आयातित एक जावास्क्रिप्ट फ़ाइल के लिए था। हमलावर उपयोगकर्ता को अपने जवाब में अपना जावास्क्रिप्ट पूरी तरह से प्रभावित कर सकता है।
### वेब कैश पॉइज़निंग करने के लिए HTTP अनुरोध स्मगलिंग का उपयोग करना <a href="#using-http-request-smuggling-to-perform-web-cache-poisoning" id="using-http-request-smuggling-to-perform-web-cache-poisoning"></a>
यदि किसी भी भाग में **फ्रंट-एंड बुनियादी ढांचा सामग्री कैश करता है** (आमतौर पर प्रदर्शन के कारण) तो यह **संभव हो सकता है कि सर्वर के प्रतिक्रिया को बदलकर उस कैश को दुर्गंधित किया जा सके**। हमने पहले ही देखा है कि कैसे सर्वर से अपेक्षित वापसी मूल्य को 404 (मूल उदाहरणों में) में संशोधित किया जा सकता है, एक समान तरीके से आप `/static/include.js` के लिए प्रतिबंधित अनुरोध करने पर सर्वर वापसी करने के लिए `/index.html` की सामग्री को वापसी कर सकते हैं। इस तरह, `/static/include.js` की सामग्री `/index.html` की सामग्री के साथ कैश की ज
### वेब कैश धोखाधड़ी करने के लिए एचटीटीपी अनुरोध तकनीक का उपयोग करना <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> * **वेब कैश पॉइज़निंग** में, हमलावर अनुप्रयोग को कैश में कुछ खतरनाक सामग्री संग्रहीत कराता है, और यह सामग्री कैश से अन्य अनुप्रयोग उपयोगकर्ताओं को सेवा कराई जाती है।
> * **वेब कैश धोखाधड़ी** में, हमलावर अनुप्रयोग को कैश में किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री संग्रहीत कराता है, और फिर हमलावर इस सामग्री को कैश से प्राप्त करता है।
यदि **जहर एक ऐसे क्लाइंट तक पहुंचता है जो कुछ स्थिर सामग्री** जैसे `/someimage.png` तक पहुंच रहा था जो **कैश** होने वाला था। पीड़ित का `/private/messages` का सामग्री `/someimage.png` में कैश हो जाएगा और हमलावर उन्हें चुरा सकेगा।\
ध्यान दें कि **हमलावर नहीं जानता है कि पीड़ित किस स्थिर सामग्री का उपयोग करने की कोशिश कर रहा था** इसलिए शायद सबसे अच्छा तरीका इसे परीक्षण करने के लिए हमला करना है, कुछ सेकंड प्रतीक्षा करें और सभी स्थिर सामग्री को **लोड करें** और **निजी डेटा** की खोज करें।
क्या आपने कुछ एचटीटीपी अनुरोध तकनीक की कमजोरी खोजी है और आप इसे कैसे शोषण करें इसका पता नहीं है। इस प्रकार के शोषण के लिए इन अन्य शोषण विधियों का प्रयास करें:
[यहां से छवि ली गई है।](https://twitter.com/SpiderSec/status/1200413390339887104?ref\_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104\&ref\_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104)
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): यह उपकरण विचित्र अनुरोध छेदन के लिए उपयोगी है।
* क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **HackTricks** में विज्ञापित करना चाहते हैं? या क्या आप **PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड** करना चाहते हैं? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारे विशेष [**NFTs**](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) या [telegram समूह](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 repo**](https://github.com/carlospolop/hacktricks) **और** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **में PR जमा करके अपना योगदान दें।**