HTTP Request Smuggling / HTTP Desync Attack
Last updated
Last updated
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
अपने वेब ऐप्स, नेटवर्क और क्लाउड पर एक हैकर का दृष्टिकोण प्राप्त करें
महत्वपूर्ण, शोषण योग्य कमजोरियों को खोजें और रिपोर्ट करें जिनका वास्तविक व्यापार पर प्रभाव है। हमारे 20+ कस्टम टूल का उपयोग करके हमले की सतह को मैप करें, सुरक्षा मुद्दों को खोजें जो आपको विशेषाधिकार बढ़ाने की अनुमति देते हैं, और आवश्यक सबूत इकट्ठा करने के लिए स्वचालित शोषण का उपयोग करें, जिससे आपका कठिन काम प्रभावशाली रिपोर्टों में बदल जाए।
यह कमजोरियाँ तब होती हैं जब फ्रंट-एंड प्रॉक्सी और बैक-एंड सर्वर के बीच एक डिसिंक्रोनाइजेशन होता है, जिससे एक हमलावर को एक HTTP अनुरोध भेजने की अनुमति मिलती है जिसे फ्रंट-एंड प्रॉक्सी (लोड बैलेंस/रिवर्स-प्रॉक्सी) द्वारा एकल अनुरोध के रूप में और बैक-एंड सर्वर द्वारा 2 अनुरोध के रूप में व्याख्यायित किया जाएगा। यह एक उपयोगकर्ता को उसके बाद बैक-एंड सर्वर पर आने वाले अगले अनुरोध को संशोधित करने की अनुमति देता है।
यदि एक संदेश दोनों एक 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): Content-Length हेडर के आधार पर अनुरोध को प्रोसेस करता है।
बैक-एंड (TE): Transfer-Encoding हेडर के आधार पर अनुरोध को प्रोसेस करता है।
हमला परिदृश्य:
हमलावर एक अनुरोध भेजता है जहाँ Content-Length हेडर का मान वास्तविक सामग्री की लंबाई से मेल नहीं खाता।
फ्रंट-एंड सर्वर Content-Length मान के आधार पर पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
बैक-एंड सर्वर Transfer-Encoding: chunked हेडर के कारण अनुरोध को टुकड़ों के रूप में प्रोसेस करता है, शेष डेटा को एक अलग, बाद के अनुरोध के रूप में व्याख्यायित करता है।
उदाहरण:
फ्रंट-एंड (TE): Transfer-Encoding हेडर के आधार पर अनुरोध को प्रोसेस करता है।
बैक-एंड (CL): Content-Length हेडर के आधार पर अनुरोध को प्रोसेस करता है।
हमला परिदृश्य:
हमलावर एक टुकड़ा अनुरोध भेजता है जहाँ टुकड़े का आकार (7b) और वास्तविक सामग्री की लंबाई (Content-Length: 4) मेल नहीं खाती।
फ्रंट-एंड सर्वर, Transfer-Encoding का सम्मान करते हुए, पूरे अनुरोध को बैक-एंड को अग्रेषित करता है।
बैक-एंड सर्वर, Content-Length का सम्मान करते हुए, केवल अनुरोध के प्रारंभिक भाग (7b बाइट्स) को प्रोसेस करता है, शेष को एक अनपेक्षित बाद के अनुरोध के भाग के रूप में छोड़ देता है।
उदाहरण:
सर्वर: दोनों Transfer-Encoding का समर्थन करते हैं, लेकिन एक को अस्पष्टता के माध्यम से अनदेखा करने के लिए धोखा दिया जा सकता है।
हमला परिदृश्य:
हमलावर अस्पष्ट Transfer-Encoding हेडरों के साथ एक अनुरोध भेजता है।
जिस सर्वर (फ्रंट-एंड या बैक-एंड) को अस्पष्टता पहचानने में विफलता होती है, उस पर CL.TE या TE.CL कमजोरियों का लाभ उठाया जा सकता है।
अनुरोध का अप्रसंस्कृत भाग, जैसा कि एक सर्वर द्वारा देखा गया है, एक बाद के अनुरोध का भाग बन जाता है, जिससे स्मगलिंग होती है।
उदाहरण:
दोनों सर्वर केवल Content-Length हेडर के आधार पर अनुरोध को प्रोसेस करते हैं।
यह परिदृश्य आमतौर पर स्मगलिंग की ओर नहीं ले जाता है, क्योंकि दोनों सर्वरों के अनुरोध की लंबाई की व्याख्या में संरेखण होता है।
उदाहरण:
उन परिदृश्यों को संदर्भित करता है जहाँ Content-Length हेडर मौजूद है और इसका मान शून्य के अलावा है, यह इंगित करता है कि अनुरोध शरीर में सामग्री है। बैक-एंड Content-Length हेडर को अनदेखा करता है (जिसे 0 के रूप में माना जाता है), लेकिन फ्रंट-एंड इसे पार्स करता है।
यह समझने और स्मगलिंग हमलों को तैयार करने में महत्वपूर्ण है, क्योंकि यह प्रभावित करता है कि सर्वर अनुरोध के अंत का निर्धारण कैसे करते हैं।
उदाहरण:
पिछले वाले की तरह लेकिन TE का उपयोग करते हुए।
तकनीक यहाँ रिपोर्ट की गई
उदाहरण:
यह तकनीक उन परिदृश्यों में भी उपयोगी है जहाँ प्रारंभिक HTTP डेटा पढ़ते समय एक वेब सर्वर को तोड़ना संभव है लेकिन कनेक्शन को बंद किए बिना। इस तरह, HTTP अनुरोध का शरीर अगले HTTP अनुरोध के रूप में माना जाएगा।
उदाहरण के लिए, जैसा कि इस लेख में समझाया गया है, Werkzeug में कुछ Unicode वर्ण भेजना संभव था और यह सर्वर को तोड़ देगा। हालाँकि, यदि HTTP कनेक्शन को Connection: keep-alive हेडर के साथ बनाया गया था, तो अनुरोध का शरीर नहीं पढ़ा जाएगा और कनेक्शन अभी भी खुला रहेगा, इसलिए अनुरोध का शरीर अगले HTTP अनुरोध के रूप में माना जाएगा।
हॉप-बाय-हॉप हेडर का दुरुपयोग करते हुए आप प्रॉक्सी को हेडर Content-Length या Transfer-Encoding को हटाने के लिए संकेत दे सकते हैं ताकि HTTP अनुरोध स्मगलिंग का दुरुपयोग संभव हो सके।
For more information about hop-by-hop headers visit:
hop-by-hop headersHTTP request smuggling कमजोरियों की पहचान अक्सर समय तकनीकों का उपयोग करके की जा सकती है, जो यह देखने पर निर्भर करती हैं कि सर्वर को हेरफेर किए गए अनुरोधों का जवाब देने में कितना समय लगता है। ये तकनीकें CL.TE और TE.CL कमजोरियों का पता लगाने के लिए विशेष रूप से उपयोगी हैं। इन तरीकों के अलावा, ऐसी कमजोरियों को खोजने के लिए अन्य रणनीतियाँ और उपकरण भी हैं:
Method:
एक अनुरोध भेजें जो, यदि एप्लिकेशन कमजोर है, तो बैक-एंड सर्वर को अतिरिक्त डेटा की प्रतीक्षा करने के लिए मजबूर करेगा।
Example:
Observation:
फ्रंट-एंड सर्वर Content-Length के आधार पर अनुरोध को संसाधित करता है और संदेश को समय से पहले काट देता है।
बैक-एंड सर्वर, जो एक चंक्ड संदेश की अपेक्षा कर रहा है, अगले चंक की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
Indicators:
प्रतिक्रिया में टाइमआउट या लंबी देरी।
बैक-एंड सर्वर से 400 Bad Request त्रुटि प्राप्त करना, कभी-कभी विस्तृत सर्वर जानकारी के साथ।
Method:
एक अनुरोध भेजें जो, यदि एप्लिकेशन कमजोर है, तो बैक-एंड सर्वर को अतिरिक्त डेटा की प्रतीक्षा करने के लिए मजबूर करेगा।
Example:
Observation:
फ्रंट-एंड सर्वर Transfer-Encoding के आधार पर अनुरोध को संसाधित करता है और पूरे संदेश को अग्रेषित करता है।
बैक-एंड सर्वर, जो Content-Length के आधार पर एक संदेश की अपेक्षा कर रहा है, अतिरिक्त डेटा की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
Differential Response Analysis:
अनुरोध के थोड़े भिन्न संस्करण भेजें और देखें कि क्या सर्वर प्रतिक्रियाएँ अप्रत्याशित तरीके से भिन्न होती हैं, जो एक पार्सिंग विसंगति को इंगित करती हैं।
Using Automated Tools:
Burp Suite के 'HTTP Request Smuggler' एक्सटेंशन जैसे उपकरण स्वचालित रूप से इन कमजोरियों का परीक्षण कर सकते हैं, विभिन्न प्रकार के अस्पष्ट अनुरोध भेजकर और प्रतिक्रियाओं का विश्लेषण करके।
Content-Length Variance Tests:
ऐसे अनुरोध भेजें जिनमें भिन्न Content-Length मान हों जो वास्तविक सामग्री की लंबाई के साथ मेल नहीं खाते और देखें कि सर्वर ऐसे असंगतियों को कैसे संभालता है।
Transfer-Encoding Variance Tests:
अस्पष्ट या गलत Transfer-Encoding हेडर वाले अनुरोध भेजें और देखें कि फ्रंट-एंड और बैक-एंड सर्वर ऐसे हेरफेर पर कैसे प्रतिक्रिया करते हैं।
समय तकनीकों की प्रभावशीलता की पुष्टि करने के बाद, यह सत्यापित करना महत्वपूर्ण है कि क्या क्लाइंट अनुरोधों को हेरफेर किया जा सकता है। एक सीधा तरीका यह है कि आप अपने अनुरोधों को विषाक्त बनाने का प्रयास करें, उदाहरण के लिए, / पर एक अनुरोध करना जिससे 404 प्रतिक्रिया प्राप्त हो। पहले चर्चा किए गए CL.TE और TE.CL उदाहरण Basic Examples में दिखाते हैं कि कैसे एक क्लाइंट के अनुरोध को विषाक्त करके 404 प्रतिक्रिया प्राप्त की जा सकती है, भले ही क्लाइंट एक अलग संसाधन तक पहुँचने का प्रयास कर रहा हो।
Key Considerations
जब अन्य अनुरोधों में हस्तक्षेप करके अनुरोध स्मगलिंग कमजोरियों का परीक्षण करें, तो ध्यान में रखें:
Distinct Network Connections: "हमला" और "सामान्य" अनुरोधों को अलग-अलग नेटवर्क कनेक्शनों के माध्यम से भेजा जाना चाहिए। दोनों के लिए एक ही कनेक्शन का उपयोग करना कमजोरियों की उपस्थिति को मान्य नहीं करता है।
Consistent URL and Parameters: दोनों अनुरोधों के लिए समान URLs और पैरामीटर नामों का उपयोग करने का प्रयास करें। आधुनिक एप्लिकेशन अक्सर URL और पैरामीटर के आधार पर अनुरोधों को विशिष्ट बैक-एंड सर्वरों पर रूट करते हैं। इन्हें मेल खाने से यह संभावना बढ़ती है कि दोनों अनुरोधों को एक ही सर्वर द्वारा संसाधित किया जाएगा, जो सफल हमले के लिए एक पूर्वापेक्षा है।
Timing and Racing Conditions: "सामान्य" अनुरोध, जो "हमला" अनुरोध से हस्तक्षेप का पता लगाने के लिए है, अन्य समवर्ती एप्लिकेशन अनुरोधों के खिलाफ प्रतिस्पर्धा करता है। इसलिए, "हमला" अनुरोध के तुरंत बाद "सामान्य" अनुरोध भेजें। व्यस्त एप्लिकेशन के लिए निर्णायक कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता हो सकती है।
Load Balancing Challenges: फ्रंट-एंड सर्वर जो लोड बैलेंसर के रूप में कार्य करते हैं, अनुरोधों को विभिन्न बैक-एंड सिस्टमों में वितरित कर सकते हैं। यदि "हमला" और "सामान्य" अनुरोध विभिन्न सिस्टमों पर समाप्त होते हैं, तो हमला सफल नहीं होगा। यह लोड बैलेंसिंग पहलू कमजोरियों की पुष्टि के लिए कई प्रयासों की आवश्यकता कर सकता है।
Unintended User Impact: यदि आपका हमला अनजाने में किसी अन्य उपयोगकर्ता के अनुरोध (जो "सामान्य" अनुरोध नहीं है जिसे आपने पहचान के लिए भेजा था) को प्रभावित करता है, तो यह इंगित करता है कि आपका हमला किसी अन्य एप्लिकेशन उपयोगकर्ता को प्रभावित करता है। निरंतर परीक्षण अन्य उपयोगकर्ताओं को बाधित कर सकता है, जिससे एक सतर्क दृष्टिकोण की आवश्यकता होती है।
कभी-कभी, फ्रंट-एंड प्रॉक्सी सुरक्षा उपाय लागू करते हैं, आने वाले अनुरोधों की जांच करते हैं। हालाँकि, इन उपायों को HTTP Request Smuggling का उपयोग करके दरकिनार किया जा सकता है, जिससे प्रतिबंधित एंडपॉइंट्स तक अनधिकृत पहुँच प्राप्त होती है। उदाहरण के लिए, /admin तक पहुँच बाहरी रूप से प्रतिबंधित हो सकती है, फ्रंट-एंड प्रॉक्सी सक्रिय रूप से ऐसे प्रयासों को रोकती है। फिर भी, यह प्रॉक्सी एक स्मगल्ड HTTP अनुरोध के भीतर एम्बेडेड अनुरोधों की जांच करने में विफल हो सकती है, जिससे इन प्रतिबंधों को दरकिनार करने के लिए एक छिद्र छोड़ दिया जाता है।
HTTP Request Smuggling का उपयोग करके फ्रंट-एंड सुरक्षा नियंत्रणों को दरकिनार करने के तरीके को दर्शाने वाले निम्नलिखित उदाहरणों पर विचार करें, विशेष रूप से /admin पथ को लक्षित करते हुए जो आमतौर पर फ्रंट-एंड प्रॉक्सी द्वारा संरक्षित होता है:
CL.TE Example
In CL.TE हमले में, प्रारंभिक अनुरोध के लिए Content-Length हेडर का उपयोग किया जाता है, जबकि बाद में एम्बेडेड अनुरोध Transfer-Encoding: chunked हेडर का उपयोग करता है। फ्रंट-एंड प्रॉक्सी प्रारंभिक POST अनुरोध को संसाधित करती है लेकिन एम्बेडेड GET /admin अनुरोध की जांच करने में विफल रहती है, जिससे /admin पथ तक अनधिकृत पहुंच की अनुमति मिलती है।
TE.CL Example
इसके विपरीत, TE.CL हमले में, प्रारंभिक POST अनुरोध Transfer-Encoding: chunked का उपयोग करता है, और इसके बाद का एम्बेडेड अनुरोध Content-Length हेडर के आधार पर संसाधित किया जाता है। CL.TE हमले के समान, फ्रंट-एंड प्रॉक्सी स्मगल्ड GET /admin अनुरोध को नजरअंदाज कर देती है, अनजाने में प्रतिबंधित /admin पथ तक पहुंच प्रदान करती है।
ऐप्लिकेशन अक्सर एक फ्रंट-एंड सर्वर का उपयोग करते हैं ताकि आने वाले अनुरोधों को संशोधित किया जा सके इससे पहले कि उन्हें बैक-एंड सर्वर को भेजा जाए। एक सामान्य संशोधन में हेडर जोड़ना शामिल होता है, जैसे X-Forwarded-For: <IP of the client> ताकि क्लाइंट का IP बैक-एंड को भेजा जा सके। इन संशोधनों को समझना महत्वपूर्ण हो सकता है, क्योंकि यह सुरक्षाओं को बायपास करने या छिपी हुई जानकारी या एंडपॉइंट्स को उजागर करने के तरीके प्रकट कर सकता है।
यह जांचने के लिए कि प्रॉक्सी एक अनुरोध को कैसे बदलती है, एक POST पैरामीटर खोजें जिसे बैक-एंड प्रतिक्रिया में प्रतिध्वनित करता है। फिर, इस पैरामीटर का उपयोग करते हुए एक अनुरोध तैयार करें, इसे अंतिम में रखते हुए, निम्नलिखित के समान:
इस संरचना में, बाद के अनुरोध घटक search= के बाद जोड़े जाते हैं, जो प्रतिक्रिया में परिलक्षित होने वाला पैरामीटर है। यह परिलक्षण बाद के अनुरोध के हेडर को उजागर करेगा।
यह महत्वपूर्ण है कि नेस्टेड अनुरोध के Content-Length हेडर को वास्तविक सामग्री की लंबाई के साथ संरेखित किया जाए। छोटे मान से शुरू करना और धीरे-धीरे बढ़ाना सलाहकार है, क्योंकि बहुत कम मान परिलक्षित डेटा को काट देगा, जबकि बहुत उच्च मान अनुरोध को त्रुटि में डाल सकता है।
यह तकनीक TE.CL भेद्यता के संदर्भ में भी लागू होती है, लेकिन अनुरोध को search=\r\n0 के साथ समाप्त होना चाहिए। नई लाइन के वर्णों की परवाह किए बिना, मान खोज पैरामीटर में जोड़े जाएंगे।
यह विधि मुख्य रूप से फ्रंट-एंड प्रॉक्सी द्वारा किए गए अनुरोध परिवर्तनों को समझने के लिए है, जो मूल रूप से एक आत्म-निर्देशित जांच कर रही है।
यह अगले उपयोगकर्ता के अनुरोधों को कैप्चर करना संभव है, एक POST ऑपरेशन के दौरान एक पैरामीटर के मान के रूप में एक विशिष्ट अनुरोध को जोड़कर। इसे इस प्रकार किया जा सकता है:
पैरामीटर के मान के रूप में निम्नलिखित अनुरोध को जोड़कर, आप अगले क्लाइंट के अनुरोध को स्टोर कर सकते हैं:
इस परिदृश्य में, comment parameter का उद्देश्य एक सार्वजनिक रूप से सुलभ पृष्ठ पर एक पोस्ट की टिप्पणी अनुभाग में सामग्री को संग्रहीत करना है। परिणामस्वरूप, अगले अनुरोध की सामग्री एक टिप्पणी के रूप में दिखाई देगी।
हालांकि, इस तकनीक की सीमाएँ हैं। सामान्यतः, यह केवल उस पैरामीटर डेलिमिटर तक डेटा कैप्चर करता है जो स्मगल्ड अनुरोध में उपयोग किया गया है। URL-encoded फॉर्म सबमिशन के लिए, यह डेलिमिटर & वर्ण है। इसका मतलब है कि पीड़ित उपयोगकर्ता के अनुरोध से कैप्चर की गई सामग्री पहले & पर रुक जाएगी, जो कि क्वेरी स्ट्रिंग का हिस्सा भी हो सकता है।
इसके अतिरिक्त, यह ध्यान देने योग्य है कि यह दृष्टिकोण TE.CL भेद्यता के साथ भी व्यवहार्य है। ऐसे मामलों में, अनुरोध को search=\r\n0 के साथ समाप्त होना चाहिए। नई लाइन वर्णों की परवाह किए बिना, मानों को खोज पैरामीटर में जोड़ा जाएगा।
HTTP Request Smuggling का उपयोग उन वेब पृष्ठों का शोषण करने के लिए किया जा सकता है जो Reflected XSS के प्रति संवेदनशील हैं, जो महत्वपूर्ण लाभ प्रदान करता है:
लक्षित उपयोगकर्ताओं के साथ संवाद की आवश्यकता नहीं है।
अनुरोध के उन हिस्सों में XSS का शोषण करने की अनुमति देता है जो सामान्यतः अप्राप्य होते हैं, जैसे HTTP अनुरोध हेडर।
उन परिदृश्यों में जहां एक वेबसाइट User-Agent हेडर के माध्यम से प्रतिबिंबित XSS के प्रति संवेदनशील है, निम्नलिखित पेलोड इस भेद्यता का शोषण करने का तरीका प्रदर्शित करता है:
यह पेलोड इस कमजोरियों का लाभ उठाने के लिए संरचित है:
एक POST अनुरोध शुरू करना, जो सामान्य प्रतीत होता है, जिसमें Transfer-Encoding: chunked हेडर होता है जो स्मगलिंग की शुरुआत को इंगित करता है।
इसके बाद 0 आता है, जो चंक किए गए संदेश के शरीर के अंत को चिह्नित करता है।
फिर, एक स्मगल किया गया GET अनुरोध पेश किया जाता है, जहां User-Agent हेडर में एक स्क्रिप्ट, <script>alert(1)</script>, इंजेक्ट की जाती है, जो सर्वर द्वारा इस बाद के अनुरोध को संसाधित करते समय XSS को ट्रिगर करती है।
User-Agent को स्मगलिंग के माध्यम से हेरफेर करके, पेलोड सामान्य अनुरोध सीमाओं को बायपास करता है, इस प्रकार एक गैर-मानक लेकिन प्रभावी तरीके से Reflected XSS कमजोरियों का लाभ उठाता है।
यदि उपयोगकर्ता की सामग्री एक 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 कोड शामिल हो सके।
ऐप्लिकेशन अक्सर Host हेडर से होस्टनेम का उपयोग करके एक URL से दूसरे URL पर रीडायरेक्ट करते हैं। यह Apache और IIS जैसे वेब सर्वरों के साथ सामान्य है। उदाहरण के लिए, बिना ट्रेलिंग स्लैश के एक फ़ोल्डर का अनुरोध करने पर रीडायरेक्ट होता है ताकि स्लैश शामिल किया जा सके:
परिणाम में:
हालांकि यह व्यवहार हानिरहित प्रतीत होता है, इसे HTTP request smuggling का उपयोग करके उपयोगकर्ताओं को एक बाहरी साइट पर पुनर्निर्देशित करने के लिए हेरफेर किया जा सकता है। उदाहरण के लिए:
यह स्मगल किया गया अनुरोध अगले संसाधित उपयोगकर्ता अनुरोध को एक हमलावर-नियंत्रित वेबसाइट पर पुनर्निर्देशित कर सकता है:
परिणाम में:
इस परिदृश्य में, एक उपयोगकर्ता की JavaScript फ़ाइल के लिए अनुरोध को हाईजैक किया जाता है। हमलावर संभावित रूप से उपयोगकर्ता को दुर्भावनापूर्ण JavaScript को प्रतिक्रिया में सर्व करके समझौता कर सकता है।
Web cache poisoning को निष्पादित किया जा सकता है यदि फ्रंट-एंड इन्फ्रास्ट्रक्चर के किसी भी घटक में सामग्री को कैश किया जाता है, आमतौर पर प्रदर्शन को बढ़ाने के लिए। सर्वर की प्रतिक्रिया को हेरफेर करके, कैश को ज़हरीला बनाना संभव है।
पहले, हमने देखा कि सर्वर की प्रतिक्रियाओं को 404 त्रुटि लौटाने के लिए कैसे बदला जा सकता है (देखें Basic Examples)। इसी तरह, सर्वर को /static/include.js के लिए अनुरोध के जवाब में /index.html सामग्री देने के लिए धोखा देना संभव है। परिणामस्वरूप, /static/include.js की सामग्री को कैश में /index.html की सामग्री से बदल दिया जाता है, जिससे /static/include.js उपयोगकर्ताओं के लिए अनुपलब्ध हो जाता है, जो संभावित रूप से Denial of Service (DoS) का कारण बन सकता है।
यह तकनीक विशेष रूप से शक्तिशाली हो जाती है यदि कोई Open Redirect vulnerability खोजी जाती है या यदि कोई ऑन-साइट रीडायरेक्ट एक ओपन रीडायरेक्ट की ओर होता है। ऐसी कमजोरियों का उपयोग /static/include.js की कैश की गई सामग्री को हमलावर के नियंत्रण में एक स्क्रिप्ट के साथ बदलने के लिए किया जा सकता है, जिससे सभी ग्राहकों के खिलाफ एक व्यापक Cross-Site Scripting (XSS) हमले की अनुमति मिलती है जो अपडेटेड /static/include.js का अनुरोध करते हैं।
नीचे कैश ज़हरीला बनाने और ऑन-साइट रीडायरेक्ट को ओपन रीडायरेक्ट के साथ मिलाकर शोषण का एक चित्रण है। उद्देश्य है /static/include.js की कैश सामग्री को हमलावर द्वारा नियंत्रित JavaScript कोड सर्व करने के लिए बदलना:
नोट करें कि एम्बेडेड अनुरोध /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 हमले को लॉन्च करेगा।
वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी में क्या अंतर है?
वेब कैश पॉइज़निंग में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री संग्रहीत करने के लिए मजबूर करता है, और यह सामग्री अन्य एप्लिकेशन उपयोगकर्ताओं को कैश से सेवा दी जाती है।
वेब कैश धोखाधड़ी में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में संग्रहीत करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
हमलावर एक स्मगल्ड अनुरोध तैयार करता है जो संवेदनशील उपयोगकर्ता-विशिष्ट सामग्री लाता है। निम्नलिखित उदाहरण पर विचार करें:
यदि यह स्मगल किया गया अनुरोध स्थिर सामग्री (जैसे, /someimage.png) के लिए अभिप्रेत कैश प्रविष्टि को विषाक्त करता है, तो पीड़ित का संवेदनशील डेटा /private/messages से स्थिर सामग्री के कैश प्रविष्टि के तहत कैश किया जा सकता है। परिणामस्वरूप, हमलावर संभावित रूप से इन कैश किए गए संवेदनशील डेटा को पुनः प्राप्त कर सकता है।
इस पोस्ट में सुझाव दिया गया है कि यदि सर्वर में TRACE विधि सक्षम है, तो इसे HTTP अनुरोध स्मगलिंग के साथ दुरुपयोग करना संभव हो सकता है। इसका कारण यह है कि यह विधि सर्वर को भेजे गए किसी भी हेडर को प्रतिक्रिया के शरीर के भाग के रूप में परावर्तित करेगी। उदाहरण के लिए:
ऐसी प्रतिक्रिया भेजी जाएगी:
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.
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:
ये प्रतिक्रियाएँ उत्पन्न करेगा (ध्यान दें कि HEAD प्रतिक्रिया में एक Content-Length है जो TRACE प्रतिक्रिया को HEAD शरीर का हिस्सा बनाता है और जब HEAD Content-Length समाप्त होता है, तो एक मान्य HTTP प्रतिक्रिया चुराई जाती है):
क्या आपने कुछ HTTP अनुरोध स्मगलिंग कमजोरियों का पता लगाया है और आप इसे कैसे शोषण करना है नहीं जानते। इन अन्य शोषण विधियों को आजमाएं:
HTTP Response Smuggling / Desyncब्राउज़र HTTP अनुरोध स्मगलिंग (क्लाइंट साइड)
HTTP/2 डाउनग्रेड में अनुरोध स्मगलिंग
From https://hipotermia.pw/bb/http-desync-idor
से: https://hipotermia.pw/bb/http-desync-account-takeover
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: यह उपकरण एक व्याकरण-आधारित HTTP Fuzzer है जो अजीब अनुरोध स्मगलिंग विसंगतियों को खोजने के लिए उपयोगी है।
अपने वेब ऐप्स, नेटवर्क और क्लाउड पर एक हैकर का दृष्टिकोण प्राप्त करें
महत्वपूर्ण, शोषण योग्य कमजोरियों को खोजें और रिपोर्ट करें जिनका वास्तविक व्यापार पर प्रभाव है। हमारे 20+ कस्टम उपकरणों का उपयोग करके हमले की सतह को मैप करें, सुरक्षा मुद्दों को खोजें जो आपको विशेषाधिकार बढ़ाने की अनुमति देते हैं, और आवश्यक सबूत इकट्ठा करने के लिए स्वचालित शोषण का उपयोग करें, जिससे आपका कठिन काम प्रभावशाली रिपोर्टों में बदल जाए।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
