Die Pentest-Checkliste für mobile Apps: OWASP MASVS in der Praxis

Geben Sie mir eine APK und fünf Minuten, und ich reiche Ihnen in der Regel etwas zurück, das die Entwickler nie ausliefern wollten. Entpacken, durch jadx jagen, den dekompilierten Quellcode nach password, secret oder api_key durchsuchen und zusehen, wie die Treffer durchlaufen. Hier ein fest eingebautes Token. Dort ein Staging-Hostname, der immer noch antwortet. Ein TODO aus einem Sprint, an den sich niemand mehr erinnert.

Genau dort beginnen viele Mobile-App-Penetrationstests, und öfter als es sein sollte, stammt daher auch der erste echte Fund. Der Client läuft auf Hardware, die Ihnen nicht gehört. Ein Angreifer kann das Binary auf seiner eigenen Werkbank zerlegen, in seinem eigenen Tempo, ohne Rate Limiting und ohne dass jemand zusieht. Web-App-Instinkte überleben den Kontakt mit dieser Realität nicht.

Wir verankern jedes Projekt im OWASP Mobile Application Security Verification Standard, MASVS, und machen daraus eine Checkliste, die wir gegen echte Android- und iOS-Builds durchgehen. So läuft das in der Praxis ab.

Die wichtigsten Erkenntnisse

• Mobile-App-Penetrationstests kombinieren die statische Analyse des dekompilierten Binaries mit der dynamischen Analyse einer laufenden, instrumentierten App, denn der Client liegt vollständig in der Hand des Angreifers.
• OWASP MASVS gliedert die Kontrollen in Speicherung, Kryptografie, Authentifizierung, Netzwerk, Plattform-Interaktion, Codequalität und Resilienz; das OWASP MASTG liefert Ihnen zu jeder davon konkrete Testfälle.
• Die schwerwiegenden Funde, die wir am häufigsten melden, sind unsichere lokale Datenspeicherung, falsch eingesetzte Kryptografie und Autorisierungsfehler im Backend, die sichtbar werden, sobald man Certificate Pinning aushebelt.
• Certificate Pinning bremst einen Tester aus. Sicher macht es eine App nicht. Wenn der Server dem Client vertraut, legt das Umgehen des Pins nur die echten Schwachstellen darunter frei.
• MASVS definiert Prüfstufen (L1 als Basis, L2 für Defense-in-Depth, R für Resilienz), also richten Sie den Prüfumfang am tatsächlichen Risiko der App aus, statt alles gleich tief zu testen.

Was ist MASVS, und warum einen Mobile-Pentest darauf aufbauen?

MASVS ist OWASPs Antwort auf eine einfache Frage: Was sollte eine sichere mobile App eigentlich leisten? Es ist das Rückgrat jedes ernsthaften Mobile-App-Penetrationstests. Die Anforderungen sind in Kontrollgruppen aufgeteilt – Speicherung (MASVS-STORAGE), Kryptografie (MASVS-CRYPTO), Authentifizierung und Sitzungsverwaltung (MASVS-AUTH), Netzwerkkommunikation (MASVS-NETWORK), Plattform-Interaktion (MASVS-PLATFORM), Codequalität (MASVS-CODE) und Resilienz gegen Reverse Engineering (MASVS-RESILIENCE).

Der zugehörige OWASP Mobile Application Security Testing Guide (MASTG) ist der Teil, in dem sich der Standard bezahlt macht. MASVS sagt, die App “sollte sensible Daten nicht unverschlüsselt speichern”. MASTG sagt Ihnen, welche Dateien Sie ziehen müssen, welche APIs Daten preisgeben und wie Sie das belegen. Wir nutzen MASVS als Abdeckungskarte, damit nichts übersehen wird, und MASTG als Anleitung für jede einzelne Kontrolle.

Eines sei klar gesagt: Eine Checkliste ist ein Fundament, keine Obergrenze. Wir gehen die MASVS-Kategorien durch, um die Abdeckung zu garantieren, und verbringen den Rest des Projekts damit, der app-spezifischen Logik nachzugehen, die kein Standard vorhersagen könnte. Die spannenden Schwachstellen stecken fast immer in der Geschäftslogik und im Backend, nicht in der Frage, ob die App ein generisches Kästchen abhakt.

Wie testet man eine mobile App? Statisch plus dynamisch

Jeder Auftrag besteht aus zwei Durchläufen über dasselbe Ziel: die App im Ruhezustand und die App, während sie läuft. Lassen Sie einen davon aus, und Ihnen entgeht die Hälfte des Bildes.

