डेवलपर के लिए नीति और सुरक्षा से जुड़े दिशा-निर्देश

Simon Hangl

Demián Renzulli

आइसोलेटेड वेब ऐप्लिकेशन (आईडब्ल्यूए) एक ऐसा सुरक्षा मॉडल उपलब्ध कराते हैं जिसकी मदद से वेब ऐप्लिकेशन, Direct Sockets और Controlled Frame जैसी सुविधाओं को ऐक्सेस कर सकते हैं. आम तौर पर, ये सुविधाएं स्टैंडर्ड "ड्राइव-बाय" वेब में उपलब्ध नहीं होती हैं. आईडब्ल्यूए, भरोसेमंद माहौल में काम करते हैं. इसलिए, उन्हें सुरक्षा और निजता से जुड़ी सख्त नीतियों का पालन करना होगा. इन गाइडलाइन को इसलिए बनाया गया है, ताकि वेब प्लैटफ़ॉर्म को ज़्यादा सुविधाएं मिलने पर भी, उपयोगकर्ता सुरक्षित रहें. साथ ही, ब्राउज़र के एनवायरमेंट की अखंडता बनी रहे.

IWA का ट्रस्ट मॉडल

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

पहचान की पुष्टि होने के बाद, IWAs को खास एपीआई का ऐक्सेस मिल जाता है. इस भरोसे को बनाए रखने के लिए, डेवलपर को सुरक्षा को प्राथमिकता देनी चाहिए. इसके लिए, उन्हें सख्त नीतियों का पालन करना होगा. इनमें कॉन्टेंट सिक्योरिटी पॉलिसी (सीएसपी) और भरोसेमंद टाइप शामिल हैं. इनसे यह पक्का किया जा सकता है कि शक्तिशाली सुविधाओं का इस्तेमाल करते समय भी उपयोगकर्ता सुरक्षित रहें. इसका मतलब है कि:

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

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

इन दिशा-निर्देशों का क्या महत्व है

इन नीतियों का पालन करना सिर्फ़ नियमों का पालन करना नहीं है, बल्कि बेहतर वेब ऐप्लिकेशन के लिए एक टिकाऊ नेटवर्क बनाना है. इन दिशा-निर्देशों का पालन करके, यह पक्का किया जा सकता है कि आपका आवेदन:

• सुरक्षा से जुड़ी समस्याओं से बचाता है: लॉजिक को अलग रखने से, क्रॉस-साइट स्क्रिप्टिंग (XSS) और रिमोट कोड एक्ज़ीक्यूशन जैसी समस्याओं को रोका जा सकता है.
• उपयोगकर्ता की निजता को सुरक्षित रखता है: यह पक्का करता है कि संवेदनशील डेटा और हार्डवेयर ऐक्सेस को सिर्फ़ उपयोगकर्ता की सहमति और पारदर्शिता के साथ मैनेज किया जाए.
• प्लैटफ़ॉर्म को लंबे समय तक इस्तेमाल किया जा सकता है: इससे, IWA प्लैटफ़ॉर्म के लिए ज़रूरी सुरक्षा मानकों को बनाए रखने में मदद मिलती है. इससे IWA प्लैटफ़ॉर्म को अपनी क्षमताओं को बढ़ाने में मदद मिलती है.

मुख्य सिद्धांत

पारदर्शिता और उपयोगकर्ता का मकसद

सबसे बुनियादी नियम यह है कि उपयोगकर्ता को चौंकाएं नहीं. आपके ऐप्लिकेशन का व्यवहार, उसके बताए गए मकसद और उपयोगकर्ता की उम्मीदों के मुताबिक होना चाहिए.

• स्कोप में रहें: ऐसी सुविधा लागू न करें जो आपके ऐप्लिकेशन के मुख्य मकसद से बाहर हो.
• एपीआई का कम से कम इस्तेमाल: अपने ऐप्लिकेशन के मुख्य फ़ंक्शन को पूरा करने के लिए, सिर्फ़ IWA एपीआई के ज़रूरी सेट का अनुरोध करें और उनका इस्तेमाल करें.

डाइनैमिक कोड को साइडलोड करने की सुविधा उपलब्ध नहीं है

IWA का सुरक्षा मॉडल, इस बात पर निर्भर करता है कि एडमिन या ब्राउज़र वेंडर, सभी एक्ज़ीक्यूटेबल लॉजिक की पुष्टि कर सकते हैं या नहीं. इसलिए, आपके आईडब्ल्यूए पैकेज में सभी ज़रूरी चीज़ें शामिल होनी चाहिए. यह प्लैटफ़ॉर्म, कॉन्टेंट की सुरक्षा के लिए बनी सख्त नीति (सीएसपी) के ज़रिए इसे लागू करता है. यह नीति, स्ट्रिंग पर आधारित एक्ज़ीक्यूशन को ब्लॉक करती है. जैसे, eval() और new Function():

script-src 'self' 'wasm-unsafe-eval';
require-trusted-types-for 'script';

