Trucchetti

Categoria OWASP: MASVS-PLATFORM: Platform Interaction

Panoramica

Il tapjacking è l'equivalente per le app per Android della vulnerabilità web clickjacking: un'app dannosa induce l'utente a fare clic su un controllo pertinente alla sicurezza (pulsante di conferma e così via) oscurando la UI con una sovrapposizione o con altri mezzi. In questa pagina, distinguiamo due varianti di attacco: occlusione totale e parziale. Nell'occlusione completa, l'aggressore sovrappone l'area di tocco, mentre nell'occlusione parziale, l'area di tocco rimane visibile.

Impatto

Gli attacchi di tapjacking vengono utilizzati per indurre gli utenti a eseguire determinate azioni. L'impatto dipende dall'azione presa di mira dall'autore dell'attacco.

Rischio: copertura completa

In caso di occlusione completa, l'autore dell'attacco sovrappone l'area di tocco per intercettare l'evento touch:

Immagine di copertura completa

Mitigazioni

L'occlusione completa viene impedita impostando View.setFilterTouchesWhenObscured(true) nel codice. In questo modo, i tocchi passati da una sovrapposizione vengono bloccati. Se preferisci un approccio dichiarativo, puoi anche aggiungere android:filterTouchesWhenObscured="true" nel file di layout per l'oggetto View che vuoi proteggere.

Rischio: occlusione parziale

Negli attacchi di occlusione parziale, l'area di tocco rimane scoperta:

Immagine di occlusione parziale

Mitigazioni

Puoi ridurre l'occlusione parziale ignorando manualmente gli eventi tocco che hanno il flag FLAG_WINDOW_IS_PARTIALLY_OBSCURED. Non sono previste protezioni predefinite contro questo scenario.

Android 16 e accessibilityDataSensitive:a partire da Android 16 (livello API 16) e versioni successive, gli sviluppatori possono utilizzare il flag accessibilityDataSensitive per proteggere ulteriormente i dati sensibili da servizi di accessibilità dannosi che non sono strumenti di accessibilità legittimi. Quando questo flag è impostato su visualizzazioni sensibili (ad es. schermate di accesso, schermate di conferma delle transazioni), impedisce alle app con autorizzazione di accessibilità di leggere o interagire con i dati sensibili a meno che non siano dichiarate come isA11yTool=true nel file manifest. In questo modo viene fornita una protezione più efficace a livello di sistema contro gli attacchi di intercettazione e iniezione di clic caratteristici degli scenari di occlusione parziale. Gli sviluppatori possono spesso attivare implicitamente accessibilityDataSensitive specificando android:filterTouchesWhenObscured="true" nei file di layout.

Rischi specifici

Questa sezione raccoglie i rischi che richiedono strategie di mitigazione non standard o che sono stati mitigati a un determinato livello di SDK e sono qui per completezza.

Rischio: android.Manifest.permission.SYSTEM_ALERT_WINDOW

L'autorizzazione SYSTEM_ALERT_WINDOW consente a un'app di creare una finestra visualizzata sopra tutte le app.

Mitigazioni

Le versioni più recenti di Android hanno introdotto diverse mitigazioni, tra cui:

  • Su Android 6 (livello API 23) e versioni successive, gli utenti devono concedere esplicitamente l'autorizzazione all'app per creare una finestra di overlay.
  • Su Android 12 (livello API 31) e versioni successive, le app possono passare true in Window.setHideOverlayWindows().

Rischio: toast personalizzato

Un malintenzionato può utilizzare Toast.setView() per personalizzare l'aspetto di un messaggio toast. Su Android 10 (livello API 29) e versioni precedenti, le app dannose potevano avviare questi avvisi dal background.

Mitigazioni

Se un'app ha come target Android 11 (livello API 30) o versioni successive, il sistema blocca i toast personalizzati in background. Tuttavia, questa mitigazione può essere elusa in alcune circostanze utilizzando Toast burst, in cui l'autore dell'attacco mette in coda più toast in primo piano e questi continuano a essere lanciati anche dopo che un'app passa in background.

I toast in background e gli attacchi di tipo toast burst vengono mitigati completamente a partire da Android 12 (livello API 31).

Rischio: sandwich di attività

Se un'app dannosa riesce a convincere un utente ad aprirla, può comunque avviare un'attività dall'app vittima e successivamente sovrapporla alla propria attività, formando un sandwich di attività e creando un attacco di occlusione parziale.

Mitigazioni

Consulta le mitigazioni generali per l'occlusione parziale. Per una difesa approfondita, assicurati di non esportare attività che non devono essere esportate per impedire a un malintenzionato di inserirle.

Risorse