सुरक्षा के लिए चेकलिस्ट

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

सुरक्षा से जुड़ी ये मुख्य सुविधाएं, सुरक्षित ऐप्लिकेशन बनाने में आपकी मदद करती हैं:

  • Android ऐप्लिकेशन सैंडबॉक्स, जो आपके ऐप्लिकेशन के डेटा और कोड को अन्य ऐप्लिकेशन से अलग रखता है.
  • यह एक ऐसा ऐप्लिकेशन फ़्रेमवर्क है जिसमें सुरक्षा से जुड़ी सामान्य सुविधाओं को बेहतर तरीके से लागू किया गया है. जैसे, क्रिप्टोग्राफ़ी, अनुमतियां, और सुरक्षित इंटरप्रोसेस कम्यूनिकेशन (आईपीसी).
  • पते के स्पेस लेआउट को रैंडमाइज़ करना (ASLR), नॉन-एक्सीक्यूट (NX), ProPolice, safe_iop, OpenBSD dlmalloc और calloc, और Linux mmap_min_addr जैसी टेक्नोलॉजी, स्मृति मैनेजमेंट से जुड़ी सामान्य गड़बड़ियों से जुड़े जोखिमों को कम करने के लिए इस्तेमाल की जाती हैं.
  • सिस्टम की सुविधाओं और उपयोगकर्ता के डेटा के ऐक्सेस पर पाबंदी लगाने के लिए, उपयोगकर्ता से मिली अनुमतियां.
  • ऐप्लिकेशन के हिसाब से डेटा को कंट्रोल करने के लिए, ऐप्लिकेशन से तय की गई अनुमतियां.

इस पेज पर, Android की सुरक्षा से जुड़े सबसे सही तरीकों के बारे में जानना ज़रूरी है. कोडिंग के दौरान इन तरीकों का पालन करने से, अनजाने में सुरक्षा से जुड़ी ऐसी समस्याएं होने से बचने में मदद मिलती है जिनका आपके उपयोगकर्ताओं पर बुरा असर पड़ता है.

पुष्टि करना

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

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

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

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

ऐप्लिकेशन के लिए पूरी सुरक्षा देने की सुविधा

Play Integrity API की मदद से यह पता किया जा सकता है कि इंटरैक्शन और सर्वर के अनुरोध, आपके ऐप्लिकेशन की सही बाइनरी से हो रहे हैं या नहीं. साथ ही, यह पता किया जा सकता है कि ऐप्लिकेशन, सही Android डिवाइस पर चल रहा है या नहीं. इस सुविधा की मदद से, ऐसे इंटरैक्शन का पता लगाया जा सकता है जो जोखिम भरे और धोखाधड़ी वाले हो सकते हैं. जैसे, बदलाव किए गए ऐप्लिकेशन वर्शन और गैर-भरोसेमंद एनवायरमेंट से होने वाले इंटरैक्शन. इससे, आपके ऐप्लिकेशन के बैकएंड सर्वर पर सही कार्रवाइयां की जा सकती हैं, ताकि हमलों को रोका जा सके और गलत इस्तेमाल को कम किया जा सके.

डेटा स्टोरेज

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

  • मोबाइल मेमोरी
  • बाहरी मेमोरी
  • कॉन्टेंट देने वाले ऐप्लिकेशन

नीचे दिए गए सेक्शन में, हर तरीके से जुड़ी सुरक्षा से जुड़ी समस्याओं के बारे में बताया गया है.

मोबाइल मेमोरी

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

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

बाहरी मेमोरी

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

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

कॉन्टेंट देने वाले ऐप्लिकेशन

कॉन्टेंट उपलब्ध कराने वाली कंपनियां, स्टोरेज का ऐसा तरीका उपलब्ध कराती हैं जिसे आपके ऐप्लिकेशन तक सीमित किया जा सकता है. इसके अलावा, इसे एक्सपोर्ट करके दूसरे ऐप्लिकेशन से ऐक्सेस करने की अनुमति भी दी जा सकती है. अगर आपको अन्य ऐप्लिकेशन को अपने ContentProvider का ऐक्सेस नहीं देना है, तो ऐप्लिकेशन मेनिफ़ेस्ट में इसे android:exported=false के तौर पर मार्क करें. इसके अलावा, अन्य ऐप्लिकेशन को स्टोर किया गया डेटा ऐक्सेस करने की अनुमति देने के लिए, android:exported एट्रिब्यूट को true पर सेट करें.

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

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

