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

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

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

बैकग्राउंड

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

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

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

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

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

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

ब्राउज़िंग कॉन्टेक्स्ट ग्रुप

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

Spectre की मदद से, यह सब बदल गया है. इससे, आपके कोड के ब्राउज़िंग कॉन्टेक्स्ट ग्रुप में लोड किए गए किसी भी डेटा को पढ़ा जा सकता है. कुछ खास ऑपरेशन में लगने वाले समय को मेज़र करके, हमलावर सीपीयू कैश मेमोरी के कॉन्टेंट का अनुमान लगा सकते हैं. इससे, प्रोसेस की मेमोरी के कॉन्टेंट का भी अनुमान लगाया जा सकता है. प्लैटफ़ॉर्म में मौजूद कम जानकारी वाले टाइमर की मदद से, टाइमिंग से जुड़े ऐसे हमले किए जा सकते हैं. हालांकि, ज़्यादा जानकारी वाले टाइमर की मदद से, इन हमलों को तेज़ किया जा सकता है. ये टाइमर, साफ़ तौर पर (जैसे कि performance.now()) और गुप्त तरीके से (जैसे कि SharedArrayBuffer) काम करते हैं. अगर evil.com कोई क्रॉस-ऑरिजिन इमेज एम्बेड करता है, तो वह उसका पिक्सल डेटा पढ़ने के लिए, स्पेटर अटैक का इस्तेमाल कर सकता है. इससे "ओपेसिटी" पर आधारित सुरक्षा सिस्टम काम नहीं करते.

Spectr

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

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

क्रॉस-ऑरिजिन रिसॉर्स नीति (सीओआरपी) को मूल रूप से ऑप्ट-इन के तौर पर शुरू किया गया था, ताकि आपके रिसॉर्स को किसी दूसरे ऑरिजिन से लोड होने से बचाया जा सके. सीओईपी के संदर्भ में, सीओआरपी, संसाधन के मालिक की नीति के बारे में बता सकता है कि कौन संसाधन लोड कर सकता है.

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 को खोलने वाले आइटम का रेफ़रंस दिया जाएगा.

सीओओपी

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 का इस्तेमाल करके, अपनी वेबसाइट को "क्रॉस-ऑरिजिन से अलग" करना लेख पढ़ें.

संसाधन