Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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 के साथ तय कर सकता है. जैसे, सामान्य. इस तरह, B को उन सभी कॉम्पोनेंट का ऐक्सेस मिल जाता है जिन्हें X ऐप्लिकेशन में उस कस्टम अनुमति से सुरक्षित रखा गया है. इसके लिए, उसे ऐप्लिकेशन A के सर्टिफ़िकेट से साइन करने की ज़रूरत नहीं होती.

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

गड़बड़ी को ठीक करने के तरीके

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