कॉन्टेंट उपलब्ध कराने वाली कंपनियां, android:grantUriPermissions एट्रिब्यूट की जानकारी देकर और कॉम्पोनेंट को चालू करने वाले Intent ऑब्जेक्ट में FLAG_GRANT_READ_URI_PERMISSION और FLAG_GRANT_WRITE_URI_PERMISSION फ़्लैग का इस्तेमाल करके, ज़्यादा बेहतर तरीके से ऐक्सेस दे सकती हैं. <grant-uri-permission> एलिमेंट की मदद से, इन अनुमतियों के दायरे को और सीमित किया जा सकता है.

कॉन्टेंट प्रोवाइडर को ऐक्सेस करते समय, पैरामीटर वाली क्वेरी के तरीकों का इस्तेमाल करें. जैसे, query, update, और delete(). इससे, भरोसेमंद सोर्स से होने वाले संभावित एसक्यूएल इंजेक्शन से बचा जा सकता है. ध्यान दें कि अगर selection आर्ग्युमेंट को, उपयोगकर्ता के डेटा को तरीके में सबमिट करने से पहले, उसे जोड़कर बनाया जाता है, तो पैरामीटर वाले तरीकों का इस्तेमाल करना काफ़ी नहीं है.

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

अनुमतियां

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

अनुमति के अनुरोध

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

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

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

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

अनुमति की परिभाषाएं

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

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

अगर आपको अब भी नई अनुमति बनानी है, तो <permission> एलिमेंट का इस्तेमाल करके, ऐप्लिकेशन मेनिफ़ेस्ट में इसकी जानकारी दें. नई अनुमति का इस्तेमाल करने वाले ऐप्लिकेशन, अपनी मेनिफ़ेस्ट फ़ाइलों में <uses-permission> एलिमेंट जोड़कर, इसका रेफ़रंस दे सकते हैं. addPermission() तरीके का इस्तेमाल करके, अनुमतियों को डाइनैमिक तौर पर भी जोड़ा जा सकता है.

अगर आपने सुरक्षा के खतरनाक लेवल के साथ कोई अनुमति बनाई है, तो आपको कई बातों का ध्यान रखना होगा:

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

इनमें से हर एक, डेवलपर के तौर पर आपके लिए एक अहम गैर-तकनीकी चुनौती है. साथ ही, इससे आपके उपयोगकर्ता भी भ्रमित हो जाते हैं. इसलिए, हम खतरनाक अनुमति के लेवल का इस्तेमाल करने का सुझाव नहीं देते.

नेटवर्किंग

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

आईपी नेटवर्किंग

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

पुष्टि किए गए और एन्क्रिप्ट किए गए सॉकेट-लेवल के कम्यूनिकेशन को SSLSocket क्लास का इस्तेमाल करके आसानी से लागू किया जा सकता है. Android डिवाइसों को वाई-फ़ाई का इस्तेमाल करके, सुरक्षित न होने वाले वायरलेस नेटवर्क से कनेक्ट करने की फ़्रीक्वेंसी को देखते हुए, नेटवर्क से कनेक्ट होने वाले सभी ऐप्लिकेशन के लिए, सुरक्षित नेटवर्क का इस्तेमाल करने का सुझाव दिया जाता है.

कुछ ऐप्लिकेशन, संवेदनशील आईपीसी को मैनेज करने के लिए localhost नेटवर्क पोर्ट का इस्तेमाल करते हैं. इस तरीके का इस्तेमाल न करें, क्योंकि इन इंटरफ़ेस को डिवाइस पर मौजूद अन्य ऐप्लिकेशन ऐक्सेस कर सकते हैं. इसके बजाय, Android IPC के ऐसे तरीके का इस्तेमाल करें जिनमें पुष्टि की जा सकती है. जैसे, Service. किसी खास आईपी पते INADDR_ANY से बाइंड करना, लूपबैक का इस्तेमाल करने से भी खराब है. ऐसा इसलिए, क्योंकि इससे आपके ऐप्लिकेशन को किसी भी आईपी पते से अनुरोध मिल सकते हैं.

पक्का करें कि आप एचटीटीपी या अन्य असुरक्षित प्रोटोकॉल से डाउनलोड किए गए डेटा पर भरोसा न करें. इसमें WebView में दिए गए इनपुट की पुष्टि करना और एचटीटीपी के लिए जारी किए गए इंटेंट के जवाब शामिल हैं.

टेलीफ़ोनी नेटवर्किंग

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

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

इनपुट की पुष्टि करना

