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

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

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

  • Android ऐप्लिकेशन सैंडबॉक्स, जो आपके ऐप्लिकेशन के डेटा और कोड को अन्य ऐप्लिकेशन से अलग रखता है.
  • यह एक ऐप्लिकेशन फ़्रेमवर्क है. इसमें सुरक्षा से जुड़ी सामान्य सुविधाओं को बेहतर तरीके से लागू किया गया है. जैसे, क्रिप्टोग्राफ़ी, अनुमतियां, और सुरक्षित इंटरप्रोसेस कम्यूनिकेशन (आईपीसी).
  • मेमोरी मैनेजमेंट से जुड़ी सामान्य गड़बड़ियों से जुड़े जोखिमों को कम करने के लिए, ऐड्रेस स्पेस लेआउट रैंडमाइज़ेशन (एएसएलआर), नो-एक्ज़ीक्यूट (एनएक्स), 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 फ़्लैग का इस्तेमाल करके, ज़्यादा बेहतर तरीके से ऐक्सेस दे सकती हैं. Intent ऑब्जेक्ट, कॉम्पोनेंट को चालू करता है. <grant-uri-permission> एलिमेंट का इस्तेमाल करके, इन अनुमतियों के दायरे को और सीमित किया जा सकता है.

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

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

अनुमतियां

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

अनुमति से जुड़े अनुरोध

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

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

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

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

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

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

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

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

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

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

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

नेटवर्किंग

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डिवाइस पर मौजूद लॉग में लिखते समय सावधानी बरतें. 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 ऐप्लिकेशन में क्रेडेंशियल के अनुरोधों को ज़्यादा सुरक्षित बनाया जा सकता है.

क्रेडेंशियल के गलत इस्तेमाल को कम करना

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

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

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

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

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

सतर्क रहें

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

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

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

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

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

जनरेट करना और सेव करना

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

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

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

सोर्स कंट्रोल को हटाने के नियम

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

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

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

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

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

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

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

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

डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनना और उसकी समयसीमा खत्म होना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

उद्देश्य

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

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

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

सेवाएं

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

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

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

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

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

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

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

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

Android को Linux कर्नल का इस्तेमाल करके बनाया गया है. Linux डेवलपमेंट के लिए सुरक्षा के सबसे सही तरीकों के बारे में जानना, खास तौर पर तब फ़ायदेमंद होता है, जब नेटिव कोड का इस्तेमाल किया जा रहा हो. इस दस्तावेज़ में, Linux की सुरक्षा से जुड़ी प्रक्रियाओं के बारे में जानकारी नहीं दी गई है. हालांकि, इस बारे में जानने के लिए सबसे लोकप्रिय संसाधनों में से एक, Secure Programming HOWTO - Creating Secure Software है.

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