इस पेज का अनुवाद Cloud Translation API से किया गया है.

कस्टम अनुमतियां

OWASP कैटगरी: MASVS-CODE: कोड क्वालिटी

खास जानकारी

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

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

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

दो या उससे ज़्यादा ऐप्लिकेशन के बीच इंटर-प्रोसेस कम्यूनिकेशन (आईपीसी) को कंट्रोल करना
तीसरे पक्ष की सेवाएं ऐक्सेस करना
किसी ऐप्लिकेशन के शेयर किए गए डेटा के ऐक्सेस पर पाबंदी लगाना

असर

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

जोखिम: कस्टम अनुमति में टाइप करने से जुड़ी गड़बड़ियां

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

पहले उस अनुमति को रजिस्टर करना
आगे के ऐप्लिकेशन में स्पेलिंग का अनुमान लगाना

इससे किसी ऐप्लिकेशन को संसाधनों का बिना अनुमति वाला ऐक्सेस मिल सकता है या वह टारगेट किए गए ऐप्लिकेशन को कंट्रोल कर सकता है.

उदाहरण के लिए, कोई असुरक्षित ऐप्लिकेशन, अनुमति READ_CONTACTS का इस्तेमाल करके किसी कॉम्पोनेंट को सुरक्षित करना चाहता है. हालांकि, गलती से अनुमति को READ_CONACTS लिख देता है. नुकसान पहुंचाने वाला ऐप्लिकेशन, READ_CONACTS पर दावा कर सकता है, क्योंकि इसका मालिकाना हक किसी ऐप्लिकेशन (या सिस्टम) के पास नहीं है. साथ ही, वह सुरक्षित कॉम्पोनेंट को ऐक्सेस कर सकता है. इस जोखिम का एक और आम वैरिएंट android:permission=True है. true और false जैसी वैल्यू, अनुमति के एलान के लिए अमान्य इनपुट हैं. भले ही, इनमें कैपिटल लेटर का इस्तेमाल किया गया हो या नहीं. इन वैल्यू को, अनुमति के एलान के लिए टाइप किए गए अन्य कस्टम वैल्यू की तरह ही माना जाता है. इसे ठीक करने के लिए, android:permission एट्रिब्यूट की वैल्यू को अनुमति की मान्य स्ट्रिंग में बदलना चाहिए. उदाहरण के लिए, अगर ऐप्लिकेशन को उपयोगकर्ता के संपर्कों को ऐक्सेस करना है, तो android:permission एट्रिब्यूट की वैल्यू android.permission.READ_CONTACTS होनी चाहिए.

जोखिम कम करने के तरीके

Android Lint की जांच

कस्टम अनुमतियां बताते समय, Android lint की जांच का इस्तेमाल करें. इससे आपको अपने कोड में टाइपो और अन्य संभावित गड़बड़ियां ढूंढने में मदद मिलेगी.

नेमिंग कन्वेंशन

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

जोखिम: अनाथ अनुमतियां

अनुमतियों का इस्तेमाल, ऐप्लिकेशन के संसाधनों को सुरक्षित रखने के लिए किया जाता है. संसाधनों को ऐक्सेस करने के लिए, ऐप्लिकेशन दो अलग-अलग जगहों पर अनुमतियों का एलान कर सकता है:

AndroidManifest.xml: AndroidManifest.xml फ़ाइल में पहले से तय की गई (अगर तय नहीं की गई है, तो <application> अनुमतियों का इस्तेमाल किया जाता है), जैसे कि प्रोवाइडर की अनुमति, रिसीवर की अनुमति, गतिविधि की अनुमति, सेवा की अनुमति;
कोड: रनटाइम कोड में रजिस्टर किया गया, जैसे कि registerReceiver().

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

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

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

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

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

जोखिम कम करने के तरीके

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

