जानें कि SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), और ज़्यादा सटीक हाई रिज़ॉल्यूशन टाइमर जैसी सुविधाओं का इस्तेमाल करने के लिए, क्रॉस-ऑरिजिन आइसोलेशन क्यों ज़रूरी है.
परिचय
COOP और COEP का इस्तेमाल करके, अपनी वेबसाइट को "क्रॉस-ऑरिजिन आइसोलेटेड" बनाना लेख में, हमने COOP और COEP का इस्तेमाल करके, "क्रॉस-ऑरिजिन आइसोलेटेड" स्थिति को अपनाने का तरीका बताया है. यह एक सहयोगी लेख है. इसमें बताया गया है कि ब्राउज़र पर बेहतर सुविधाएं चालू करने के लिए, क्रॉस-ऑरिजिन आइसोलेशन क्यों ज़रूरी है.
बैकग्राउंड
वेब, एक ही ऑरिजिन की नीति पर आधारित है. यह एक सुरक्षा सुविधा है. यह सुविधा, इस बात पर पाबंदी लगाती है कि दस्तावेज़ और स्क्रिप्ट, किसी दूसरे ऑरिजिन के संसाधनों के साथ कैसे इंटरैक्ट कर सकते हैं. इस सिद्धांत के तहत, वेबसाइटों के लिए क्रॉस-ऑरिजिन संसाधनों को ऐक्सेस करने के तरीकों पर पाबंदी लगाई जाती है. उदाहरण के लिए, https://a.example के किसी दस्तावेज़ को https://b.example पर होस्ट किए गए डेटा को ऐक्सेस करने से रोका जाता है.
हालांकि, एक ही ऑरिजिन से जुड़ी नीति के कुछ अपवाद रहे हैं. कोई भी वेबसाइट:
- क्रॉस-ऑरिजिन iframe एम्बेड करना
- इसमें अलग-अलग ऑरिजिन के रिसॉर्स शामिल हों, जैसे कि इमेज या स्क्रिप्ट
- डीओएम रेफ़रंस की मदद से, अलग-अलग ऑरिजिन वाली पॉप-अप विंडो खोलना
अगर वेब को शुरू से डिज़ाइन किया जा सकता, तो ये अपवाद मौजूद नहीं होते. माफ़ करें, जब तक वेब कम्यूनिटी को स्ट्रिक्ट सेम-ऑरिजिन नीति के मुख्य फ़ायदों के बारे में पता चला, तब तक वेब पहले से ही इन अपवादों पर भरोसा कर रहा था.
एक ही ऑरिजिन वाली इस नीति के सुरक्षा से जुड़े साइड इफ़ेक्ट को दो तरीकों से ठीक किया गया. इसके लिए, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) नाम का एक नया प्रोटोकॉल लॉन्च किया गया. इसका मकसद यह पक्का करना है कि सर्वर, किसी दिए गए ऑरिजिन के साथ रिसॉर्स शेयर करने की अनुमति दे. दूसरा तरीका यह है कि बैकवर्ड कंपैटिबिलिटी को बनाए रखते हुए, क्रॉस-ऑरिजिन रिसॉर्स के लिए स्क्रिप्ट के डायरेक्ट ऐक्सेस को हटा दिया जाए. ऐसे क्रॉस-ऑरिजिन संसाधनों को "ओपेक" संसाधन कहा जाता है. उदाहरण के लिए, यही वजह है कि CanvasRenderingContext2D के ज़रिए, क्रॉस-ऑरिजिन इमेज के पिक्सल में बदलाव नहीं किया जा सकता. ऐसा तब तक नहीं किया जा सकता, जब तक इमेज पर सीओआरएस लागू न हो.
नीति से जुड़े ये सभी फ़ैसले, ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में लिए जा रहे हैं.
काफ़ी समय तक, सीओआरएस और ओपेक रिसॉर्स का कॉम्बिनेशन, ब्राउज़र को सुरक्षित रखने के लिए काफ़ी था. कभी-कभी, कुछ खास मामलों (जैसे कि JSON की कमज़ोरियां)) का पता चला और उन्हें ठीक करने की ज़रूरत पड़ी. हालांकि, कुल मिलाकर इस सिद्धांत का पालन किया गया कि क्रॉस-ऑरिजिन रिसॉर्स के रॉ बाइट को सीधे तौर पर पढ़ने की अनुमति नहीं दी जाएगी.
Spectre के आने के बाद, यह सब बदल गया. इसकी वजह से, आपके कोड के साथ एक ही ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में लोड किया गया कोई भी डेटा पढ़ा जा सकता है. कुछ कार्रवाइयों में लगने वाले समय का पता लगाकर, हमलावर सीपीयू कैश के कॉन्टेंट का अनुमान लगा सकते हैं. इससे वे प्रोसेस की मेमोरी के कॉन्टेंट का भी अनुमान लगा सकते हैं. प्लैटफ़ॉर्म में मौजूद कम ग्रैन्युलैरिटी वाले टाइमर की मदद से, इस तरह के टाइमिंग अटैक किए जा सकते हैं. हालांकि, ज़्यादा ग्रैन्युलैरिटी वाले टाइमर की मदद से, इन्हें तेज़ी से किया जा सकता है. ये टाइमर, साफ़ तौर पर (जैसे, performance.now()) और इंप्लिसिट तौर पर (जैसे, SharedArrayBuffers) दोनों तरह के हो सकते हैं. अगर evil.com किसी दूसरे ऑरिजिन की इमेज को एम्बेड करता है, तो वह स्पेक्ट्र अटैक का इस्तेमाल करके उसके पिक्सल डेटा को पढ़ सकता है. इससे "ओपेसिटी" पर निर्भर रहने वाली सुरक्षाएं असरदार नहीं रहती हैं.
सबसे सही तरीका यह है कि अलग-अलग ऑरिजिन से किए गए सभी अनुरोधों की जांच, उस सर्वर को करनी चाहिए जिसके पास संसाधन का मालिकाना हक है. अगर संसाधन के मालिक वाले सर्वर से जांच की सुविधा नहीं मिलती है, तो डेटा कभी भी बुरे मकसद से काम करने वाले व्यक्ति के ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में नहीं जाएगा. इसलिए, यह किसी भी ऐसे स्पेकटर अटैक की पहुंच से बाहर रहेगा जो कोई वेब पेज कर सकता है. हम इसे क्रॉस-ऑरिजिन आइसोलेटेड स्टेट कहते हैं. COOP+COEP का मकसद भी यही है.
क्रॉस-ऑरिजिन आइसोलेटेड स्टेट में, अनुरोध करने वाली साइट को कम खतरनाक माना जाता है. इससे SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), और हाई रिज़ॉल्यूशन वाले टाइमर जैसी बेहतर सुविधाएं अनलॉक हो जाती हैं. इनका इस्तेमाल, Spectre जैसे हमलों के लिए किया जा सकता है. इससे document.domain में बदलाव नहीं किया जा सकेगा.
क्रॉस ओरिजन एम्बेडर नीति
क्रॉस ओरिजिन एम्बेडर नीति (सीओईपी), किसी दस्तावेज़ को ऐसे क्रॉस-ऑरिजिन रिसॉर्स लोड करने से रोकती है जिन्होंने दस्तावेज़ को अनुमति नहीं दी है. इसके लिए, सीओआरपी या सीओआरएस का इस्तेमाल किया जाता है. इस सुविधा की मदद से, यह एलान किया जा सकता है कि कोई दस्तावेज़ इस तरह के संसाधनों को लोड नहीं कर सकता.
इस नीति को चालू करने के लिए, दस्तावेज़ में यह एचटीटीपी हेडर जोड़ें:
Cross-Origin-Embedder-Policy: require-corp
COEP, require-corp की सिर्फ़ एक वैल्यू लेता है. इससे यह नीति लागू होती है कि दस्तावेज़ सिर्फ़ एक ही ऑरिजिन से रिसॉर्स लोड कर सकता है. इसके अलावा, ऐसे रिसॉर्स लोड कर सकता है जिन्हें साफ़ तौर पर किसी दूसरे ऑरिजिन से लोड किए जा सकने वाले रिसॉर्स के तौर पर मार्क किया गया हो.
किसी दूसरे ऑरिजिन से लोड किए जा सकने वाले संसाधनों के लिए, यह ज़रूरी है कि वे क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) या क्रॉस-ऑरिजिन रिसॉर्स नीति (सीओआरपी) के साथ काम करते हों.
क्रॉस ओरिजिन रिसॉर्स शेयरिंग
अगर कोई क्रॉस-ऑरिजिन रिसॉर्स, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) के साथ काम करता है, तो उसे अपने वेब पेज पर लोड करने के लिए, crossorigin एट्रिब्यूट का इस्तेमाल किया जा सकता है. ऐसा करने पर, सीओईपी उसे ब्लॉक नहीं करेगा.
<img src="https://third-party.example.com/image.jpg" crossorigin>
उदाहरण के लिए, अगर इस इमेज रिसॉर्स को सीओआरएस हेडर के साथ दिखाया जाता है, तो crossorigin एट्रिब्यूट का इस्तेमाल करें. इससे रिसॉर्स को फ़ेच करने का अनुरोध, सीओआरएस मोड का इस्तेमाल करेगा. इससे इमेज को तब तक लोड होने से रोका जाता है, जब तक कि वह सीओआरएस हेडर सेट न कर दे.
इसी तरह, fetch() तरीके से क्रॉस ऑरिजिन डेटा फ़ेच किया जा सकता है. इसके लिए, किसी खास तरीके से डेटा को मैनेज करने की ज़रूरत नहीं होती. हालांकि, ऐसा तब तक होता है, जब तक सर्वर सही एचटीटीपी हेडर के साथ जवाब देता है.
क्रॉस ओरिजन रिसॉर्स पॉलिसी
क्रॉस ऑरिजिन रिसॉर्स पॉलिसी (सीओआरपी) को मूल रूप से ऑप्ट-इन के तौर पर पेश किया गया था. इसका मकसद, आपके संसाधनों को किसी दूसरे ऑरिजिन से लोड होने से बचाना था. COEP के संदर्भ में, CORP यह तय कर सकता है कि संसाधन का मालिक कौन है और कौन संसाधन को लोड कर सकता है.
Cross-Origin-Resource-Policy हेडर के लिए तीन वैल्यू दी जा सकती हैं:
Cross-Origin-Resource-Policy: same-site
same-site के तौर पर मार्क किए गए संसाधनों को सिर्फ़ उसी साइट से लोड किया जा सकता है.
Cross-Origin-Resource-Policy: same-origin
same-origin के तौर पर मार्क किए गए संसाधनों को सिर्फ़ एक ही ऑरिजिन से लोड किया जा सकता है.
Cross-Origin-Resource-Policy: cross-origin
cross-origin के तौर पर मार्क की गई संसाधन फ़ाइलों को कोई भी वेबसाइट लोड कर सकती है. (यह वैल्यू, सीओईपी के साथ-साथ CORP स्पेसिफ़िकेशन में भी जोड़ी गई थी.)
क्रॉस ओरिजन ओपनर पॉलिसी
क्रॉस ऑरिजिन ओपनर नीति (सीओओपी) की मदद से, यह पक्का किया जा सकता है कि टॉप-लेवल विंडो को अन्य दस्तावेज़ों से अलग रखा गया हो. इसके लिए, उन दस्तावेज़ों को किसी दूसरे ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में रखा जाता है, ताकि वे सीधे तौर पर टॉप-लेवल विंडो के साथ इंटरैक्ट न कर सकें. उदाहरण के लिए, अगर COOP वाला कोई दस्तावेज़ पॉप-अप खोलता है, तो उसकी window.opener प्रॉपर्टी null होगी. साथ ही, ओपनर के रेफ़रंस की .closed प्रॉपर्टी, true वैल्यू दिखाएगी.
Cross-Origin-Opener-Policy हेडर के लिए तीन वैल्यू दी जा सकती हैं:
Cross-Origin-Opener-Policy: same-origin
same-origin के तौर पर मार्क किए गए दस्तावेज़, एक ही ऑरिजिन के उन दस्तावेज़ों के साथ एक ही ब्राउज़िंग कॉन्टेक्स्ट ग्रुप शेयर कर सकते हैं जिन्हें साफ़ तौर पर same-origin के तौर पर मार्क किया गया है.
Cross-Origin-Opener-Policy: same-origin-allow-popups
same-origin-allow-popups वाला टॉप-लेवल का दस्तावेज़, अपने किसी भी पॉप-अप के रेफ़रंस को बनाए रखता है. ये ऐसे पॉप-अप होते हैं जो COOP सेट नहीं करते या unsafe-none का COOP सेट करके, आइसोलेशन से ऑप्ट आउट करते हैं.
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none डिफ़ॉल्ट वैल्यू है. इससे दस्तावेज़ को ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में जोड़ा जा सकता है. हालांकि, ऐसा सिर्फ़ तब किया जा सकता है, जब दस्तावेज़ खोलने वाले व्यक्ति के पास same-origin का COOP न हो.
खास जानकारी
अगर आपको SharedArrayBuffer, performance.measureUserAgentSpecificMemory() या बेहतर सटीक टाइमिंग के साथ हाई रिज़ॉल्यूशन वाले टाइमर जैसी बेहतरीन सुविधाओं का ऐक्सेस चाहिए, तो बस यह ध्यान रखें कि आपके दस्तावेज़ में COEP की वैल्यू require-corp और COOP की वैल्यू same-origin, दोनों का इस्तेमाल किया गया हो. इनमें से किसी भी सुविधा के न होने पर, ब्राउज़र यह गारंटी नहीं देगा कि उन सुविधाओं को सुरक्षित तरीके से चालू करने के लिए, ज़रूरी आइसोलेशन उपलब्ध है. अपने पेज की स्थिति का पता लगाने के लिए, देखें कि self.crossOriginIsolated, true दिखाता है या नहीं.
इसे लागू करने का तरीका जानने के लिए, COOP और COEP का इस्तेमाल करके अपनी वेबसाइट को "क्रॉस-ऑरिजिन आइसोलेटेड" बनाना पर जाएं.