इनपुट की पुष्टि ठीक से न करना, ऐप्लिकेशन पर असर डालने वाली सुरक्षा से जुड़ी सबसे आम समस्याओं में से एक है. भले ही, वे किसी भी प्लैटफ़ॉर्म पर काम करते हों. Android में, प्लैटफ़ॉर्म-लेवल पर कुछ उपाय किए गए हैं. इनकी मदद से, ऐप्लिकेशन को इनपुट की पुष्टि से जुड़ी समस्याओं से बचाया जा सकता है. हमारा सुझाव है कि जहां भी हो सके, इन सुविधाओं का इस्तेमाल करें. साथ ही, हमारा सुझाव है कि इनपुट की पुष्टि से जुड़ी समस्याओं को कम करने के लिए, टाइप-सेफ़ भाषाओं का इस्तेमाल करें.

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

JavaScript और SQL जैसी डाइनैमिक और स्ट्रिंग पर आधारित भाषाओं में भी, एस्केप कैरेक्टर और स्क्रिप्ट इंजेक्शन की वजह से इनपुट की पुष्टि करने से जुड़ी समस्याएं आ सकती हैं.

अगर किसी SQL डेटाबेस या कॉन्टेंट प्रोवाइडर को सबमिट की गई क्वेरी में डेटा का इस्तेमाल किया जा रहा है, तो एसक्यूएल इंजेक्शन की समस्या हो सकती है. कॉन्टेंट उपलब्ध कराने वाली कंपनियों के सेक्शन में बताए गए तरीके के मुताबिक, पैरामीटर वाली क्वेरी का इस्तेमाल करना सबसे अच्छा तरीका है. अनुमतियों को रीड-ओनली या राइड-ओनली पर सीमित करने से, एसक्यूएल इंजेक्शन से होने वाले नुकसान की संभावना भी कम हो सकती है.

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

उपयोगकर्ता का डेटा

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

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

यह भी देखें कि क्या आपका ऐप्लिकेशन, गलती से अन्य पक्षों को निजी जानकारी ज़ाहिर कर सकता है. जैसे, विज्ञापन दिखाने के लिए तीसरे पक्ष के कॉम्पोनेंट या आपके ऐप्लिकेशन में इस्तेमाल की जाने वाली तीसरे पक्ष की सेवाएं. अगर आपको नहीं पता कि किसी कॉम्पोनेंट या सेवा के लिए निजी जानकारी क्यों ज़रूरी है, तो उसे न दें. आम तौर पर, अपने ऐप्लिकेशन के लिए निजी जानकारी के ऐक्सेस को कम करने से, इस क्षेत्र में समस्याओं की संभावना कम हो जाती है.

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

अगर ग्लोबल यूनीक आइडेंटिफ़ायर (GUID) की ज़रूरत है, तो एक बड़ी और यूनीक संख्या बनाएं और उसे सेव करें. फ़ोन नंबर या IMEI जैसे फ़ोन आइडेंटिफ़ायर का इस्तेमाल न करें. ये आइडेंटिफ़ायर, निजी जानकारी से जुड़े हो सकते हैं. इस विषय के बारे में ज़्यादा जानकारी के लिए, यूनीक आइडेंटिफ़ायर के इस्तेमाल के सबसे सही तरीकों वाले पेज पर जाएं.

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

WebView

WebView, वेब कॉन्टेंट का इस्तेमाल करता है. इसमें एचटीएमएल और JavaScript शामिल हो सकता है. गलत तरीके से इस्तेमाल करने पर, वेब की सुरक्षा से जुड़ी सामान्य समस्याएं हो सकती हैं. जैसे, क्रॉस-साइट स्क्रिप्टिंग (JavaScript इंजेक्शन). Android में कई तरह के तरीके शामिल हैं, जिनकी मदद से इन संभावित समस्याओं को कम किया जा सकता है. इसके लिए, WebView की सुविधाओं को आपके ऐप्लिकेशन के लिए ज़रूरी कम से कम फ़ंक्शन तक सीमित किया जाता है.

अगर आपका ऐप्लिकेशन WebView में सीधे तौर पर JavaScript का इस्तेमाल नहीं करता है, तो setJavaScriptEnabled को न कॉल करें. कुछ सैंपल कोड में इस तरीके का इस्तेमाल किया जाता है. अगर किसी सैंपल कोड का इस्तेमाल, प्रोडक्शन ऐप्लिकेशन में किया जाता है, तो ज़रूरत न होने पर उस तरीके को हटा दें. डिफ़ॉल्ट रूप से, WebView में JavaScript को लागू नहीं किया जाता. इसलिए, क्रॉस-साइट स्क्रिप्टिंग की सुविधा काम नहीं करती.

