apk-interceptor

Helper per la valutazione di deeplink Android, Intent e bridge WebView

apk-interceptor è un APK di test Android portabile per valutazioni di sicurezza applicativa autorizzate. Aiuta gli ingegneri della sicurezza a verificare come un'app Android gestisce i punti di ingresso esterni, come scheme URI personalizzati, deeplink, Activity esportate e bridge JavaScript WebView.

Lo strumento è volutamente limitato:

• Non dichiara android.permission.INTERNET
• Non invia dati a server esterni
• Non esegue comandi shell
• Non richiede root, Magisk, Frida o instrumentazione a runtime
• Serve un solo file payload locale content://
• Registra un unico scheme URI personalizzato fissato in fase di build

Motivazione

Durante le valutazioni di sicurezza di applicazioni Android, molti risultati dell'analisi statica necessitano ancora di una piccola prova di concetto sul dispositivo prima di poter essere confermati: registrare uno scheme URI personalizzato, inviare un Intent esplicito, servire un payload content:// locale o verificare se JavaScript può raggiungere un bridge WebView.

Creare una nuova app di test usa-e-getta per ogni caso è ripetitivo e soggetto a errori. Piccole differenze nelle voci del manifest, nelle authority, nelle grant URI, nei nomi dei pacchetti o nella costruzione degli Intent possono rallentare la verifica e rendere i risultati più difficili da riprodurre.

apk-interceptor è stato creato per rendere ripetibile questa fase di conferma. Invece di scrivere un nuovo APK PoC per ogni valutazione, costruisci questo strumento con lo scheme autorizzato o l'application ID di cui hai bisogno, esegui il test sul dispositivo e mantieni il flusso di lavoro volutamente limitato: nessun permesso INTERNET, nessuna trasmissione di dati esterni, nessuna esecuzione shell e nessuna dipendenza da root.

Cosa Puoi Testare

apk-interceptor è utile per queste attività di valutazione:

Approfondimenti dettagliati sulle vulnerabilità:

• Hijacking di scheme URI personalizzati
• Open Redirect tramite deeplink
• Activity esportata con dati Intent non attendibili
• Esposizione del bridge JavaScript WebView tramite content://

L'app mantiene un log di valutazione in memoria per Intent inviati, deeplink ricevuti, callback del bridge, risultati JavaScript ed errori. I log scompaiono quando il processo dell'app viene terminato. Poiché i log non vengono persistiti, acquisisci le evidenze con screenshot o registrazione dello schermo mentre lavori.

Come si Confronta

apk-interceptor è uno strumento di conferma, non un framework di scoperta o exploitation. Presuppone che tu sappia già cosa testare (scheme, classe Activity, nome del bridge) dall'analisi statica e offre un modo sicuro, sul dispositivo, per verificare la raggiungibilità e acquisire evidenze. È pensato per essere installato su un dispositivo di valutazione e persino condiviso con un cliente, quindi non include permesso INTERNET, nessuna esecuzione shell, nessuna esfiltrazione di dati e nessun requisito di root.

Dove si colloca rispetto ai soliti strumenti Android:

Le due aree in cui apk-interceptor ha il vantaggio più chiaro rispetto alle alternative:

• Evidenza di scheme hijack: agisce come la seconda app che registra effettivamente lo scheme e registra ogni parametro ricevuto, cosa che adb/l'analisi statica non possono mostrare.
• Verifica del bridge WebView tramite content://: un provider non esportato, a file singolo, il cui payload viene consegnato solo tramite una grant di lettura Intent temporanea, più una WebView di auto-test locale per validare prima la sintassi del payload.

Invio vs Intercettazione

apk-interceptor tratta l'invio e l'intercettazione in modo diverso, e questa è la cosa più importante da capire prima di usarlo:

Per inviare un deeplink appositamente costruito all'app valutata, non è necessario ricompilare: usa la modalità Implicit Deeplink della scheda Sender e inserisci un qualsiasi URI.

Per intercettare un deeplink, cioè far sì che Android instradi uno scheme personalizzato verso apk-interceptor in modo da poter osservare un possibile scheme-hijack, devi compilare l'APK con quello scheme tramite --scheme. Lo scheme è fissato in fase di build deliberatamente (un guardrail di progettazione); apk-interceptor non registra mai scheme arbitrari a runtime. Se cambi lo scheme che stai valutando, ricompila e reinstalla.

Requisiti

