सुविधाओं की जांच करना और उन्हें डीबग करना

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

खास जानकारी

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

टेस्टिंग/ डीबग करने की सुविधाओं के उदाहरण:

  • छिपे हुए मेन्यू
  • डीबग लॉग जनरेट करने की सुविधा चालू करने के विकल्प
  • ऐप्लिकेशन के फ़्लो में बदलाव करने के विकल्प
  • पेमेंट या सदस्यता की प्रोसेस को दरकिनार करने के विकल्प
  • पुष्टि करने की प्रोसेस को बायपास करने के विकल्प
  • ऐप्लिकेशन से जुड़ी गतिविधियों के लिए टेस्ट

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

टेस्टिंग या डीबग करने की सुविधाओं को चालू रखने से होने वाला जोखिम अलग-अलग हो सकता है. यह जोखिम, डीबग करने की सुविधाओं से जुड़ी कार्रवाई के हिसाब से तय होता है.

ऐप्लिकेशन के लिए जोखिम का एक और क्षेत्र, AndroidManifest.xml एलिमेंट <application> में सेट किया गया android:debuggable एट्रिब्यूट है. android:debuggable लेख में बताया गया है कि प्रोडक्शन ऐप्लिकेशन को ऊपर दी गई वैल्यू के साथ डिप्लॉय करने से, गलत इरादे वाले लोगों को ऐसे एडमिन रिसॉर्स ऐक्सेस करने की अनुमति मिल जाती है जिन्हें आम तौर पर ऐक्सेस नहीं किया जा सकता.

असर

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

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

डीबग कॉम्पोनेंट का इस्तेमाल न करना

टेस्ट या डीबग करने की सुविधाओं को कभी भी प्रोडक्शन ऐप्लिकेशन कॉम्पोनेंट में लागू नहीं किया जाना चाहिए. जैसे, ऐक्टिविटी, ब्रॉडकास्ट रिसीवर, सेवाएं या कॉन्टेंट प्रोवाइडर. ऐसा इसलिए, क्योंकि एक्सपोर्ट किए जाने पर, इन्हें डिवाइस पर किसी अन्य प्रोसेस से चलाया जा सकता है. डीबग कॉम्पोनेंट को एक्सपोर्ट नहीं किए गए कॉम्पोनेंट के तौर पर सेट करने से (android:exported="false"), क्षमताओं के लिए मान्य सुरक्षा नहीं मिलती. ऐसा इसलिए, क्योंकि रूट किए गए किसी भी डिवाइस पर, Android Debug Bridge (ADB) टूल के ज़रिए इसे अब भी एक्ज़ीक्यूट किया जा सकता है. हालांकि, ऐसा तब ही किया जा सकता है, जब डीबग करने का विकल्प चालू हो.

डीबग या टेस्ट करने की सुविधाओं को सिर्फ़ स्टेजिंग बिल्ड के लिए सीमित करें

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

अपने-आप होने वाले यूज़र इंटरफ़ेस टेस्ट लागू करना

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

संसाधन