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

Android एप्लिकेशन की मूलभूत जानकारी

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की आवश्यकता है? सदस्यता योजनाएं की जांच करें!
• The PEASS Family की खोज करें, हमारा विशेष NFT संग्रह।
• आधिकारिक PEASS & HackTricks swag प्राप्त करें
• 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या मुझे Twitter 🐦@carlospolopm** का पालन करें**।**
• अपने हैकिंग ट्रिक्स को hacktricks रेपो और hacktricks-cloud रेपो में पीआर जमा करके अपना योगदान दें।

विशेषता को ठीक करने के लिए महत्वपूर्ण दुर्बलताओं का पता लगाएं। Intruder आपकी हमला सतह का ट्रैक करता है, प्रोएक्टिव धमकी स्कैन चलाता है, एपीआई से वेब ऐप्स और क्लाउड सिस्टम तक इस्तेमाल करने वाली समस्याओं का पता लगाता है। इसे नि: शुल्क परीक्षण के लिए आज़माएं।

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

---

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

यहां दो स्तर हैं:

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

UID अलगाव

प्रत्येक एप्लिकेशन को एक विशिष्ट उपयोगकर्ता आईडी सौंपा जाता है। इसे एप्लिकेशन के स्थापना के दौरान किया जाता है ताकि ऐप केवल अपने उपयोगकर्ता आईडी या साझा किए गए फ़ाइलों के साथ इंटरैक्ट कर सके। इसलिए, केवल ऐप इसे, ओएस के कुछ घटक और रूट उपयोगकर्ता ही ऐप्स डेटा तक पहुंच सकते हैं।

UID साझा करना

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

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

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

ROMs

एक कस्टम फर्मवेयर स्थापित करके ओएस को बदलना संभव है। इसे करके पुराने उपकरण की उपयोगिता बढ़ाई जा सकती है, सॉफ़्टवेयर प्रतिबंधों को दूर किया जा सकता है या नवीनतम Android कोड तक पहुंच मिल सकती है। OmniROM और LineageOS इस्तेमाल करने के लिए दो सबसे लोकप्रिय फर्मवेयर हैं।

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

प्रभाव

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

Android एप्लिकेशन के मूलभूत तत्व

यह परिचय https://maddiestone.github.io/AndroidAppRE/app_fundamentals.html से लिया गया है।

मूलभूत तत्व समीक्षा

• Android एप्लिकेशन APK फ़ाइल प्रारूप में होते हैं। APK मूल रूप से एक ZIP फ़ाइल है। (आप फ़ाइल एक्सटेंशन को .zip में बदलकर फ़ाइल को खोलने और उसकी सामग्री देखने के लिए उपयोग कर सकते हैं।)
• APK सामग्री (अपूर्ण नहीं)
• AndroidManifest.xml
• resources.arsc/strings.xml
• resources.arsc: बाइनरी XML जैसे पूर्व-संकलित संसाधनों को समेटने वाली फ़ाइल।
• res/xml/files_paths.xml
• META-INF/
• प्रमाणपत्र यहां रहता है!
• classes.dex
• एप्लिकेशन के लिए Dalvik bytecode, DEX फ़ाइल प्रारूप में। यह जावा (या कोटलिन) कोड है जिसे एप्लिकेशन डिफ़ॉल्ट रूप से चलाएगा।
• lib/
• एप्लिकेशन के लिए नेटिव पुस्तकालय, डिफ़ॉल्ट रूप में, यहां रहती हैं! lib/ निर्देशिका के अंतर्गत, cpu-विशिष्ट निर्देशिकाएँ होती हैं।
• armeabi: सभी ARM आधारित प्रोसेसरों के लिए संकलित कोड
• armeabi-v7a: सभी ARMv7 और उससे ऊपर के आधारित प्रोसेसरों के लिए संकलित कोड
• x86: X86 के लिए संकलित कोड
• mips: केवल MIPS प्रोसेसरों के लिए संकलित कोड
• assets/
• ऐप द्वारा आवश्यक हो सकने वाली किसी अन्य फ़ाइलें।
• यहां अतिरिक्त नेटिव पुस्तकालय या DEX फ़ाइलें शामिल हो सकती हैं। यह खासकर तब हो सकता है जब मैलवेयर लेखक अतिरिक्त कोड, नेटिव या Dalvik, को "छिपाने" की कोशिश करना चाहते हैं, इसे डिफ़ॉल्ट स्थानों में शामिल नहीं करके।
• res/
• संसाधनों को संकलित न करने वाले संसाधनों को समेटने वाली निर्देशिका