• Android Studio con Android SDK 35
• Dispositivo o emulatore Android 12+
• JDK 17+
• adb per l'installazione sul dispositivo e test opzionali da riga di comando

Build e Installazione

Compila l'APK con lo scheme URI personalizzato che sei autorizzato a valutare:

./build-interceptor.sh --scheme <authorized_custom_scheme>
adb install ./out/apk-interceptor-<authorized_custom_scheme>-debug.apk

Flag di build opzionali:

./build-interceptor.sh \
  --scheme <authorized_custom_scheme> \
  --app-id <custom.application.id> \
  --output ./out

--app-id imposta l'application ID installato (l'identità del pacchetto sul dispositivo e l'autorità content://<applicationId>.payload) in fase di build. Il valore predefinito è com.sterrasec.apkinterceptor. Puoi sovrascriverlo con --app-id quando hai bisogno di più build installabili separatamente per valutazioni diverse. L'equivalente Windows è build-interceptor.bat.

Lo scheme predefinito intercept-poc-example è un segnaposto innocuo. Lo script di build rifiuta di produrre un APK di valutazione con questo scheme predefinito.

Primo Avvio

Al primo avvio per ogni versione dell'app, apk-interceptor mostra un dialogo di uso autorizzato. Dopo aver toccato Ho capito, la stessa versione non mostra più il dialogo. La scheda Sender mostra comunque un avviso persistente perché può inviare Intent ad altre app.

Schermate

Sender	Payload	Interceptor

Moduli dell'App

Interceptor

Usa questa scheda per verificare l'intercettazione di scheme URI personalizzati.

Cosa mostra:

• Lo scheme compilato in questo APK
• Un avviso se lo scheme predefinito fittizio è ancora in uso
• I log dei deeplink ricevuti
• Un campo per il parametro di test query
• Send Test Deeplink
• Clear

Flusso di lavoro base:

1. Compila l'APK con lo scheme personalizzato valutato.
2. Installalo insieme all'app valutata.
3. Attiva un deeplink per quello scheme dal flusso valutato, dal browser, da adb o dal pulsante integrato Send Test Deeplink.
4. Se Android instrada il link verso apk-interceptor, apri la scheda Interceptor e verifica l'URI ricevuto e i parametri query.

Informazioni su Send Test Deeplink: invia sempre <scheme>://test?<i tuoi parametri> con un host test fisso, quindi serve a confermare che apk-interceptor riceva e registri lo scheme, non a pilotare le rotte deeplink specifiche dell'app valutata. Per inviare un deeplink appositamente costruito che corrisponda all'host o al path richiesto dall'app valutata, usa invece la modalità Implicit Deeplink della scheda Sender.

Esempio adb:

adb shell am start -W \
  -a android.intent.action.VIEW \
  -d 'my-authorized-scheme://test?source=adb\&message=hello%20world'

Usa \& quando invii più parametri query tramite adb shell; altrimenti la shell del dispositivo potrebbe trattare & come separatore di comandi.

Risultato atteso:

• apk-interceptor si apre sulla scheda Interceptor
• Compare una voce di log RECEIVED
• Toccando la voce di log si espandono l'URI completo e l'elenco dei parametri

Sender

Usa questa scheda per inviare Intent controllati durante un test autorizzato.

Modalità:

• Implicit Deeplink: invia Intent(ACTION_VIEW, Uri.parse(uri))
• Explicit Activity: invia un Intent a un pacchetto e a una classe Activity specifici

Campi e controlli:

• URI per la modalità deeplink implicito
• Package name per la modalità Activity esplicita
• Activity class per la modalità Activity esplicita
• Attach content:// URI per impostare l'URI del payload locale come dati dell'Intent (mostrato solo in modalità Explicit Activity; vedi nota sotto)
• FLAG_GRANT_READ_URI_PERMISSION per concedere l'accesso in lettura all'URI del payload allegato
• Send Intent

Flusso di lavoro con deeplink implicito:

1. Seleziona Implicit Deeplink.
2. Inserisci un URI che corrisponda al pattern deeplink dell'app valutata.
3. Tocca Send Intent.
4. Osserva il comportamento dell'app valutata e il log di apk-interceptor.

Flusso di lavoro con Activity esplicita:

1. Conferma che l'Activity target sia esportata e coperta dalla tua autorizzazione.
2. Seleziona Explicit Activity.
3. Inserisci il nome del pacchetto dell'app valutata.
4. Inserisci il nome della classe dell'Activity esportata.
5. Facoltativamente, abilita Attach content:// URI.
6. Tocca Send Intent.

