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

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 लिंट जांच का इस्तेमाल करें. इससे आपको अपने कोड में टाइपिंग और दूसरी संभावित गड़बड़ियां ढूंढने में मदद मिलेगी.

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

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

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

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

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

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

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

संसाधन