* क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग** करने की आवश्यकता है? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFT**](https://opensea.io/collection/the-peass-family) संग्रह।
* [**आधिकारिक PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में **शामिल** हों या मुझे **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)** का पालन करें**।**
* **अपने हैकिंग ट्रिक्स को** [**hacktricks रेपो**](https://github.com/carlospolop/hacktricks) **और** [**hacktricks-cloud रेपो**](https://github.com/carlospolop/hacktricks-cloud) **में पीआर जमा करके अपना योगदान दें।**
विशेषता को ठीक करने के लिए महत्वपूर्ण दुर्बलताओं का पता लगाएं। Intruder आपकी हमला सतह का ट्रैक करता है, प्रोएक्टिव धमकी स्कैन चलाता है, एपीआई से वेब ऐप्स और क्लाउड सिस्टम तक इस्तेमाल करने वाली समस्याओं का पता लगाता है। [**इसे नि: शुल्क परीक्षण के लिए आज़माएं**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks)।
**प्रत्येक एप्लिकेशन को एक विशिष्ट उपयोगकर्ता आईडी सौंपा जाता है**। इसे एप्लिकेशन के स्थापना के दौरान किया जाता है ताकि **ऐप केवल अपने उपयोगकर्ता आईडी या साझा किए गए** फ़ाइलों के साथ इंटरैक्ट कर सके। इसलिए, केवल ऐप इसे, ओएस के कुछ घटक और रूट उपयोगकर्ता ही ऐप्स डेटा तक पहुंच सकते हैं।
**दो ऐप्लिकेशनों को एक ही UID का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है**। यह जानकारी साझा करने के लिए उपयोगी हो सकता है, लेकिन यदि इनमें से कोई भी संक्रमित हो जाता है, तो दोनों ऐप्लिकेशनों के डेटा प्रभावित हो जाएगा। इसलिए इस व्यवहार को **अस्वीकार किया जाता है**।\
**एक ही UID को साझा करने के लिए, ऐप्लिकेशनों को अपने मेनिफेस्ट में `android:sharedUserId` मान की परिभाषा करनी होगी।**
**Android एप्लिकेशन सैंडबॉक्स** हर एक एप्लिकेशन को एक अलग प्रक्रिया के रूप में एक अलग उपयोगकर्ता आईडी के तहत चलाने की अनुमति देता है। प्रत्येक प्रक्रिया में अपनी खुद की वर्चुअल मशीन होती है, इसलिए ऐप का कोड अन्य ऐप्स से अलगाव में चलता है।\
Android 5.0(L) से **SELinux** लागू होता है। मूल रूप से, SELinux ने सभी प्रक्रिया इंटरैक्शन को अस्वीकार किया और फिर उनके बीच की **उम्मीद की जाने वाली इंटरैक्शन को केवल स्वीकृत करने के लिए नीतियाँ बनाई
एक कस्टम फर्मवेयर स्थापित करके ओएस को बदलना संभव है। इसे करके पुराने उपकरण की उपयोगिता बढ़ाई जा सकती है, सॉफ़्टवेयर प्रतिबंधों को दूर किया जा सकता है या नवीनतम Android कोड तक पहुंच मिल सकती है।
**OmniROM** और **LineageOS** इस्तेमाल करने के लिए दो सबसे लोकप्रिय फर्मवेयर हैं।
ध्यान दें कि एक कस्टम फर्मवेयर स्थापित करने के लिए हमेशा उपकरण को रूट करने की आवश्यकता नहीं होती है। कुछ निर्माताओं की अनुमति होती है उनके बूटलोडर्स को एक अच्छी तरह से दस्तावेजीकृत और सुरक्षित तरीके से अनलॉक करने की।
एक उपकरण को रूट करने के बाद, कोई भी ऐप रूट के रूप में पहुंच का अनुरोध कर सकती है। यदि कोई दुष्ट ऐप इसे प्राप्त करता है, तो उसे लगभग सबकुछ का उपयोग करने की अनुमति होगी और वह फोन को क्षति पहुंचा सकेगी।
यह परिचय [https://maddiestone.github.io/AndroidAppRE/app\_fundamentals.html](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/
* संसाधनों को संकलित न करने वाले संसाधनों को समेटने वाली निर्देशिका
अधिकांश Android एप्लिकेशन जावा में लिखे जाते हैं। Kotlin भी समर्थित है और जावा के साथ संगत है। सुविधा के लिए, इस कार्यशाला के शेष भाग के लिए, जब मैं "जावा" का उल्लेख करता हूँ, तो आप यह मान सकते हैं कि मैं "जावा या Kotlin" का मतलब कर रहा हूँ। जबकि डेस्कटॉप एप्लिकेशनों की तरह जावा कोड को जावा वर्चुअल मशीन (JVM) में चलाया जाता है, Android में जावा को \_Dalvik Executable (DEX) bytecode\_\* फ़ॉर्मेट में कंपाइल किया जाता है। पहले के संस्करणों के लिए, बाइटकोड को Dalvik वर्चुअल मशीन द्वारा अनुवादित किया गया था। हाल के संस्करणों के लिए, Android रनटाइम (ART) का उपयोग किया जाता है।\
यदि डेवलपर जावा में लिखता है और कोड DEX bytecode में कंपाइल होता है, तो उल्टे इंजीनियरिंग करने के लिए, हम उल्टी दिशा में काम करते हैं
**क्रिया** पहले से घोषित इंटेंट की **ACTION\_SEND** है और **अतिरिक्त** एक मेलटू **यूआरआई** है (अतिरिक्त जो इंटेंट की अतिरिक्त जानकारी है जिसे इंटेंट की उम्मीद होती है।)
"इंटेंट संकलन" प्रक्रिया यह निर्धारित करती है कि कौन सा ऐप हर संदेश प्राप्त करना चाहिए। इस प्रक्रिया में **प्राथमिकता विशेषता** को ध्यान में रखा जाता है, जो **इंटेंट-फ़िल्टर घोषणा** में सेट की जा सकती है, और **उच्चतम प्राथमिकता वाला** चयन किया जाएगा। इस प्राथमिकता को -1000 से 1000 तक सेट किया जा सकता है और ऐप्लिकेशन `SYSTEM_HIGH_PRIORITY` मान का उपयोग कर सकते हैं। यदि **विरोध** उत्पन्न होता है, तो "चयनकर्ता" विंडो दिखाई देती है ताकि **उपयोगकर्ता निर्णय** कर सके।
ये अन्य एप्लिकेशनों को आपकी एप्लिकेशन के नाम और अनुमतियों का उपयोग करके कार्रवाई करने की अनुमति देते हैं। पेंडिंग इंटेंट बनाने के लिए एक इंटेंट और करने के लिए कार्रवाई को निर्दिष्ट करना चाहिए। यदि घोषित इंटेंट स्पष्ट नहीं है (जिसमें यह घोषणा नहीं की गई है कि कौन सा इंटेंट इसे कॉल कर सकता है), तो एक खतरनाक एप्लिकेशन पीड़ित ऐप के नाम पर घोषित कार्रवाई कर सकती है। इसके अलावा, यदि कोई कार्रवाई निर्दिष्ट नहीं है, तो खतरनाक ऐप पीड़ित के नाम पर किसी भी कार्रवाई कर सकेगी।
पिछले इंटेंट्स के विपरीत, जो केवल एक ऐप द्वारा प्राप्त किए जाते हैं, ब्रॉडकास्ट इंटेंट्स कई ऐप्स द्वारा प्राप्त किए जा सकते हैं। हालांकि, API संस्करण 14 से, Intent.set Package का उपयोग करके संदेश प्राप्त करने वाला ऐप निर्दिष्ट किया जा सकता है।
ब्रॉडकास्ट के दो प्रकार होते हैं: सामान्य (असिंक्रोनस) और आदेशित (सिंक्रोनस)। क्रम ग्राहक तत्व के भीतर कॉन्फ़िगर की गई प्राथमिकता पर आधारित होता है। प्रत्येक ऐप ब्रॉडकास्ट को प्रोसेस, रिले या छोड़ सकता है।
एक ब्रॉडकास्ट भेजने के लिए आप `Context` कक्षा से `sendBroadcast(intent, receiverPermission)` फ़ंक्शन का उपयोग कर सकते हैं।\
आप `LocalBroadCastManager` से `sendBroadcast` फ़ंक्शन का उपयोग करके संदेश को कभी भी ऐप से नहीं निकलने देता है। इसका उपयोग करके आपको एक प्राप्तकर्ता घटक को निर्यात करने की भी आवश्यकता नहीं होगी।
यदि आप "स्टिकी" शब्द को समेत करने वाले फ़ंक्शन जैसे `sendStickyBroadcast` या `sendStickyBroadcastAsUser` पाते हैं, तो प्रभाव की जांच करें और उन्हें हटाने का प्रयास करें।
डीप लिंक्स एक इंटेंट को URL के माध्यम से ट्रिगर करने की अनुमति देते हैं। एक ऐप्लिकेशन अपने एक्टिविटी के भीतर एक URL योजना घोषित कर सकती है, इसलिए हर बार जब एंड्रॉइड डिवाइस उस योजना का उपयोग करके किसी पते तक पहुंचने की कोशिश करता है, ऐप्लिकेशन की गतिविधि को बुलाया जाएगा:
इसका मतलब होगा कि यह `example://gizmos` से शुरू होने वाला एक URL चाहता है\
इस मामले में आप इस कार्यक्षमता का दुरुपयोग करने की कोशिश कर सकते हैं और निम्नलिखित payloads के साथ एक वेब बना सकते हैं। यह विचार करेगा कि यह अनियमित पृष्ठों पर नेविगेट करने की कोशिश करेगा और JS को निष्पादित करने की कोशिश करेगा:
**Android Interface Definition Language** (AIDL) आपको इंटरप्रोसेस कम्यूनिकेशन (IPC) का उपयोग करके एक दूसरे के साथ संवाद करने के लिए क्लाइंट और सर्विस के बीच समझौता करने के लिए प्रोग्रामिंग इंटरफ़ेस को परिभाषित करने की अनुमति देता है। एंड्रॉइड पर, **एक प्रक्रिया सामान्यतः दूसरी प्रक्रिया की मेमोरी तक पहुंच नहीं कर सकती**। इसलिए बातचीत करने के लिए, वे अपने ऑब्जेक्ट्स को प्राथमिक तत्वों में विभाजित करने की आवश्यकता होती है जिन्हें **ऑपरेटिंग सिस्टम** समझ सके, और आपके लिए उस सीमा के पार ऑब्जेक्ट्स को मार्शल करते हैं। उस मार्शलिंग कोड को लिखना थका करने वाला होता है, इसलिए एंड्रॉइड इसे AIDL के साथ आपके लिए संभालता है।
AIDL का उपयोग करने वाली सेवाएं **बाउंड सेवाएं** के रूप में उपयोग की जाती हैं। सेवा की कक्षा में आपको **`onBind`** विधि मिलेगी। यहां **बातचीत की शुरुआत होती है**, इसलिए यह कोड की समीक्षा करने का पहला हिस्सा है जहां संभावित सुरक्षा की कमजोरियों की तलाश करनी चाहिए।
एक बाउंड सेवा एक क्लाइंट-सर्वर इंटरफ़ेस में सर्वर होती है। यह कंपोनेंट (जैसे कि गतिविधियाँ) को सेवा से बाइंड करने, अनुरोध भेजने, प्रतिक्रिया प्राप्त करने और इंटरप्रोसेस कम्यूनिकेशन (IPC) करने की अनुमति देती है। एक बाउंड सेवा आमतौर पर केवल तब तक जीती है जब वह एक अन्य एप्लिकेशन कंपोनेंट की सेवा करती है और अनिश्चित समय तक पृष्ठभूमि में नहीं चलती है।
मैसेंजर एक और प्रकार का IPC मेकेनिज़्म है। क्योंकि **मैसेंजर भी "बाउंड सेवा" है**, इसलिए क्लाइंट ऐप से पास किए गए डेटा को भी `onBind` विधि के माध्यम से प्रोसेस किया जाता है। इसलिए, कोड समीक्षा इस विधि पर शुरू होनी चाहिए और आपको संवेदनशीलता की कार्यान्वयन की आहुति या डेटा के असुरक्षित हैंडलिंग की तलाश करनी चाहिए।
बाइंडर कक्षा को सीधे बुलाया जाना अजीब है क्योंकि AIDL का उपयोग करना (जो बाइंडर कक्षा को अलग करता है) बहुत आसान होता है। हालांकि, जानना अच्छा होता है कि **बाइंडर एक कर्नल-स्तरीय ड्राइवर है जो डेटा को एक प्रक्रिया की मेमोरी से दूसरी प्रक्रिया मेमोरी में ले जाता है** ([https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8))।
एक **एंड्रॉइड गतिविधि** एंड्रॉइड ऐप के उपयोगकर्ता इंटरफ़ेस का एक स्क्रीन होती है। इस तरह से एक **एंड्रॉइड गतिविधि** एक डेस्कटॉप एप्लिकेशन में विंडोज के बहुत समान होती है। एक **एंड्रॉइड** ऐप में एक से अधिक गतिविधियाँ हो सकती हैं, यानी एक से अधिक स्क्रीन।
लॉन्चर गतिविधि वह गतिविधि है जिसे अधिकांश लोग एंड्रॉइड ऐप्लिकेशन के **प्रवेश बिंदु** के रूप में सोचते हैं। लॉन्चर गतिविधि वह गतिविधि है जो एक उपयोगकर्ता ऐप्लिकेशन के चिह्नित करने पर शुरू होती है। आप ऐप्लिकेशन के मैनिफेस्ट की ओर देखकर लॉन्चर गतिविधि का निर्धारण कर सकते हैं। लॉन्चर गतिविधि में निम्नलिखित MAIN और LAUNCHER इंटेंट्स सूचीबद्ध होंगे।
ध्यान दें कि हर एप्लिकेशन में लॉन्चर गतिविधि नहीं होगी, विशेष रूप से यूआई वाले ऐप्स नहीं। उदाहरण रूप में, यूज़र वॉयसमेल जैसी पीछे की तरफ सेवाएँ प्रदान करने वाले प्री-इंस्टॉल की गई ऐप्लिकेशनें ऐसी होती हैं।
गतिविधियों को निर्यात किया जा सकता है जिससे उपकरण पर अन्य प्रक्रियाएं गतिविधि को लॉन्च कर सकती हैं। डिफ़ॉल्ट रूप से, वे निर्यात नहीं होती हैं लेकिन आप उन्हें निर्यात कर सकते हैं जो सेट करते हैं:
नोट करें कि **गतिविधि सुरक्षा को अनदेखा करने की क्षमता हमेशा एक संकट नहीं होती है**, आपको जांचना चाहिए कि आपको किस डेटा तक पहुंच मिली है।
इसके अलावा, **कुछ गतिविधियाँ डेटा को कॉलर को वापस भेजती हैं**। इन स्थितियों में, आपको **`setResult`** मेथड की खोज करनी चाहिए और इंटेंट पैरामीटर में पास किए गए डेटा की जांच करनी चाहिए। **यदि यह संवेदनशील डेटा है, तो आपके पास एक जानकारी लीकेज संकट हो सकता है** और इसे ऐप्स के साथ उपयोग करके उत्पन्न किया जा सकता है।
Android एप्लिकेशन [Application](https://developer.android.com/reference/android/app/Application) का एक **सबक्लास** परिभाषित कर सकते हैं। एंड्रॉइड ऐप एक Application सबक्लास परिभाषित करता है, तो **इस कक्षा को ऐप्लिकेशन में किसी भी अन्य कक्षा से पहले निर्मित किया जाता है**।
[सेवाएं](https://developer.android.com/guide/components/services) **बिना UI के पिछले में चलती हैं।** वे **लंबे समय तक चलने वाले प्रक्रियाएं करने के लिए उपयोग की जाती हैं, यदि उपयोगकर्ता एक अलग ऐप्लिकेशन का उपयोग करना शुरू कर देता है तो भी।
इन्हें शुरू करने के तरीकों की असंख्य विधियाँ हैं और इसलिए ये ऐप्लिकेशन के लिए एंट्री प्वाइंट होती हैं। एक सेवा को एंट्री प्वाइंट के रूप में शुरू करने का डिफ़ॉल्ट तरीका इंटेंट के माध्यम से होता है।
जब सेवा को शुरू करने के लिए **`startService`** मेथड को कॉल किया जाता है, तो सेवा में **`onStart`** मेथड को निष्पादित किया जाता है। यह बंद होने तक अनिश्चित समय तक चलेगा जब तक **`stopService`** मेथड को कॉल नहीं किया जाता है। यदि सेवा केवल उस समय आवश्यक है जब क्लाइंट कनेक्टेड है, तो क्लाइंट को इसे "बाइंड" करना चाहिए और **`bindService`** मेथड का उपयोग करना चाहिए।
उदाहरण के लिए, एक सेवा बैकग्राउंड में संगीत चला सकती है जब उपयोगकर्ता एक अलग ऐप्लिकेशन में होता है, या यह नेटवर्क पर डेटा प्राप्त कर सकती है जब उपयोगकर्ता की गतिविधि को ब्लॉक नहीं करती है।
**एक सेवा निर्यात की जा सकती है जिससे उपकरण पर अन्य प्रक्रियाएं सेवा शुरू कर सकती हैं**। डिफ़ॉल्ट रूप से सेवाएं निर्यात नहीं होती हैं, लेकिन इसे मैनिफेस्ट में कॉन्फ़िगर किया जा सकता है:
ब्रॉडकास्ट को संदेश प्रणाली के रूप में समझा जा सकता है और **ब्रॉडकास्ट रिसीवर सुनने वाले होते हैं**। यदि कोई एप्लिकेशन किसी विशेष ब्रॉडकास्ट के लिए एक रिसीवर को पंजीकृत करती है, तो जब सिस्टम ब्रॉडकास्ट भेजता है, उस रिसीवर में कोड क्रियान्वित होता है। ध्यान दें कि इस मामले में **कई ऐप्स एक ही संदेश को प्राप्त कर सकते हैं**।
किसी एप्लिकेशन को रिसीवर पंजीकृत करने के लिए **2 तरीके** हैं: एप्लिकेशन के मैनिफेस्ट में या एप्लिकेशन के कोड में डायनामिक रूप से पंजीकृत किया जा सकता है, जहां प्रयोग किए जाने वाले **`registerReceiver`** API कॉल का उपयोग किया जाता है। मैनिफेस्ट में आप रिसीवर तत्व के भीतर अनुमतियों के माध्यम से आप स्वीकार करने वाले ब्रॉडकास्ट को सीमित कर सकते हैं। डायनामिक रूप से परिभाषित करने पर आप **`registerReceiver`** विधि को अनुमति पास कर सकते हैं।
दोनों मामलों में, रिसीवर को पंजीकृत करने के लिए, रिसीवर के लिए इंटेंट फ़िल्टर सेट किए जाते हैं। ये इंटेंट फ़िल्टर वे ब्रॉडकास्ट हैं जो रिसीवर को ट्रिगर करने चाहिए।
एक ब्रॉडकास्ट रिसीवर में अंतर्गत कोड की जांच करने के लिए आपको रिसीवर की कक्षा के **`onReceive`** विधि की खोज करनी होगी।\
ध्यान दें कि **आदेशित ब्रॉडकास्ट आदेशित रूप से प्राप्त किए जा सकते हैं या उन्हें संशोधित किया जा सकता है** सेटर विधियों में से किसी एक का उपयोग करके। इसलिए, **रिसीवर्स को डेटा को सत्यापित करना चाहिए**।
कंटेंट प्रोवाइडर ऐसे ढंग से हैं जिससे **ऐप्स संरचित डेटा साझा करते हैं**, जैसे कि संबंधित डेटाबेस। इसलिए, इन्हें सुरक्षा के लिए **अनुमतियाँ** और उचित सुरक्षा स्तर सेट करना बहुत महत्वपूर्ण है।\
कंटेंट प्रोवाइडर एप्लिकेशन को यह निर्दिष्ट करने के लिए **`readPermission`** और **`writePermission`** विशेषताएं उपयोग कर सकते हैं कि किस अनुमति की आवश्यकता होती है। **ये अनुमतियाँ अनुमति विशेषता से पहले आवश्यकता लेती हैं**।\
इसके अलावा, वे अस्थायी छूट भी **अनुमति को सक्षम** कर सकते हैं और फिर मैनिफेस्ट फ़ाइल के प्रोवाइडर तत्व के भीतर **`grant-uri-permission`** तत्व में उचित पैरामीटर को कॉन्फ़िगर करके।
ध्यान दें **`android:exported`** एट्रिब्यूट पर क्योंकि अगर यह **`true`** होता है तो बाहरी एप्लिकेशन साझा की गई फ़ोल्डरों तक पहुँच पा सकेंगी।\
ध्यान दें कि कॉन्फ़िगरेशन `android:resource="@xml/filepaths"` यह दर्शा रहा है कि फ़ाइल _res/xml/filepaths.xml_ में **कौन से फ़ोल्डर** को यह **FileProvider** साझा करेगा। यहां एक उदाहरण है कि उस फ़ाइल में एक फ़ोल्डर को साझा करने का तरीका कैसे दिखाया जाता है:
ऐसा कुछ साझा करना जैसे **`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)
वेबव्यूज़ वास्तव में Android ऐप्स में समाहित **वेब ब्राउज़र** हैं।\
वेबव्यूज़ सामग्री दूरस्थ साइटों से खींची जा सकती है या ऐप में शामिल फ़ाइलों से हो सकती हैं।\
वेबव्यूज़ किसी भी वेब ब्राउज़र को प्रभावित करने वाली **वेब ब्राउज़रों के वे ही दुर्बलताओं के प्रति संवेदनशील होते हैं**। हालांकि, कुछ **कॉन्फ़िगरेशन** हैं जो **हमले की सतह को सीमित करने** में उपयोगी हो सकती हैं।
* **WebViewClient**, सरल HTML प्रदर्शन के लिए सबसे उपयुक्त। यह JS चेतावनी कार्य को नहीं चलाएगा। इसलिए, इस फ़ंक्शन का उपयोग करके XSS परीक्षण अमान्य हो जाएंगे।
* **WebChrome** **client**, एक Chrome ब्राउज़र है।
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 सुरक्षित है।
