<summary><strong>जानें AWS हैकिंग को शून्य से हीरो तक</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>के साथ!</strong></summary>
* अगर आप अपनी **कंपनी का विज्ञापन HackTricks में देखना चाहते हैं** या **HackTricks को PDF में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह।
**प्रत्येक एप्लिकेशन को एक विशिष्ट उपयोगकर्ता आईडी सौंपी जाती है**। यह एप्लिकेशन के स्थापना के दौरान किया जाता है ताकि **एप्लिकेशन केवल अपने उपयोगकर्ता आईडी या साझा** फ़ाइलों के स्वामित्व वाले फ़ाइलों के साथ बातचीत कर सके। इसलिए, केवल एप्लिकेशन खुद, ओएस के कुछ घटक और रूट उपयोगकर्ता ही एप्लिकेशन के डेटा तक पहुंच सकते हैं।
**दो एप्लिकेशन को समान UID का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है**। यह सूचना साझा करने के लिए उपयोगी हो सकता है, लेकिन अगर इनमें से कोई भी संक्रमित हो जाता है तो दोनों एप्लिकेशनों के डेटा संक्रमित हो जाएगा। इसलिए यह व्यवहार **असलाह** है।\
**एंड्रॉयड एप्लिकेशन सैंडबॉक्स** हर एप्लिकेशन को एक अलग प्रक्रिया के रूप में एक अलग उपयोगकर्ता आईडी के तहत चलाने की अनुमति देता है। प्रत्येक प्रक्रिया का अपना वर्चुअल मशीन होता है, इसलिए एक ऐप का कोड अन्य ऐप्स से अलग चलता है।\
एंड्रॉयड 5.0(L) से **SELinux** लागू है। मूल रूप से, SELinux ने सभी प्रक्रिया अंतराक्रियाओं को इनकार किया और फिर उनके बीच केवल उम्मीद की जाने वाली अंतराक्रियाओं को **अनुमति देने के नीतियाँ बनाईं।**
जब आप **एक ऐप स्थापित करते हैं और यह अनुमतियाँ मांगता है**, तो ऐप वह अनुमतियाँ मांग रहा है जो **AndroidManifest.xml** फ़ाइल में **`uses-permission`** तत्वों में कॉन्फ़िगर की गई हैं। **uses-permission** तत्व अनुमति का नाम निर्दिष्ट करता है जो **नाम****विशेषता में अनुमति के लिए पूछता है।** इसमें **maxSdkVersion** विशेषता भी होती है जो उच्च संस्करणों पर अनुमतियाँ मांगना बंद कर देती है।\
ध्यान दें कि एंड्रॉयड एप्लिकेशनों को शुरू में सभी अनुमतियाँ मांगने की आवश्यकता नहीं है, वे डायनेमिक रूप से भी **अनुमतियाँ मांग सकते हैं** लेकिन सभी अनुमतियाँ **मैनिफ़ेस्ट में घोषित** होनी चाहिए।
* **सामान्य**: जब किसी **एप्लिकेशन के लिए कोई ज्ञात खतरे नहीं** होते हैं। उपयोगकर्ता को **इसे स्वीकृत करने की आवश्यकता नहीं होती** है।
* **खतरनाक**: यह अनुमति अनुरोध करने वाले एप्लिकेशन को कुछ **उच्च पहुंच** प्रदान करती है। **उपयोगकर्ताओं से इन्हें स्वीकृत करने का अनुरोध किया जाता है**।
* **हस्ताक्षर**: केवल **उन ऐप्स को ही अनुमति दी जा सकती है जिन्होंने** उन ऐप्लिकेशन के साथ समान प्रमाणपत्र द्वारा हस्ताक्षरित किया है जैसा कि निर्यात करने वाला एक है। यह सबसे मजबूत स्तर की सुरक्षा है।
* **SignatureOrSystem**: केवल **उन ऐप्स को ही अनुमति दी जा सकती है जिन्होंने** उन ऐप्लिकेशन के साथ समान प्रमाणपत्र द्वारा हस्ताक्षरित किया है या **सिस्टम स्तर की पहुंच** के साथ चल रहे ऐप्स को।
ये एप्लिकेशन आम तौर पर **`/system/app`** या **`/system/priv-app`** निर्देशिकाओं में पाए जाते हैं और कुछ समय तक वे **अनुकूलित** होते हैं (आप `classes.dex` फ़ाइल भी नहीं मिल सकती है)। इन एप्लिकेशनों की जांच करना महत्वपूर्ण है क्योंकि कभी-कभी वे **बहुत सारी अनुमतियों के साथ चल रहे होते हैं** (जैसे रूट के रूप में)।
एक फिजिकल एंड्रॉयड उपकरण में रूट एक्सेस प्राप्त करने के लिए आम तौर पर आपको 1 या 2 **वंशानुक्रमों का शोधन करना होता है** जो आम तौर पर उपकरण और संस्करण के लिए **विशेष** होते हैं।\\
एंड्रॉइड विकास में, **जावा या कोटलिन** का उपयोग ऐप्स बनाने के लिए किया जाता है। डेस्कटॉप ऐप्स की तरह JVM का उपयोग न करके, एंड्रॉइड इस कोड को **डलविक एग्जीक्यूटेबल (DEX) बाइटकोड** में कंपाइल करता है। पहले, डलविक वर्चुअल मशीन इस बाइटकोड को हैंडल करती थी, लेकिन अब, नए एंड्रॉइड संस्करणों में एंड्रॉइड रनटाइम (ART) इसे संभालता है।
पुनर्मुहानी के लिए, **स्माली** महत्वपूर्ण हो जाता है। यह DEX बाइटकोड का मानव-पठनीय संस्करण है, स्रोत कोड को बाइटकोड निर्देशों में अनुवाद करके एसेम्बली भाषा की तरह काम करता है। स्माली और बैकस्माली इस संदर्भ में एसेम्बली और डिसेम्बली उपकरणों को संदर्भित करते हैं।
इंटेंट्स एंड्रॉइड ऐप्स के घटकों के बीच या अन्य ऐप्स के साथ संवाद करने का मुख्य साधन हैं। ये संदेश वस्तुएं डेटा भी ले सकती हैं, जैसे कि GET/POST अनुरोध HTTP संचार में उपयोग किया जाता है।
इसलिए एक इंटेंट बुनियादी रूप से **घटकों के बीच पारित संदेश** है। इंटेंट्स **निर्दिष्ट घटकों या ऐप्स के लिए निर्दिष्ट प्राप्तकर्ता के बिना भेजे जा सकते हैं**।\
**इंटेंट फ़िल्टर्स** परिभाषित करते हैं **कि एक एक्टिविटी, सेवा, या ब्रॉडकास्ट रिसीवर विभिन्न प्रकार के इंटेंट्स के साथ कैसे बातचीत कर सकते हैं**। मुख्य रूप से, वे इन घटकों की क्षमताओं का वर्णन करते हैं, जैसे कि वे कौन-कौन से क्रियाएँ कर सकते हैं या वे किस प्रकार के ब्रॉडकास्ट्स को प्रसंस्कृत कर सकते हैं। इन फ़िल्टर्स को प्रमुख रूप से **AndroidManifest.xml फ़ाइल** में घोषित किया जाता है, हालांकि ब्रॉडकास्ट रिसीवर्स के लिए, इन्हें कोडिंग करना भी एक विकल्प है।
इंटेंट फ़िल्टर्स श्रेणियों, क्रियाएँ, और डेटा फ़िल्टर्स से मिलकर बने होते हैं, और अतिरिक्त मेटाडेटा शामिल करने की संभावना होती है। यह सेटअप घटकों को विशेष इंटेंट्स को संभालने की अनुमति देता है जो घोषित मानदंडों से मेल खाते हैं।
एंड्रॉइड के घटकों (एक्टिविटी/सेवा/कंटेंट प्रोवाइडर/ब्रॉडकास्ट रिसीवर) का एक महत्वपूर्ण पहलू उनकी दृश्यता या **सार्वजनिक स्थिति** है। यदि कोई घटक सार्वजनिक माना जाता है और अन्य ऐप्स के साथ बातचीत कर सकता है अगर इसे मेनिफेस्ट में **`exported`** के साथ **`true`** मान दिया गया है या अगर इसके लिए एक इंटेंट फ़िल्टर घोषित किया गया है। हालांकि, डेवलपर्स के लिए इन घटकों को अनजाने में अन्य ऐप्स के साथ बातचीत न करने के लिए स्पष्ट रूप से रखने का एक तरीका है। इसे उनके मेनिफेस्ट परिभाषाओं में **`exported`** विशेषता को **`false`** में सेट करके प्राप्त किया जाता है।
इसके अतिरिक्त, डेवलपर्स को इन घटकों तक पहुंच को और भी सुरक्षित बनाने का विकल्प है। **`permission`** विशेषता को सेट करने से केवल उन ऐप्स को पहुंच मिल सकती है जिनके पास निर्धारित अनुमति है, जो एक अतिरिक्त सुरक्षा और नियंत्रण की एक अतिरिक्त परत जोड़ता है कि कौन इससे बातचीत कर सकता है।
**क्रिया** पहले घोषित intent की **ACTION\_SEND** है और **अतिरिक्त** एक mailto **Uri** है (अतिरिक्त जो intent की अतिरिक्त जानकारी की अपेक्षा कर रहा है)।
"Intent resolution" प्रक्रिया तय करती है कि प्रत्येक संदेश को कौन सा ऐप प्राप्त करना चाहिए। यह प्रक्रिया **प्राथमिकता विशेषता** को ध्यान में रखती है, जो **intent-filter घोषणा** में सेट किया जा सकता है, और **जिसकी प्राथमिकता अधिक होगी, वह चयनित किया जाएगा**। यह प्राथमिकता -1000 से 1000 के बीच सेट की जा सकती है और ऐप्लिकेशन `SYSTEM_HIGH_PRIORITY` मान का उपयोग कर सकते हैं। यदि **संघर्ष** उत्पन्न होता है, तो "चयनकर्ता" विंडो दिखाई देती है ताकि **उपयोगकर्ता निर्णय** कर सके।
ये अन्य एप्लिकेशनों को **आपकी एप्लिकेशन की पहचान और अनुमतियों का उपयोग करके कार्रवाई करने की अनुमति देते हैं**। Pending Intent बनाते समय **एक इंटेंट और करने के लिए कार्रवाई को निर्दिष्ट करना चाहिए**। यदि **निर्धारित इंटेंट स्पष्ट नहीं** है (जो इंटेंट को कौन कॉल कर सकता है यह निर्धारित नहीं करता), तो **किसी दुरुपयोगी एप्लिकेशन को पीड़ित एप्लिकेशन के नाम पर घोषित कार्रवाई करने की अनुमति हो सकती है**। इसके अतिरिक्त, **यदि कोई कार्रवाई निर्दिष्ट नहीं है**, तो दुरुपयोगी एप्लिकेशन को **पीड़ित के नाम पर कोई भी कार्रवाई करने की अनुमति होगी**।
पिछले इंटेंट के विपरीत, जो केवल एक एप्लिकेशन द्वारा प्राप्त किए जाते हैं, ब्रॉडकास्ट इंटेंट **कई एप्लिकेशनों द्वारा प्राप्त किए जा सकते हैं**। हालांकि, API संस्करण 14 से, यह **संदेश प्राप्त करने वाला ऐप स्पष्ट करना संभव है** उपयोग करके Intent.set Package करना।
ब्रॉडकास्ट के **दो प्रकार** होते हैं: **सामान्य** (असमंजस) और **क्रमबद्ध** (समंजस)। **क्रम** प्राप्तकर्ता तत्व के भीतर विन्यासित प्राथमिकता पर आधारित है। **प्रत्येक एप्लिकेशन ब्रॉडकास्ट को प्रसंस्करण, पुनर्प्रेषण या छोड़ सकता है**।
एक **ब्रॉडकास्ट भेजना** संबंधित फ़ंक्शन `sendBroadcast(intent, receiverPermission)` का उपयोग करके `Context` वर्ग से किया जा सकता है।\
आप **`LocalBroadCastManager`** से **`sendBroadcast`** फ़ंक्शन का उपयोग कर सकते हैं जिससे **संदेश कभी भी ऐप नहीं छोड़ता**। इसका उपयोग करके आपको एक प्राप्तकर्ता घटक को निर्यात करने की आवश्यकता नहीं होगी।
यदि आप "sticky" शब्द वाले फ़ंक्शन जैसे **`sendStickyBroadcast`** या **`sendStickyBroadcastAsUser`** पाते हैं, **उनका प्रभाव जांचें और उन्हें हटाने की कोशिश करें**।
Android एप्लिकेशन में, **गहरे संवाद** का उपयोग URL के माध्यम से सीधे कार्रवाई (इंटेंट) प्रारंभ करने के लिए किया जाता है। इसे एक विशेष **URL योजना** की घोषणा करके एक गतिविधि के भीतर किया जाता है। जब एक Android उपकरण इस योजना के साथ एक URL तक पहुंचने की कोशिश करता है, तो एप्लिकेशन के भीतर निर्धारित गतिविधि लॉन्च की जाती है।
**एंड्रॉइड इंटरफेस परिभाषा भाषा (AIDL)** का उद्देश्य एंड्रॉइड एप्लिकेशन में क्लाइंट और सर्विस के बीच संचार को सुविधाजनक बनाना है इंटरप्रोसेस संचार (IPC) के माध्यम से। एंड्रॉइड पर दूसरे प्रक्रिया की मेमोरी तक सीधे पहुंचने की अनुमति नहीं है, इसलिए AIDL ऑब्जेक्ट्स को ऑपरेटिंग सिस्टम द्वारा समझे जाने वाले एक फॉर्मेट में मार्शल करके प्रक्रियाओं के बीच संचार को सुविधाजनक बनाता है।
* **बाउंड सेवाएं**: ये सेवाएं IPC के लिए AIDL का उपयोग करती हैं, जिससे गतिविधियों या घटकों को सेवा से जोड़ने, अनुरोध करने और प्रतिक्रिया प्राप्त करने की सुविधा होती है। सेवा की कक्षा में `onBind` विधि संवेदनशीलता समीक्षा के लिए महत्वपूर्ण है, जिसे सुरक्षा की दृष्टि से खोजने के लिए महत्वपूर्ण क्षेत्र माना जाता है।
* **मेसेंजर**: एक बाउंड सेवा के रूप में काम करते हुए, मेसेंजर IPC को सुविधाजनक बनाता है जिसका मुख्य ध्यान डेटा को `onBind` विधि के माध्यम से प्रसंस्करण करने पर होता है। इस विधि को किसी भी असुरक्षित डेटा हैंडलिंग या संवेदनशील फ़ंक्शनों के निष्पादन के लिए ध्यान से जांचना महत्वपूर्ण है।
* **बाइंडर**: AIDL की अवस्थान के कारण बाइंडर क्लास का सीधा उपयोग कम होता है, लेकिन बाइंडर का उपयोग अलग-अलग प्रक्रियाओं की मेमोरी स्थानों के बीच डेटा स्थानांतरण सुविधा प्रदान करने वाले कर्नेल स्तर के ड्राइवर के रूप में करता है। अधिक समझने के लिए, एक संसाधन उपलब्ध है [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8)।
एंड्रॉइड ऐप्स में, **गतिविधाएँ** स्क्रीनों की तरह होती हैं, जो ऐप के उपयोगकर्ता इंटरफ़ेस के विभिन्न हिस्से दिखाती हैं। एक ऐप में कई गतिविधाएँ हो सकती हैं, प्रत्येक एक उपयोगकर्ता को एक अद्वितीय स्क्रीन प्रस्तुत करती है।
**लॉन्चर गतिविधा** एक ऐप का मुख्य द्वार होती है, जिसे आप ऐप के प्रतीक पर टैप करते हैं तो लॉन्च होती है। इसे ऐप के मैनिफ़ेस्ट फ़ाइल में विशिष्ट MAIN और LAUNCHER इंटेंट्स के साथ परिभाषित किया जाता है:
एक्टिविटी को "निर्यात" के रूप में चिह्नित करके अन्य ऐप्स या प्रक्रियाओं के लिए उपलब्ध किया जा सकता है। इस सेटिंग से अन्य ऐप्स को इस एक्टिविटी को शुरू करने की अनुमति होती है:
हालांकि, एक एक्टिविटी को दूसरे ऐप से एक्सेस करना हमेशा एक सुरक्षा जोखिम नहीं है। चिंता उत्पन्न होती है अगर संवेदनशील डेटा गलत तरीके से साझा किया जा रहा है, जिससे सूचना लीक हो सकती है।
Android विकास में, एक ऐप को [एप्लिकेशन](https://developer.android.com/reference/android/app/Application) क्लास का एक **सबक्लास** बनाने का विकल्प होता है, हालांकि यह अनिवार्य नहीं है। जब ऐसा सबक्लास परिभाषित किया जाता है, तो यह ऐप के भीतर पहली क्लास बन जाता है। यदि इस सबक्लास में **`attachBaseContext`** मेथड को लागू किया गया है, तो यह **`onCreate`** मेथड से पहले निष्पादित होता है। यह सेटअप अन्य एप्लिकेशन शुरू होने से पहले पहले प्रारंभिकीकरण की अनुमति देता है।
[सेवाएं](https://developer.android.com/guide/components/services) **पिछली प्रयोगकर्ता इंटरफ़ेस के बिना कार्यों को क्रियान्वित करने की क्षमता रखने वाले पृष्ठभूमि कार्यकर्ता** हैं। ये कार्य चाहे उपयोगकर्ता विभिन्न एप्लिकेशनों में स्विच कर दें, तो भी चलते रह सकते हैं, जिससे सेवाएं **लंबे समय तक चलने वाले कार्यों** के लिए महत्वपूर्ण होती हैं।
सेवाएं विविध हैं; इन्हें विभिन्न तरीकों से प्रारंभ किया जा सकता है, **इंटेंट्स** इन्हें लॉन्च करने के लिए मुख्य तरीका होते हैं जैसे कि एक एप्लिकेशन का प्रवेश बिंदु। जब एक सेवा `startService` विधि का उपयोग करके शुरू की जाती है, तो उसकी `onStart` विधि क्रियाशील हो जाती है और `stopService` विधि को स्पष्ट रूप से बुलाया जाने तक चलती रहती है। अल्टरनेटिवली, यदि किसी सेवा की भूमिका एक सक्रिय क्लाइंट कनेक्शन पर निर्भर है, तो `bindService` विधि का उपयोग सेवा को क्लाइंट से जोड़ने के लिए किया जाता है, डेटा पासेज के लिए `onBind` विधि को सक्रिय करता है।
सेवाओं का एक दिलचस्प उपयोग बैकग्राउंड संगीत प्लेबैक या नेटवर्क डेटा प्राप्ति जैसे कार्यों के लिए बिना एप्लिकेशन के उपयोगकर्ता के बातचीत को बाधित किए बिना किया जा सकता है। इसके अतिरिक्त, सेवाएं अन्य प्रक्रियाओं के लिए उपलब्ध कराई जा सकती हैं जो उसी उपकरण पर होती हैं। यह डिफ़ॉल्ट व्यवहार नहीं है और एंड्रॉइड मैनिफ़ेस्ट फ़ाइल में स्पष्ट रूप से कॉन्फ़िगरेशन की आवश्यकता होती है:
**ब्रॉडकास्ट रिसीवर** मैसेजिंग सिस्टम में सुनने वाले के रूप में काम करते हैं, जो कई एप्लिकेशनों को सिस्टम से एक ही संदेश का जवाब देने की अनुमति देते हैं। एक एप्लिकेशन **दो मुख्य तरीकों** से रिसीवर को **रजिस्टर** कर सकता है: एप्लिकेशन के **मैनिफेस्ट** के माध्यम से या एप्लिकेशन के कोड के भीतर **डायनामिक रूप से** एपीआई के माध्यम से **`registerReceiver`**। मैनिफेस्ट में, ब्रॉडकास्ट को अनुमतियों के साथ फ़िल्टर किया जाता है, जबकि डायनामिक रूप से रजिस्टर किए गए रिसीवर भी पंजीकरण के समय अनुमतियाँ निर्दिष्ट कर सकते हैं।
**इंटेंट फ़िल्टर** दोनों पंजीकरण विधियों में महत्वपूर्ण हैं, जो रिसीवर को कौन से ब्रॉडकास्ट को ट्रिगर करें यह निर्धारित करते हैं। एक मिलती जुलती ब्रॉडकास्ट भेजी जाती है, तो रिसीवर का **`onReceive`** मेथड चालू हो जाता है, जिससे एप्लिकेशन उसके अनुसार प्रतिक्रिया दे सकती है, जैसे किसी कम बैटरी अलर्ट के प्रतिक्रिया में व्यवहार समायोजित करना।
ब्रॉडकास्ट या तो **असिंक्रोनस** हो सकते हैं, जो सभी रिसीवर्स तय विन्यास के बिना पहुंच जाते हैं, या **सिंक्रोनस**, जहां रिसीवर्स को सेट की गई प्राथमिकताओं के आधार पर ब्रॉडकास्ट मिलती है। हालांकि, किसी भी एप्लिकेशन को ब्रॉडकास्ट को अंतर्गत करने के लिए अपने आप को प्राथमिकता देने की संभावना को ध्यान में रखना जरूरी है।
रिसीवर की कार्यक्षमता को समझने के लिए, उसकी कक्षा में **`onReceive`** मेथड खोजें। इस मेथड का कोड प्राप्त इंटेंट को संशोधित कर सकता है, रिसीवर्स द्वारा डेटा मान्यता की आवश्यकता को हाइलाइट करता है, विशेषकर **ऑर्डर्ड ब्रॉडकास्ट्स** में, जो इंटेंट को संशोधित या छोड़ सकते हैं।
**कंटेंट प्रोवाइडर्स** एप्लिकेशनों के बीच **संरचित डेटा साझा करने** के लिए महत्वपूर्ण हैं, डेटा सुरक्षा सुनिश्चित करने के लिए **अनुमतियों** को लागू करने की महत्वपूर्णता को जोर देते हैं। वे एप्लिकेशनों को विभिन्न स्रोतों से डेटा तक पहुंचने की अनुमति देते हैं, जैसे डेटाबेस, फ़ाइलसिस्टम, या वेब से। विशेष अनुमतियाँ, जैसे **`readPermission`** और **`writePermission`**, पहुंच को नियंत्रित करने के लिए महत्वपूर्ण हैं। इसके अतिरिक्त, अस्थायी पहुंच को एप्लिकेशन के मैनिफेस्ट में **`grantUriPermission`** सेटिंग्स के माध्यम से प्रदान किया जा सकता है, जिसमें `path`, `pathPrefix`, और `pathPattern` जैसे विस्तृत पहुंच नियंत्रण के लिए गुणों का उपयोग किया जा सकता है।
इनपुट मान्यता महत्वपूर्ण है ताकि सुरक्षा दोषों, जैसे एसक्यूएल इंजेक्शन, को रोकने में मदद मिले। कंटेंट प्रोवाइडर्स मूल ऑपरेशन्स का समर्थन करते हैं: `insert()`, `update()`, `delete()`, और `query()`, डेटा संशोधन और एप्लिकेशनों के बीच साझा करने की सुविधा प्रदान करते हैं।
**FileProvider**, एक विशेष रूप से डेटा सुरक्षित रूप से साझा करने पर ध्यान केंद्रित करने वाला कंटेंट प्रोवाइडर, एप्लिकेशन के मैनिफेस्ट में परिभाषित है। इसमें फ़ोल्डर तक पहुंच को नियंत्रित करने के लिए विशेष गुणों के साथ परिभाषित किया जाता है, जिन्हें `android:exported` और `android:resource` द्वारा फ़ोल्डर कॉन्फ़िगरेशन को संकेतित करने के लिए उपयोग किया जाता है। संवेदनशील डेटा को अनजाने में उजागर करने से बचने के लिए डायरेक्टरी साझा करते समय सावधानी बरतने की सलाह दी जाती है।
WebViews are like **mini web browsers** inside Android apps, pulling content either from the web or from local files. They face similar risks as regular browsers, yet there are ways to **reduce these risks** through specific **settings**.
For loading content, methods such as `loadUrl`, `loadData`, and `loadDataWithBaseURL` are available. It's crucial to ensure these URLs or files are **safe to use**. Security settings can be managed via the `WebSettings` class. For instance, disabling JavaScript with `setJavaScriptEnabled(false)` can prevent XSS attacks.
The JavaScript "Bridge" lets Java objects interact with JavaScript, requiring methods to be marked with `@JavascriptInterface` for security from Android 4.2 onwards.
Allowing content access (`setAllowContentAccess(true)`) lets WebViews reach Content Providers, which could be a risk unless the content URLs are verified as secure.
* Disabling file access (`setAllowFileAccess(false)`) limits access to the filesystem, with exceptions for certain assets, ensuring they're only used for non-sensitive content.
* **Digital signing** is a must for Android apps, ensuring they're **authentically authored** before installation. This process uses a certificate for app identification and must be verified by the device's package manager upon installation. Apps can be **self-signed or certified by an external CA**, safeguarding against unauthorized access and ensuring the app remains untampered during its delivery to the device.
* Starting from **Android 4.2**, a feature called **Verify Apps** allows users to have apps checked for safety before installation. This **verification process** can warn users against potentially harmful apps, or even prevent the installation of particularly malicious ones, enhancing user security.
* **MDM solutions** provide **oversight and security** for mobile devices through **Device Administration API**. They necessitate the installation of an Android app to manage and secure mobile devices effectively. Key functions include **enforcing password policies**, **mandating storage encryption**, and **permitting remote data wipe**, ensuring comprehensive control and security over mobile devices.
<summary><strong>जीरो से हीरो तक AWS हैकिंग सीखें</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* अगर आप अपनी **कंपनी का विज्ञापन हैकट्रिक्स में देखना चाहते हैं** या **हैकट्रिक्स को पीडीएफ में डाउनलोड करना चाहते हैं** तो [**सब्सक्रिप्शन प्लान्स देखें**](https://github.com/sponsors/carlospolop)!
* [**आधिकारिक PEASS और HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
* हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) कलेक्शन, [**द पीएस फैमिली**](https://opensea.io/collection/the-peass-family) खोजें