addJavaScriptInterface() का इस्तेमाल सावधानी से करें, क्योंकि इससे JavaScript उन ऑपरेशन को शुरू कर सकता है जो आम तौर पर Android ऐप्लिकेशन के लिए रिज़र्व होते हैं. अगर इसका इस्तेमाल किया जाता है, तो addJavaScriptInterface() को सिर्फ़ उन वेब पेजों के लिए दिखाएं जिनसे मिलने वाला सारा इनपुट भरोसेमंद हो. अगर गैर-भरोसेमंद इनपुट की अनुमति दी जाती है, तो गैर-भरोसेमंद JavaScript आपके ऐप्लिकेशन में Android के तरीकों को चालू कर सकता है. आम तौर पर, हमारा सुझाव है कि addJavaScriptInterface() को सिर्फ़ उस JavaScript के लिए दिखाएं जो आपके ऐप्लिकेशन के APK में मौजूद है.

अगर आपका ऐप्लिकेशन WebView का इस्तेमाल करके संवेदनशील डेटा ऐक्सेस करता है, तो लोकल स्टोरेज में सेव की गई किसी भी फ़ाइल को मिटाने के लिए, clearCache() तरीके का इस्तेमाल करें. no-store जैसे सर्वर-साइड हेडर का इस्तेमाल करके भी यह बताया जा सकता है कि किसी ऐप्लिकेशन को किसी खास कॉन्टेंट को कैश मेमोरी में सेव नहीं करना चाहिए.

Android 4.4 (एपीआई लेवल 19) से पहले के प्लैटफ़ॉर्म पर काम करने वाले डिवाइसों में, webkit का ऐसा वर्शन इस्तेमाल किया जाता है जिसमें सुरक्षा से जुड़ी कई समस्याएं होती हैं. अगर आपका ऐप्लिकेशन इन डिवाइसों पर चल रहा है, तो इस समस्या को हल करने के लिए यह ज़रूरी है कि वह पुष्टि करे कि WebView ऑब्जेक्ट सिर्फ़ भरोसेमंद कॉन्टेंट दिखाते हैं. यह पक्का करने के लिए कि आपका ऐप्लिकेशन एसएसएल में संभावित कमजोरियों से सुरक्षित रहे, अपडेट किए जा सकने वाले सुरक्षा Provider ऑब्जेक्ट का इस्तेमाल करें. इस बारे में ज़्यादा जानने के लिए, एसएसएल के गलत इस्तेमाल से बचाने के लिए, सुरक्षा सेवा देने वाली कंपनी को अपडेट करें लेख पढ़ें. अगर आपके ऐप्लिकेशन को ओपन वेब से कॉन्टेंट रेंडर करना है, तो अपने रेंडरर का इस्तेमाल करें. इससे, आपके पास सुरक्षा से जुड़े नए पैच के साथ इसे अप-टू-डेट रखने का विकल्प होगा.

क्रेडेंशियल के अनुरोध

क्रेडेंशियल के अनुरोध, हमले के लिए एक वेक्टर होते हैं. यहां कुछ सुझाव दिए गए हैं, जिनकी मदद से अपने Android ऐप्लिकेशन में क्रेडेंशियल के अनुरोधों को ज़्यादा सुरक्षित बनाया जा सकता है.

क्रेडेंशियल को कम से कम एक्सपोज़र दें

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

सुरक्षित तरीके से पुष्टि करने की सुविधा का इस्तेमाल करना

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

खाते को सुरक्षित तरीके से मैनेज करना

  • AccountManager का इस्तेमाल करके, उन सेवाओं से कनेक्ट करें जिन्हें कई ऐप्लिकेशन ऐक्सेस कर सकते हैं. क्लाउड-आधारित सेवा को शुरू करने के लिए, AccountManager क्लास का इस्तेमाल करें. साथ ही, डिवाइस पर पासवर्ड सेव न करें.
  • Account को वापस पाने के लिए AccountManager का इस्तेमाल करने के बाद, किसी भी क्रेडेंशियल को पास करने से पहले CREATOR का इस्तेमाल करें. इससे, अनजाने में किसी गलत ऐप्लिकेशन को क्रेडेंशियल पास करने से बचा जा सकता है.
  • अगर क्रेडेंशियल का इस्तेमाल सिर्फ़ आपके बनाए गए ऐप्लिकेशन करते हैं, तो checkSignatures का इस्तेमाल करके, AccountManager को ऐक्सेस करने वाले ऐप्लिकेशन की पुष्टि की जा सकती है. इसके अलावा, अगर सिर्फ़ एक ऐप्लिकेशन क्रेडेंशियल का इस्तेमाल करता है, तो स्टोरेज के लिए KeyStore का इस्तेमाल किया जा सकता है.

सतर्क रहें

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

एपीआई पासकोड मैनेज करना

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

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

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

जनरेट और स्टोर करना

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

कुंजी को सुरक्षित तरीके से सेव करना

