डेस्कटॉप पर Chrome 67 में साइट आइसोलेशन नाम की नई सुविधा है, जो डिफ़ॉल्ट रूप से चालू होती है. इस लेख में बताया गया है कि 'साइट आइसोलेशन' क्या है, यह क्यों ज़रूरी है, और वेब डेवलपर को इसके बारे में क्यों पता होना चाहिए.
साइट आइसोलेशन क्या है?
इंटरनेट पर, बिल्लियों के वीडियो देखने और क्रिप्टो करंसी वॉलेट मैनेज करने के साथ-साथ, अन्य काम किए जा सकते हैं —
हालांकि, ऐसा नहीं है कि fluffycats.example के पास आपके कीमती क्रिप्टोकॉइन का ऐक्सेस हो! अच्छी बात यह है कि
सेम-ऑरिजिन पॉलिसी की वजह से, आम तौर पर वेबसाइटें एक-दूसरे के डेटा को ब्राउज़र में ऐक्सेस
नहीं कर पातीं. फिर भी, नुकसान पहुंचाने वाली वेबसाइटें इस नीति को बायपास करके दूसरी वेबसाइटों पर हमला करने की कोशिश कर सकती हैं.
कभी-कभी, एक ही ऑरिजिन वाली नीति को लागू करने वाले ब्राउज़र कोड में सुरक्षा से जुड़ी गड़बड़ियां मिल जाती हैं. Chrome की टीम की कोशिश है कि इन गड़बड़ियों को जल्द से जल्द ठीक किया जाए.
साइट आइसोलेशन Chrome की एक सुरक्षा सुविधा है जो ऐसे हमलों के सफल होने की संभावना कम करने के लिए सुरक्षा की एक और सुविधा देती है. यह पक्का करता है कि अलग-अलग वेबसाइटों के पेजों को हमेशा अलग-अलग प्रोसेस में रखा जाए. हर पेज एक सैंडबॉक्स में चलता है, जो इस बात को सीमित करता है कि प्रोसेस को क्या करने की अनुमति है. यह प्रोसेस को दूसरी साइटों से कुछ खास तरह की संवेदनशील जानकारी पाने से भी रोकता है. इस वजह से, 'साइट आइसोलेशन' सुविधा की मदद से, किसी नुकसान पहुंचाने वाली वेबसाइट के लिए, अनुमान पर आधारित साइड-चैनल हमलों, जैसे कि Spectre का इस्तेमाल करके, दूसरी साइटों से डेटा चुराना बहुत मुश्किल हो जाता है. जैसे ही Chrome टीम अतिरिक्त एनफ़ोर्समेंट को खत्म करती है, 'साइट आइसोलेशन' तब भी मदद करता है, जब किसी हमलावर का पेज अपनी प्रक्रिया में कुछ नियमों को तोड़ सकता है.
साइट आइसोलेशन की सुविधा से, गैर-भरोसेमंद वेबसाइटों के लिए, दूसरी वेबसाइटों पर मौजूद आपके खातों की जानकारी को ऐक्सेस करना या चुराना मुश्किल हो जाता है. इससे कई तरह की सुरक्षा गड़बड़ियों से बचा जा सकता है. जैसे, हाल ही में हुए Mailtdown और 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 फ़ाइल का कॉन्टेंट, रेंडरर प्रोसेस की मेमोरी में पहुंच जाएगा. इस दौरान, रेंडरर को पता चलता है कि यह मान्य इमेज फ़ॉर्मैट नहीं है और यह किसी इमेज को रेंडर नहीं करता है. हालांकि, इसके बाद हमलावर स्पेक्टर जैसी जोखिम की आशंका का फ़ायदा उठा सकता है, ताकि वह मेमोरी के उस हिस्से को पढ़ सके.
<img> का इस्तेमाल करने के बजाय, हमलावर संवेदनशील डेटा को मेमोरी में सेव करने के लिए, <script> का भी इस्तेमाल कर सकता है:
<script src="https://your-bank.example/balance.json"></script>
क्रॉस-ऑरिजिन रीड ब्लॉकिंग या सीओआरबी, सुरक्षा की एक नई सुविधा है. यह balance.json के कॉन्टेंट को, MIME टाइप के आधार पर रेंडरर प्रोसेस की मेमोरी में कभी भी डेटा डालने से रोकती है.
चलिए, सीओआरबी के काम करने के तरीके के बारे में जानते हैं. कोई वेबसाइट, सर्वर से दो तरह के संसाधनों का अनुरोध कर सकती है:
- डेटा संसाधन जैसे एचटीएमएल, एक्सएमएल या JSON दस्तावेज़
- मीडिया संसाधन, जैसे कि इमेज, JavaScript, सीएसएस या फ़ॉन्ट
कोई वेबसाइट अपने ऑरिजिन से या दूसरे ऑरिजिन से, डेटा रिसॉर्स पा सकती है. इन ऑरिजिन से, अनुमति वाले सीओआरएस हेडर जैसे कि
Access-Control-Allow-Origin: * का इस्तेमाल किया जाता है. दूसरी ओर, मीडिया रिसॉर्स किसी भी ऑरिजिन से शामिल किए जा सकते हैं, यहां तक कि अनुमति देने वाले सीओआरएस हेडर के बिना भी.
सीओआरबी, रेंडरर प्रोसेस को क्रॉस-ऑरिजिन डेटा रिसॉर्स (जैसे, एचटीएमएल, एक्सएमएल या JSON) पाने से रोकता है. ऐसा तब होता है, जब:
- संसाधन में एक
X-Content-Type-Options: nosniffहेडर है - सीओआरएस साफ़ तौर पर संसाधन को ऐक्सेस करने की अनुमति नहीं देता
अगर क्रॉस-ऑरिजिन डेटा रिसॉर्स में X-Content-Type-Options: nosniff हेडर सेट नहीं है,
तो सीओआरबी रिस्पॉन्स के मुख्य हिस्से को स्निफ़ करने की कोशिश करता है, ताकि यह पता लगाया जा सके कि वह एचटीएमएल, एक्सएमएल या JSON है. यह इसलिए ज़रूरी है, क्योंकि कुछ वेब सर्वर गलत तरीके से कॉन्फ़िगर किए गए होते हैं और इमेज को text/html के तौर पर दिखाते हैं.
सीओआरबी नीति के तहत ब्लॉक किए गए डेटा रिसॉर्स को प्रोसेस के लिए, खाली दिखाया गया है. हालांकि, अनुरोध, बैकग्राउंड में अब भी किया जाता है. इस वजह से, नुकसान पहुंचाने वाले किसी वेब पेज को क्रॉस-साइट डेटा को चोरी करने में मुश्किल होती है.
बेहतर सुरक्षा और सीओआरबी से फ़ायदा पाने के लिए, हम ये सुझाव देते हैं:
- जवाबों को सही
Content-Typeहेडर से मार्क करें. (उदाहरण के लिए, एचटीएमएल रिसॉर्स कोtext/htmlके तौर पर, JSON MIME टाइप वाले JSON रिसॉर्स और एक्सएमएल MIME टाइप वाले एक्सएमएल रिसॉर्स के तौर पर दिखाया जाना चाहिए. X-Content-Type-Options: nosniffहेडर का इस्तेमाल करके स्निफ़िंग से ऑप्ट आउट करें. इस हेडर के बिना, Chrome तेज़ी से कॉन्टेंट का विश्लेषण करके यह पुष्टि करता है कि टाइप सही है या नहीं. हालांकि, इस तरह JavaScript फ़ाइलों जैसी चीज़ों को ब्लॉक करने से रोकने के लिए, जवाब देने की अनुमति होती है. इसलिए, बेहतर होगा कि आप खुद ही सही काम करें.
ज़्यादा जानकारी के लिए, वेब डेवलपर के लिए CORB लेख या CORB के बारे में पूरी जानकारी देखें.
वेब डेवलपर को साइट आइसोलेशन पर ध्यान क्यों देना चाहिए?
ज़्यादातर मामलों में, साइट आइसोलेशन पर्दे के पीछे की गतिविधि वाली ब्राउज़र सुविधा है, जो सीधे तौर पर वेब डेवलपर को नहीं दिखती है. उदाहरण के लिए, सीखने के लिए कोई नया वेब-एक्सपोज़्ड एपीआई नहीं है. आम तौर पर, वेब पेजों को 'साइट आइसोलेशन' के साथ या उनके बिना काम करते समय अंतर नहीं बताना चाहिए.
हालांकि, इस नियम के कुछ अपवाद हैं. साइट आइसोलेशन को चालू करने के कुछ छोटे-छोटे खराब असर होते हैं, जो आपकी वेबसाइट पर असर डाल सकते हैं. हमने साइट आइसोलेशन से जुड़ी समस्याओं की एक सूची बनाई हुई है. साथ ही, नीचे दी गई सबसे ज़रूरी समस्याओं के बारे में बताया है.
पूरे पेज का लेआउट अब सिंक्रोनस नहीं है
साइट आइसोलेशन के साथ, पूरे पेज के लेआउट के सिंक्रोनस होने की कोई गारंटी नहीं है, क्योंकि हो सकता है कि किसी पेज के फ़्रेम को अब कई प्रोसेस में बांटा गया हो. इसका असर उन पेजों पर पड़ सकता है जिन्हें लगता है कि लेआउट में बदलाव, पेज के सभी फ़्रेम पर तुरंत लागू हो जाता है.
उदाहरण के लिए, मान लें कि 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 पिक्सल है. इसके बाद, FluffyKit{8/} पेज
चौड़ाई को बदलकर 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 और उसके सबफ़्रेम के लिए, अनलोड हैंडलर, बैकग्राउंड में old.example प्रोसेस में चलते हैं. साथ ही, new.example पेज दिखने के बाद ये प्रोसेसर पर चलते हैं. साथ ही, अगर अनलोड हैंडलर एक तय टाइम आउट के अंदर भी पूरा नहीं होते हैं, तो उन्हें बंद कर दिया जाता है. हो सकता है कि अनलोड हैंडलर, टाइम आउट से पहले पूरा न हो. इसलिए, अनलोड करने का तरीका कम भरोसेमंद होता है.
साइट आइसोलेशन से, सभी क्रॉस-साइट नेविगेशन, क्रॉस-प्रोसेस हो जाते हैं. इससे, अलग-अलग साइटों के दस्तावेज़ एक-दूसरे के साथ प्रोसेस शेयर नहीं करते. इस वजह से, ऊपर दी गई स्थिति
ज़्यादा मामलों में लागू होती है. <iframe> में, अनलोड हैंडलर में अक्सर बैकग्राउंड और टाइम आउट के व्यवहार
ऊपर बताए गए होते हैं.
साइट आइसोलेशन से मिला एक और अंतर है, यह अनलोड हैंडलर का नया पैरलल ऑर्डर है: साइट आइसोलेशन के बिना, अनलोड हैंडलर सभी फ़्रेम पर टॉप-डाउन के सख्त क्रम में चलते हैं. हालांकि, साइट आइसोलेशन के साथ, अनलोड हैंडलर अलग-अलग प्रोसेस पर साथ-साथ चलते हैं.
साइट आइसोलेशन चालू करने के ये बुनियादी नतीजे हैं. Chrome की टीम, जहां संभव हो वहां अनलोड हैंडलर की विश्वसनीयता बेहतर बनाने पर काम कर रही है. हमें उन गड़बड़ियों के बारे में भी पता है जिनमें सबफ़्रेम अनलोड हैंडलर कुछ सुविधाओं का इस्तेमाल नहीं कर पा रहे हैं और हम उन्हें ठीक करने की कोशिश कर रहे हैं.
अनलोड हैंडलर के लिए एक अहम मामला यह है कि सेशन खत्म होने के बाद वाले पिंग भेजे जाएं. आम तौर पर, ऐसा इन तरीकों से किया जाता है:
addEventListener('pagehide', () => {
const image = new Image();
img.src = '/end-of-session';
});
इस बदलाव को ध्यान में रखते हुए, एक बेहतर तरीका यह है कि आप इसके बजाय navigator.sendBeacon का इस्तेमाल करें:
addEventListener('pagehide', () => {
navigator.sendBeacon('/end-of-session');
});
अगर आपको अनुरोध पर ज़्यादा कंट्रोल चाहिए, तो आपके पास फ़ेच एपीआई के keepalive विकल्प का इस्तेमाल करने का विकल्प है:
addEventListener('pagehide', () => {
fetch('/end-of-session', {keepalive: true});
});
नतीजा
साइट आइसोलेशन, हर साइट को उसकी अपनी प्रोसेस के हिसाब से बांटकर, दूसरी वेबसाइटों पर मौजूद गैर-भरोसेमंद वेबसाइटों के लिए, आपके खातों की जानकारी को ऐक्सेस करना या उसे चुराना मुश्किल बना देता है. इसी के तहत, सीओआरबी संवेदनशील डेटा संसाधनों को रेंडर करने की प्रक्रिया से बाहर रखने की कोशिश करता है. ऊपर दिए गए हमारे सुझावों से यह पक्का होता है कि आपको इन नई सुरक्षा सुविधाओं का ज़्यादा से ज़्यादा फ़ायदा मिले.
इस लेख का ड्राफ़्ट वर्शन पढ़ने और सुझाव देने के लिए, एलेक्स मॉशचक, चार्ली रीस, जेसन मिलर, नास्को ओस्कोव, फ़िलिप वॉल्टन, शूफ़ी पैनिकर, थॉमस स्टेनर, को धन्यवाद.