Note:

• apk-interceptor non sa se l'app valutata ha gestito l'Intent in modo sicuro. Devi osservare il comportamento, i log o l'harness di test dell'app valutata.
• L'allegato content:// è utile quando si verifica se un'Activity target passa dati Intent non attendibili a una WebView.
• Attach content:// URI è disponibile solo in modalità Explicit Activity. Il payload viene consegnato come data dell'Intent, il che sovrascriverebbe l'URI digitato in modalità Implicit Deeplink, quindi l'opzione è nascosta in quel caso.
• PayloadProvider non è esportato. L'app valutata può leggere il payload content:// allegato solo perché l'Intent le concede un accesso temporaneo in lettura tramite FLAG_GRANT_READ_URI_PERMISSION. Mantieni questo flag abilitato e consegna l'URI tramite l'Intent. Un URI content:// aperto in qualsiasi altro modo non sarà leggibile da un'altra app.

Payload

Usa questa scheda per creare un payload HTML locale e validare la sintassi del bridge JavaScript nella WebView di auto-test di apk-interceptor.

Cosa contiene:

• Editor HTML
• Editor JavaScript valutato dopo il caricamento della pagina
• Nome dell'oggetto bridge
• URI content:// generato
• Save Payload
• Run Self-Test
• WebView di auto-test
• Risultato del bridge e log console

Formato URI del payload generato:

content://<applicationId>.payload/current.html

Il provider serve solo questo file fisso:

filesDir/payloads/current.html

Flusso di lavoro di auto-test del payload:

1. Inserisci o incolla l'HTML nel campo HTML.
2. Inserisci il nome dell'oggetto bridge che vuoi testare localmente, ad esempio localBridge.
3. Aggiungi JavaScript all'interno dell'HTML o nell'editor JavaScript.
4. Tocca Save Payload.
5. Tocca Run Self-Test.
6. Controlla le voci BRIDGE_RESULT, console.log e evaluateJavascript result nel log.

Esempio di JavaScript per l'auto-test:

console.log("payload loaded");
window.localBridge.logResult(window.localBridge.getInfo());

Il bridge di auto-test espone:

window.<bridgeName>.logResult("message");
window.<bridgeName>.getInfo();

Limitazione importante:

La WebView di auto-test conferma che il payload locale e la sintassi delle chiamate al bridge funzionano all'interno di apk-interceptor. Non può osservare se la WebView di un'altra app ha eseguito il tuo payload o ha chiamato il proprio bridge. Per l'app valutata, verifica tramite l'interfaccia utente, i log, gli hook di test o Chrome DevTools se l'app è debuggable.

Flussi di Lavoro Orientati alle Vulnerabilità

1. Hijacking di Scheme URI Personalizzati

Rischio:

Un'app Android registra uno scheme URI personalizzato invece di un App Link verificato. Qualsiasi altra app può registrare lo stesso scheme, quindi Android potrebbe mostrare un selettore di app o instradare i link verso un'app diversa.

Usa apk-interceptor per verificare:

• Se lo scheme può essere registrato da un'altra app
• Se Android offre apk-interceptor come gestore
• Se nei parametri dei deeplink compaiono valori sensibili

Passaggi:

1. Identifica lo scheme personalizzato dell'app valutata dal manifest o dalla documentazione.
2. Compila apk-interceptor con quello scheme.
3. Installa apk-interceptor e l'app valutata sullo stesso dispositivo di test.
4. Attiva un deeplink dal flusso di test autorizzato.
5. Se apk-interceptor lo riceve, controlla il log della scheda Interceptor.

Evidenze da acquisire:

• Comportamento del selettore del sistema operativo, se mostrato
• URI completo ricevuto
• Parametri query e se contengono valori sensibili
• Interazione utente necessaria per instradare il link

2. Iniezione di Parametri nei Deeplink

Rischio:

L'app valutata si fida dei parametri dei deeplink per navigazione, caricamento di URL, feature flag, selezione dell'account o rendering senza una validazione sufficiente.

Usa apk-interceptor per verificare:

• Se i parametri appositamente costruiti vengono accettati
• Se l'app naviga verso una schermata non prevista
• Se vengono usati valori URL/path/contenuto non sicuri

Passaggi:

1. Identifica il formato dei deeplink dell'app valutata.
2. Apri Sender.
3. Seleziona Implicit Deeplink.
4. Inserisci un URI di test autorizzato con parametri controllati.
5. Tocca Send Intent.
6. Osserva il comportamento dell'app valutata.