सीएसपी, 'wasm-unsafe-eval' को WebAssembly के साथ काम करने की अनुमति देता है. हालांकि, आपको सुरक्षा से जुड़ी इस सीमा को नज़रअंदाज़ नहीं करना चाहिए.

वे काम जिन पर पाबंदी है

• रिमोट कोड के लिए इंटरप्रेटर शिप करना: आपको कोड इंटरप्रेटर (उदाहरण के लिए, Python या Lua को WASM में कंपाइल किया गया) को डाउनलोड करने और बाहरी स्क्रिप्ट को एक्ज़ीक्यूट करने के लिए, डायरेक्ट सॉकेट जैसे खास नेटवर्क ऐक्सेस का इस्तेमाल करने की अनुमति नहीं है.
• दूर से लोड किया गया लॉजिक: सर्विस वर्कर का इस्तेमाल करके, दूर से लोड किए गए कोड को IWA ऑरिजिन में एम्बेड न करें.
• कोड बनाम डेटा: डेटा (जैसे कि JSON) डाउनलोड करने की अनुमति है. हालांकि, ऐसे किसी भी कोड को डाउनलोड करना नीति का सीधा उल्लंघन है जिसे इंटरप्रेट या चलाया जाना है.

कम से कम अधिकारों का सिद्धांत

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

एपीआई से जुड़े दिशा-निर्देश

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

Direct Sockets API

Direct Sockets API, रॉ टीसीपी और यूडीपी का ऐक्सेस देता है. इसमें मल्टीकास्ट और लोकल नेटवर्क का ऐक्सेस भी शामिल है.

अनुमति है

• कस्टम प्रोटोकॉल के साथ काम करना: ऐसे रिमोट सर्वर से कनेक्ट करना जो कस्टम प्रोटोकॉल का इस्तेमाल करते हैं. फ़िलहाल, इनके लिए कोई हायर-लेवल वेब एपीआई उपलब्ध नहीं है.
• बैकएंड सेवाओं को बनाए रखना: पहले से तय किए गए, हार्ड-कोड किए गए सर्वर से कनेक्ट करना. इस सर्वर का इस्तेमाल खास तौर पर आपके ऐप्लिकेशन की बैकएंड सेवाओं के लिए किया जाता है.
• ज़रूरी हार्डवेयर ढूंढना: ऐप्लिकेशन के काम करने के लिए ज़रूरी हार्डवेयर ढूंढने के लिए, लोकल नेटवर्क को ऐक्सेस करना या मल्टीकास्ट का इस्तेमाल करना. उदाहरण के लिए, वीडियो एडिटिंग ऐप्लिकेशन के लिए नेटवर्क से जुड़ा स्टोरेज ढूंढना.

अनुमति नहीं है

• उपयोगकर्ता को चौंकाना: ऐप्लिकेशन की मुख्य सुविधा के हिसाब से नेटवर्क ऐक्सेस की सुविधा को लागू न करना. जैसे, टेक्स्ट एडिटर का लोकल नेटवर्क डिवाइसों से कम्यूनिकेट करना.
• नेटवर्क को मनमाने तरीके से स्कैन करना: उपयोगकर्ता की प्रोफ़ाइल बनाने या उससे जुड़े डिवाइसों का पता लगाने के लिए, उसके लोकल नेटवर्क को बड़े पैमाने पर स्कैन करना. उदाहरण के लिए, 192.168.1.0/24 को पोर्ट-स्कैन करना.
• लोकल डिवाइसों को टारगेट करना: लोकल नेटवर्क पर मौजूद अन्य डिवाइसों की जांच करने, उन्हें फिर से कॉन्फ़िगर करने या उन पर हमला करने की कोशिश करने पर पाबंदी है.

Controlled Frame API

<controlledframe> एलिमेंट की मदद से, अलग-अलग ऑरिजिन के कॉन्टेंट को एम्बेड किया जा सकता है और उसमें बदलाव किया जा सकता है. इसमें स्क्रिप्ट इंजेक्ट करना और हेडर में बदलाव करना शामिल है.

अनुमति है

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

अनुमति नहीं है

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

बिना किसी पाबंदी के स्क्रीन रिकॉर्डिंग

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

अनुमति है

• मुख्य फ़ंक्शन उपलब्ध कराना: स्क्रीन कैप्चर करने की सुविधा को ऐप्लिकेशन की सेवा के एक अहम हिस्से के तौर पर इस्तेमाल करना. जैसे, वर्चुअल मीटिंग या ट्यूटोरियल रिकॉर्ड करने की सुविधाओं में.
• उपयोगकर्ता को जानकारी देना: उपयोगकर्ताओं को साफ़ तौर पर यह बताना कि ऐप्लिकेशन का इस्तेमाल करने से पहले ही रिकॉर्डिंग शुरू हो सकती है.

अनुमति नहीं है

