खास जानकारी
3 जनवरी को Project Zero ने मॉडर्न सीपीयू में जोखिम की आशंकाओं का पता लगाया. इन जोखिमों का इस्तेमाल किसी प्रोसेस के ज़रिए, आर्बिट्रेरी मेमोरी (सबसे खराब) को पढ़ने के लिए किया जा सकता है. इसमें ऐसी मेमोरी भी शामिल है जो उस प्रोसेस से जुड़ी न हो. इन जोखिम की आशंकाओं को स्पेक्टर और मेल्टडाउन नाम दिया गया है. वेब को सुरक्षित रखने के लिए Chrome क्या कर रहा है और वेब डेवलपर को अपनी साइटों के लिए क्या करना चाहिए?
बहुत कम शब्द; कहा गया
वेब ब्राउज़ करने वाले उपयोगकर्ता के तौर पर, आपको यह पक्का करना चाहिए कि आपका ऑपरेटिंग सिस्टम और ब्राउज़र अपडेट रहे. इसके अलावा, Chrome इस्तेमाल करने वाले लोग साइट आइसोलेशन को चालू करने पर विचार कर सकते हैं.
अगर आप वेब डेवलपर हैं, तो Chrome की टीम आपको सलाह देती है:
- जहां भी हो सके,
SameSiteऔरHTTPOnlyकुकी एट्रिब्यूट का इस्तेमाल करके कुकी को रेंडरर प्रोसेस की मेमोरी में जाने से रोकें. साथ ही, उन्हेंdocument.cookieसे पढ़ने से बचें. - पक्का करें कि आपके MIME टाइप सही हैं और उपयोगकर्ता के हिसाब से या संवेदनशील कॉन्टेंट वाले किसी भी यूआरएल के लिए
X-Content-Type-Options: nosniffहेडर तय करें. इससे उन उपयोगकर्ताओं को क्रॉस-ऑरिजिन रीड ब्लॉकिंग का ज़्यादा से ज़्यादा फ़ायदा मिलेगा जिनके लिए साइट को अलग करने की सुविधा चालू है. - अगर इससे आपकी साइट पर समस्या होती है, तो साइट आइसोलेशन को चालू करें और Chrome टीम को इसकी जानकारी दें.
अगर आपको यह जानना है कि इन तरीकों को अपनाने से आपको क्यों मदद मिलेगी, तो यह लेख पढ़ें!
खतरा
इन जोखिमों की कई अलग-अलग वजहें रही हैं, इसलिए मैं इनके अलावा दूसरी चीज़ों को भी नहीं जोड़ूंगी. अगर आप जानना चाहते हैं कि इन कमियों का फ़ायदा किस तरह फ़ायदा लिया जा सकता है, तो हमारा सुझाव है कि Google Cloud टीम के मेरे सहकर्मियों की ब्लॉग पोस्ट देखें.
मेल्टडाउन और स्पेक्टर, दोनों ही प्रोसेस को मेमोरी में मौजूद जानकारी को पढ़ने की अनुमति देते हैं. कभी-कभी, अलग-अलग साइटों के कई दस्तावेज़ से, Chrome में एक ही प्रोसेस शेयर हो सकती है. ऐसा तब हो सकता है, जब किसी व्यक्ति ने
window.open या <a href="..." target="_blank"> या iframes का इस्तेमाल करके, अन्य खोला हो. अगर किसी वेबसाइट में उपयोगकर्ता का खास डेटा होता है, तो हो सकता है कि कोई दूसरी साइट, उपयोगकर्ता के डेटा को पढ़ने के लिए इन नए जोखिमों का इस्तेमाल कर सकती हो.
पाबंदियां
इस खतरे को कम करने के लिए, Chrome और V8 की इंजीनियरिंग टीम कई कोशिशें कर रही है.
साइट आइसोलेशन
संवेदनशील जानकारी को हमलावर के कंट्रोल किए गए कोड के साथ प्रोसेस को शेयर करने से रोककर, Spectre के गलत इस्तेमाल के असर को काफ़ी कम किया जा सकता है. Chrome की टीम, इसे पाने के लिए एक सुविधा पर काम कर रही है. इस सुविधा को “साइट आइसोलेशन” कहा जाता है:
'साइट आइसोलेशन' सुविधा अब तक डिफ़ॉल्ट रूप से चालू नहीं की गई है, क्योंकि आम तौर पर होने वाली कुछ समस्याएं हैं. इसलिए, Chrome की टीम ज़्यादा से ज़्यादा फ़ील्ड की जांच करना चाहती है. अगर आप वेब डेवलपर हैं, तो आपको साइट आइसोलेशन की सुविधा चालू करनी चाहिए. साथ ही, यह देखना चाहिए कि आपकी साइट ठीक से काम कर रही है या नहीं. अगर आपको अभी ऑप्ट-इन करना है, तो
chrome://flags#enable-site-per-process को चालू करें. अगर आपको कोई ऐसी साइट मिलती है जो काम नहीं करती, तो कृपया गड़बड़ी की शिकायत करके हमारी मदद करें. साथ ही, यह भी बताएं कि आपने 'साइट आइसोलेशन' चालू कर रखा है.
क्रॉस-साइट दस्तावेज़ ब्लॉक करना
भले ही, क्रॉस-साइट वाले सभी पेजों को अलग-अलग प्रोसेस में रखा जाता हो, फिर भी पेज, इमेज और JavaScript जैसे कुछ क्रॉस-साइट सबरिसॉर्स के लिए, वैध रूप से अनुरोध कर सकते हैं. संवेदनशील जानकारी को इस जानकारी को लीक होने से रोकने के लिए, साइट आइसोलेशन में “क्रॉस-साइट दस्तावेज़ ब्लॉक करने” की सुविधा शामिल है. इससे यह तय किया जाता है कि रेंडरर की प्रोसेस को कौनसे नेटवर्क रिस्पॉन्स दिए जाएं.
कोई वेबसाइट, सर्वर से दो तरह के डेटा का अनुरोध कर सकती है: “दस्तावेज़” और “संसाधन”. यहां एचटीएमएल, एक्सएमएल, JSON, और टेक्स्ट फ़ाइलें दस्तावेज़ हैं. किसी वेबसाइट को अपने डोमेन या अनुमति वाले सीओआरएस हेडर वाले दूसरे डोमेन से दस्तावेज़ मिल सकते हैं. संसाधनों में इमेज, JavaScript, सीएसएस, और फ़ॉन्ट जैसी चीज़ें शामिल होती हैं. किसी भी साइट से संसाधन शामिल किए जा सकते हैं.
क्रॉस-साइट दस्तावेज़ ब्लॉक करने की नीति किसी प्रोसेस को अन्य ऑरिजिन से “दस्तावेज़” पाने से रोकती है, अगर:
- उनमें एचटीएमएल, एक्सएमएल, JSON या टेक्स्ट/सादा MIME टाइप हो और
- उनमें या तो
X-Content-Type-Options: nosniffएचटीटीपी रिस्पॉन्स हेडर होता है या फटाफट कॉन्टेंट का विश्लेषण (“स्निफ़िंग”) होता है, इससे पता चलता है कि टाइप सही है - सीओआरएस, दस्तावेज़ को ऐक्सेस करने की अनुमति साफ़ तौर पर नहीं देता है
इस नीति के तहत ब्लॉक किए गए दस्तावेज़ों को, प्रोसेस के लिए खाली दिखाया जाता है. हालांकि, अनुरोध अब भी बैकग्राउंड में होता है.
उदाहरण के लिए: मान लें कि कोई हमलावर ऐसा <img> टैग बना रहा है जिसमें <img src="https://yourbank.com/balance.json"> जैसी संवेदनशील जानकारी वाली JSON फ़ाइल शामिल है.
साइट आइसोलेशन के बिना, JSON फ़ाइल का कॉन्टेंट, रेंडरर प्रोसेस की मेमोरी में पहुंच जाएगा. इस समय रेंडरर को पता चलता है कि यह एक मान्य इमेज फ़ॉर्मैट नहीं है और यह किसी इमेज को रेंडर नहीं करता है. हालांकि, Spectre की मदद से इस तरह की
जानकारी को आसानी से पढ़ा जा सकता है. किसी दूसरी साइट से दस्तावेज़ को ब्लॉक करने की सुविधा से,
इस फ़ाइल के कॉन्टेंट को रेंडरर की प्रोसेस की मेमोरी में जाने से रोका जा सकेगा. इसकी वजह यह है कि क्रॉस-साइट दस्तावेज़ को ब्लॉक करने
की वजह से, MIME टाइप को ब्लॉक किया जाता है.
उपयोगकर्ता मेट्रिक के मुताबिक, बहुत सारी JavaScript और सीएसएस फ़ाइलें मौजूद हैं, जिन्हें text/html या text/plain MIME टाइप में डिलीवर किया जाता है. गलती से दस्तावेज़ के तौर पर मार्क हुए संसाधनों को ब्लॉक करने से बचने के लिए, Chrome रिस्पॉन्स को स्निफ़ करने की कोशिश करता है, ताकि यह पक्का किया जा सके कि MIME टाइप सही है. यह स्निफ़िंग सटीक नहीं है, इसलिए
अगर आपको पक्का पता है कि आप अपनी वेबसाइट पर सही Content-Type हेडर सेट कर रहे हैं, तो Chrome टीम का सुझाव है कि आप अपने सभी जवाबों में X-Content-Type-Options: nosniff
हेडर जोड़ें.
अगर आपको क्रॉस-साइट दस्तावेज़ को ब्लॉक करने की सुविधा को आज़माना है, तो ऊपर बताए गए तरीके से साइट आइसोलेशन की सुविधा के लिए ऑप्ट-इन करें.
SameSite कुकी
आइए, ऊपर दिए गए उदाहरण पर वापस चलते हैं: <img
src="https://yourbank.com/balance.json">. यह सिर्फ़ तब काम करता है, जब yourbank.com
पर ऐसी कुकी सेव की गई हो जो उपयोगकर्ता को अपने-आप लॉग इन करती है. आम तौर पर, कुकी, कुकी सेट करने वाली वेबसाइट पर किए गए सभी अनुरोधों के लिए भेजी जाती हैं — भले ही, कोई तीसरा पक्ष, <img> टैग का इस्तेमाल करके अनुरोध करे. 'सेमसाइट कुकी' एक नया एट्रिब्यूट है. इससे पता चलता है कि कुकी को सिर्फ़ उसी अनुरोध से अटैच किया जाना चाहिए जो उसी साइट से शुरू हुआ है. इसलिए, इस कुकी का नाम रखा गया है. अफ़सोस की बात यह है कि डेटा लिखते समय, सिर्फ़ Chrome और Firefox 58+ में ही इस एट्रिब्यूट का इस्तेमाल किया जा सकता है.
HTTPOnly और document.cookie
अगर आपकी साइट की कुकी का इस्तेमाल सिर्फ़ सर्वर साइड का इस्तेमाल किया जाता है, क्लाइंट JavaScript के ज़रिए नहीं, तो ऐसे कुछ तरीके हैं जिनसे कुकी के डेटा को रेंडरर प्रोसेस में जाने से रोका जा सकता है. आपके पास HTTPOnly कुकी एट्रिब्यूट सेट करने का विकल्प होता है. इससे यह पक्का होता है कि Chrome जैसे ब्राउज़र पर, क्लाइंट साइड स्क्रिप्ट से कुकी को ऐक्सेस नहीं किया जा सकता. अगर HTTPOnly को सेट नहीं किया जा सकता, तो रेंडर की गई प्रोसेस में कुकी डेटा लोड होने का जोखिम कम करें. अगर बहुत ज़रूरी न हो, तो document.cookie पढ़ें.
rel="noopener" का इस्तेमाल करके बाहरी लिंक खोलें
target="_blank" का इस्तेमाल करके किसी अन्य पेज से लिंक करने पर, खुले हुए पेज को आपके window ऑब्जेक्ट का ऐक्सेस मिलता है,
आपके पेज को किसी दूसरे यूआरएल पर नेविगेट किया जा सकता है. साथ ही, 'साइट आइसोलेशन' के बिना, यह वही प्रोसेस होगा जो आपके पेज पर होता है. आपके पेज की बेहतर सुरक्षा के लिए, नई विंडो में खुलने वाले बाहरी पेजों के लिंक में, हमेशा rel="noopener" की जानकारी दी जानी चाहिए.
हाई रिज़ॉल्यूशन वाले टाइमर
मेल्टडाउन या स्पेक्टर का फ़ायदा उठाने के लिए, किसी हमलावर को यह मापना होगा कि मेमोरी से किसी खास वैल्यू को पढ़ने में उसे कितना समय लगेगा. इसके लिए, एक भरोसेमंद और सटीक टाइमर की ज़रूरत होती है.
वेब प्लैटफ़ॉर्म पर उपलब्ध एक एपीआई
performance.now()
पांच माइक्रोसेकंड तक सटीक होता है. इसे कम करने के लिए, सभी मुख्य ब्राउज़र ने performance.now() के रिज़ॉल्यूशन को कम कर दिया है, ताकि हमलों को माउंट करना मुश्किल हो जाए.
हाई-रिज़ॉल्यूशन टाइमर पाने का एक और तरीका है, SharedArrayBuffer का इस्तेमाल करना. काउंटर को बढ़ाने के लिए, एक खास वर्कर, बफ़र का इस्तेमाल करता है. मुख्य थ्रेड इस काउंटर को पढ़ता है और उसका इस्तेमाल टाइमर के तौर पर करता है. कुछ समय के लिए ब्राउज़र ने SharedArrayBuffer को बंद करने का फ़ैसला किया है, जब तक कि अन्य पाबंदियां लागू नहीं हो जातीं.
V8
Spectre का फ़ायदा उठाने के लिए, खास तौर पर सीपीयू से जुड़े निर्देशों के बनाए गए क्रम की ज़रूरत होती है. V8 की टीम ने हमले के प्रसिद्ध सबूतों के लिए पाबंदियां लागू की हैं. साथ ही, वह TurboFan का ऑप्टिमाइज़ करने वाला ऐसा कंपाइलर है जो इसके जनरेट किए गए कोड को सुरक्षित रखता है. हालांकि, कोड जनरेट करने के इन बदलावों की वजह से परफ़ॉर्मेंस पेनल्टी लगाई जा सकती है.
वेब को सुरक्षित रखना
स्पेक्टर और मेल्टडाउन की खोज और इनके असर को लेकर अनिश्चितता बनी हुई है. मुझे उम्मीद है कि इस लेख से कुछ पता चलेगा कि Chrome और V8 की टीमें, वेब प्लैटफ़ॉर्म को सुरक्षित रखने के लिए क्या कर रही हैं. साथ ही, यह भी पता चलेगा कि वेब डेवलपर, मौजूदा सुरक्षा सुविधाओं का इस्तेमाल करके किस तरह मदद कर सकते हैं. अगर आपका कोई सवाल है, तो बेझिझक Twitter पर हमसे संपर्क करें.