ऐप्लिकेशन की सुरक्षा के लिए सबसे सही तरीके

इस सेक्शन में, Android डिवाइसों पर ऐप्लिकेशन को सुरक्षित रखने के लिए सुझाव दिए गए हैं.

सोर्स कोड की समीक्षा

सोर्स कोड की समीक्षा करने से, सुरक्षा से जुड़ी कई समस्याओं का पता लगाया जा सकता है. इनमें वे समस्याएं भी शामिल हैं जिनके बारे में इस दस्तावेज़ में बताया गया है. Android, सोर्स कोड की मैन्युअल और ऑटोमेटेड, दोनों तरह से समीक्षा करने का सुझाव देता है.

• समीक्षाएं करते समय, सुरक्षा से जुड़े सभी दिशा-निर्देशों का पालन करें, ताकि यह पक्का किया जा सके कि सभी पहलुओं को शामिल किया गया है. समीक्षाओं को एक जैसा और पूरा करने के लिए, काम के अंदरूनी या बाहरी स्टैंडर्ड का इस्तेमाल करें.
• Android SDK का इस्तेमाल करके, ऐप्लिकेशन के सभी कोड पर लिंटर चलाएं. जैसे, Android Studio लिंटर. साथ ही, पहचानी गई सभी समस्याओं को ठीक करें.
• ऑटोमेटेड टूल का इस्तेमाल करके, नेटिव कोड का विश्लेषण करें. यह टूल, मेमोरी मैनेजमेंट से जुड़ी समस्याओं का पता लगा सकता है. जैसे, बफ़र ओवरफ़्लो और ऑफ़-बाय-वन गड़बड़ियां.
• Android बिल्ड सिस्टम, LLVM सैनिटाइज़र के कई टूल के साथ काम करता है. जैसे, AddressSanitizer और UndefinedBehaviorSanitizer. इनका इस्तेमाल, मेमोरी से जुड़ी समस्याओं का रनटाइम विश्लेषण करने के लिए किया जा सकता है. सैनिटाइज़र, फ़ज़िंग के साथ मिलकर काम करते हैं. फ़ज़िंग की सुविधा, Android में libFuzzer के ज़रिए उपलब्ध है. सैनिटाइज़र, ऐसे असामान्य एज केस का पता लगा सकते हैं जिनकी आगे जांच करने की ज़रूरत होती है.
• सुरक्षा का आकलन करने वाले विशेषज्ञ को, ज़्यादा जोखिम वाले कोड की समीक्षा करनी चाहिए. जैसे, क्रिप्टोग्राफ़ी, पेमेंट प्रोसेसिंग, और पीआईआई प्रोसेसिंग.

अपने-आप होने वाली टेस्टिंग

ऑटोमेटेड टेस्टिंग से, सुरक्षा से जुड़ी कई समस्याओं का पता लगाया जा सकता है. इसलिए, इसे नियमित रूप से किया जाना चाहिए.

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

कमियां पता लगाना

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

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

नुकसान पहुंचा सकने वाले ऐप्लिकेशन

यह पक्का करना ज़रूरी है कि आपके डिवाइस पर पहले से इंस्टॉल किए गए ऐप्लिकेशन, संभावित रूप से नुकसान पहुंचाने वाले ऐप्लिकेशन (पीएचए) न हों. आपके डिवाइसों पर मौजूद सभी ऐप्लिकेशन के व्यवहार की ज़िम्मेदारी आपकी है. डिवाइस लॉन्च करने से पहले, पहले से लोड किए गए सभी ऐप्लिकेशन को स्कैन करें, ताकि कमज़ोरियों का पता चल सके.

पीएचए और Google Play Store में Google उनसे कैसे निपट रहा है, इस बारे में ज़्यादा जानने के लिए, Google Play Protect के डेवलपर दस्तावेज़ देखें.

ऐप्लिकेशन इंस्टॉल करना और अनुमतियां

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

• पहले से इंस्टॉल किए गए ऐप्लिकेशन को गैर-ज़रूरी अनुमतियां या विशेषाधिकार न दें. सिस्टम के विशेषाधिकारों वाले ऐप्लिकेशन की अच्छी तरह से समीक्षा करें, क्योंकि उनके पास बहुत संवेदनशील अनुमतियां हो सकती हैं.
• पक्का करें कि मांगी गई सभी अनुमतियां, उस ऐप्लिकेशन के फ़ंक्शन के लिए ज़रूरी और काम की हों.
• पक्का करें कि पहले से इंस्टॉल किए गए सभी ऐप्लिकेशन के लिए, उपयोगकर्ता को जानकारी दी गई हो. ये ऐसे ऐप्लिकेशन होने चाहिए जो INSTALL_PACKAGES अनुमति का इस्तेमाल करते हैं.
• पक्का करें कि डेवलपर, कानूनी समझौते के तहत UID 0 के तौर पर कोई भी ऐप्लिकेशन इंस्टॉल न करे.
• डेवलपर के नेटवर्क के ज़रिए इंस्टॉल किए जाने वाले सभी ऐप्लिकेशन के मेनिफ़ेस्ट में बताई गई अनुमतियों का आकलन करें.
• पक्का करें कि डेवलपर, डिवाइस पर ऐप्लिकेशन उपलब्ध कराने से पहले, Google Safe Browsing API की मदद से, अपने-आप अपडेट होने वाले और इंस्टॉलर ऐप्लिकेशन के सभी डाउनलोड यूआरएल को स्कैन करने के लिए कानूनी तौर पर बाध्य हो.

ऐप पर हस्ताक्षर

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

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

ऐप्लिकेशन और प्रोसेस को आइसोलेट करना

Android का सैंडबॉक्सिंग मॉडल, सही तरीके से इस्तेमाल करने पर ऐप्लिकेशन और प्रोसेस को ज़्यादा सुरक्षा देता है.

रूट प्रोसेस को आइसोलेट करना

रूट प्रोसेस, विशेषाधिकार बढ़ाने वाले हमलों का सबसे ज़्यादा बार निशाना बनती हैं. रूट प्रोसेस की संख्या कम करने से, विशेषाधिकार बढ़ाने वाले हमलों का जोखिम कम हो जाता है.

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

सिस्टम ऐप्लिकेशन को अलग करना

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

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

प्रोसेस को आइसोलेट करना

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

• पक्का करें कि रूट प्रोसेस, किसी ऐप्लिकेशन के डेटा फ़ोल्डर में मौजूद डेटा को ऐक्सेस न करें. ऐसा तब तक न करें, जब तक कि Android की डिबगिंग के लिए दस्तावेज़ में बताए गए तरीके का इस्तेमाल न किया जा रहा हो.
• यह पक्का करें कि रूट प्रोसेस, ऐप्लिकेशन की मेमोरी को ऐक्सेस न करें. हालांकि, अगर Android के डीबग करने के किसी ऐसे तरीके का इस्तेमाल किया जा रहा है जिसके बारे में दस्तावेज़ में बताया गया है, तो रूट प्रोसेस, ऐप्लिकेशन की मेमोरी को ऐक्सेस कर सकती हैं.
• पक्का करें कि डिवाइसों में ऐसा कोई ऐप्लिकेशन न हो जो दूसरे ऐप्लिकेशन या प्रोसेस के डेटा या मेमोरी को ऐक्सेस करता हो.