Dalvik और Smali

अधिकांश Android एप्लिकेशन जावा में लिखे जाते हैं। Kotlin भी समर्थित है और जावा के साथ संगत है। सुविधा के लिए, इस कार्यशाला के शेष भाग के लिए, जब मैं "जावा" का उल्लेख करता हूँ, तो आप यह मान सकते हैं कि मैं "जावा या Kotlin" का मतलब कर रहा हूँ। जबकि डेस्कटॉप एप्लिकेशनों की तरह जावा कोड को जावा वर्चुअल मशीन (JVM) में चलाया जाता है, Android में जावा को _Dalvik Executable (DEX) bytecode_* फ़ॉर्मेट में कंपाइल किया जाता है। पहले के संस्करणों के लिए, बाइटकोड को Dalvik वर्चुअल मशीन द्वारा अनुवादित किया गया था। हाल के संस्करणों के लिए, Android रनटाइम (ART) का उपयोग किया जाता है।
यदि डेवलपर जावा में लिखता है और कोड DEX bytecode में कंपाइल होता है, तो उल्टे इंजीनियरिंग करने के लिए, हम उल्टी दिशा में काम करते हैं

निहित इंटेंट्स

इंटेंट्स को कार्यक्रमात्मक रूप से एक इंटेंट निर्माता का उपयोग करके बनाया जाता है:

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

क्रिया पहले से घोषित इंटेंट की ACTION_SEND है और अतिरिक्त एक मेलटू यूआरआई है (अतिरिक्त जो इंटेंट की अतिरिक्त जानकारी है जिसे इंटेंट की उम्मीद होती है।)

इस इंटेंट को निम्नलिखित उदाहरण के रूप में मेनिफेस्ट में घोषित किया जाना चाहिए:

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

एक इंटेंट-फ़िल्टर को संदेश प्राप्त करने के लिए क्रिया, डेटा और श्रेणी के साथ मेल खाना चाहिए।

"इंटेंट संकलन" प्रक्रिया यह निर्धारित करती है कि कौन सा ऐप हर संदेश प्राप्त करना चाहिए। इस प्रक्रिया में प्राथमिकता विशेषता को ध्यान में रखा जाता है, जो इंटेंट-फ़िल्टर घोषणा में सेट की जा सकती है, और उच्चतम प्राथमिकता वाला चयन किया जाएगा। इस प्राथमिकता को -1000 से 1000 तक सेट किया जा सकता है और ऐप्लिकेशन SYSTEM_HIGH_PRIORITY मान का उपयोग कर सकते हैं। यदि विरोध उत्पन्न होता है, तो "चयनकर्ता" विंडो दिखाई देती है ताकि उपयोगकर्ता निर्णय कर सके।

स्पष्ट इंटेंट्स

स्पष्ट इंटेंट निर्दिष्ट करता है कि वह किस कक्ष को लक्ष्य बना रहा है:

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

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

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

पेंडिंग इंटेंट्स

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

ब्रॉडकास्ट इंटेंट्स

पिछले इंटेंट्स के विपरीत, जो केवल एक ऐप द्वारा प्राप्त किए जाते हैं, ब्रॉडकास्ट इंटेंट्स कई ऐप्स द्वारा प्राप्त किए जा सकते हैं। हालांकि, API संस्करण 14 से, Intent.set Package का उपयोग करके संदेश प्राप्त करने वाला ऐप निर्दिष्ट किया जा सकता है।

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

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

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

