बेहतरीन सुविधाओं के लिए, आपको "क्रॉस-ऑरिजिन आइसोलेटेड" की ज़रूरत क्यों है

पब्लिश होने की तारीख: 4 मई, 2020

COOP और COEP का इस्तेमाल करके, अपनी वेबसाइट को "क्रॉस-ऑरिजिन आइसोलेटेड" बनाने के तरीके में, हमने बताया है कि COOP और COEP का इस्तेमाल करके, "क्रॉस-ऑरिजिन आइसोलेटेड" स्थिति को कैसे अपनाया जा सकता है. यह एक साथ पढ़ने वाला लेख है. इसमें बताया गया है कि ब्राउज़र पर काम की सुविधाएं चालू करने के लिए, क्रॉस-ऑरिजिन आइसोलेशन की ज़रूरत क्यों होती है.

शब्दावली

इस दस्तावेज़ में, एक जैसे नाम और संक्षिप्त शब्दों वाली कई शब्दावली का इस्तेमाल किया गया है. इसलिए, हमने एक मिनी ग्लॉसरी तैयार की है:

बैकग्राउंड

वेब, _एक ही ऑरिजिन से जुड़ी नीति_ पर काम करता है. यह एक सुरक्षा सुविधा है. इसकी मदद से, यह तय किया जाता है कि दस्तावेज़ और स्क्रिप्ट, किसी दूसरे ऑरिजिन के रिसॉर्स के साथ कैसे इंटरैक्ट कर सकते हैं. इस सिद्धांत से, यह तय होता है कि वेबसाइटें, क्रॉस-ऑरिजिन रिसॉर्स को कैसे ऐक्सेस कर सकती हैं. उदाहरण के लिए, https://a.example का कोई दस्तावेज़, https://b.example पर होस्ट किए गए डेटा को ऐक्सेस नहीं कर सकता.

हालांकि, एक ही ऑरिजिन से जुड़ी नीति के कुछ अपवाद भी रहे हैं. कोई भी वेबसाइट:

  • क्रॉस-ऑरिजिन iframe एम्बेड कर सकती है
  • क्रॉस-ऑरिजिन रिसॉर्स शामिल कर सकती है. जैसे, इमेज या स्क्रिप्ट
  • डीओएम रेफ़रंस के साथ, क्रॉस-ऑरिजिन डायलॉग विंडो खोल सकती है

जब तक वेब कम्यूनिटी को एक ही ऑरिजिन से जुड़ी सख्त नीति के फ़ायदों के बारे में पता चला, तब तक वेब पहले से ही इन अपवादों पर निर्भर था.

एक ही ऑरिजिन से जुड़ी इस तरह की ढीली नीति के सुरक्षा से जुड़े साइड इफ़ेक्ट को दो तरीकों से ठीक किया गया:

  • क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) प्रोटोकॉल यह पक्का करता है कि सर्वर, किसी दिए गए ऑरिजिन के साथ कोई रिसॉर्स शेयर करने की अनुमति दे.
  • डेवलपर, बैकवर्ड कंपैटिबिलिटी बनाए रखते हुए, क्रॉस-ऑरिजिन रिसॉर्स को स्क्रिप्ट से सीधे ऐक्सेस करने की सुविधा को हटा देते हैं. ऐसे क्रॉस-ऑरिजिन रिसॉर्स को "ओपेक" रिसॉर्स कहा जाता है. इसलिए, CanvasRenderingContext2D की मदद से, क्रॉस-ऑरिजिन पिक्सल में बदलाव नहीं किया जा सकता. हालांकि, अगर इमेज पर सीओआरएस लागू किया जाता है, तो ऐसा किया जा सकता है.

नीति से जुड़े ये सभी फ़ैसले, ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में लिए जाते हैं.

ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में, प्राइमरी साइट और एम्बेड की गई साइट की ऐसेट शामिल होती हैं.