कुंजी मैनेजमेंट की बेहतर सुरक्षा के लिए, Android कीस्टोर का इस्तेमाल करें. साथ ही, Tink Java जैसे किसी मज़बूत टूल का इस्तेमाल करके, सेव की गई कुंजियों को एन्क्रिप्ट करें.

सोर्स कंट्रोल से बाहर रखने की सुविधा

अपनी सोर्स कोड रिपॉज़िटरी में कभी भी एपीआई पासकोड को कमिट न करें. सोर्स कोड में एपीआई कुंजियां जोड़ने पर, सार्वजनिक रिपॉज़िटरी, शेयर किए गए कोड के उदाहरणों, और गलती से शेयर की गई फ़ाइलों में कुंजियों के दिखने का खतरा होता है. इसके बजाय, अपने प्रोजेक्ट में एपीआई पासकोड के साथ काम करने के लिए, secrets-gradle-plugin जैसे Gradle प्लग इन का इस्तेमाल करें.

एनवायरमेंट के हिसाब से बटन

अगर हो सके, तो डेवलपमेंट, टेस्टिंग, और प्रोडक्शन के लिए अलग-अलग एपीआई कुंजियों का इस्तेमाल करें. हर एनवायरमेंट को अलग रखने के लिए, एनवायरमेंट के हिसाब से पासकोड का इस्तेमाल करें. इससे, प्रोडक्शन डेटा को एक्सपोज़ होने का जोखिम कम हो जाता है. साथ ही, प्रोडक्शन एनवायरमेंट पर असर डाले बिना, हैक किए गए पासकोड को बंद किया जा सकता है.

इस्तेमाल और ऐक्सेस कंट्रोल

एपीआई और उपयोगकर्ताओं को सुरक्षित रखने के लिए, एपीआई पासकोड को सुरक्षित रखने के तरीके अपनाना ज़रूरी है. सबसे बेहतर सुरक्षा के लिए, अपनी कुंजियों को तैयार करने का तरीका यहां बताया गया है:

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

ध्यान दें: आपकी सेवा में, किसी खास पैकेज या प्लैटफ़ॉर्म के लिए पासकोड की पाबंदी लगाने की सुविधाएं होनी चाहिए. उदाहरण के लिए, Google Maps API, पैकेज के नाम और साइनिंग पासकोड के हिसाब से पासकोड के ऐक्सेस को सीमित करता है.

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

पासकोड का रोटेशन और उसकी समयसीमा खत्म होना

एपीआई की ऐसी कमजोरियों की वजह से, बिना अनुमति के ऐक्सेस किए जाने का जोखिम कम करने के लिए, एपीआई कुंजियों को नियमित तौर पर बदलना ज़रूरी है. ISO 27001 स्टैंडर्ड, नियमों का पालन करने के लिए एक फ़्रेमवर्क तय करता है. इससे यह तय होता है कि पासकोड कितनी बार बदला जाए. ज़्यादातर मामलों में, पासकोड बदलने की अवधि 90 दिन से लेकर छह महीने के बीच होनी चाहिए. बेहतर पासकोड मैनेजमेंट सिस्टम लागू करने से, इन प्रोसेस को आसानी से मैनेज किया जा सकता है. इससे पासकोड को बदलने और उसकी समयसीमा खत्म होने की सुविधा को बेहतर बनाया जा सकता है.

सबसे सही तरीके

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

क्रिप्टोग्राफी

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

जानें कि आपका सॉफ़्टवेयर, Java Cryptography Architecture (JCA) के तहत सुरक्षा सेवा देने वाली किन कंपनियों का इस्तेमाल करता है. पहले से मौजूद फ़्रेमवर्क के सबसे बेहतर लेवल का इस्तेमाल करने की कोशिश करें, ताकि आपके इस्तेमाल के उदाहरण के लिए यह फ़्रेमवर्क काम कर सके. अगर लागू हो, तो Google की बताई गई सेवा देने वाली कंपनियों का इस्तेमाल, Google के बताए गए क्रम में करें.

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

