hacktricks/mobile-pentesting/android-app-pentesting/android-applications-basics.md

Android एप्लिकेशन की मूल बातें

AWS हैकिंग सीखें शून्य से लेकर हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

• यदि आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे या HackTricks को PDF में डाउनलोड करें तो सब्सक्रिप्शन प्लान्स देखें!
• आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
• The PEASS Family की खोज करें, हमारा एक्सक्लूसिव NFTs का संग्रह
• 💬 Discord group में शामिल हों या telegram group में या Twitter पर 🐦 @carlospolopm को फॉलो करें.
• अपनी हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github repos में PRs सबमिट करके.

सबसे महत्वपूर्ण कमजोरियों को खोजें ताकि आप उन्हें तेजी से ठीक कर सकें। Intruder आपकी अटैक सरफेस को ट्रैक करता है, प्रोएक्टिव थ्रेट स्कैन चलाता है, आपके पूरे टेक स्टैक में मुद्दों को ढूंढता है, APIs से लेकर वेब एप्स और क्लाउड सिस्टम्स तक। आज ही मुफ्त में आजमाएं।

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

---

Android सुरक्षा मॉडल

दो परतें हैं:

• OS, जो स्थापित एप्लिकेशनों को एक-दूसरे से अलग रखता है।
• एप्लिकेशन स्वयं, जो डेवलपर्स को कुछ कार्यक्षमताओं को उजागर करने की अनुमति देता है और एप्लिकेशन क्षमताओं को कॉन्फ़िगर करता है।

UID विभाजन

प्रत्येक एप्लिकेशन को एक विशिष्ट यूजर ID दी जाती है। यह एप्लिकेशन की स्थापना के दौरान किया जाता है ताकि एप्लिकेशन केवल अपनी यूजर ID या साझा फाइलों के स्वामित्व वाली फाइलों के साथ इंटरैक्ट कर सके। इसलिए, केवल एप्लिकेशन स्वयं, OS के कुछ घटक और रूट यूजर ही एप्लिकेशन के डेटा तक पहुंच सकते हैं।

UID साझाकरण

दो एप्लिकेशनों को एक ही UID का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है। यह जानकारी साझा करने के लिए उपयोगी हो सकता है, लेकिन यदि उनमें से एक समझौता किया जाता है तो दोनों एप्लिकेशनों का डेटा समझौता किया जाएगा। इसीलिए इस व्यवहार को हतोत्साहित किया जाता है।
एक ही UID साझा करने के लिए, एप्लिकेशनों को उनके मैनिफेस्ट में android:sharedUserId मान को परिभाषित करना होगा।

सैंडबॉक्सिंग

Android एप्लिकेशन सैंडबॉक्स अनुमति देता है कि प्रत्येक एप्लिकेशन एक अलग प्रक्रिया के रूप में एक अलग यूजर ID के तहत चलाया जाए। प्रत्येक प्रक्रिया का अपना वर्चुअल मशीन होता है, इसलिए एक एप्लिकेशन का कोड अन्य एप्लिकेशनों से अलग चलता है।
Android 5.0(L) से SELinux लागू किया जाता है। मूल रूप से, SELinux सभी प्रक्रिया इंटरैक्शन को अस्वीकार कर देता है और फिर उनके बीच केवल अपेक्षित इंटरैक्शन की अनुमति देने के लिए नीतियां बनाई जाती हैं।

अनुमतियां

जब आप एक एप्लिकेशन इंस्टॉल करते हैं और वह अनुमतियों के लिए पूछता है, एप्लिकेशन uses-permission तत्वों में कॉन्फ़िगर की गई अनुमतियों के लिए पूछ रहा है जो AndroidManifest.xml फाइल में हैं। uses-permission तत्व नाम विशेषता के अंदर अनुरोधित अनुमति का नाम इंगित करता है। इसमें maxSdkVersion विशेषता भी होती है जो निर्दिष्ट संस्करण से अधिक संस्करणों पर अनुमतियों के लिए पूछना बंद कर देती है।
नोट करें कि Android एप्लिकेशनों को शुरुआत में सभी अनुमतियों के लिए नहीं पूछना पड़ता है, वे गतिशील रूप से अनुमतियों के लिए भी पूछ सकते हैं लेकिन सभी अनुमतियों को मैनिफेस्ट में घोषित किया जाना चाहिए।

