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