अगर आपको अपना प्रोटोकॉल लागू करना है, तो अपने क्रिप्टोग्राफ़िक एल्गोरिदम लागू न करें. मौजूदा क्रिप्टोग्राफ़िक एल्गोरिदम का इस्तेमाल करें. जैसे, Cipher क्लास में दिए गए AES और आरएसए के लागू होने की सुविधा. इसके अलावा, इन सबसे सही तरीकों का पालन करें:

  • व्यावसायिक मकसद के लिए, 256-बिट एईएस का इस्तेमाल करें. (अगर उपलब्ध नहीं है, तो 128-बिट AES का इस्तेमाल करें.)
  • एलिप्टिक कर्व (ईसी) क्रिप्टोग्राफ़ी के लिए, 224 या 256-बिट की सार्वजनिक पासकोड साइज़ का इस्तेमाल करें.
  • जानें कि सीबीसी, सीटीआर या जीसीएम ब्लॉक मोड का इस्तेमाल कब करना है.
  • सीटीआर मोड में, आईवी/काउंटर का फिर से इस्तेमाल करने से बचें. पक्का करें कि वे क्रिप्टोग्राफ़िक तरीके से यादृच्छिक हों.
  • एन्क्रिप्शन का इस्तेमाल करते समय, CBC या सीटीआर मोड का इस्तेमाल करके, इनमें से किसी एक फ़ंक्शन के साथ इंटिग्रिटी लागू करें:
    • HMAC-SHA1
    • HMAC-SHA-256
    • HMAC-SHA-512
    • GCM मोड

KeyGenerator से जनरेट की गई किसी भी क्रिप्टोग्राफ़िक कुंजी को शुरू करने के लिए, सुरक्षित रैंडम नंबर जनरेटर, SecureRandom का इस्तेमाल करें. किसी ऐसी कुंजी का इस्तेमाल करने पर जिसे सुरक्षित रैंडम नंबर जनरेटर की मदद से जनरेट नहीं किया गया है, एल्गोरिदम की सुरक्षा बहुत कम हो जाती है. साथ ही, ऑफ़लाइन हमले भी हो सकते हैं.

अगर आपको किसी कुंजी को बार-बार इस्तेमाल करने के लिए सेव करना है, तो KeyStore जैसे किसी ऐसे तरीके का इस्तेमाल करें जो क्रिप्टोग्राफ़िक कुंजियों को लंबे समय तक सेव और वापस पाने की सुविधा देता हो.

इंटरप्रोसेस कम्यूनिकेशन

कुछ ऐप्लिकेशन, नेटवर्क सॉकेट और शेयर की गई फ़ाइलों जैसी पारंपरिक Linux तकनीकों का इस्तेमाल करके, आईपीसी लागू करने की कोशिश करते हैं. हालांकि, हमारा सुझाव है कि आप IPC के लिए, Android सिस्टम की सुविधाओं का इस्तेमाल करें. जैसे, Intent, Binder या Messenger के साथ Service और BroadcastReceiver. Android IPC प्रोटोकॉल की मदद से, अपने IPC से कनेक्ट होने वाले ऐप्लिकेशन की पहचान की पुष्टि की जा सकती है. साथ ही, हर IPC प्रोटोकॉल के लिए सुरक्षा नीति सेट की जा सकती है.

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

अगर आपके आईपीसी को दूसरे ऐप्लिकेशन ऐक्सेस कर सकते हैं, तो <permission> एलिमेंट का इस्तेमाल करके, सुरक्षा नीति लागू की जा सकती है. अगर आईपीसी आपके ऐप्लिकेशन के बीच है और एक ही पासकोड से साइन किया गया है, तो android:protectionLevel में signature-level अनुमति का इस्तेमाल करें.

मूड

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

चेतावनी: अगर **Service** से बाइंड करने के लिए किसी इंटेंट का इस्तेमाल किया जाता है, तो अपने ऐप्लिकेशन को सुरक्षित रखने के लिए, साफ़ तौर पर बताने वाले इंटेंट का इस्तेमाल करें. किसी सेवा को शुरू करने के लिए, इंप्लिसिट इंटेंट का इस्तेमाल करना सुरक्षा के लिहाज़ से खतरनाक है. ऐसा इसलिए, क्योंकि यह पक्का नहीं किया जा सकता कि इंटेंट का जवाब कौनसी सेवा देगी और उपयोगकर्ता यह नहीं देख सकता कि कौनसी सेवा शुरू हुई है. Android 5.0 (एपीआई लेवल 21) से, अगर किसी इंप्लिसिट इंटेंट के साथ **bindService()** को कॉल किया जाता है, तो सिस्टम एक अपवाद दिखाता है.

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

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

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

सेवाएं

Service का इस्तेमाल अक्सर, दूसरे ऐप्लिकेशन के लिए फ़ंक्शन उपलब्ध कराने के लिए किया जाता है. हर सेवा क्लास की मेनिफ़ेस्ट फ़ाइल में, उससे जुड़ा <service> डिक्लेरेशन होना चाहिए.