Esempio segnaposto:

my-authorized-scheme://open?next=https%3A%2F%2Fauthorized-test.example%2Flanding

Non usare domini o account reali di terze parti a meno che non siano esplicitamente in scope.

3. Controllo degli Accessi delle Activity Esportate

Rischio:

Un'Activity esportata esegue azioni sensibili o mostra dati sensibili senza verificare il chiamante, lo stato dell'utente o l'autorizzazione richiesta.

Usa apk-interceptor per verificare:

• Se l'Activity esportata viene avviata da un'altra app
• Se esegue comportamenti sensibili senza i controlli previsti
• Se i dati dell'Intent ne modificano il comportamento

Passaggi:

1. Conferma che l'Activity sia esportata e in scope.
2. Apri Sender.
3. Seleziona Explicit Activity.
4. Inserisci il nome del pacchetto e la classe dell'Activity.
5. Facoltativamente, allega l'URI del payload content:// locale.
6. Tocca Send Intent.
7. Osserva se l'app valutata applica il controllo degli accessi.

Evidenze da acquisire:

• Activity avviata o bloccata
• Eventuale prompt di autenticazione o autorizzazione
• Esposizione di azioni o dati sensibili
• Dati Intent usati dall'Activity

4. Esposizione del Bridge JavaScript WebView Tramite content://

Rischio:

L'app valutata carica dati Intent content:// non attendibili in una WebView che espone anche un bridge JavaScript tramite addJavascriptInterface.

Usa apk-interceptor per verificare:

• Se un payload HTML locale può essere consegnato come content://
• Se la WebView target carica il payload
• Se il JavaScript proveniente da quella sorgente può raggiungere il bridge

Passaggi:

1. Identifica l'Activity target e il nome dell'oggetto bridge durante l'analisi autorizzata.
2. Apri Payload.
3. Crea HTML/JS che chiami il bridge previsto.
4. Usa Run Self-Test per validare la sintassi localmente.
5. Apri Sender.
6. Seleziona Explicit Activity.
7. Inserisci il pacchetto target e la classe dell'Activity.
8. Abilita Attach content:// URI e mantieni abilitato FLAG_GRANT_READ_URI_PERMISSION.
9. Tocca Send Intent.
10. Osserva l'app valutata per determinare se la sua WebView ha caricato il payload e se le chiamate al bridge sono state eseguite.

Limitazione importante:

apk-interceptor non può ricevere risultati da un'altra app a meno che quell'app non li restituisca o li mostri esplicitamente. Lo strumento è progettato per consegnare un payload locale e validare la sintassi, non per esfiltrare dati.

Controlli da Riga di Comando

Verifica che l'APK non richieda accesso alla rete:

aapt dump permissions ./out/apk-interceptor-<scheme>-debug.apk

Previsto: nessun android.permission.INTERNET.

Attiva un deeplink esplicitamente verso apk-interceptor:

adb shell am start -W \
  -n com.sterrasec.apkinterceptor/.InterceptActivity \
  -a android.intent.action.VIEW \
  -d 'my-authorized-scheme://test?source=adb'

Attiva un deeplink tramite il resolver di Android:

adb shell am start -W \
  -a android.intent.action.VIEW \
  -d 'my-authorized-scheme://test?source=adb'

Il comando esplicito conferma il comportamento di InterceptActivity. Il comando implicito conferma l'intent-filter del manifest e il comportamento del resolver.

Test

I test unitari vengono eseguiti sulla JVM con Robolectric, quindi non è richiesto un dispositivo o un emulatore. Coprono PayloadProvider, inclusi i controlli di whitelisting dei path e di traversal che impediscono al provider di servire qualsiasi cosa diversa dal singolo payload current.html.

./gradlew testDebugUnitTest

I risultati dei test vengono scritti in app/build/reports/tests/testDebugUnitTest/index.html. La stessa attività viene eseguita in CI a ogni push e pull request su main.

Guardrail di Progettazione

• Nessun android.permission.INTERNET
• Nessuna trasmissione di dati esterni o esfiltrazione automatica
• Nessuna funzionalità di esecuzione di comandi shell
• Nessuna dipendenza da root, Magisk, Frida o instrumentazione
• Nessuna registrazione a runtime di scheme arbitrari
• Nessun provider generico per la distribuzione di file
• Solo /current.html viene servito da PayloadProvider

Licenza

MIT