काफ़ी समय तक, ब्राउज़र को सुरक्षित रखने के लिए, यह कॉम्बिनेशन काफ़ी था. हालांकि, कुछ ऐसे मामले भी सामने आए जिनमें सीधे तौर पर पैचिंग की ज़रूरत पड़ी. जैसे, JSON की कमज़ोरियां.

Spectre की वजह से, यह स्थिति बदल गई है. इसकी मदद से, आपके कोड के साथ एक ही ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में लोड किया गया कोई भी डेटा पढ़ा जा सकता है. कुछ कार्रवाइयों में लगने वाले समय को मेज़र करके, हमलावर सीपीयू कैश के कॉन्टेंट का अनुमान लगा सकते हैं. इसलिए, वे प्रोसेस की मेमोरी के कॉन्टेंट का भी अनुमान लगा सकते हैं. प्लेटफ़ॉर्म में मौजूद कम ग्रैन्युलैरिटी वाले टाइमर की मदद से, इस तरह के हमले किए जा सकते हैं. साथ ही, इन्हें ज़्यादा ग्रैन्युलैरिटी वाले टाइमर की मदद से तेज़ किया जा सकता है. ये टाइमर, साफ़ तौर पर (जैसे, performance.now()) और इंप्लिसिट (जैसे, SharedArrayBuffers) दोनों तरह के हो सकते हैं.

अगर evil.com, क्रॉस-ऑरिजिन इमेज एम्बेड करता है, तो वह Spectre हमले का इस्तेमाल करके, एम्बेड की गई इमेज के पिक्सल डेटा को पढ़ सकता है. इससे, "ओपेकनेस" पर निर्भर रहने वाली सुरक्षाएं काम नहीं करतीं.

Evil.com मुख्य वेबसाइट है. यह Spectre का इस्तेमाल करके, एंबेड किए गए b.example iframe और इमेज पर हमला करती है.

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

जब एम्बेड किया गया कोड, क्रॉस-ऑरिजिन आइसोलेटेड स्थिति में होता है, तो अनुरोध करने वाली साइट को कम खतरनाक माना जाता है. इससे, अनुरोध करने वाली साइट, SharedArrayBuffer, performance.measureUserAgentSpecificMemory() और हाई रिज़ॉल्यूशन वाले टाइमर का इस्तेमाल बेहतर सटीक तरीके से कर सकती है. साथ ही, Spectre के हमलों को रोका जा सकता है. इस स्थिति में, document.domain में बदलाव नहीं किया जा सकता.

क्रॉस-ऑरिजिन एम्बेडर नीति

क्रॉस-ऑरिजिन एम्बेडर नीति (सीओईपी) किसी दस्तावेज़ को, ऐसे क्रॉस-ऑरिजिन रिसॉर्स लोड करने से रोकती है जो CORP या सीओआरएस की मदद से, दस्तावेज़ को साफ़ तौर पर अनुमति नहीं देते. इस सुविधा की मदद से, यह एलान किया जा सकता है कि कोई दस्तावेज़, ऐसे रिसॉर्स लोड नहीं कर सकता.

एक ऐसा डायग्राम जिसमें यह दिखाया गया है कि सीओआरपी नीतियों की वजह से, किन एम्बेड की गई ऐसेट को अनुमति है और किनको नहीं.
पैरंट साइट, a.example, ने सीओईपी नीति को require-corp पर सेट किया है. a.example , b.example से तीन ऐसेट एम्बेड करना चाहता है, लेकिन सिर्फ़ दो ऐसेट एम्बेड हो पाती हैं. एम्बेड की गई दो ऐसेट में, क्रॉस-ऑरिजिन CORP नीति वाली JavaScript फ़ाइल और सीओआरएस की अनुमति वाली इमेज शामिल है. तीसरी ऐसेट एक वीडियो है. इसकी CORP नीति के मुताबिक, इसे सिर्फ़ एक ही ऑरिजिन पर एम्बेड किया जा सकता है. इसलिए, वीडियो को a.example पर लोड नहीं किया जाएगा.

इस नीति को चालू करने के लिए, दस्तावेज़ में यह एचटीटीपी हेडर जोड़ें:

Cross-Origin-Embedder-Policy: require-corp

सीओईपी की वैल्यू सिर्फ़ 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 के तौर पर मार्क किए गए रिसॉर्स, किसी भी वेबसाइट से लोड किए जा सकते हैं. (इस वैल्यू को, सीओआरपी की खास जानकारी में, सीओईपी के साथ-साथ जोड़ा गया था.)

क्रॉस-ऑरिजिन ओपनर नीति

क्रॉस-ऑरिजिन ओपनर नीति (सीओओपी) की मदद से, टॉप-लेवल विंडो को अन्य दस्तावेज़ों से आइसोलेट किया जा सकता है. इसके लिए, दस्तावेज़ों को अलग ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में रखा जाता है. इस तरह, दस्तावेज़ सीधे तौर पर टॉप-लेवल विंडो के साथ इंटरैक्ट नहीं कर सकते. उदाहरण के लिए, अगर सीओओपी वाला कोई दस्तावेज़, डायलॉग खोलता है, तो उसकी window.opener प्रॉपर्टी null होती है. ओपनर के रेफ़रंस की .closed प्रॉपर्टी true होती है.

a.example, b.example को डायलॉग बॉक्स में नहीं खोल सका.

Cross-Origin-Opener-Policy हेडर की तीन वैल्यू हो सकती हैं:

Cross-Origin-Opener-Policy: same-origin

same-origin के तौर पर मार्क किए गए दस्तावेज़, एक ही ऑरिजिन के उन दस्तावेज़ों के साथ एक ही ब्राउज़िंग कॉन्टेक्स्ट ग्रुप शेयर कर सकते हैं जिन्हें साफ़ तौर पर same-origin के तौर पर मार्क किया गया है.

इस इमेज में, एक विंडो को दिखाया गया है. यह विंडो, 'same-origin' पॉप-अप से इंटरैक्ट कर सकती है. यह पॉप-अप, उसी ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में है. हालांकि, यह ब्राउज़िंग कॉन्टेक्स्ट ग्रुप से बाहर है. इसलिए, इसे 'same-origin' के तौर पर लेबल नहीं किया गया है.

Cross-Origin-Opener-Policy: same-origin-allow-popups

same-origin-allow-popups वाला टॉप-लेवल दस्तावेज़, अपने उन पॉप-अप के रेफ़रंस बनाए रखता है जिनमें सीओओपी सेट नहीं है या जिन्होंने सीओओपी को unsafe-none पर सेट करके, आइसोलेशन से ऑप्ट आउट किया है.

COOP

Cross-Origin-Opener-Policy: unsafe-none

unsafe-none डिफ़ॉल्ट वैल्यू है. इसकी मदद से, दस्तावेज़ को उसके ओपनर के ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में जोड़ा जा सकता है. हालांकि, ऐसा तब नहीं किया जा सकता, जब ओपनर का सीओओपी, same-origin पर सेट हो.

खास जानकारी

अगर आपको SharedArrayBuffer, performance.measureUserAgentSpecificMemory() या बेहतर सटीक तरीके से काम करने वाले हाई रिज़ॉल्यूशन वाले टाइमर जैसी सुविधाओं को ऐक्सेस करना है, तो आपके दस्तावेज़ को सीओईपी और सीओओपी, दोनों का इस्तेमाल करना होगा. सीओईपी की वैल्यू require-corp और सीओओपी की वैल्यू same-origin होनी चाहिए. इनमें से किसी भी सुविधा के न होने पर, ब्राउज़र उन काम की सुविधाओं को सुरक्षित तरीके से चालू करने के लिए, आइसोलेशन की गारंटी नहीं देगा. अपनी पेज की स्थिति का पता यह देखकर लगाया जा सकता है कि self.crossOriginIsolated की वैल्यू true है या नहीं.

इसे लागू करने का तरीका जानने के लिए, COOP और COEP का इस्तेमाल करके, अपनी वेबसाइट को "क्रॉस-ऑरिजिन आइसोलेटेड" बनाने का तरीका लेख पढ़ें.

संसाधन