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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

अपने-आप होने वाली जांच

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

रूट प्रोसेस को अलग करना

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

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

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

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

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

प्रोसेस को अलग करना

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

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