8 Oktober 2026 / 3 Minuten Lesedauer
Mobile Anwendungen enthielten durchschnittlich 6,5 Schwachstellen pro Projekt. In 39 Projekten identifizierten wir 254 Funde. Dabei handelte es sich überwiegend um Schwachstellen mit mittlerem Schweregrad, die die Client-Anwendung selbst betrafen, einschließlich APK-/AAB-Paketen unter Android und IPA-Paketen unter iOS. Am häufigsten finden wir fest eingebettete Zugangsdaten und API-Schlüssel. Hinzu kommen unverschlüsselt auf dem Gerät gespeicherte sensible Daten und schwache clientseitige Sicherheitsmechanismen. Diese Probleme stehen auch am Anfang der aktualisierten OWASP Mobile Top 10, die erstmals seit 2016 vollständig überarbeitet wurde und Improper Credential Usage sowie Inadequate Supply Chain Security auf den vorderen Plätzen aufführt.
Betrachten wir eine typische Situation. Ihre Mobile-Banking-App möchte Sie wiedererkennen, damit Sie sich nicht bei jedem Öffnen erneut anmelden müssen. Deshalb speichert sie nach der Anmeldung ein Zugriffstoken direkt auf dem Gerät. Wird dieses unverschlüsselt und außerhalb des geschützten Android Keystore oder der iOS Keychain gespeichert, bleibt es lesbar. Dafür genügt bereits ein verlorenes Smartphone, die Übergabe des Geräts an einen Reparaturdienst, Schadsoftware auf einem gerooteten Gerät oder ein unverschlüsseltes Backup. Das Token wird offengelegt und ermöglicht einem Angreifer den Zugriff auf das Konto – ohne Passwort und ohne biometrische Authentifizierung. Das ist Improper Credential Usage: Zugangsdaten, die durch den Systemtresor geschützt werden sollten, liegen frei im lokalen Speicher der Anwendung.
Das zweite Risiko entsteht überhaupt nicht in Ihrem eigenen Code. Dieselbe Banking-App enthält Dutzende Bibliotheken von Drittanbietern, von Analyse-SDKs bis hin zu Zahlungskomponenten. Wird auch nur eine davon zum Ziel eines Lieferkettenangriffs, beispielsweise durch ein manipuliertes Update, kann ein Angreifer eindringen, ohne einen einzigen Ihrer eigenen Sicherheitsmechanismen überwinden zu müssen. Das ist Inadequate Supply Chain Security: Sie übernehmen die Schwachstellen jeder Komponente, die Sie in die Anwendung integrieren.
Das dritte Risiko zeigt sich bei einer anderen Funktion derselben Anwendung. Bei einer geteilten Zahlung scannen Sie einen QR-Code, aus dem die Anwendung die Angaben zum Empfänger und zum Betrag ausliest. Ein QR-Code ist jedoch lediglich ein Datenträger, in den ein Angreifer praktisch beliebige Inhalte einfügen kann. Wenn die Anwendung diese Inhalte nicht konsequent prüft und sie statt gewöhnlicher Zahlungsdaten direkt an ihre interne Logik übergibt, beispielsweise an eine WebView mit Zugriff auf native Funktionen, kann sich ein manipulierter QR-Code von einer Zahlungsanweisung in ausführbaren Code verwandeln. Ab diesem Zeitpunkt handelt nicht mehr der Benutzer, sondern der Angreifer: Er kann in Ihrem Namen einen vorgegebenen Betrag überweisen oder ein Zugriffstoken aus der Anwendung extrahieren und das Konto übernehmen. Das ist Insufficient Input/Output Validation: Die Anwendung vertraut einer Eingabe, die sie zuerst hätte überprüfen müssen.
Wenn Ihr Unternehmen eine mobile Anwendung entwickelt, ist die auf den Geräten Ihrer Benutzer installierte App Teil Ihrer Angriffsfläche. Testen Sie daher nicht nur die Backend-Dienste, sondern auch die Anwendung, die Ihre Kunden tatsächlich verwenden.
Alle Neuigkeiten
Bitte melden Sie sich für unseren Newsletter an, um alle wichtigen Neuigkeiten zu Cybersicherheit und ethischem Hacking zu erhalten.