डिफ़ॉल्ट रूप से, सेवाएं एक्सपोर्ट नहीं होतीं और किसी दूसरे ऐप्लिकेशन से इन्हें शुरू नहीं किया जा सकता. हालांकि, अगर सेवा के एलान में कोई इंटेंट फ़िल्टर जोड़ा जाता है, तो वह डिफ़ॉल्ट रूप से एक्सपोर्ट हो जाता है. android:exported एट्रिब्यूट के बारे में साफ़ तौर पर एलान करना सबसे अच्छा होता है, ताकि यह पक्का किया जा सके कि यह आपके हिसाब से काम कर रहा है. android:permission एट्रिब्यूट का इस्तेमाल करके भी सेवाओं को सुरक्षित किया जा सकता है. ऐसा करने पर, अन्य ऐप्लिकेशन को सेवा को शुरू करने, रोकने या उससे कनेक्ट करने के लिए, अपने मेनिफ़ेस्ट में उससे मिलते-जुलते <uses-permission> एलिमेंट के बारे में बताना होगा.

ध्यान दें: अगर आपका ऐप्लिकेशन Android 5.0 (एपीआई लेवल 21) या उसके बाद के वर्शन को टारगेट करता है, तो बैकग्राउंड सेवाओं को लागू करने के लिए, **JobScheduler** का इस्तेमाल करें.

कोई सेवा, अनुमतियों के साथ उसमें किए गए अलग-अलग आईपीसी कॉल की सुरक्षा कर सकती है. ऐसा करने के लिए, कॉल लागू करने से पहले checkCallingPermission() को कॉल करें. हमारा सुझाव है कि आप मेनिफ़ेस्ट में, एलान वाली अनुमतियों का इस्तेमाल करें. ऐसा इसलिए, क्योंकि इनमें गलती होने की संभावना कम होती है.

चेतावनी: क्लाइंट और सर्वर की अनुमतियों को एक-दूसरे से न जोड़ें. पक्का करें कि कॉल किए गए ऐप्लिकेशन के पास ज़रूरी अनुमतियां हों. साथ ही, यह भी पुष्टि करें कि आपने कॉल करने वाले ऐप्लिकेशन को भी वही अनुमतियां दी हों.

Binder और Messenger के इंटरफ़ेस

Android पर आरपीसी स्टाइल आईपीसी के लिए, Binder या Messenger का इस्तेमाल करना सबसे सही तरीका है. ये अच्छी तरह से तय किए गए इंटरफ़ेस उपलब्ध कराते हैं, जिनकी मदद से ज़रूरत पड़ने पर, एंडपॉइंट की आपस में पुष्टि की जा सकती है.

हमारा सुझाव है कि आप अपने ऐप्लिकेशन के इंटरफ़ेस को इस तरह से डिज़ाइन करें कि इंटरफ़ेस के हिसाब से अनुमति की जांच की ज़रूरत न पड़े. Binder और Messenger ऑब्जेक्ट, ऐप्लिकेशन मेनिफ़ेस्ट में एलान नहीं किए गए हैं. इसलिए, इन पर सीधे तौर पर एलान वाली अनुमतियां लागू नहीं की जा सकतीं. आम तौर पर, ये उन Service या Activity के लिए, ऐप्लिकेशन मेनिफ़ेस्ट में बताई गई अनुमतियों को इनहेरिट करते हैं जिनमें इन्हें लागू किया जाता है. अगर आपको ऐसा इंटरफ़ेस बनाना है जिसके लिए पुष्टि और/या ऐक्सेस कंट्रोल की ज़रूरत है, तो आपको उन कंट्रोल को Binder या Messenger इंटरफ़ेस में कोड के तौर पर साफ़ तौर पर जोड़ना होगा.

अगर आपको ऐसा इंटरफ़ेस उपलब्ध कराना है जिसके लिए ऐक्सेस कंट्रोल की ज़रूरत है, तो checkCallingPermission() का इस्तेमाल करके पुष्टि करें कि कॉल करने वाले के पास ज़रूरी अनुमति है या नहीं. कॉलर की ओर से किसी सेवा को ऐक्सेस करने से पहले, यह करना ज़रूरी है. ऐसा इसलिए, क्योंकि आपके ऐप्लिकेशन की पहचान दूसरे इंटरफ़ेस को भेजी जाती है. अगर किसी Service से दिए गए इंटरफ़ेस को शुरू किया जा रहा है, तो हो सकता है कि bindService() को शुरू करने में समस्या आ जाए. ऐसा तब होता है, जब आपके पास उस सेवा को ऐक्सेस करने की अनुमति न हो. अगर आपको किसी बाहरी प्रोसेस को अपने ऐप्लिकेशन के साथ इंटरैक्ट करने की अनुमति देनी है, लेकिन उसके पास ऐसा करने के लिए ज़रूरी अनुमतियां नहीं हैं, तो clearCallingIdentity() तरीके का इस्तेमाल करें. इस तरीके से, आपके ऐप्लिकेशन के इंटरफ़ेस पर कॉल किया जाता है. ऐसा लगता है कि बाहरी व्यक्ति के बजाय, आपका ऐप्लिकेशन ही कॉल कर रहा है. कॉलर की अनुमतियों को बाद में, restoreCallingIdentity() तरीके से वापस लाया जा सकता है.