जब एक एप्लिकेशन कार्यक्षमता को उजागर करता है, तो वह केवल उन एप्लिकेशनों को पहुंच सीमित कर सकता है जिनके पास एक निर्दिष्ट अनुमति है।
एक अनुमति तत्व में तीन विशेषताएं होती हैं:

• अनुमति का नाम
• permission-group विशेषता, जो संबंधित अनुमतियों के समूहन की अनुमति देता है।
• protection-level जो इंगित करता है कि अनुमतियां कैसे दी जाती हैं। चार प्रकार होते हैं:
  • Normal: जब एप्लिकेशन के लिए कोई ज्ञात खतरे नहीं होते हैं। उपयोगकर्ता को इसे स्वीकृति देने की आवश्यकता नहीं होती है।
  • Dangerous: इंगित करता है कि अनुमति अनुरोध करने वाले एप्लिकेशन को कुछ उन्नत पहुंच प्रदान करती है। उपयोगकर्ताओं से उन्हें स्वीकृति देने का अनुरोध किया जाता है।
  • Signature: केवल वही एप्लिकेशन जो उसी प्रमाणपत्र द्वारा हस्ताक्षरित हैं जैसे कि घटक को निर्यात करने वाले एक को अनुमति दी जा सकती है। यह सबसे मजबूत प्रकार की सुरक्षा है।
  • SignatureOrSystem: केवल **वही एप्लिकेशन जो उसी प्रमाणपत्र द्वारा हस्ताक्षरित हैं जैसे कि घटक को निर्यात करने वाले एक या सिस्टम-स्तरीय पहुंच के साथ चल रहे एप्लिकेशन को अनुमति दी जा सकती है

प्री-इंस्टॉल्ड एप्लिकेशन

ये एप्लिकेशन आमतौर पर /system/app या /system/priv-app निर्देशिकाओं में पाए जाते हैं और कुछ अनुकूलित होते हैं (आपको classes.dex फाइल तक नहीं मिल सकती है)। इन एप्लिकेशनों की जांच करना महत्वपूर्ण है क्योंकि कभी-कभी वे बहुत अधिक अनुमतियों के साथ चल रहे होते हैं (रूट के रूप में)।