• छुपकर रिकॉर्ड करना: उपयोगकर्ता की सहमति लिए बिना और उसे साफ़ तौर पर जानकारी दिए बिना, उसकी स्क्रीन को कैप्चर करना.
• निजता से जुड़े नियमों का उल्लंघन करना: रिकॉर्डिंग से जुड़ी ऐसी किसी भी गतिविधि में शामिल होना जिससे निजता से जुड़े स्थानीय या अंतरराष्ट्रीय कानूनों का उल्लंघन होता हो.

WebUSB पर कोई पाबंदी नहीं है

WebUSB पर कोई पाबंदी नहीं सेटिंग, WebUSB की स्टैंडर्ड ब्लॉकलिस्ट को बायपास करती है, ताकि डिवाइसों के साथ लोअर-लेवल इंटरैक्शन किया जा सके.

अनुमति है

• मालिकाना हक वाले हार्डवेयर के साथ काम करना: ऐसे खास या लेगसी हार्डवेयर के साथ इंटरैक्ट करना जिसके लिए कोई हाई-लेवल वेब एपीआई मौजूद नहीं है. जैसे, इंडस्ट्रियल कंट्रोलर.

अब अनुमति है

• खास तौर पर बनाए गए एपीआई को बायपास करना: WebUSB का इस्तेमाल उन डिवाइसों के लिए करना जिनमें ज़्यादा खास और सीमित एपीआई होता है. जैसे, स्मार्ट कार्ड (Smart Card API का इस्तेमाल करें) या बाहरी स्टोरेज (File System Access API का इस्तेमाल करें).

विंडो मैनेजमेंट (window.open और window.focus)

आईडब्ल्यूए, पॉपअप और फ़ोकस विंडो बना सकते हैं. इसके लिए, उन्हें स्टैंडर्ड वेब के लिए ज़रूरी उपयोगकर्ता के जेस्चर की ज़रूरत नहीं होती.

अनुमति है

• टास्क पूरा होने की सूचना देना: जब उपयोगकर्ता की शुरू की गई कोई ज़रूरी कार्रवाई पूरी हो जाती है, तब ऐप्लिकेशन विंडो पर फ़ोकस करना. जैसे, वीडियो रेंडर करना.

अनुमति नहीं है

• स्पैम करना: उपयोगकर्ता को एक साथ कई अनचाही विंडो दिखाना.
• फ़िशिंग: ऐसे विंडो खोलना जो सिस्टम डायलॉग की नकल करते हैं या उपयोगकर्ता को धोखा देते हैं.
• ध्यान भटकाना: ज़रूरी न होने वाले इवेंट के लिए, अन्य ऐप्लिकेशन से उपयोगकर्ता का ध्यान भटकाना.

नतीजा

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

• पारदर्शिता को प्राथमिकता दें: आपके ऐप्लिकेशन का व्यवहार हमेशा उसके बताए गए मकसद के मुताबिक होना चाहिए. कभी भी ऐसी सुविधा लागू न करें जिससे उपयोगकर्ता को हैरानी हो या उसे धोखा मिले.
• पैकेज इंटिग्रिटी लागू करें: सभी एक्ज़ीक्यूटेबल लॉजिक को आपके आईडब्ल्यूए बंडल में शामिल किया जाना चाहिए, ताकि स्टैटिक पुष्टि की जा सके. डाइनैमिक कोड साइडलोडिंग या रिमोट इंटरप्रेटर के ज़रिए सुरक्षा मॉडल को बायपास करने पर पूरी तरह से पाबंदी है.
• कम से कम विशेषाधिकारों का पालन करें: किसी टास्क के लिए, हमेशा सबसे सीमित एपीआई चुनें. आईडब्ल्यूए के खास एपीआई का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब ऐप्लिकेशन के मुख्य फ़ंक्शन के लिए स्टैंडर्ड वेब एपीआई काफ़ी न हों.
• गेटकीपर के तौर पर काम करना: <controlledframe> जैसे शक्तिशाली टूल का इस्तेमाल करते समय, आपके आईडब्ल्यूए को भरोसेमंद न होने वाले कॉन्टेंट के लिए पारदर्शी प्रॉक्सी के बजाय, सुरक्षित मीडिएटर के तौर पर काम करना चाहिए.

अपने आईडब्ल्यूए को पब्लिश करने से पहले, लागू करने की प्रोसेस का आखिरी ऑडिट करें. इसके लिए, ये सवाल पूछें:

1. क्या इस टास्क के लिए, सबसे आसान और कम से कम पाबंदियों वाला एपीआई इस्तेमाल किया जा रहा है?
2. क्या मेरे ऐप्लिकेशन की गतिविधियों से किसी उपयोगकर्ता को हैरानी होगी या उसे लगेगा कि उसके साथ धोखा हुआ है?

अगर पहले सवाल का जवाब "नहीं" है या दूसरे सवाल का जवाब "हां" है, तो हो सकता है कि आपका आवेदन, IWA की सुरक्षा नीतियों का उल्लंघन करता हो. ऐसे में, उसे हटाया जा सकता है.