खास जानकारी
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"> या iframe का इस्तेमाल करके
अन्य ऐप्लिकेशन को खोला हो. अगर किसी वेबसाइट में उपयोगकर्ता का खास डेटा मौजूद है, तो इस बात की संभावना होती है कि कोई दूसरी साइट, उपयोगकर्ता के डेटा को पढ़ने के लिए इन नए जोखिमों का इस्तेमाल कर सकती है.
खतरों को कम करना
इस खतरे को कम करने के लिए, Chrome और V8 इंजीनियरिंग टीम कई कोशिशें कर रही है.
साइट आइसोलेशन
संवेदनशील डेटा को हमलावर के कंट्रोल वाले कोड के साथ प्रोसेस शेयर करने से रोककर, स्पेक्टर का सही तरीके से इस्तेमाल करने के असर को काफ़ी हद तक कम किया जा सकता है. Chrome टीम, “साइट आइसोलेशन” नाम की एक सुविधा पर काम कर रही है:
साइट आइसोलेशन को अभी तक डिफ़ॉल्ट रूप से चालू नहीं किया गया है, क्योंकि इसमें कुछ
जानी-पहचानी समस्याएं हैं.
Chrome टीम फ़ील्ड की ज़्यादा से ज़्यादा जांच करने की कोशिश कर रही है. अगर आप वेब डेवलपर हैं, तो आपको 'साइट आइसोलेशन' चालू करना चाहिए और यह देखना चाहिए कि आपकी साइट ठीक से काम कर रही है या नहीं. अगर आपको अभी ऑप्ट-इन करना है, तो
chrome://flags#enable-site-per-process को चालू करें. अगर आपको कोई ऐसी साइट मिलती है जो काम नहीं करती है,
तो कृपया गड़बड़ी की शिकायत करें और हमें बताएं कि आपने साइट आइसोलेशन की सुविधा चालू की है.
अलग-अलग साइटों पर दस्तावेज़ ब्लॉक करने की सुविधा
भले ही, अलग-अलग साइट के सभी पेजों को अलग-अलग प्रोसेस में रखा जाता है, तब भी पेज, इमेज और JavaScript जैसे कुछ क्रॉस-साइट सबरिसॉर्स का मान्य तरीके से अनुरोध कर सकते हैं. संवेदनशील जानकारी को लीक होने से रोकने के लिए, साइट आइसोलेशन में “क्रॉस-साइट दस्तावेज़ ब्लॉक करने” की सुविधा शामिल है. यह सुविधा, रेंडरर प्रोसेस के दौरान मिलने वाले नेटवर्क रिस्पॉन्स को सीमित करती है.
कोई वेबसाइट, सर्वर से दो तरह के डेटा का अनुरोध कर सकती है: “दस्तावेज़” और “संसाधन”. यहां दस्तावेज़, एचटीएमएल, एक्सएमएल, JSON, और टेक्स्ट फ़ाइलें हैं. कोई वेबसाइट अपने डोमेन या दूसरे डोमेन से अनुमति वाले सीओआरएस हेडर वाले दस्तावेज़ पा सकती है. संसाधनों में चित्र, JavaScript, CSS और फ़ॉन्ट जैसी चीज़ें शामिल होती हैं. संसाधन किसी भी साइट से शामिल किए जा सकते हैं.
क्रॉस-साइट दस्तावेज़ पर रोक लगाने की नीति, किसी प्रोसेस को अन्य ऑरिजिन से “दस्तावेज़” पाने से रोकती है, अगर:
- उनमें एचटीएमएल, एक्सएमएल, JSON या टेक्स्ट/सादा MIME टाइप होता है और
- इनमें
X-Content-Type-Options: nosniffएचटीटीपी रिस्पॉन्स हेडर या क्विक कॉन्टेंट ऐनलिसिस ("स्निफ़िंग") होता है, जिससे यह पुष्टि होती है कि टाइप सही है - सीओआरएस साफ़ तौर पर दस्तावेज़ को ऐक्सेस करने की अनुमति नहीं देता है
इस नीति के तहत ब्लॉक किए गए दस्तावेज़ों को प्रोसेस के लिए खाली दिखाया जाता है. हालांकि, अनुरोध अब भी बैकग्राउंड में किया जाता है.
उदाहरण के लिए: मान लें कि कोई हमलावर <img> टैग बना रहा है, जिसमें <img src="https://yourbank.com/balance.json"> जैसे संवेदनशील जानकारी वाली JSON फ़ाइल शामिल है.
साइट आइसोलेशन के बिना, JSON फ़ाइल का कॉन्टेंट, उसे रेंडरर प्रोसेस की मेमोरी में भेज देता है. इस दौरान, रेंडरर को पता चलता है कि यह एक मान्य इमेज फ़ॉर्मैट नहीं है और वह इमेज रेंडर नहीं कर पाता. हालांकि, स्पेक्ट्र के साथ अब एक ऐसा तरीका उपलब्ध है
जिससे मेमोरी के उस हिस्से को पढ़ा जा सकता है. क्रॉस-साइट दस्तावेज़ ब्लॉक करने से, इस फ़ाइल के कॉन्टेंट को उस प्रोसेस की मेमोरी में जाने से रोका जा सकता है जिसमें रेंडरर चल रहा है. ऐसा इसलिए होगा, क्योंकि 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> टैग का इस्तेमाल करके किया हो. SameSite कुकी एक नया एट्रिब्यूट है, जिसमें बताया जाता है कि कुकी को सिर्फ़ उसी साइट से आने वाले अनुरोध से जोड़ा जाना चाहिए. इसलिए, इसे उसका नाम दिया गया है. अफ़सोस की बात है, लिखने के समय, सिर्फ़ 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
स्पेक्ट्र का इस्तेमाल करने के लिए, खास तौर पर सीपीयू के निर्देशों का तैयार किया गया क्रम ज़रूरी है. V8 टीम ने हमले के कॉन्सेप्ट के बारे में पहले से जानकारी पाने के लिए, खतरों को कम करने की प्रोसेस लागू की है. साथ ही, वह TurboFan में होने वाले बदलावों पर काम कर रही है. यह उनका ऑप्टिमाइज़ेशन कंपाइलर है, जिससे इन हमलों के ट्रिगर होने पर भी, जनरेट किया गया कोड सुरक्षित रहता है. हालांकि, कोड जनरेशन में हुए इन बदलावों की वजह से परफ़ॉर्मेंस पर असर पड़ सकता है.
वेब को सुरक्षित रखना
स्पेक्टर और मेल्टडाउन की खोज और इनके असर को लेकर कई अनिश्चितता है. मुझे उम्मीद है कि इस लेख से आपको पता चलेगा कि Chrome और V8 की टीमें, वेब प्लैटफ़ॉर्म को सुरक्षित रखने के लिए क्या कर रही हैं. साथ ही, यह भी पता चलेगा कि वेब डेवलपर, सुरक्षा से जुड़ी मौजूदा सुविधाओं का इस्तेमाल करके किस तरह मदद कर सकते हैं. अगर आपका कोई सवाल है, तो बेझिझक Twitter पर हमसे संपर्क करें.