वेब डेवलपर के लिए साइट आइसोलेशन

Mathias Bynens

डेस्कटॉप पर Chrome 67 में एक नई सुविधा मौजूद है. इसे साइट आइसोलेशन डिफ़ॉल्ट रूप से चालू किया गया है. यह लेख में बताया गया है कि साइट आइसोलेशन क्या है, यह क्यों ज़रूरी है, और वेब डेवलपर को जागरूक रहें.

साइट आइसोलेशन क्या है?

इंटरनेट पर बिल्लियों के वीडियो देखने और क्रिप्टो करंसी वॉलेट मैनेज करने के साथ-साथ कई और सुविधाएं मिलती हैं — हालांकि, आप नहीं चाहतीं कि fluffycats.example को आपके कीमती क्रिप्टोकॉइन का ऐक्सेस मिले! अच्छी बात यह है कि सेम-ऑरिजिन वाली वेबसाइट की वजह से, आम तौर पर वेबसाइटें ब्राउज़र में एक-दूसरे के डेटा को ऐक्सेस नहीं कर पाती हैं नीति. फिर भी, नुकसान पहुंचाने वाली वेबसाइटें इस नीति को बायपास करके दूसरी वेबसाइटों पर हमला कर सकती हैं और कभी-कभी ब्राउज़र कोड में सुरक्षा से जुड़ी गड़बड़ियां मिल जाती हैं, जो एक ही ऑरिजिन वाली नीति को लागू करता है. कॉन्टेंट बनाने Chrome टीम का लक्ष्य इस तरह की गड़बड़ियों को जल्द से जल्द ठीक करना है.

साइट आइसोलेशन, Chrome की एक सुरक्षा सुविधा है. यह ऐसे हमलों के सफल होने की संभावना कम होती है. इससे पक्का होता है कि अलग-अलग वेबसाइटों के पेज हमेशा अलग-अलग प्रोसेस में चला जाता है, जिसमें हर प्रोसेस सैंडबॉक्स में चलती है. इससे यह तय होता है कि प्रोसेस क्या कर सकती है. यह प्रोसेस को, दूसरी साइटों से कुछ खास तरह का संवेदनशील डेटा पाने से भी रोकती है. बतौर साइट आइसोलेशन की वजह से, नुकसान पहुंचाने वाली वेबसाइट के लिए अनुमान का इस्तेमाल करना ज़्यादा मुश्किल हो जाता है की तरह, अन्य साइटों से डेटा चुराने के लिए, स्पेक्ट्रर जैसे साइड-चैनल हमले किए गए हों. जैसे ही Chrome टीम खत्म हो गई नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) लागू करने के बाद, 'साइट आइसोलेशन' भी तब भी मदद करेगा, जब कोई हमलावर का पेज नियमों को लागू करने की क्षमता है.

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

साइट आइसोलेशन के बारे में ज़्यादा जानकारी के लिए, 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>

क्रॉस-ऑरिजिन रीड ब्लॉकिंग या सीओआरबी एक नई सुरक्षा सुविधा है. यह सुविधा, MIME टाइप के आधार पर, रेंडरर प्रोसेस मेमोरी की मेमोरी में जाने से balance.json.

आइए, जानते हैं कि CORB के काम करने का तरीका क्या है. कोई वेबसाइट, सर्वर से दो तरह के संसाधनों का अनुरोध कर सकती है:

1. डेटा रिसॉर्स, जैसे कि एचटीएमएल, एक्सएमएल या JSON दस्तावेज़
2. मीडिया संसाधन, जैसे कि इमेज, JavaScript, सीएसएस या फ़ॉन्ट

कोई वेबसाइट अपने ऑरिजिन से या अन्य ऑरिजिन सेडेटा रिसॉर्स को अनुमति देने वाले CORS हेडर, जैसे कि Access-Control-Allow-Origin: *. वहीं दूसरी ओर, मीडिया संसाधनों को किसी भी ऑरिजिन के लिए अनुमति का इस्तेमाल करें. ऐसा सीओआरएस हेडर के बिना भी किया जा सकता है.

CORB, रेंडरर प्रोसेस को क्रॉस-ऑरिजिन डेटा रिसॉर्स (जैसे, एचटीएमएल, एक्सएमएल या JSON) अगर:

• संसाधन में X-Content-Type-Options: nosniff हेडर है
• सीओआरएस साफ़ तौर पर संसाधन को ऐक्सेस करने की अनुमति नहीं देता

