mobile-webviewlisted

# Mobile WebView abuse ## When it applies The app shows web content in a WebView (Android `WebView` / iOS `WKWebView`) and either exposes a native JS bridge or loads URLs/content an attacker can influence (deep link, param, MITM'd http). ## Why it works WebViews blur the web/native boundary. A JS bridge (`addJavascriptInterface` / `WKScriptMessageHandler`) lets page JavaScript call native code — so XSS or a malicious loaded page can invoke native functionality. Misconfig (`setAllowFileAccess`, `setJavaScriptEnabled`, mixed content) widens it to local file theft. ## Method 1. **Find the WebView config** in `jadx`/class-dump: `setJavaScriptEnabled(true)`, `addJavascriptInterface(obj,"name")` (Android <17 = any method exposed), `setAllowFileAccess`, `setAllowUniversalAccessFromFileURLs`, and what URLs it loads. 2. **Reach the WebView with your content**: via a deep link that passes a URL param into `loadUrl`, a param reflected into the page (XSS), or MITM if it loads `http://` (ATS/cleartext). 3. **Abuse the bridge**: from injected JS call the exposed native methods (`window.name.method(...)`) — read files, get device data, trigger actions the bridge exposes. 4. **File/scheme access**: `file://` loads + universal file access → read app-private files; `content://` tricks. ## Gotchas - `addJavascriptInterface` on old targetSdk exposes reflection → RCE-ish; on modern it's limited to `@JavascriptInterface` methods — enumerate those. - Impact = what the bridge exposes