2015-02-15 7 views
9

CORS के लिए विकिपीडिया पृष्ठ में क्रॉस-साइट स्क्रिप्टिंग (एक्सएसएस) का उल्लेख किया गया है। लेकिन मैं नहीं देखता कि वे कैसे संबंधित हैं। सीओआरएस और एक्सएसएस के बीच क्या संबंध है?क्या सीओआरएस और एक्सएसएस का कोई कनेक्शन है?

+0

एक्सएसएस का उपयोग सीओआरएस के प्रतिबंध को बाईपास करने के लिए किया जा सकता है यदि आप किसी अनुमत मूल से अनुरोध करने के लिए एक्सएसएस भेद्यता का लाभ उठाते हैं। – Gumbo

+0

@ गम्बो मुझे यकीन नहीं है कि मुझे आपका अंक मिल गया है या नहीं। कहें एक्सएसएस मुद्दे के साथ साइट ए से एक पेज है। मैं बी साइट से ए के पेज में एक स्क्रिप्ट इंजेक्ट करता हूं। ए साइट सी की अनुमत साइट सूची में है। इसलिए अब इंजेक्शन बी स्क्रिप्ट सी में सामग्री तक पहुंच सकती है लेकिन मुझे लगता है कि बी स्क्रिप्ट को सीओआरएस मानक का पालन करना होगा जैसे कि सी – smwikipedia

+0

के साथ संवाद करने के लिए कुछ आवश्यक शीर्षलेख जोड़ें। यह सही है। लेकिन ब्राउजर आपके लिए स्वचालित रूप से ऐसा करेगा। – Gumbo

उत्तर

1

उदाहरण के लिए: आप अपने जेएस कोड इंजेक्ट कर सकते हैं, जो आपको कुछ पेज (xss) में उपयोगकर्ताओं की कुकीज़ चुरा सकता है। आप इसे कोरस के लिए धन्यवाद कर सकते हैं।

आशा है कि मैं झूठी नहीं हूं। शायद कोई आपको बेहतर उत्तर देगा।

6

जेएसओएनपी के संबंध में विकिपीडिया लेख पर एक्सएसएस का उल्लेख किया गया है, न कि कॉर्स।

<script src="https://example.com/jsonp.aspx?callback=foo"></script> 

फिर आप foo कहा जाता है अपने पृष्ठ पर एक जावास्क्रिप्ट समारोह है कि बाहरी साइट से बुलाया जाएगा है:

JSONP में आप एक पेज डेटा वाली तुम इतनी तरह अपने पेज में ग्राहक के पक्ष शामिल करना चाहते हैं को संदर्भित (example.com इस मामले में) उस डेटा को पास करने के लिए जो आपके क्लाइंट-साइड की आवश्यकता है।

हालांकि, अगर example.com समझौता हो जाता है और आप example.com पर स्क्रिप्ट के स्रोत के रूप में भरोसा कर रहे हैं तो हमलावर आपकी साइट को इसके साथ ले जा सकता है और क्लाइंट साइड कोड का मालिक हो सकता है। उदाहरण के लिए, वे आगंतुकों को अपनी साइट पर रीडायरेक्ट कर सकते हैं, अपने आगंतुकों की कुकीज़ भेज सकते हैं या अपने foo फ़ंक्शन को कॉल करने के बजाय जावास्क्रिप्ट कीलॉगर्स इंजेक्शन दे सकते हैं।

CORS साथ

हालांकि, example.com सेट करता है, तो सही हेडर अपनी साइट AJAX यह करने के लिए कॉल कर सकते हैं और डेटा पुनर्प्राप्त, तो के रूप में आप बल्कि HTML से untrused इनपुट के रूप में डेटा के इलाज होना चाहिए अनुमति देने के लिए, यह कम होने की संभावना है कि आपकी साइट पर असफलता से समझौता किया गया है। यह इस बात पर निर्भर करता है कि डेटा क्या है - यदि यह वास्तव में पूर्ववर्ती HTML है और आप इसे आउटपुट कर रहे हैं तो एक समझौता बाहरी साइट अभी भी एक्सएसएस के माध्यम से आपकी प्रभावित हो सकती है - हालांकि, यह निश्चित रूप से JSONP के मामले में है।

एक और मुद्दा यह है कि यदि आपकी साइट पर कोई भी एक्सएसएस बग है, तो यह किसी भी सीओआरएस प्रतिबंध अप्रासंगिक बना देगा। हमला करने वाली वेबसाइट XHR के बजाय डीओएम स्तर पर Same Origin Policy को "बाईपास" करने के लिए एक्सएसएस वूलन का उपयोग करने में सक्षम होगी। अगर उन्हें कुछ जानकारी की आवश्यकता होती है जिसे केवल एजेक्स अनुरोध द्वारा आपके मूल से पुनर्प्राप्त किया जा सकता है, तो वे बस ऐसा करने के लिए आवश्यक स्क्रिप्ट को इंजेक्ट करने के लिए एक्सएसएस हमले का उपयोग करेंगे और इसे अपने डोमेन पर वापस भेज देंगे।

+0

सबसे उपयोगी उत्तर, afaic – dalvarezmartinez1

1

https://www.e-systems.tech/documents/20143/30947/main.pdf

हाँ, वे बहुत जुड़े हुए हैं। जब मैं इस अनुत्तरित धागे में आया तो मैं इस मामले की खोज कर रहा था। असल में, यह छोटी, सरल और सार्वजनिक सामग्री के लिए एक समस्या नहीं होनी चाहिए।

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

मेरे शोध पर मैंने पाया कि सीओआरएस सबसे आम भेद्यता, विशेष रूप से हाइब्रिड और बहुस्तरीय हमलों के साथ समस्याओं का कारण बन जाएगा; एक्सएसएस-सीएसआरएफ जैसे जोड़े।

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

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

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

+0

क्या आपका पेपर प्रकाशित/ऑनलाइन उपलब्ध है? – jeremy

+0

इसके अलावा: http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html – Victor

+0

आलेख स्थानांतरित हो गया: https://www.e-systems.tech/est-framework/-/knowledge_base/CORS/CORS – Victor

संबंधित मुद्दे