स्टिकी ब्रॉडकास्ट्स

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

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

डीप लिंक्स / URL योजनाएँ

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

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

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

तो, इसका मतलब है कि यह http://www.example.com/gizmos जैसी कुछ चाहता है

यदि आप कुछ इस तरह का पाते पाते हैं:

इसका मतलब होगा कि यह example://gizmos से शुरू होने वाला एक URL चाहता है
इस मामले में आप इस कार्यक्षमता का दुरुपयोग करने की कोशिश कर सकते हैं और निम्नलिखित payloads के साथ एक वेब बना सकते हैं। यह विचार करेगा कि यह अनियमित पृष्ठों पर नेविगेट करने की कोशिश करेगा और 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) का उपयोग करके एक दूसरे के साथ संवाद करने के लिए क्लाइंट और सर्विस के बीच समझौता करने के लिए प्रोग्रामिंग इंटरफ़ेस को परिभाषित करने की अनुमति देता है। एंड्रॉइड पर, एक प्रक्रिया सामान्यतः दूसरी प्रक्रिया की मेमोरी तक पहुंच नहीं कर सकती। इसलिए बातचीत करने के लिए, वे अपने ऑब्जेक्ट्स को प्राथमिक तत्वों में विभाजित करने की आवश्यकता होती है जिन्हें ऑपरेटिंग सिस्टम समझ सके, और आपके लिए उस सीमा के पार ऑब्जेक्ट्स को मार्शल करते हैं। उस मार्शलिंग कोड को लिखना थका करने वाला होता है, इसलिए एंड्रॉइड इसे AIDL के साथ आपके लिए संभालता है।

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

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

मैसेंजर

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

बाइंडर

