डेस्कटॉप पर Chrome 67 में एक नई सुविधा है, जिसे साइट आइसोलेशन कहा जाता है. यह सुविधा डिफ़ॉल्ट रूप से चालू होती है. इस लेख में बताया गया है कि साइट आइसोलेशन क्या है, यह क्यों ज़रूरी है, और वेब डेवलपर को इसकी जानकारी क्यों होनी चाहिए.
साइट आइसोलेशन क्या है?
इंटरनेट का इस्तेमाल, बिल्ली के वीडियो देखने और क्रिप्टो करंसी वॉलेट मैनेज करने के साथ-साथ कई अन्य कामों के लिए किया जाता है. हालांकि, आपके पास यह तय करने का विकल्प होता है कि fluffycats.example को आपके कीमती क्रिप्टो करंसी का ऐक्सेस मिले या नहीं! आम तौर पर, एक ही सोर्स वाली नीति की वजह से, वेबसाइटें ब्राउज़र में एक-दूसरे का डेटा ऐक्सेस नहीं कर सकतीं. फिर भी, नुकसान पहुंचाने वाली वेबसाइटें दूसरी वेबसाइटों पर हमला करने के लिए इस नीति को बायपास करने की कोशिश कर सकती हैं.
कभी-कभी, सुरक्षा से जुड़ी गड़बड़ियां भी ब्राउज़र कोड में मिल जाती हैं, जो सेम-ऑरिजिन नीति को लागू करता है. Chrome टीम, इस तरह के गड़बड़ियों को जल्द से जल्द ठीक करने की कोशिश करती है.
साइट आइसोलेशन, Chrome की एक सुरक्षा सुविधा है. यह इस तरह के हमलों के सफल होने की संभावना को कम करने के लिए, सुरक्षा की एक और लाइन उपलब्ध कराती है. इससे पक्का होता है कि अलग-अलग वेबसाइटों के पेज हमेशा अलग-अलग प्रोसेस में रखे जाएं. हर पेज एक सैंडबॉक्स में चल रहा है, जिससे प्रोसेस को सीमित किया जा सकता है. यह प्रोसेस को दूसरी साइटों से कुछ खास तरह का संवेदनशील डेटा पाने से भी रोकता है. इस वजह से, साइट अलग-अलग प्रोसेस में होने की वजह से, नुकसान पहुंचाने वाली वेबसाइट के लिए, अन्य साइटों से डेटा चुराने के लिए, Spectre जैसे अनुमानित साइड-चैनल हमलों का इस्तेमाल करना बहुत मुश्किल हो जाता है. Chrome की टीम, नीति उल्लंघन ठीक करने के लिए अतिरिक्त उपाय कर रही है. साइट अलग-अलग रखने की सुविधा से, तब भी मदद मिलेगी, जब हमलावर का पेज अपनी प्रोसेस में कुछ नियमों का उल्लंघन कर सकता है.
साइट आइसोलेशन से, उन वेबसाइटों के लिए अन्य वेबसाइटों पर मौजूद आपके खातों की जानकारी को ऐक्सेस करना या चुराना मुश्किल हो जाता है जिन पर भरोसा नहीं किया जा सकता. यह कई तरह के सुरक्षा बग से अतिरिक्त सुरक्षा देता है. जैसे, हाल ही में हुए Meltdown और Spectre साइड-चैनल हमले.
साइट आइसोलेशन के बारे में ज़्यादा जानने के लिए, Google के सुरक्षा ब्लॉग पर हमारा लेख पढ़ें.
क्रॉस-ऑरिजिन रीड ब्लॉकिंग
सभी क्रॉस-साइट पेजों को अलग-अलग प्रोसेस में डालने के बाद भी, पेज कुछ क्रॉस-साइट सब-रिसॉर्स का अनुरोध कर सकते हैं. जैसे, इमेज और JavaScript. नुकसान पहुंचाने वाला वेब पेज, आपके बैंक बैलेंस जैसे संवेदनशील डेटा वाली JSON फ़ाइल लोड करने के लिए, <img> एलिमेंट का इस्तेमाल कर सकता है:
<img src="https://your-bank.example/balance.json" />
<!-- Note: the attacker refused to add an `alt` attribute, for extra evil points. -->
साइट अलगाव के बिना, JSON फ़ाइल का कॉन्टेंट रेंडरर प्रोसेस की मेमोरी में चला जाएगा. इस दौरान, रेंडरर को पता चलता है कि यह मान्य इमेज फ़ॉर्मैट नहीं है और वह इमेज को रेंडर नहीं करता. हालांकि, हमलावर उस मेमोरी का इस्तेमाल करने के लिए, Spectre जैसी किसी कमजोरी का फ़ायदा उठा सकता है.
हमलावर, <img> का इस्तेमाल करने के बजाय <script> का इस्तेमाल करके भी संवेदनशील डेटा को मेमोरी में सेव कर सकता है:
<script src="https://your-bank.example/balance.json"></script>
क्रॉस-ओरिजिन रीड ब्लॉकिंग या सीओआरबी, सुरक्षा से जुड़ी एक नई सुविधा है. यह balance.json के कॉन्टेंट को, MIME टाइप के आधार पर रेंडरर प्रोसेस मेमोरी में कभी भी शामिल होने से रोकती है.
आइए, जानते हैं कि सीओआरबी कैसे काम करता है. कोई वेबसाइट, सर्वर से दो तरह के संसाधनों का अनुरोध कर सकती है:
- डेटा रिसॉर्स, जैसे कि एचटीएमएल, एक्सएमएल या JSON दस्तावेज़
- मीडिया रिसॉर्स, जैसे कि इमेज, JavaScript, सीएसएस या फ़ॉन्ट
कोई वेबसाइट, अपने ओरिजिन या दूसरे ओरिजिन से डेटा रिसॉर्स पा सकती है. इसके लिए, CORS हेडर की अनुमति ज़रूरी है. जैसे, Access-Control-Allow-Origin: *. दूसरी ओर, मीडिया रिसॉर्स को किसी भी ऑरिजिन से शामिल किया जा सकता है. इसके लिए, अनुमति देने वाले सीओआरएस हेडर की ज़रूरत नहीं होती.
CORB, रेंडरर प्रोसेस को क्रॉस-ऑरिजिन डेटा रिसॉर्स (जैसे, एचटीएमएल, एक्सएमएल या JSON) पाने से रोकता है, अगर:
- रिसॉर्स में
X-Content-Type-Options: nosniffहेडर है - सीओआरएस, संसाधन को ऐक्सेस करने की अनुमति साफ़ तौर पर नहीं देता
अगर क्रॉस-ऑरिजिन डेटा रिसॉर्स में X-Content-Type-Options: nosniff हेडर सेट नहीं है, तो
CORB, रिस्पॉन्स बॉडी को स्निफ करके यह पता लगाने की कोशिश करता है कि वह एचटीएमएल, एक्सएमएल या JSON है. ऐसा करना ज़रूरी है, क्योंकि कुछ वेब सर्वर गलत तरीके से कॉन्फ़िगर किए गए हैं और उदाहरण के लिए, वे इमेज को text/html के तौर पर दिखाते हैं.
सीओआरबी नीति के तहत ब्लॉक किए गए डेटा रिसॉर्स, प्रोसेस में खाली के तौर पर दिखाए जाते हैं. हालांकि, अनुरोध अब भी बैकग्राउंड में होता है. इस वजह से, नुकसान पहुंचाने वाले वेब पेज को, चुराने की प्रोसेस में क्रॉस-साइट डेटा खींचने में मुश्किल होती है.
बेहतर सुरक्षा और सीओआरबी का फ़ायदा पाने के लिए, हमारा सुझाव है कि आप ये काम करें:
- जवाबों को सही
Content-Typeहेडर के साथ मार्क करें. (उदाहरण के लिए, एचटीएमएल रिसॉर्स कोtext/htmlके तौर पर, JSON रिसॉर्स को JSON MIME टाइप के साथ, और एक्सएमएल रिसॉर्स को एक्सएमएल MIME टाइप के साथ दिखाया जाना चाहिए). X-Content-Type-Options: nosniffहेडर का इस्तेमाल करके, स्निफ़िंग से ऑप्ट आउट करें. इस हेडर के बिना, Chrome कॉन्टेंट का तुरंत विश्लेषण करता है, ताकि यह पक्का किया जा सके कि टाइप सही है. हालांकि, यह JavaScript फ़ाइलों जैसी चीज़ों को ब्लॉक करने से बचने के लिए, जवाबों को अनुमति देता है. इसलिए, बेहतर होगा कि आप खुद ही सही तरीके से जवाब दें.
ज़्यादा जानकारी के लिए, वेब डेवलपर के लिए सीओआरबी लेख या सीओआरबी के बारे में ज़्यादा जानकारी देने वाला हमारा एक्सप्लेनर पढ़ें.
वेब डेवलपर को साइट आइसोलेशन का ध्यान क्यों रखना चाहिए?
ज़्यादातर मामलों में, 'साइट आइसोलेशन' ब्राउज़र की ऐसी सुविधा है जो पर्दे के पीछे की होती है. यह सीधे तौर पर वेब डेवलपर को नहीं दिखती. उदाहरण के लिए, वेब पर एक्सपोज़ किया गया कोई नया एपीआई नहीं है. आम तौर पर, वेब पेजों को साइट अलगाव की सुविधा के साथ या उसके बिना चलने में कोई फ़र्क़ नहीं पड़ना चाहिए.
हालांकि, इस नियम के कुछ अपवाद हैं. साइट आइसोलेशन की सुविधा चालू करने पर, कुछ साइड इफ़ेक्ट होते हैं. इनसे आपकी वेबसाइट पर असर पड़ सकता है. हम साइट आइसोलेशन की समस्याओं की एक सूची तैयार करते हैं और सबसे अहम समस्याओं के बारे में नीचे बताते हैं.
पूरे पेज का लेआउट अब सिंक नहीं होता
साइट आइसोलेशन के साथ, पूरे पेज का लेआउट अब सिंक्रोनस होने की गारंटी नहीं है, क्योंकि हो सकता है कि अब पेज के फ़्रेम एक से ज़्यादा प्रोसेस में बंटे हों. अगर पेज यह मानते हैं कि लेआउट में हुए बदलाव, पेज के सभी फ़्रेम पर तुरंत लागू हो जाते हैं, तो उन पर इसका असर पड़ सकता है.
उदाहरण के लिए, fluffykittens.example नाम की एक वेबसाइट पर, social-widget.example पर होस्ट किए गए सोशल विजेट से इंटरैक्ट किया जा रहा है:
<!-- https://fluffykittens.example/ -->
<iframe src="https://social-widget.example/" width="123"></iframe>
<script>
const iframe = document.querySelector('iframe');
iframe.width = 456;
iframe.contentWindow.postMessage(
// The message to send:
'Meow!',
// The target origin:
'https://social-widget.example'
);
</script>
शुरुआत में, सोशल विजेट के <iframe> की चौड़ाई 123 पिक्सल होती है. हालांकि, इसके बाद FluffyKittens पेज, चौड़ाई को 456 पिक्सल (लेआउट को ट्रिगर करना) में बदल देता है और सोशल विजेट को एक मैसेज भेजता है. इस विजेट में यह कोड होता है:
<!-- https://social-widget.example/ -->
<script>
self.onmessage = () => {
console.log(document.documentElement.clientWidth);
};
</script>
जब भी सोशल विजेट को postMessage एपीआई से कोई मैसेज मिलता है, तो वह अपने रूट <html> एलिमेंट की चौड़ाई को लॉग करता है.
चौड़ाई की कौनसी वैल्यू लॉग की जाती है? Chrome पर साइट अलगाव की सुविधा चालू होने से पहले, इसका जवाब 456 था. document.documentElement.clientWidth को ऐक्सेस करने पर, लेआउट को फ़ोर्स किया जाता है. Chrome पर साइट आइसोलेशन की सुविधा चालू होने से पहले, यह सिंक होता था. हालांकि, साइट आइसोलेशन की सुविधा चालू होने पर, क्रॉस-ऑरिजिन सोशल विजेट का फिर से लेआउट, अब अलग प्रोसेस में असिंक्रोनस तरीके से होता है. इसलिए, जवाब अब 123 भी हो सकता है. इसका मतलब है कि width की पुरानी वैल्यू.
अगर कोई पेज, क्रॉस-ऑरिजिन <iframe> का साइज़ बदलता है और फिर उसमें postMessage भेजता है, तो हो सकता है कि साइट अलगाव की सुविधा के साथ, मैसेज पाने वाले फ़्रेम को मैसेज मिलने के समय उसका नया साइज़ न पता हो. आम तौर पर, अगर पेज यह मानते हैं कि लेआउट में हुए बदलाव, पेज के सभी फ़्रेम में तुरंत लागू हो जाते हैं, तो हो सकता है कि पेज काम न करें.
इस खास उदाहरण में, ज़्यादा बेहतर समाधान के लिए पैरंट फ़्रेम में width सेट किया जाएगा. साथ ही, resize इवेंट को सुनकर <iframe> में हुए बदलाव का पता लगाया जाएगा.
अनलोड हैंडलर के टाइम आउट होने की संभावना ज़्यादा होती है
जब कोई फ़्रेम नेविगेट करता है या बंद होता है, तो पुराने दस्तावेज़ के साथ-साथ उसमें एम्बेड किए गए सभी सबफ़्रेम दस्तावेज़, अपना unload हैंडलर चलाते हैं. अगर नया नेविगेशन, एक ही रेंडरर प्रोसेस में होता है (उदाहरण के लिए, एक ही ऑरिजिन वाले नेविगेशन के लिए), तो नए नेविगेशन को कमिट करने से पहले, पुराने दस्तावेज़ और उसके सबफ़्रेम के unload हैंडलर, मनमुताबिक लंबे समय तक चल सकते हैं.
addEventListener('unload', () => {
doSomethingThatMightTakeALongTime();
});
इस स्थिति में, सभी फ़्रेम में unload हैंडलर बहुत भरोसेमंद होते हैं.
हालांकि, साइट आइसोलेशन के बिना भी कुछ मुख्य फ़्रेम नेविगेशन, क्रॉस-प्रोसेस होते हैं. इससे अनलोड हैंडलर के व्यवहार पर असर पड़ता है. उदाहरण के लिए, अगर पता बार में यूआरएल टाइप करके old.example से new.example पर नेविगेट किया जाता है, तो new.example पर नेविगेट करने की प्रोसेस नई होती है. old.example और उसके सबफ़्रेम के लिए अनलोड करने वाले हैंडलर, new.example पेज दिखने के बाद, बैकग्राउंड में old.example प्रोसेस में चलते हैं. साथ ही, अगर वे तय किए गए टाइम आउट में काम नहीं करते, तो पुराने अनलोड करने वाले हैंडलर बंद कर दिए जाते हैं. हो सकता है कि अनलोड हैंडलर, टाइम आउट से पहले काम पूरा न कर पाएं. इसलिए, अनलोड करने के तरीके पर भरोसा करना मुश्किल होता है.
साइट आइसोलेशन के साथ, सभी क्रॉस-साइट नेविगेशन, क्रॉस-प्रोसेस बन जाते हैं. इससे, अलग-अलग साइटों के दस्तावेज़ एक-दूसरे के साथ प्रोसेस शेयर नहीं करते. इस वजह से, ऊपर बताई गई स्थिति
ज़्यादा मामलों में लागू होती है. <iframe> में अनलोड हैंडलर के लिए, अक्सर बैकग्राउंड और टाइम आउट के बारे में ऊपर बताया गया तरीका अपनाया जाता है.
साइट अलगाव की वजह से एक और अंतर यह है कि अनलोड हैंडलर के नए पैरलल ऑर्डरिंग: साइट अलगाव के बिना, अनलोड हैंडलर सभी फ़्रेम में टॉप-डाउन क्रम में चलते हैं. हालांकि, साइट आइसोलेशन के साथ, अनलोड हैंडलर अलग-अलग प्रोसेस में साथ-साथ चलते हैं.
साइट अलगाव की सुविधा चालू करने के ये बुनियादी नतीजे हैं. Chrome की टीम, सामान्य इस्तेमाल के उदाहरणों के लिए, अनलोड हैंडलर की भरोसेमंदता को बेहतर बनाने पर काम कर रही है. हालांकि, ऐसा सिर्फ़ तब किया जाएगा, जब यह मुमकिन हो. हम उन गड़बड़ियों के बारे में भी जानते हैं जिनमें सबफ़्रेम अनलोड करने वाले हैंडलर, अब तक कुछ सुविधाओं का इस्तेमाल नहीं कर पा रहे हैं. हम इन गड़बड़ियों को ठीक करने के लिए काम कर रहे हैं.
अनलोड हैंडलर के लिए, सेशन खत्म होने पर पिंग भेजना एक अहम मामला है. आम तौर पर, यह काम इस तरह किया जाता है:
addEventListener('pagehide', () => {
const image = new Image();
img.src = '/end-of-session';
});
इस बदलाव को ध्यान में रखते हुए, एक बेहतर तरीका यह है कि आप इसके बजाय navigator.sendBeacon का इस्तेमाल करें:
addEventListener('pagehide', () => {
navigator.sendBeacon('/end-of-session');
});
अगर आपको अनुरोध पर ज़्यादा कंट्रोल चाहिए, तो Fetch API के keepalive विकल्प का इस्तेमाल किया जा सकता है:
addEventListener('pagehide', () => {
fetch('/end-of-session', {keepalive: true});
});
नतीजा
साइट आइसोलेशन की सुविधा से, हर साइट को अलग प्रोसेस में अलग रखा जाता है. इससे, भरोसेमंद नहीं होने वाली वेबसाइटों के लिए, दूसरी वेबसाइटों पर मौजूद आपके खातों से जानकारी ऐक्सेस करना या उसे चुराना मुश्किल हो जाता है. इसके तहत, सीओआरबी, संवेदनशील डेटा संसाधनों को रेंडरर प्रोसेस से बाहर रखने की कोशिश करता है. ऊपर दिए गए सुझावों से, आपको सुरक्षा से जुड़ी इन नई सुविधाओं का ज़्यादा से ज़्यादा फ़ायदा पाने में मदद मिलेगी.
इस लेख का ड्राफ़्ट वर्शन पढ़ने और सुझाव देने के लिए, एलेक्स मोशचुक, चार्ली रीस, जेसन मिलर, नास्को ऑस्कोव, फ़िलिप वॉल्टन, शुबी पनिकर, थॉमस स्टाइनर को धन्यवाद.