किसी सेवा के साथ आईपीसी करने के बारे में ज़्यादा जानकारी के लिए, बाउंड सेवाएं देखें.

ब्रॉडकास्ट रिसीवर

BroadcastReceiver, Intent से शुरू किए गए एसिंक्रोनस अनुरोधों को मैनेज करता है.

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

डाइनैमिक तौर पर लोड किए गए कोड की मदद से सुरक्षा

हमारा सुझाव है कि आप अपने ऐप्लिकेशन के APK से बाहर से कोड लोड न करें. ऐसा करने पर, कोड इंजेक्शन या कोड में छेड़छाड़ की वजह से, ऐप्लिकेशन के हैक होने की संभावना काफ़ी बढ़ जाती है. इससे वर्शन मैनेजमेंट और ऐप्लिकेशन टेस्टिंग में भी मुश्किलें आती हैं. साथ ही, इससे किसी ऐप्लिकेशन के व्यवहार की पुष्टि करना मुश्किल हो सकता है. इसलिए, कुछ एनवायरमेंट में इसकी अनुमति नहीं दी जा सकती.

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

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

वर्चुअल मशीन में सुरक्षा

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

अगर आपको वर्चुअल मशीन की सुरक्षा के बारे में ज़्यादा जानना है, तो इस विषय पर मौजूद कुछ मौजूदा लेख पढ़ें. सबसे ज़्यादा लोकप्रिय दो संसाधन ये हैं:

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

  • कुछ वर्चुअल मशीनें, जैसे कि JVM या .NET रनटाइम, सुरक्षा के लिए बाउंड्री के तौर पर काम करती हैं. ये कोड को ऑपरेटिंग सिस्टम की सुविधाओं से अलग करती हैं. Android पर, Dalvik VM सुरक्षा की सीमा नहीं है. ऐप्लिकेशन सैंडबॉक्स, OS लेवल पर लागू किया जाता है. इसलिए, Dalvik किसी भी सुरक्षा पाबंदी के बिना, उसी ऐप्लिकेशन में नेटिव कोड के साथ इंटरऑपरेट कर सकता है.
  • मोबाइल डिवाइसों पर स्टोरेज की कमी को देखते हुए, डेवलपर आम तौर पर, मॉड्यूलर ऐप्लिकेशन बनाने और डाइनैमिक क्लास लोडिंग का इस्तेमाल करना चाहते हैं. ऐसा करते समय, उस सोर्स और लोकल स्टोरेज, दोनों का ध्यान रखें जहां आपने ऐप्लिकेशन लॉजिक को रिट्रीव किया है. ऐसे सोर्स से डाइनैमिक क्लास लोडिंग का इस्तेमाल न करें जिनकी पुष्टि नहीं की गई है. जैसे, असुरक्षित नेटवर्क सोर्स या बाहरी स्टोरेज, क्योंकि उस कोड में नुकसान पहुंचाने वाले व्यवहार को शामिल करने के लिए बदलाव किया जा सकता है.

नेटिव कोड में सुरक्षा

आम तौर पर, हमारा सुझाव है कि ऐप्लिकेशन डेवलप करने के लिए, Android NDK के साथ नेटिव कोड का इस्तेमाल करने के बजाय, Android SDK टूल का इस्तेमाल करें. नेटिव कोड से बनाए गए ऐप्लिकेशन ज़्यादा जटिल होते हैं और इन्हें एक डिवाइस से दूसरे डिवाइस पर ले जाने में ज़्यादा समस्या होती है. साथ ही, इनमें मेमोरी में गड़बड़ी से जुड़ी सामान्य गड़बड़ियां होने की संभावना ज़्यादा होती है. जैसे, बफ़र ओवरफ़्लो.

Android को Linux kernel का इस्तेमाल करके बनाया गया है. नेटिव कोड का इस्तेमाल करने पर, Linux डेवलपमेंट के लिए सुरक्षा के सबसे सही तरीकों के बारे में जानना ज़रूरी है. इस दस्तावेज़ में, Linux की सुरक्षा से जुड़े तरीकों के बारे में नहीं बताया गया है. हालांकि, सुरक्षित प्रोग्रामिंग का तरीका - सुरक्षित सॉफ़्टवेयर बनाना सबसे लोकप्रिय संसाधनों में से एक है.

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