अगर क्रॉस-ऑरिजिन डेटा रिसॉर्स में, X-Content-Type-Options: nosniff हेडर सेट नहीं है, तो CORB, रिस्पॉन्स के मुख्य भाग को स्निफ़ करके यह तय करता है कि वह एचटीएमएल, एक्सएमएल या JSON है या नहीं. यह है ज़रूरी है, क्योंकि कुछ वेब सर्वर गलत तरीके से कॉन्फ़िगर किए गए हैं और उदाहरण के लिए, इमेज को text/html के तौर पर दिखाते हैं.

सीओआरबी नीति के तहत ब्लॉक किए गए डेटा रिसॉर्स को इस प्रोसेस में खाली दिखाया जाता है. हालांकि, अनुरोध अब भी बैकग्राउंड में चलता रहता है. इस वजह से, नुकसान पहुंचाने वाले वेब पेज के लिए क्रॉस-साइट डेटा को चुराना होता है.

बेहतर सुरक्षा और सीओआरबी का फ़ायदा पाने के लिए, हम ये सुझाव देते हैं:

• जवाबों को सही Content-Type हेडर के साथ मार्क करें. (उदाहरण के लिए, HTML संसाधन text/html के तौर पर दिखाया गया है. यह JSON रिसॉर्स के साथ काम करता है JSON MIME टाइप और एक्सएमएल संसाधन एक्सएमएल MIME टाइप) होता है.
• X-Content-Type-Options: nosniff हेडर का इस्तेमाल करके, स्निफ़िंग की सुविधा से ऑप्ट आउट करें. इस हेडर के बिना, Chrome तेज़ी से कॉन्टेंट का विश्लेषण करता है, ताकि यह पुष्टि की जा सके कि टाइप सही है या नहीं, लेकिन जवाबों को अनुमति देने के साथ-साथ JavaScript फ़ाइलें, बेहतर होगा कि आप खुद ही सही काम करें.

ज़्यादा जानकारी के लिए, इसे देखें वेब डेवलपर के लिए सीओआरबी का लेख या 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 पिक्सल है. लेकिन फिर, 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 और इसके सबफ़्रेम के लिए हैंडलर, बैकग्राउंड में old.example प्रोसेस में चलते हैं, new.example पेज दिखाए जाने के बाद और अगर पुराने अनलोड हैंडलर मौजूद नहीं हैं, तो उन्हें बंद कर दिया जाता है तय टाइम आउट में खत्म करना होगा. क्योंकि अनलोड हैंडलर, टाइम आउट से पहले शायद खत्म न हों, अनलोड करने के तरीके पर ज़्यादा भरोसा नहीं किया जा सकता.

साइट आइसोलेशन के साथ, सभी क्रॉस-साइट नेविगेशन, क्रॉस-प्रोसेस बन जाते हैं. इससे, अलग-अलग साइटें एक-दूसरे के साथ प्रोसेस शेयर नहीं करतीं. इस वजह से, ऊपर दी गई स्थिति इन मामलों में लागू होती है: ज़्यादा मामलों का इस्तेमाल किया जाता है और <iframe> में अनलोड हैंडलर के लिए बैकग्राउंड और टाइम आउट की सेटिंग अक्सर दिखती है ऊपर बताया गया है.

साइट आइसोलेशन की वजह से दूसरा अंतर, अनलोड हैंडलर का नया पैरलल क्रम है: साइट आइसोलेशन के बिना, अनलोड हैंडलर सभी फ़्रेम पर सख्त टॉप-डाउन ऑर्डर में चलते हैं. लेकिन Site के साथ आइसोलेशन और अनलोड हैंडलर, अलग-अलग प्रोसेस पर साथ-साथ चलते हैं.

साइट आइसोलेशन को चालू करने के बुनियादी नतीजे. 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});
});

नतीजा

साइट आइसोलेशन की मदद से, गैर-भरोसेमंद वेबसाइटों के लिए आपके ऐप्लिकेशन की जानकारी को ऐक्सेस करना या चुराना मुश्किल हो जाता है खातों को लिंक करने के लिए किया जा सकता है. इसके लिए, हर साइट को उसकी प्रोसेस में अलग-अलग करें. इसी के तहत, सीओआरबी रेंडरर की प्रोसेस से संवेदनशील डेटा संसाधनों को बाहर रखने के लिए. ऊपर दिए गए हमारे सुझावों से पक्का होता है कि सुरक्षा से जुड़ी इन नई सुविधाओं का ज़्यादा से ज़्यादा फ़ायदा पाएं.

इन्हें धन्यवाद एलेक्स मोशचुक, चार्ली रीस, जेसन मिलर, नास्को ओस्कोव, फ़िलिप वॉल्टन, शुभी पनिकर, और थॉमस स्टाइनर इस लेख का ड्राफ़्ट वर्शन पढ़ने और अपने सुझाव देने के लिए.