OWASP Mobile Top 10: Was es ist, Schwachstellenliste und wie man es anwendet

Was ist OWASP Mobile Top 10?

OWASP Mobile Top 10 ist eine standardisierte Liste der kritischsten Sicherheitsrisiken, die für mobile Anwendungen spezifisch sind. Im Gegensatz zum allgemeinen OWASP Top 10 für Webanwendungen berücksichtigt die mobile Version die Besonderheiten der Plattformen: lokale Speicherung auf dem Gerät, Interaktion mit Sensoren, Offline-Modi und Besonderheiten der App-Stores. Das Dokument wird seit 2010 veröffentlicht und alle 2–4 Jahre überarbeitet: Die aktuelle Version für 2024 enthält Kategorien wie M1 — Improper Credential Usage und M8 — Security Misconfiguration. Das Projekt wird von einer Community mit mehr als 500 Freiwilligen weltweit unterstützt.

Geschichte und Zweck

Ursprünglich deckte OWASP Top 10 nur Webanwendungen ab, aber das Wachstum der mobilen Entwicklung in den 2010er Jahren erforderte ein separates Dokument. Die erste Version von Mobile Top 10 wurde 2011 veröffentlicht und enthielt nur 7 Punkte. Bis 2024 erweiterte sich die Liste auf 10 Kategorien, die jeweils mehrere spezifische Angriffsszenarien enthalten. Der Hauptzweck des Dokuments ist es, Entwicklern und Sicherheitsteams eine gemeinsame Sprache zur Diskussion von Risiken und Prioritätensetzung von Korrekturen zu geben. Regelmäßige Aktualisierungen der Liste spiegeln Veränderungen in der Bedrohungslandschaft wider: das Auftauchen neuer APIs, die Entwicklung von Betriebssystemen (Android, iOS) und neue Angriffstechniken, die in Berichten von Positive Technologies und anderen Forschungszentren beschrieben werden.

Wie die OWASP Mobile Top 10 Liste erstellt wird

Die Methodik zur Zusammenstellung von Mobile Top 10 basiert auf Daten aus realen Projekten: Ergebnisse von Penetrationstests mobiler Anwendungen, Vorfallsberichte und Schwachstellenforschung werden analysiert. Jede Kategorie wird nach zwei Parametern bewertet: Häufigkeit (Incidence Rate) und technische Auswirkung (Technical Impact). Die Kombination dieser Metriken bildet die endgültige Rangliste. Im Gegensatz zu subjektiven Listen verwendet OWASP offene Daten: Jedes Community-Mitglied kann über das GitHub-Repository des Projekts einen Antrag auf Aufnahme einer neuen Kategorie stellen. Für die aktuelle Version 2024 wurden mehr als 300.000 Sicherheitstests aus 25 Ländern verarbeitet, was die Statistiken repräsentativ für das globale mobile Entwicklungssystem macht. Darüber hinaus veröffentlicht OWASP MASVS (Mobile Application Security Verification Standard) — eine Reihe detaillierter Sicherheitsanforderungen, die mehr als 80 spezifische Prüfungen in 8 Kategorien umfasst. MASVS wird als Grundlage für die Anwendungszertifizierung und als Checkliste für Penetrationstests verwendet: Jede Anforderung hat einen Verweis auf eine Kategorie aus Mobile Top 10, was die Rückverfolgbarkeit zwischen dem Standard und der Risikoliste gewährleistet.

Überblick über die wichtigsten Schwachstellen der Top 10

Betrachten wir die drei kritischsten Kategorien aus OWASP Mobile Top 10 2024, die mehr als 70% aller Sicherheitsvorfälle in mobilen Projekten abdecken. Jede Kategorie enthält spezifische Ausnutzungsszenarien und Schutzempfehlungen.

Unsachgemäße Plattformnutzung

Diese Kategorie (M1) deckt Situationen ab, in denen Entwickler APIs und Plattformmechanismen unsachgemäß verwenden. Typische Beispiele: Intent Injection auf Android, offene Deep-Link-Handler auf iOS, falsche Handhabung von Keychain und SharedPreferences. Ein Angreifer kann einen speziell präparierten Intent senden und Zugriff auf Daten einer anderen Anwendung oder Komponente erhalten. Laut NowSecure-Bericht (2023) enthielten 22% der getesteten Android-Anwendungen Schwachstellen vom Typ Intent Redirection. Schutz umfasst: strenge Eingabevalidierung, Überprüfung der Intent-Quelle und Verwendung von Berechtigungen für exportierte Komponenten.

Unsicheres Datenspeicher