बाइंडर कक्षा को सीधे बुलाया जाना अजीब है क्योंकि AIDL का उपयोग करना (जो बाइंडर कक्षा को अलग करता है) बहुत आसान होता है। हालांकि, जानना अच्छा होता है कि बाइंडर एक कर्नल-स्तरीय ड्राइवर है जो डेटा को एक प्रक्रिया की मेमोरी से दूसरी प्रक्रिया मेमोरी में ले जाता है (https://www.youtube.com/watch?v=O-UHvFjxwZ8)।

कंपोनेंट्स

इनमें शामिल हैं: गतिविधियाँ, सेवाएँ, ब्रॉडकास्ट रिसीवर और प्रोवाइडर्स।

लॉन्चर गतिविधि और अन्य गतिविधियाँ

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

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

ध्यान दें कि हर एप्लिकेशन में लॉन्चर गतिविधि नहीं होगी, विशेष रूप से यूआई वाले ऐप्स नहीं। उदाहरण रूप में, यूज़र वॉयसमेल जैसी पीछे की तरफ सेवाएँ प्रदान करने वाले प्री-इंस्टॉल की गई ऐप्लिकेशनें ऐसी होती हैं।

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

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

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

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

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

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

Android एप्लिकेशन Application का एक सबक्लास परिभाषित कर सकते हैं। एंड्रॉइड ऐप एक Application सबक्लास परिभाषित करता है, तो इस कक्षा को ऐप्लिकेशन में किसी भी अन्य कक्षा से पहले निर्मित किया जाता है।

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

सेवाएं

सेवाएं बिना UI के पिछले में चलती हैं। वे **लंबे समय तक चलने वाले प्रक्रियाएं करने के लिए उपयोग की जाती हैं, यदि उपयोगकर्ता एक अलग ऐप्लिकेशन का उपयोग करना शुरू कर देता है तो भी।

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

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

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

उदाहरण के लिए, एक सेवा बैकग्राउंड में संगीत चला सकती है जब उपयोगकर्ता एक अलग ऐप्लिकेशन में होता है, या यह नेटवर्क पर डेटा प्राप्त कर सकती है जब उपयोगकर्ता की गतिविधि को ब्लॉक नहीं करती है।

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

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

ब्रॉडकास्ट रिसीवर

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

किसी एप्लिकेशन को रिसीवर पंजीकृत करने के लिए 2 तरीके हैं: एप्लिकेशन के मैनिफेस्ट में या एप्लिकेशन के कोड में डायनामिक रूप से पंजीकृत किया जा सकता है, जहां प्रयोग किए जाने वाले registerReceiver API कॉल का उपयोग किया जाता है। मैनिफेस्ट में आप रिसीवर तत्व के भीतर अनुमतियों के माध्यम से आप स्वीकार करने वाले ब्रॉडकास्ट को सीमित कर सकते हैं। डायनामिक रूप से परिभाषित करने पर आप registerReceiver विधि को अनुमति पास कर सकते हैं।

दोनों मामलों में, रिसीवर को पंजीकृत करने के लिए, रिसीवर के लिए इंटेंट फ़िल्टर सेट किए जाते हैं। ये इंटेंट फ़िल्टर वे ब्रॉडकास्ट हैं जो रिसीवर को ट्रिगर करने चाहिए।

जब रिसीवर के लिए पंजीकृत ब्रॉडकास्ट भेजे जाते हैं, तो BroadcastReceiver कक्षा के onReceive में क्रियान्वित होता है।

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

ब्रॉडकास्ट असिंक्रोनस (प्रत्येक रिसीवर इसे प्राप्त करता है) या सिंक्रोनस (प्राथमिकता के आधार पर आदेशित तरीके से रिसीव किया जाता है) हो सकता है।

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

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

कंटेंट प्रोवाइडर

कंटेंट प्रोवाइडर ऐसे ढंग से हैं जिससे ऐप्स संरचित डेटा साझा करते हैं, जैसे कि संबंधित डेटाबेस। इसलिए, इन्हें सुरक्षा के लिए अनुमतियाँ और उचित सुरक्षा स्तर सेट करना बहुत महत्वपूर्ण है।
कंटेंट प्रोवाइडर एप्लिकेशन को यह निर्दिष्ट करने के लिए readPermission और writePermission विशेषताएं उपयोग कर सकते हैं कि किस अनुमति की आवश्यकता होती है। ये अनुमतियाँ अनुमति विशेषता से पहले आवश्यकता लेती हैं।
इसके अलावा, वे अस्थायी छूट भी अनुमति को सक्षम कर सकते हैं और फिर मैनिफेस्ट फ़ाइल के प्रोवाइडर तत्व के भीतर grant-uri-permission तत्व में उचित पैरामीटर को कॉन्फ़िगर करके।

grant-uri-permission में तीन विशेषताएं होती हैं: पथ, पथप्रिफ़िक्स और पथपैटर्न:

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

यह महत्वपूर्ण है कि प्राप्त इनपुट को सत्यापित और स्वच्छ करना व्यक्तिगत सुरक्षा की संभावित खोज से बचने के लिए।

कंटेंट प्रोवाइडर की विशेषताएं:

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

FileProvider

यह एक प्रकार का कंटेंट प्रो

<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> तत्व का उपयोग करके अपने आंतरिक कैश डायरेक्टरी में डायरेक्टरी को साझा करने के लिए कर सकते हैं।
विशेष फ़ाइल प्रदाता गुणों के बारे में अधिक जानकारी के लिए यहां जाएं।

फ़ाइल प्रदाताओं के बारे में अधिक जानकारी यहां.

वेबव्यू

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

Android में दो प्रकार के वेबव्यूज़ होते हैं:

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

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

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

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

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

डिफ़ॉल्ट रूप से, वेबव्यूज़ द्वारा स्थानीय फ़ाइलों का उपयोग file:// URLs के माध्यम से किया जा सकता है, लेकिन इस व्यवहार को रोकने के लिए कई तरीके हैं:

• setAllowFileAccess में false पास करने से, फ़ाइल सिस्टम