Statische Analyse: das Binary lesen

Unter Android dekompilieren wir zuerst. apktool liefert Ihnen das Manifest und die Ressourcen; jadx verwandelt den DEX zurück in lesbares Java. Unter iOS arbeiten Sie mit einer entschlüsselten IPA, Class-Dumps und der Info.plist. Der Sinn des statischen Durchlaufs ist, die App zu verstehen, bevor man sie ausführt, und Dinge zu erwischen, die im Datenverkehr nie auftauchen.

Ein typischer Auftakt unter Android:

apktool d target.apk -o target_src
jadx -d target_out target.apk

# hunt for obvious secrets and dangerous config
grep -rniE "api[_-]?key|secret|password|token|BEGIN RSA" target_out/
grep -rn "usesCleartextTraffic" target_src/AndroidManifest.xml

Dann lesen wir das AndroidManifest nach exportierten Komponenten: Activities, Services, Broadcast Receiver und Content Provider, die mit android:exported="true" ohne Berechtigungsschutz markiert sind. Eine exportierte Activity, die einen Intent entgegennimmt und eine URL in eine WebView lädt, ist ein klassischer Weg zu Task Hijacking oder WebView-Injection. Unter iOS lautet die entsprechende Suche: benutzerdefinierte URL-Schemata und Universal Links, die im plist deklariert sind, denn auch das sind für Angreifer erreichbare Einstiegspunkte.

Auch die Netzwerkkonfiguration ist hier wichtig. usesCleartextTraffic="true" oder eine permissive network_security_config.xml, die vom Nutzer hinzugefügten CAs vertraut, verrät Ihnen schon vor dem Öffnen eines Proxys, dass Klartext oder Interception im Spiel sein können.

Dynamische Analyse: ausführen und beobachten

Die dynamische Analyse braucht ein gerootetes Android-Gerät oder ein jailbroken iPhone, oder deren Emulator-Pendants. Unsere Standard-Instrumentierung ist Frida mit Objection obendrauf. Frida hookt Methoden zur Laufzeit, gibt Argumente aus und schreibt Rückgabewerte um. Objection liefert uns schnelle Erfolge – Keychain-Einträge auflisten, SharedPreferences auslesen, gängige Pin-Prüfungen deaktivieren – ohne für jede einzelne einen Hook von Hand zu schreiben.

Wir leiten den gesamten Datenverkehr über Burp Suite. Sobald die App mit ihrem Backend spricht, endet die mobil-spezifische Arbeit weitgehend und es beginnt klassisches API-Testing: Autorisierungsprüfungen, IDOR auf Objektbezeichnern, Mass Assignment, das Wiederholen der Requests eines anderen Nutzers. Einen sauberen Blick auf diesen Verkehr zu bekommen hat oberste Priorität, und genau deshalb ist Certificate Pinning für den Ablauf so entscheidend.

Was sind die häufigsten Funde bei Mobile-App-Pentests?

Dieselbe Handvoll Probleme taucht projektübergreifend immer wieder auf. Sie lassen sich sauber den MASVS-Kategorien zuordnen, ein guter Hinweis darauf, dass der Standard aus echtem Leidensdruck entstanden ist und nicht aus Theorie.

Unsichere Datenspeicherung (MASVS-STORAGE)

Das ist der Fund, den wir am häufigsten melden. Apps speichern weit mehr zwischen, als Entwicklern bewusst ist. Unter Android ziehen wir die Sandbox und arbeiten uns durch die SharedPreferences-XML, SQLite-Datenbanken und Dateien im internen Datenverzeichnis:

adb shell run-as com.example.app ls -la /data/data/com.example.app/
adb shell run-as com.example.app cat shared_prefs/*.xml

Session-Tokens. Vollständige Zugangsdaten. PII. Gelegentlich Zahlungsdaten, im Klartext in den SharedPreferences oder in einer unverschlüsselten SQLite-Tabelle. Unter iOS zeigt sich dieselbe Fehlerklasse in NSUserDefaults, plist-Dateien, Core-Data-Stores und Keychain-Einträgen, die mit einer schwachen Accessibility-Klasse wie kSecAttrAccessibleAlways gespeichert sind. Alles, was auf einem verlorenen oder mit Malware infizierten Gerät lesbar ist, ist ein echtes Risiko, und es entspricht CWE-312, Klartextspeicherung sensibler Informationen.

Schwache oder falsch eingesetzte Kryptografie (MASVS-CRYPTO)

Bei der Krypto-Kategorie geht es selten um gebrochene Mathematik. Es geht um Missbrauch. Fest eingebaute Schlüssel, direkt aus dem dekompilierten Quellcode gezogen. ECB-Modus, bei dem sich wiederholende Klartextblöcke Struktur im Chiffretext preisgeben – diese Wahl eines gebrochenen Algorithmus ist CWE-327. Statische oder null-IVs. Selbstgebaute “Verschlüsselung”, die sich als Base64 mit ein paar Extraschritten entpuppt, und Base64 ist Kodierung, kein Schutz.

Frida eignet sich perfekt, um das live zu bestätigen. Hooken Sie das Cipher-Setup und geben Sie Schlüssel und IV aus, während die App läuft:

Java.perform(function () {
  var Cipher = Java.use("javax.crypto.Cipher");
  Cipher.init.overload("int", "java.security.Key").implementation = function (mode, key) {
    console.log("[cipher] alg=" + this.getAlgorithm() +
                " key=" + Java.use("android.util.Base64").encodeToString(key.getEncoded(), 0));
    return this.init(mode, key);
  };
});

Wenn der Schlüssel, der Ihre Daten “schützt”, beim App-Start auf der Konsole erscheint, ist die Diskussion über theoretische Stärke beendet.

Autorisierungs- und Sitzungsfehler im Backend (MASVS-AUTH)

Sobald der Datenverkehr sichtbar ist, trägt der Server das Vertrauen, und genau dort verstecken sich die schwerwiegenden Schwachstellen. Tokens, die nie ablaufen. Vorhersagbare Session-Identifikatoren. Autorisierungsentscheidungen, die client-seitig statt server-seitig getroffen werden. Wenn die App einen Admin-Button versteckt, die API den Admin-Aufruf aber bereitwillig aus einem normalen Konto beantwortet, ist das eine kritische Schwachstelle, und keine noch so gute Client-Härtung behebt das.

Wie umgeht man Certificate Pinning?

Sie umgehen Pinning, indem Sie den Code hooken, der die Pin-Prüfung durchführt, und ihn zum Bestehen zwingen – meist mit Frida oder Objection -, sodass Ihrer Proxy-CA wieder vertraut wird. Objection bringt dafür einen Einzeiler mit:

objection -g com.example.app explore
# then, in the Objection prompt:
android sslpinning disable

Bei Apps mit einer eigenen Pinning-Implementierung oder Prüfungen im nativen Code scheitert der generische Bypass, und Sie greifen zu einem gezielten Frida-Skript, das den konkreten TrustManager, den OkHttp CertificatePinner oder den nativen SSL_CTX_set_custom_verify-Pfad hookt. Unter iOS hooken Sie meist TrustKit oder die eigene Trust-Evaluierungslogik der App rund um SecTrustEvaluate.

Jetzt der meinungsstarke Teil. Pinning ist eine Bremsschwelle, keine Schutzmaßnahme. Es erhöht die Kosten für einen Gelegenheitsangreifer und verschafft Zeit gegen automatisierte Werkzeuge, was durchaus nützlich und die Umsetzung wert ist. Aber wenn das Aushebeln des Pins eine API mit kaputter Autorisierung freilegt, war das Pinning nur Kosmetik. Wir testen jede App so, als wäre das Pinning bereits ausgehebelt, denn ein motivierter Angreifer mit dem Binary und einem gerooteten Gerät wird es aushebeln. MASVS ordnet Pinning genau aus diesem Grund der Resilienz zu: Es ist Defense-in-Depth, kein Ersatz für ein Backend, das seine eigenen Regeln durchsetzt.

Wie behebt man diese Probleme?

Vor allem, indem man die Plattform respektiert. Nutzen Sie den vom Betriebssystem bereitgestellten sicheren Speicher, statt selbst etwas zu bauen: Android Keystore und EncryptedSharedPreferences über Jetpack Security sowie die iOS-Keychain mit einer sinnvollen Accessibility-Klasse wie kSecAttrAccessibleWhenUnlockedThisDeviceOnly. Parken Sie langlebige Geheimnisse niemals in den SharedPreferences oder in NSUserDefaults.

Greifen Sie bei Kryptografie zu geprüften High-Level-Bibliotheken statt zu rohen Cipher-Aufrufen. Googles Tink ist eine gute Standardwahl, weil sie die sichere Option zur einfachen macht. Liefern Sie keine Schlüssel innerhalb der App aus; leiten Sie sie zur Laufzeit ab oder stellen Sie sie dann bereit und belassen Sie die eigentlichen Vertrauensentscheidungen auf dem Server. Behandeln Sie den Client durchgängig als nicht vertrauenswürdig – jede relevante Autorisierungs- und Validierungsprüfung muss server-seitig erzwungen werden, denn der mobile Client kann und wird manipuliert. Fügen Sie Pinning und Anti-Tampering als zusätzliche Schichten hinzu, sobald die Grundlagen stimmen, nicht vorher.

Wie CyberXplore unterstützt

Unser Service für Penetrationstests mobiler Anwendungen führt die hier beschriebene, vollständig auf MASVS abgebildete Methodik gegen Ihre Android- und iOS-Builds aus: statische Analyse des dekompilierten Binaries, dynamische Analyse auf instrumentierten Geräten, Pinning-Bypass und einen genauen Blick auf die Backend-APIs, auf die sich die App stützt. Sie erhalten einen Bericht, der die Funde nach tatsächlichem Geschäftsrisiko einordnet, mit Reproduktionsschritten, denen ein Entwickler folgen kann, und einem Retest, sobald die Fixes stehen, damit der Fix belegt und nicht nur behauptet ist. Bereiten Sie sich auf ein App-Store-Review, einen Sicherheitsfragebogen eines Kunden oder ein Compliance-Audit vor? Wir richten das Projekt an der passenden MASVS-Prüfstufe aus. Fordern Sie ein Angebot an und erzählen Sie uns von Ihrer App; wir schätzen den Umfang ehrlich ein.

FAQ

Wie lange dauert ein Penetrationstest einer mobilen App?

Eine fokussierte App auf einer Plattform bedeutet in der Regel ein bis zwei Wochen Testarbeit, abhängig von der Anzahl der Funktionen, der Größe der API-Oberfläche und davon, ob sowohl Android als auch iOS im Scope sind. Apps mit umfangreicher Backend-Logik dauern länger, weil die meisten der schwerwiegenden Funde in der server-seitigen Autorisierung stecken, und genau dorthin fließen die Stunden, sobald der Datenverkehr sichtbar ist.

Braucht man den Quellcode, um eine mobile App zu testen?

Nein. Wir kommen im Black-Box-Modus allein mit der kompilierten APK oder IPA gut zurecht, da Dekompilierung ohnehin zum Job gehört. Allerdings findet ein Gray-Box-Test, bei dem Sie Quellcode und Testkonten bereitstellen, mehr und findet es schneller, weil wir die Teststunden in echte Schwachstellen statt in Reverse Engineering stecken. Wir empfehlen Gray-Box für das beste Preis-Leistungs-Verhältnis.

Was ist der Unterschied zwischen MASVS und MASTG?

MASVS ist der Standard: Er definiert die Sicherheitsanforderungen, die eine mobile App erfüllen sollte, gruppiert in Kategorien und Prüfstufen. MASTG ist der Testleitfaden: Er gibt Testern konkrete Techniken, den Einsatz von Werkzeugen und Testfälle an die Hand, um jede Anforderung zu überprüfen. In der Praxis nutzen wir MASVS als Abdeckungs-Checkliste und MASTG als Handbuch für das Vorgehen.

Macht Certificate Pinning meine App sicher?

Nein. Pinning ist eine Resilienz-Maßnahme, die Interception und automatisierte Angriffe verlangsamt, was durchaus sinnvoll ist, aber ein entschlossener Tester mit einem gerooteten Gerät umgeht es. Gegen unsichere lokale Speicherung, schwache Kryptografie oder kaputte Backend-Autorisierung richtet es nichts aus. Betrachten Sie es als eine Schicht auf einer App, die auch ohne es schon sicher ist.

Wie oft sollten wir eine mobile App pentesten?

Mindestens jährlich und nach jeder wesentlichen Änderung wie einem neuen Authentifizierungsablauf, einer Zahlungsfunktion oder einer größeren Backend-Integration. Mobile Apps erscheinen in schneller Folge, und jedes Release kann alte Probleme wieder einführen oder neue Angriffsfläche schaffen, sodass ein Test zu einem Zeitpunkt nur etwas über den getesteten Build aussagt. Viele Teams kombinieren einen jährlichen Volltest mit leichteren Retests bei größeren Releases.