ऐप्लिकेशन, कॉन्टेंट उपलब्ध कराने वाले के ऐक्सेस को सुरक्षित रखने के लिए, कस्टम अनुमतियों my.app.provider.READ और my.app.provider.WRITE का इस्तेमाल करता है:

एक्सएमएल

<provider android:name="my.app.database.CommonContentProvider" android:readPermission="my.app.provider.READ" android:writePermission="my.app.provider.WRITE" android:exported="true" android:process=":myappservice" android:authorities="my.app.database.contentprovider"/>

ऐप्लिकेशन, पसंद के मुताबिक बनाई गई इन अनुमतियों को तय और इस्तेमाल भी करता है. इससे, नुकसान पहुंचाने वाले दूसरे ऐप्लिकेशन ऐसा नहीं कर पाते:

एक्सएमएल

<permission android:name="my.app.provider.READ"/>
<permission android:name="my.app.provider.WRITE"/>
<uses-permission android:name="my.app.provider.READ" />
<uses-permission android:name="my.app.provider.WRITE" />

जोखिम: android:protectionLevel का गलत इस्तेमाल

यह एट्रिब्यूट, अनुमति में संभावित जोखिम के लेवल के बारे में बताता है. साथ ही, यह भी बताता है कि अनुमति देने या न देने का फ़ैसला करते समय, सिस्टम को किन प्रक्रियाओं का पालन करना चाहिए.

जोखिम कम करने के तरीके

सुरक्षा के सामान्य या खतरनाक लेवल से बचना

अनुमतियों के लिए सामान्य या खतरनाक protectionLevel का इस्तेमाल करने का मतलब है कि ज़्यादातर ऐप्लिकेशन, अनुमति का अनुरोध कर सकते हैं और उसे पा सकते हैं:

"सामान्य" के लिए, सिर्फ़ एलान करना ज़रूरी है
"खतरनाक" को कई उपयोगकर्ताओं की ओर से मंज़ूरी दी जाएगी

इसलिए, ये protectionLevels ज़्यादा सुरक्षित नहीं होते.

हस्ताक्षर की अनुमतियों का इस्तेमाल करना (Android 10 और उसके बाद के वर्शन)

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

अपने मेनिफ़ेस्ट में कस्टम अनुमति तय करने के लिए, यह तरीका अपनाएं:

एक्सएमएल

<permission
    android:name="my.custom.permission.MY_PERMISSION"
    android:protectionLevel="signature"/>

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

एक्सएमएल

<activity android:name=".MyActivity" android:permission="my.custom.permission.MY_PERMISSION"/>

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

एक्सएमएल

<uses-permission android:name="my.custom.permission.MY_PERMISSION" />

Android 10 से पहले के वर्शन के लिए, हस्ताक्षर की ज़रूरत वाली कस्टम अनुमतियों से सावधान रहें

अगर आपका ऐप्लिकेशन Android 10 से पहले के वर्शन पर काम करता है, तो जब भी ऐप्लिकेशन को अनइंस्टॉल करने या अपडेट करने की वजह से, ऐप्लिकेशन की कस्टम अनुमतियां हटाई जाती हैं, तो नुकसान पहुंचाने वाले ऐप्लिकेशन अब भी उन कस्टम अनुमतियों का इस्तेमाल कर सकते हैं. इस तरह, वे जांच को बायपास कर सकते हैं. ऐसा, ऐप्लिकेशन के लिए ज़्यादा अनुमतियां हासिल करने की सुविधा (CVE-2019-2200) से जुड़ी एक समस्या की वजह से होता है. इसे Android 10 में ठीक कर दिया गया है.

रेस कंडीशन के जोखिम के साथ-साथ, यह एक और वजह है कि कस्टम अनुमतियों के बजाय, हस्ताक्षर की जांच का सुझाव दिया जाता है.

जोखिम: रेस कंडीशन

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

अगर B, A से पहले इंस्टॉल हो जाता है, तो भी ऐसा ही होता है.

जोखिम कम करने के तरीके

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