Tapjacking

OWASP-Kategorie:MASVS-PLATFORM: Platform Interaction

Übersicht

Tapjacking ist das Android-App-Äquivalent der Clickjacking-Websicherheitslücke: Eine schädliche App verleitet den Nutzer dazu, auf ein sicherheitsrelevantes Steuerelement (Bestätigungsschaltfläche usw.) zu klicken, indem sie die Benutzeroberfläche mit einem Overlay oder auf andere Weise verdeckt. Auf dieser Seite unterscheiden wir zwei Angriffsvarianten: vollständige und teilweise Verdeckung. Bei vollständiger Verdeckung wird der Touchbereich überlagert, bei teilweiser Verdeckung bleibt er frei.

Positiv beeinflussen

Bei Tapjacking-Angriffen werden Nutzer dazu verleitet, bestimmte Aktionen auszuführen. Die Auswirkungen hängen von der Aktion ab, die der Angreifer im Visier hat.

Risiko: Vollständige Verdeckung

Bei vollständiger Verdeckung überlagert der Angreifer den Touchbereich, um das Touch-Ereignis zu manipulieren:

Bild mit vollständiger Verdeckung

Abhilfemaßnahmen

Eine vollständige Verdeckung wird durch Festlegen von View.setFilterTouchesWhenObscured(true) im Code verhindert. Dadurch werden Berührungen blockiert, die über ein Overlay weitergeleitet werden. Wenn Sie einen deklarativen Ansatz bevorzugen, können Sie auch android:filterTouchesWhenObscured="true" in der Layoutdatei für das View-Objekt hinzufügen, das Sie schützen möchten.

Risiko: Teilweise Verdeckung

Bei Angriffen mit teilweiser Verdeckung bleibt der Touchbereich frei:

Bild mit teilweiser Verdeckung

Abhilfemaßnahmen

Sie können eine teilweise Verdeckung vermeiden, indem Sie Touch-Ereignisse mit dem Flag FLAG_WINDOW_IS_PARTIALLY_OBSCURED manuell ignorieren. Es gibt keinen Standardschutz gegen dieses Szenario.

Android 16 und accessibilityDataSensitive:Ab Android 16 (API-Level 16) und höher können Entwickler das Flag accessibilityDataSensitive verwenden, um sensible Daten vor schädlichen Bedienungshilfen zu schützen, die keine legitimen Bedienungshilfen sind. Wenn dieses Flag für vertrauliche Ansichten (z.B. Anmeldebildschirme, Bildschirme zur Bestätigung von Transaktionen) festgelegt ist, wird verhindert, dass Apps mit Barrierefreiheitsberechtigung die vertraulichen Daten lesen oder mit ihnen interagieren können, sofern sie in ihrem Manifest nicht als isA11yTool=true deklariert sind. Dies bietet einen robusteren Schutz auf Systemebene vor Abhör- und Click-Injection-Angriffen, die für Szenarien mit teilweiser Verdeckung charakteristisch sind. Entwickler können accessibilityDataSensitive oft implizit aktivieren, indem sie android:filterTouchesWhenObscured="true" in ihren Layoutdateien angeben.

Spezifische Risiken

In diesem Abschnitt werden Risiken zusammengefasst, für die nicht standardmäßige Maßnahmen erforderlich sind oder die auf einer bestimmten SDK-Ebene gemindert wurden und hier der Vollständigkeit halber aufgeführt sind.

Risiko: android.Manifest.permission.SYSTEM_ALERT_WINDOW

Mit der Berechtigung SYSTEM_ALERT_WINDOW kann eine App ein Fenster erstellen, das über allen Apps angezeigt wird.

Abhilfemaßnahmen

In neueren Android-Versionen wurden mehrere Maßnahmen eingeführt, darunter die folgenden:

  • Unter Android 6 (API-Level 23) und höher müssen Nutzer explizit die Berechtigung für die App erteilen, ein Overlay-Fenster zu erstellen.
  • Unter Android 12 (API‑Level 31) und höher können Apps true an Window.setHideOverlayWindows() übergeben.

Risiko: Benutzerdefinierter Toast

Ein Angreifer kann Toast.setView() verwenden, um das Erscheinungsbild einer Toast-Nachricht anzupassen. Unter Android 10 (API‑Level 29) und niedriger konnten schädliche Apps solche Pop‑up-Benachrichtigungen im Hintergrund starten.

Abhilfemaßnahmen

Wenn eine App auf Android 11 (API‑Level 30) oder höher ausgerichtet ist, blockiert das System benutzerdefinierte Hintergrund-Toasts. Diese Maßnahme kann jedoch unter Umständen durch Toast-Burst umgangen werden. Dabei reiht der Angreifer mehrere Toasts ein, während die App im Vordergrund ist. Diese werden dann auch nach dem Wechsel in den Hintergrund weiterhin gestartet.

Hintergrund-Toasts und Toast-Burst-Angriffe werden ab Android 12 (API-Level 31) vollständig abgemildert.

Risiko: Aktivitätssandwich

Wenn eine schädliche App einen Nutzer dazu bringt, sie zu öffnen, kann sie trotzdem eine Aktivität aus der Opfer-App starten und sie anschließend mit ihrer eigenen Aktivität überlagern. So entsteht ein Aktivitätssandwich und ein partieller Okklusionsangriff.

Abhilfemaßnahmen

Allgemeine Maßnahmen zur Behebung von Problemen mit teilweiser Verdeckung Achten Sie im Sinne einer umfassenden Sicherheitsstrategie darauf, dass Sie keine Aktivitäten exportieren, die nicht exportiert werden müssen, um zu verhindern, dass ein Angreifer sie abfängt.

Ressourcen