Unsicheres Datenspeicher (M2) ist das häufigste Problem in mobilen Anwendungen. Es tritt auf, wenn vertrauliche Daten (Zugriffstoken, Passwörter, personenbezogene Daten) im Klartext oder mit unzureichendem Schutz gespeichert werden. Typische Schwachstellenquellen: SQLite-Datenbanken ohne Verschlüsselung, SharedPreferences ohne EncryptedSharedPreferences, Datenprotokollierung im Debug-Modus. Laut OWASP Foundation (2024) speichern mehr als 60% der kostenlosen Anwendungen bei Google Play mindestens eine Art vertraulicher Daten unverschlüsselt. Die Lösung ist die Verwendung von Android EncryptedSharedPreferences, iOS Keychain und die Verschlüsselung von Daten vor dem Schreiben in den lokalen Speicher.

Unsichere Kommunikation

Kategorie M3 — Unsichere Kommunikation — umfasst Schwachstellen in den Datenübertragungskanälen zwischen App und Server. Fehlendes HTTPS, falsche SSL-Zertifikatsvalidierung, Verwendung veralteter TLS 1.0/1.1-Protokolle — all diese Probleme ermöglichen es einem Angreifer, Datenverkehr durch Man-in-the-Middle-Angriffe abzufangen. Besonders gefährlich ist die Situation, wenn die Anwendung mit sensiblen Daten (Banktransaktionen, medizinische Informationen) über einen ungeschützten Kanal arbeitet. Im Jahr 2023 fanden Forscher der NCC Group heraus, dass 12% der beliebten Finanzanwendungen eine falsche TLS-Konfiguration verwenden. Empfehlung: zwingende Verwendung von HTTPS mit Certificate Pinning und Ablehnung von HTTP in Produktions-Builds.

So testen Sie Anwendungen nach OWASP Mobile Top 10

Sicherheitstests einer mobilen Anwendung nach der OWASP-Methodik umfassen mehrere Phasen: statische Codeanalyse (SAST), dynamische Analyse (DAST) und manuelle Tests (Penetrationstest). Jede Phase zielt darauf ab, bestimmte Schwachstellenkategorien aus Mobile Top 10 zu identifizieren.

Testwerkzeuge

Für die automatisierte Analyse empfiehlt OWASP die Verwendung von MobSF (Mobile Security Framework) — einem Open-Source-Tool. MobSF führt eine statische Analyse von Quellcode und Binärdateien durch, überprüft die Manifestkonfiguration, analysiert Berechtigungen und identifiziert Schwachstellen aus Mobile Top 10. Für die dynamische Analyse werden Burp Suite (Proxy zur Verkehrsabfang) und Frida (Laufzeitanalyse-Tool) verwendet. Die Kombination dieser Tools deckt mehr als 80% der Kategorien der Liste ab. Regelmäßige Tests in einer CI/CD-Pipeline mit MobSF ermöglichen die Identifizierung von Schwachstellen in frühen Entwicklungsphasen und reduzieren die Kosten für deren Behebung um 60–70%. Die Integration von SAST- und DAST-Tools in die Pipeline sollte über Gradle/Maven-Plugins oder Fastlane-Schritte in iOS-Builds automatisiert werden.

Interpretation des MobSF-Berichts

Nach dem Ausführen von MobSF erhält der Entwickler einen Bericht mit Farbindikatoren: Rot — kritische Schwachstelle, Orange — mittleres Risiko, Gelb — geringes Risiko. Jede Warnung enthält einen Verweis auf die entsprechende OWASP Mobile Top 10-Kategorie, eine Problembeschreibung und eine Korrekturmpfehlung. Es ist wichtig, nicht nur rote Warnungen zu beseitigen, sondern auch orangefarbene zu analysieren: Viele von ihnen (z. B. exportierte Aktivitäten ohne Schutz) können sich kombinieren und einem Angreifer einen Angriffsvektor bieten. Es wird empfohlen, vor jeder Veröffentlichung null rote Warnungen und nicht mehr als 2–3 orangefarbene zu erreichen. Der MobSF-Bericht enthält auch eine Analyse der Anwendungsberechtigungen: Jede übermäßige Berechtigung (z. B. Kamerazugriff in einem Taschenrechner) wird als Verstoß gegen das Prinzip der geringsten Privilegien markiert und sollte aus dem Manifest entfernt werden. Für iOS-Anwendungen führt MobSF eine ähnliche Analyse von .ipa-Dateien durch, einschließlich der Überprüfung von Info.plist auf ATS-Ausnahmen und der Analyse von Mach-O-Binärdateien auf unsichere APIs wie NSAllowsArbitraryLoads.

class InsecureStorage {
    private val prefs = context.getSharedPreferences("my_app", Context.MODE_PRIVATE)

    fun saveToken(token: String) {
        prefs.edit().putString("auth_token", token).apply()
    }

    fun getToken(): String? {
        return prefs.getString("auth_token", null)
    }
}

class SecureStorage(context: Context) {
    private val masterKey = MasterKey.Builder(context)
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build()

    private val securePrefs = EncryptedSharedPreferences.create(
        context,
        "secure_prefs",
        masterKey,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun saveToken(token: String) {
        securePrefs.edit().putString("auth_token", token).apply()
    }
}