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