• AOSP (Android OpenSource Project) ROM के साथ शिप किए गए
• डिवाइस निर्माता द्वारा जोड़े गए
• सेल फोन प्रदाता द्वारा जोड़े गए (यदि उन

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

पहले घोषित Intent का Action ACTION_SEND है और Extra एक mailto Uri है (Extra वह अतिरिक्त जानकारी है जिसकी intent को अपेक्षा होती है)।

इस intent को manifest में निम्नलिखित उदाहरण के अनुसार घोषित किया जाना चाहिए:

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

एक intent-filter को संदेश प्राप्त करने के लिए action, data और category से मेल खाना चाहिए।

"Intent resolution" प्रक्रिया यह निर्धारित करती है कि प्रत्येक संदेश को कौन सा ऐप प्राप्त करना चाहिए। यह प्रक्रिया priority attribute पर विचार करती है, जिसे intent-filter declaration में सेट किया जा सकता है, और उच्च प्राथमिकता वाला चुना जाएगा। यह प्राथमिकता -1000 से 1000 के बीच सेट की जा सकती है और एप्लिकेशन SYSTEM_HIGH_PRIORITY मान का उपयोग कर सकते हैं। यदि कोई संघर्ष उत्पन्न होता है, तो एक "choser" विंडो प्रकट होती है ताकि उपयोगकर्ता निर्णय ले सके।

स्पष्ट Intents

एक स्पष्ट intent उस क्लास नाम को निर्दिष्ट करता है जिस पर यह लक्षित है:

Intent downloadIntent = new (this, DownloadService.class):

अन्य एप्लिकेशन्स में पहले से घोषित intent तक पहुँचने के लिए आप इस्तेमाल कर सकते हैं:

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

Pending Intents

ये अन्य एप्लिकेशन्स को आपके एप्लिकेशन की ओर से कार्रवाई करने की अनुमति देते हैं, आपके एप्प की पहचान और अनुमतियों का उपयोग करते हुए। Pending Intent बनाते समय इसे निर्दिष्ट इरादा और कार्रवाई करने के लिए होना चाहिए। यदि घोषित इरादा Explicit नहीं है (यह नहीं बताता कि कौन सा इरादा इसे कॉल कर सकता है) तो एक दुर्भावनापूर्ण एप्लिकेशन घोषित कार्रवाई को पीड़ित एप्प की ओर से कर सकता है। इसके अलावा, यदि कोई कार्रवाई निर्दिष्ट नहीं है, तो दुर्भावनापूर्ण एप्लिकेशन पीड़ित की ओर से कोई भी कार्रवाई करने में सक्षम होगा।

Broadcast Intents

पिछले intents के विपरीत, जो केवल एक एप्लिकेशन द्वारा प्राप्त किए जाते हैं, broadcast intents कई एप्लिकेशन्स द्वारा प्राप्त किए जा सकते हैं। हालांकि, API संस्करण 14 से, यह संभव है कि निर्दिष्ट करें कि कौन सा एप्लिकेशन संदेश प्राप्त करना चाहिए Intent.set Package का उपयोग करके।

वैकल्पिक रूप से यह भी संभव है कि जब ब्रॉडकास्ट भेजते हैं तो एक अनुमति निर्दिष्ट करें। प्राप्तकर्ता एप्लिकेशन के पास उस अनुमति का होना आवश्यक है।

Broadcasts के दो प्रकार होते हैं: सामान्य (असमकालिक) और आदेशित (समकालिक)। क्रम रिसीवर तत्व के भीतर निर्धारित प्राथमिकता पर आधारित होता है। प्रत्येक एप्लिकेशन ब्रॉडकास्ट को प्रोसेस, रिले या ड्रॉप कर सकता है।

यह संभव है कि ब्रॉडकास्ट भेजें फ़ंक्शन **sendBroadcast(intent, receiverPermission) ** का उपयोग करके Context क्लास से।
आप sendBroadcast फ़ंक्शन का भी उपयोग कर सकते हैं जो LocalBroadCastManager से है, यह सुनिश्चित करता है कि संदेश कभी एप्लिकेशन से बाहर नहीं जाता। इसका उपयोग करते समय आपको एक रिसीवर कौम्पोनॅन्ट को निर्यात करने की भी आवश्यकता नहीं होगी।

Sticky Broadcasts

इस प्रकार के Broadcasts उन्हें भेजे जाने के बहुत बाद तक एक्सेस किया जा सकता है।
ये API स्तर 21 में deprecated कर दिए गए थे और इनका उपयोग न करने की सिफारिश की गई है।
ये किसी भी एप्लिकेशन को डेटा को सूंघने की, लेकिन इसे संशोधित करने की भी अनुमति देते हैं।

यदि आपको "sticky" शब्द वाले फ़ंक्शन्स मिलते हैं जैसे कि sendStickyBroadcast या sendStickyBroadcastAsUser, प्रभाव की जांच करें और उन्हें हटाने का प्रयास करें।

Deep links / URL schemes

Deep links का उपयोग करके URL के माध्यम से एक Intent ट्रिगर करने की अनुमति देते हैं। एक एप्लिकेशन एक URL स्कीमा को एक गतिविधि के अंदर घोषित कर सकता है ताकि जब भी एंड्रॉइड डिवाइस कोशिश करता है उस स्कीमा का उपयोग करके एक पते तक पहुंचने की तो एप्लिकेशन की गतिविधि को बुलाया जाएगा:

इस मामले में स्कीम myapp:// है (ध्यान दें category BROWSABLE भी)

यदि आप intent-filter के अंदर ऐसा कुछ पाते हैं:

तो, यह कुछ ऐसा उम्मीद कर रहा है http://www.example.com/gizmos

यदि आपको ऐसा कुछ मिलता है:

इसका मतलब होगा कि यह एक URL की उम्मीद कर रहा है जो example://gizmos से शुरू होता है
इस मामले में आप निम्नलिखित पेलोड्स के साथ एक वेब बनाकर कार्यक्षमता का दुरुपयोग करने की कोशिश कर सकते हैं। यह मनमाने पृष्ठों पर नेविगेट करने की कोशिश करेगा और JS को निष्पादित करने का प्रयास करेगा:

<a href="example://gizmos/https://google.com">click here</a>
<a href="example://gizmos/javascript://%250dalert(1)">click here</a>

ऐप में निष्पादित होने वाले कोड को खोजने के लिए, डीपलिंक द्वारा कॉल की गई गतिविधि पर जाएं और onNewIntent फ़ंक्शन की खोज करें।

HTML पृष्ठों का उपयोग किए बिना डीप लिंक्स को कॉल करना सीखें।

AIDL - Android Interface Definition Language

Android Interface Definition Language (AIDL) आपको ऐसा प्रोग्रामिंग इंटरफ़ेस परिभाषित करने की अनुमति देता है जिस पर क्लाइंट और सेवा दोनों सहमत होते हैं ताकि वे इंटरप्रोसेस कम्युनिकेशन (IPC) का उपयोग करके एक दूसरे के साथ संवाद कर सकें। Android पर, एक प्रक्रिया सामान्यतः दूसरी प्रक्रिया की मेमोरी तक पहुँच नहीं सकती। इसलिए बातचीत करने के लिए, उन्हें अपनी वस्तुओं को प्राइमिटिव्स में विघटित करने की आवश्यकता होती है जिसे ऑपरेटिंग सिस्टम समझ सकता है, और आपके लिए उस सीमा के पार वस्तुओं को मार्शल करता है। उस मार्शलिंग को करने वाला कोड लिखना थकाऊ होता है, इसलिए Android आपके लिए AIDL के साथ इसे संभालता है।

AIDL का उपयोग करने वाली सेवाओं को Bound Services के रूप में संदर्भित किया जाता है। सेवा की क्लास में आपको onBind मेथड मिलेगा। यह बातचीत शुरू होने का स्थान है इसलिए यह संभावित कमजोरियों की खोज करने के लिए कोड की समीक्षा का प्रारंभिक भाग है।

एक bound service एक क्लाइंट-सर्वर इंटरफ़ेस में सर्वर होती है। यह घटकों (जैसे कि गतिविधियों) को सेवा से बांधने, अनुरोध भेजने, प्रतिक्रियाएं प्राप्त करने और इंटरप्रोसेस कम्युनिकेशन (IPC) करने की अनुमति देती है। एक bound service आमतौर पर केवल तब तक जीवित रहती है जब तक यह किसी अन्य एप्लिकेशन घटक की सेवा करती है और अनिश्चितकाल तक पृष्ठभूमि में नहीं चलती है।

Messenger

Messenger एक अन्य प्रकार का IPC तंत्र है। चूंकि Messenger भी "Bound Service" है, क्लाइंट ऐप से पारित डेटा भी onBind मेथड के माध्यम से संसाधित होता है। इसलिए, कोड समीक्षा इस मेथड पर शुरू होनी चाहिए और आपको संवेदनशील कार्यक्षमता के आह्वान या डेटा के असुरक्षित हैंडलिंग की खोज करनी चाहिए।

Binder

Binder क्लास को सीधे आह्वान किया जाना अजीब है क्योंकि AIDL का उपयोग करना बहुत आसान है (जो Binder क्लास को सार करता है)। हालांकि, यह जानना अच्छा है कि Binder एक कर्नेल-स्तर का ड्राइवर है जो एक प्रक्रिया की मेमोरी से दूसरे की मेमोरी में डेटा स्थानांतरित करता है।

Components

इनमें शामिल हैं: Activities, Services, Broadcast Receivers और Providers.

Launcher Activity और अन्य गतिविधियाँ

एक Android activity Android ऐप के यूजर इंटरफ़ेस की एक स्क्रीन होती है। इस तरह एक Android activity डेस्कटॉप एप्लिकेशन में विंडोज़ के समान होती है। एक Android ऐप में एक या अधिक गतिविधियाँ हो सकती हैं, अर्थात एक या अधिक स्क्रीन।

Launcher activity वह होती है जिसे अधिकांश लोग एक Android एप्लिकेशन के प्रवेश बिंदु के रूप में सोचते हैं। Launcher activity वह गतिविधि होती है जो तब शुरू होती है जब उपयोगकर्ता किसी एप्लिकेशन के आइकन पर क्लिक करता है। आप एप्लिकेशन के मैनिफेस्ट को देखकर लॉन्चर गतिविधि का निर्धारण कर सकते हैं। Launcher activity में निम्न MAIN और LAUNCHER इरादे सूचीबद्ध होंगे।

ध्यान रखें कि हर एप्लिकेशन में एक लॉन्चर गतिविधि नहीं होगी, विशेषकर बिना UI वाले ऐप्स। UI के बिना एप्लिकेशन के उदाहरण हैं पूर्व-स्थापित एप्लिकेशन जो पृष्ठभूमि में सेवाएं प्रदान करते हैं, जैसे कि वॉयसमेल।

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

Activities को निर्यात किया जा सकता है जिससे डिवाइस पर अन्य प्रक्रियाएं activity को लॉन्च कर सकती हैं। डिफ़ॉल्ट रूप से, वे निर्यात नहीं किए जाते हैं लेकिन आप उन्हें निम्नलिखित सेटिंग करके निर्यात कर सकते हैं:

<service android:name=".ExampleExportedService" android:exported="true"/>

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

एक गतिविधि का कोड onCreate मेथड से शुरू होता है।

एप्लिकेशन सबक्लास

Android एप्लिकेशन Application का एक सबक्लास परिभाषित कर सकते हैं। एप्लिकेशन को एक कस्टम सबक्लास ऑफ एप्लिकेशन परिभाषित करना आवश्यक नहीं है। यदि एक Android ऐप एक एप्लिकेशन सबक्लास परिभाषित करता है, तो यह क्लास एप्लिकेशन में किसी भी अन्य क्लास से पहले इंस्टेंटिएट किया जाता है।

यदि attachBaseContext मेथड एप्लिकेशन सबक्लास में परिभाषित है, तो यह पहले कॉल किया जाता है, onCreate मेथड से पहले।

सेवाएं

Services बिना UI के पृष्ठभूमि में चलती हैं। वे लंबे समय तक चलने वाली प्रक्रियाओं को प्रदर्शन करने के लिए इस्तेमाल की जाती हैं, भले ही उपयोगकर्ता किसी अन्य एप्लिकेशन का उपयोग करना शुरू कर दे।

उन्हें शुरू करने के लिए अनेक तरीके हो सकते हैं और इसलिए वे एप्लिकेशन के लिए एक प्रवेश बिंदु हैं। एक सेवा को एक एप्लिकेशन के प्रवेश बिंदु के रूप में शुरू करने का डिफ़ॉल्ट तरीका Intents के माध्यम से है।

जब startService मेथड को एक सेवा शुरू करने के लिए कॉल किया जाता है, तो सेवा में onStart मेथड निष्पादित होता है। यह अनिश्चितकाल तक चलेगा जब तक कि stopService मेथड कॉल नहीं किया जाता। यदि सेवा केवल तब तक आवश्यक है जब तक क्लाइंट जुड़ा हुआ है, तो क्लाइंट को इससे "बाइंड" करना चाहिए bindService मेथड का उपयोग करके।

एक बाउंड सेवा के लिए (पिछले अनुभाग देखें), डेटा onBind मेथड को पास किया जाएगा।

उदाहरण के लिए, एक सेवा पृष्ठभूमि में संगीत बजा सकती है जबकि उपयोगकर्ता किसी अन्य एप्लिकेशन में है, या यह नेटवर्क पर डेटा फेच कर सकती है बिना गतिविधि के साथ उपयोगकर्ता के इंटरैक्शन को ब्लॉक किए।

एक सेवा को निर्यात किया जा सकता है जो डिवाइस पर अन्य प्रक्रियाओं को सेवा शुरू करने की अनुमति देता है। डिफ़ॉल्ट रूप से सेवाएं निर्यात नहीं की जाती हैं लेकिन इसे Manifest में कॉन्फ़िगर किया जा सकता है:

<service android:name=".ExampleExportedService" android:exported="true"/>

Broadcast Receivers

Broadcasts को मैसेजिंग सिस्टम के रूप में सोचा जा सकता है और broadcast receivers श्रोता होते हैं। यदि किसी एप्लिकेशन ने किसी विशेष broadcast के लिए एक receiver पंजीकृत किया है, तो जब सिस्टम broadcast भेजता है, तो उस receiver में कोड निष्पादित होता है। ध्यान दें कि इस मामले में कई एप्स एक ही संदेश प्राप्त कर सकते हैं।

एक एप्लिकेशन द्वारा receiver को पंजीकृत करने के 2 तरीके होते हैं: एप्लिकेशन के Manifest में या डायनामिक रूप से एप्लिकेशन के कोड में registerReceiver API कॉल का उपयोग करके। Manifest में आप receiver तत्व के भीतर permissions का उपयोग करके आपके द्वारा स्वीकार किए जाने वाले broadcasts को सीमित कर सकते हैं। जब डायनामिक रूप से परिभाषित किया जाता है तो आप registerReceiver मेथड को permission पास कर सकते हैं।

दोनों मामलों में, receiver को पंजीकृत करने के लिए, receiver के लिए intent filters सेट किए जाते हैं। ये intent filters वे broadcasts होते हैं जो receiver को ट्रिगर करना चाहिए।

जब विशेष broadcasts जिनके लिए receiver पंजीकृत है, भेजे जाते हैं, तो BroadcastReceiver क्लास में onReceive निष्पादित होता है।

उदाहरण के लिए, एक एप्लिकेशन कम बैटरी संदेश के लिए एक receiver पंजीकृत कर सकता है, और उस जानकारी के आधार पर अपने व्यवहार को बदल सकता है।

Broadcast असिंक्रोनस (हर receiver इसे प्राप्त करता है) या सिंक्रोनस (broadcast को प्राप्त करने के लिए सेट की गई प्राथमिकता के आधार पर एक क्रमिक तरीके से प्राप्त किया जाता है) हो सकता है।

{% hint style="danger" %} ध्यान दें कि कोई भी एप्लिकेशन खुद को Broadcast प्राप्त करने के लिए शीर्ष प्राथमिकता के रूप में सेट कर सकता है। {% endhint %}

Broadcast Receiver में लागू कोड की जांच करने के लिए आपको receiver क्लास के onReceive मेथड की खोज करनी होगी।
ध्यान दें कि Ordered Broadcasts Intent प्राप्त करने के बाद उसे छोड़ सकते हैं या यहां तक कि उसे सेटर मेथड्स का उपयोग करके संशोधित भी कर सकते हैं। इसलिए, receivers को डेटा को मान्य करना चाहिए।

Content Provider

Content Providers वह तरीका है जिससे एप्स संरचित डेटा साझा करते हैं, जैसे कि रिलेशनल डेटाबेस। इसलिए, उन्हें सुरक्षित करने के लिए permissions का उपयोग करना और उचित सुरक्षा स्तर सेट करना बहुत महत्वपूर्ण है।
Content Providers readPermission और writePermission विशेषताओं का उपयोग करके यह निर्दिष्ट कर सकते हैं कि किसी एप्लिकेशन के पास कौन सी permissions होनी चाहिए। ये permissions permission विशेषता पर प्राथमिकता लेती हैं।
इसके अलावा, वे grantUriPermission को सच के रूप में सेट करके और फिर manifest फाइल के अंदर provider तत्व के भीतर grant-uri-permission तत्व में उचित पैरामीटर्स को कॉन्फ़िगर करके अस्थायी अपवादों की अनुमति दे सकते हैं।

grant-uri-permission में तीन विशेषताएं होती हैं: path, pathPrefix और pathPattern:

• path: पूरे पथ को बाहर करने के लिए निर्दिष्ट करने की अनुमति देता है
• pathPrefix: पथ की शुरुआत को निर्दिष्ट करने की अनुमति देता है
• pathPattern: अधिक विस्तृत नियंत्रण प्राप्त करने के लिए वाइल्डकार्ड्स और प्रतीकात्मक प्रतिस्थापन का उपयोग करने की अनुमति देता है।

प्राप्त इनपुट को मान्य करना और साफ करना महत्वपूर्ण है ताकि SQL इंजेक्शन जैसी संभावित कमजोरियों से बचा जा सके।

Content Provider की विशेषताएं:

• Content Provider घटक अनुरोध पर एक एप्लिकेशन से दूसरे एप्लिकेशन को डेटा प्रदान करता है।
• आप डेटा को फाइल सिस्टम, SQLite डेटाबेस, वेब पर, या आपके एप्लिकेशन द्वारा पहुंच योग्य किसी अन्य स्थायी स्टोरेज स्थान पर स्टोर कर सकते हैं।
• Content provider के माध्यम से, अन्य एप्स डेटा को क्वेरी कर सकते हैं या यहां तक कि मॉडिफाई भी कर सकते हैं (यदि content provider इसकी अनुमति देता है)।
• Content Provider उन मामलों में उपयोगी है जब कोई एप्लिकेशन दूसरे एप्लिकेशन के साथ डेटा साझा करना चाहता है।
• यह डेटाबेस के समान है और इसमें चार मेथड्स होते हैं।
• insert()
• update()
• delete()
• query()

FileProvider

यह Content Provider का एक प्रकार है जो एक फोल्डर से फाइलें साझा करेगा। आप इस तरह से एक file provider घोषित कर सकते हैं:

<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true" android:exported="false">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>

ध्यान दें android:exported विशेषता पर क्योंकि यदि यह true है तो बाहरी एप्लिकेशन शेयर किए गए फोल्डर्स तक पहुँच सकेंगे।
यह ध्यान दें कि कॉन्फ़िगरेशन android:resource="@xml/filepaths" यह संकेत कर रहा है कि फ़ाइल res/xml/filepaths.xml में कौन से फोल्डर्स को यह FileProvider शेयर करने वाला है। यह उस फ़ाइल में एक फोल्डर शेयर करने का तरीका बताने का उदाहरण है:

<paths>
<files-path path="images/" name="myimages" />
</paths>

**`path="."`** को साझा करना **खतरनाक** हो सकता है, भले ही प्रोवाइडर निर्यात नहीं किया गया हो, अगर कोड के किसी अन्य भाग में अन्य कमजोरी हो जो इस प्रोवाइडर तक पहुंचने की कोशिश करती है।\
आप `content://com.example.myapp.fileprovider/myimages/default_image.jpg` के साथ उस फोल्डर के अंदर एक **इमेज** तक **पहुंच** सकते हैं।

`<paths>` तत्व के कई बच्चे हो सकते हैं, प्रत्येक एक अलग निर्देशिका साझा करने का निर्दिष्ट करता है। **`<files-path>`** तत्व के अलावा, आप **`<external-path>`** तत्व का उपयोग करके **बाहरी संग्रहण** में निर्देशिकाओं को साझा कर सकते हैं, और **`<cache-path>`** तत्व का उपयोग करके अपने **आंतरिक कैश निर्देशिका** में निर्देशिकाओं को साझा कर सकते हैं।\
[विशिष्ट फाइल प्रोवाइडर्स विशेषताओं के बारे में अधिक जानकारी के लिए यहां जाएं।](https://developer.android.com/reference/androidx/core/content/FileProvider)

[फाइल प्रोवाइडर्स के बारे में अधिक जानकारी यहां](https://developer.android.com/training/secure-file-sharing/setup-sharing)।

## WebViews

WebViews मूल रूप से Android Apps में एम्बेडेड **वेब ब्राउज़र** हैं।\
WebViews की सामग्री दूरस्थ साइटों से आ सकती है या ऐप में शामिल फाइलें हो सकती हैं।\
WebViews **वेब ब्राउज़रों को प्रभावित करने वाली समान कमजोरियों के लिए संवेदनशील** होते हैं। हालांकि, कुछ **कॉन्फ़िगरेशन** होते हैं जो **हमले** की **सतह** को **सीमित** करने के लिए उपयोगी हो सकते हैं।

Android में दो प्रकार के WebViews होते हैं:

* **WebViewClient**, सरल HTML रेंडरिंग के लिए सबसे उपयुक्त। यह JS alert फ़ंक्शन को नहीं चलाएगा। इसलिए, उस फ़ंक्शन का उपयोग करके XSS परीक्षण अमान्य होंगे।
* **WebChrome** **क्लाइंट**, एक Chrome ब्राउज़र है।

ध्यान दें कि **WebView ब्राउज़रों को मूल ब्राउज़र के कुकीज़ तक पहुंच नहीं है**।

URL या फाइल को लोड करने के लिए **`loadUrl`**, **`loadData`** या **`loadDataWithBaseURL`** फ़ंक्शनों का उपयोग किया जा सकता है। **केवल सेनिटाइज़्ड URLs तक पहुंचना महत्वपूर्ण है।**\
WebView सुरक्षा को **`WebSettings`** ऑब्जेक्ट के माध्यम से कॉन्फ़िगर किया जा सकता है।\
उदाहरण के लिए, JS कोड निष्पादन को **`setJavaScriptEnabled`** विधि का उपयोग करके **`false`** मान के साथ अक्षम किया जा सकता है। इससे **XSS** और अन्य JS संबंधित कमजोरियों की संभावना **हट** जाएगी।

JavaScript "**Bridge**" कार्यक्षमता **WebView में Java ऑब्जेक्ट्स को इंजेक्ट करती है जिससे वे JS के लिए सुलभ हो जाते हैं**। Android 4.2 से विधियों को JavaScript के लिए सुलभ होने के लिए **`@JavascriptInterface`** के साथ एनोटेट किया जाना चाहिए।

यदि **`true`** को **`setAllowContentAccess`** के लिए पास किया जाता है, तो **WebViews Content Providers तक पहुंचने में सक्षम होंगे** **`content://`** स्कीम के माध्यम से। यह स्पष्ट रूप से एक सुरक्षा जोखिम प्रस्तुत करता है। ध्यान दें कि यदि यह पहुंच दी जाती है, तो यह बहुत महत्वपूर्ण है कि **`content://`** URL **सुरक्षित** हो।

डिफ़ॉल्ट रूप से, WebViews file:// URLs के माध्यम से स्थानीय फाइलों तक पहुंच सकते हैं, लेकिन इस व्यवहार को रोकने के कई तरीके हैं:

* **`setAllowFileAccess`** को **`false`** पास करने से, फाइलसिस्टम तक पहुंच को रोका जा सकता है, `file:///android_asset` _और_ `file:///android_res` के अपवाद के साथ। इन पथों का उपयोग केवल गैर-संवेदनशील डेटा (जैसे इमेज) के लिए किया जाना चाहिए इसलिए यह सुरक्षित होना चाहिए।
* **`setAllowFileAccess`** विधि इंगित करती है कि क्या एक file:// URL से एक पथ को अन्य फाइल स्कीम URLs की सामग्री तक पहुंचने की अनुमति होनी चाहिए।
* **`setAllowUniversalAccessFromFileURLs`** विधि इंगित करती है कि क्या एक file:// URL से एक पथ को किसी भी मूल से सामग्री तक पहुंचने की अनुमति होनी चाहिए।

## अन्य ऐप घटक

### **एप्लिकेशन साइनिंग**

* Android मांग करता है कि **सभी ऐप्स को इंस्टॉल होने से पहले एक प्रमाणपत्र के साथ डिजिटल रूप से हस्ताक्षरित किया जाए**। Android इस प्रमाणपत्र का उपयोग एक ऐप के लेखक की पहचान करने के लिए करता है।
* डिवाइस पर एप्लिकेशन चलाने के लिए, इसे हस्ताक्षरित किया जाना चाहिए। जब एप्लिकेशन को डिवाइस पर स्थापित किया जाता है तो **पैकेज मैनेजर सत्यापित करता है** कि क्या एप्लिकेशन को एपीके फाइल में प्रमाणपत्र के साथ ठीक से हस्ताक्षरित किया गया है या नहीं।
* एप्लिकेशन को स्वयं हस्ताक्षरित किया जा सकता है या CA के माध्यम से हस्ताक्षरित किया जा सकता है।
* एप्लिकेशन साइनिंग सुनिश्चित करता है कि एक एप्लिकेशन किसी अन्य एप्लिकेशन तक नहीं पहुंच सकता है, सिवाय अच्छी तरह से परिभाषित IPC के माध्यम से और यह भी कि यह डिवाइस पर अपरिवर्तित पारित किया गया है।

### **एप्लिकेशन सत्यापन**

* Android 4.2 और बाद में एप्लिकेशन सत्यापन का समर्थन करते हैं। उपयोगकर्ता "एप्स को सत्यापित करें" को सक्षम करने का विकल्प चुन सकते हैं और इंस्टॉलेशन से पहले एप्लिकेशनों का मूल्यांकन एक एप्लिकेशन सत्यापक द्वारा करवा सकते हैं।
* एप्लिकेशन सत्यापन उपयोगकर्ता को चेतावनी दे सकता है यदि वे कोई ऐसा एप्लिकेशन स्थापित करने की कोशिश करते हैं जो हानिकारक हो सकता है; यदि कोई एप्लिकेशन विशेष रूप से बुरा है, तो यह स्थापना को अवरुद्ध कर सकता है।

## मोबाइल डिवाइस प्रबंधन

MDM या मोबाइल डिवाइस प्रबंधन वह सॉफ्टवेयर सूट हैं जो मोबाइल डिवाइसों पर **नियंत्रण और सुरक्षा आवश्यकताओं** को सुनिश्चित करने के लिए उपयोग किए जाते हैं। ये सूट डिवाइस प्रशासन API के रूप में जाने जाने वाले फीचर्स का उपयोग करते हैं और एक Android ऐप को स्थापित किया जाना चाहिए।

आम तौर पर MDM समाधान पासवर्ड नीतियों को लागू करने, संग्रहण के एन्क्रिप्शन को मजबूर करने और डिवाइस डेटा को दूरस्थ रूप से मिटाने जैसे कार्य करते हैं।

<figure><img src="/.gitbook/assets/image (675).png" alt=""><figcaption></figcaption></figure>

स