Ein sauberer Penetrationstestbericht bedeutet nicht, dass Ihre mobile App sicher ist. Er kann schlicht bedeuten, dass der Tester die API-Ebene nie verlassen hat. Wenn das Sicherheitsteam eines Unternehmenskunden oder ein Auditor einen Pentest der mobilen App angefordert hat und Sie einen Bericht aus API-Endpunkt-Scans übergeben haben, haben Sie das falsche Dokument übergeben, und das fällt spätestens auf Seite zwei auf.
Penetrationstests für mobile Apps sind eine Sicherheitsbewertung des App-Binaries selbst und des Geräts, auf dem es läuft, nicht der Server, mit denen es spricht. Ein qualifizierter Tester extrahiert die App, prüft, wie sie Daten lokal speichert, kontrolliert, ob Geheimnisse fest in den kompilierten Code eingebaut sind, fängt ihren Netzwerkverkehr ab und manipuliert ihn, und führt sie live auf einem Gerät mit Jailbreak oder Root aus, um zu sehen, welche Schutzmechanismen tatsächlich halten. Die API gehört ebenfalls dazu, aber sie ist die kleinere Hälfte der Arbeit.
Dieser Unterschied ist wichtig, weil die meisten Anbieter, die mit “mobilen Penetrationstests” werben, einen Webscanner gegen das Backend Ihrer App laufen lassen, das Ergebnis in ein PDF packen und die Sache damit für erledigt erklären. Es sieht gründlich aus. Es beantwortet keine einzige der Fragen, die ein auf Mobile spezialisierter Prüfer oder Ihr eigenes Sicherheitsteam tatsächlich stellen wird.
Worin unterscheiden sich mobile Penetrationstests von Web-Pentests?
Eine Webanwendung läuft auf einem Server, den Sie kontrollieren. Eine mobile App läuft auf dem Telefon eines Fremden, und dieses Telefon ist die eigene Hardware des Angreifers. Er kann es auf die Werkbank legen, die App dekompilieren, einen Debugger anhängen und sich so viel Zeit nehmen, wie er will. Niemand hat diese Art von physischem Zugriff auf Ihre Produktionsserver.
Diese eine Tatsache verändert, was der Test abdecken muss.
Wo der Angreifer arbeitet
Aus der Ferne, über das Netzwerk
Lokal, mit voller Kontrolle über Gerät und Binary
Primäre Angriffsfläche
Serverseitige Logik, Session-Handling, Eingabevalidierung
Client-Binary, lokale Speicherung, Schutzmechanismen des Betriebssystems, Transportschicht
Standardreferenz
OWASP Top 10
Typische Befunde
Injection, defekte Authentifizierung, Fehlkonfiguration
Unsichere lokale Speicherung, fest eingebaute Geheimnisse, fehlendes Pinning, per Reverse Engineering lesbare Logik
Testumgebung
Standardbrowser oder HTTP-Client
iOS-Gerät mit Jailbreak oder Android-Gerät mit Root, oft beide Plattformen
Kann automatisiertes Scannen das abdecken?
Teilweise
Nein. Statische und dynamische Werkzeuge markieren Kandidaten; ein Mensch muss das Binary zurückentwickeln und es live ausführen, um die Ausnutzbarkeit zu bestätigen
Für den Teil, in dem API und Serverseite ihren eigenen eigenständigen Durchgang bekommen, deckt unsere Checkliste für Penetrationstests von Webanwendungen dieses Feld sauber ab. Dieser Artikel bleibt beim Client, beim Gerät und beim Transport dazwischen, denn das ist die Fläche, die ein rein mobiles Projekt abdecken soll.
Was decken Penetrationstests für mobile Apps tatsächlich ab?
Jedes ernstzunehmende Projekt zu Sicherheit und Penetrationstests mobiler Apps arbeitet dieselbe zentrale Angriffsfläche ab, abgebildet auf OWASP MASVS und die OWASP Mobile Top 10. Hier ist, was ein Tester auf jeder Ebene tatsächlich tut, und was als Nachweis im Bericht landet.
Lokale Datenspeicherung
Angriffsweg: Ein Angreifer mit dem Gerät oder einer Kopie seines Backups zieht die Sandbox der App heraus und liest alles, was sie auf die Festplatte geschrieben hat: SQLite-Datenbanken, Plist- oder Shared-Preference-Dateien, zwischengespeicherte API-Antworten, Logdateien. Enthält irgendetwas davon Tokens, personenbezogene Daten oder Sitzungsdaten im Klartext, hat er sie, ohne einen einzigen Server anzufassen.
Was als Nachweis eingereicht wird: Eine Datei-für-Datei-Auflistung der lokalen Speicherung der App mit markierten unverschlüsselten Inhalten, Screenshots der lesbaren Daten direkt aus dem Dateisystem des Geräts, und ein Hinweis darauf, welche OWASP-MASVS-Speicheranforderung damit verletzt wird.
Fehlnutzung von Keychain und Keystore
Angriffsweg: iOS Keychain und Android Keystore existieren, damit Geheimnisse nicht in einfachen Dateien liegen, aber viele Apps nutzen sie falsch und speichern ein Token mit der falschen Zugriffsklasse oder Schutzstufe, sodass es nach einem Jailbreak oder auf einem Gerät ohne Sperrbildschirm lesbar ist. Der Angreifer fragt einfach das Betriebssystem nach dem Eintrag und bekommt ihn zurück.
Was als Nachweis eingereicht wird: Der konkrete Keychain- oder Keystore-Eintrag, die Zugriffs- beziehungsweise Schutzeinstellung, unter der er gespeichert wurde, und ein Proof of Concept der Extraktion, der den Wert im Klartext zeigt.
Fest eingebaute Geheimnisse im Binary
Angriffsweg: API-Schlüssel, Signaturgeheimnisse oder interne URLs werden direkt in die App kompiliert, statt zur Laufzeit abgerufen zu werden. Ein Tester dekompiliert das Binary (oder lässt einfach strings darüber laufen) und das Geheimnis liegt im Klartext bereit, um direkt gegen Ihr Backend wiederverwendet zu werden.
Was als Nachweis eingereicht wird: Der dekompilierte oder disassemblierte Ausschnitt, der das Geheimnis im Kontext zeigt, und eine Demonstration dessen, was dieses Geheimnis freischaltet: einen internen Endpunkt, den Schlüssel eines Drittanbieterdienstes, ein Signaturzertifikat.
Certificate Pinning und Abfangen von Datenverkehr
Angriffsweg: Ohne sauberes Pinning leitet ein Angreifer den Datenverkehr der App über einen Intercepting Proxy auf einem Gerät um, das er kontrolliert, liest jede Anfrage und jede Antwort und verändert sie im Flug, etwa einen Preis, eine Nutzer-ID oder ein Berechtigungsflag.
Was als Nachweis eingereicht wird: Ein vollständiger Mitschnitt von Anfragen und Antworten aus der Interception-Sitzung und, wenn Pinning vorhanden, aber umgehbar ist, die konkret eingesetzte Umgehungstechnik (Hooking-Framework, gepatchtes Binary) zusammen mit dem dadurch offengelegten Datenverkehr.
Umgehung der Jailbreak- und Root-Erkennung
Angriffsweg: Apps, die auf Jailbreak- oder Root-Status prüfen, verlassen sich oft auf eine Handvoll bekannter Kontrollen, Dateipfade, Systemaufrufe, Paketlisten, die ein Tester mit einem Standard-Hooking-Werkzeug in Minuten aushebelt. Ist das einmal umgangen, bedeutet jeder weitere Schutzmechanismus, der auf “diesem Gerät kann man vertrauen” aufbaut, nichts mehr.
Was als Nachweis eingereicht wird: Welche Erkennungsmethode im Einsatz war, die genaue dagegen verwendete Umgehung, und was nach dem Aushebeln der Prüfung erreichbar wurde (üblicherweise: alles oberhalb dieser Zeile).
Reverse Engineering und Repackaging
Angriffsweg: Ein Tester dekompiliert die App, um zu bewerten, wie viel ihrer Geschäftslogik, Lizenzprüfungen oder Anti-Tamper-Mechanismen offen und lesbar sind, packt dann eine veränderte Version neu (freigeschaltete Funktionen, entfernte Werbung, eingeschleuster Code) und prüft, ob sie sich wie das Original installieren und ausführen lässt.
Was als Nachweis eingereicht wird: Der dekompilierte Quellcode oder seine Zwischendarstellung, eine kommentierte Liste der wiederherstellbaren Logik und, falls das Repackaging gelungen ist, die veränderte App installiert und laufend auf einem Testgerät.
Kommunikation zwischen Apps: Deep Links und exportierte Komponenten
Angriffsweg: Deep Links und exportierte Activities, Intents oder Content Provider sind der Weg, auf dem Apps miteinander sprechen, und zugleich der Weg, auf dem eine bösartige App auf demselben Gerät in Ihre hineingreift, eine Aktion auslöst oder Daten abzieht, ohne jemals Ihre vorgesehene Oberfläche oder Ihr Session-Handling zu durchlaufen. Hier taucht ein großer Teil derselben gebrochenen Vertrauenslogik, die im Web zu einer defekten Authentifizierung führt, auf Mobilgeräten wieder auf, nur durch eine andere Tür.
Was als Nachweis eingereicht wird: Die exportierte Komponente oder das Deep-Link-Schema, ein funktionierender Aufruf aus einer nicht privilegierten Test-App, der sie auslöst, und was dadurch offengelegt oder ausgeführt wurde.
Wie ein echtes Ergebnis eines mobilen Pentests aussieht
Der schnellste Weg, ein echtes Projekt von einem automatisierten Scan mit angeflanschtem Berichtsgenerator zu unterscheiden: Fragen Sie, was auf einem echten Gerät gelaufen ist.
Ein echter Penetrationstest für mobile Apps verbindet drei Dinge, nicht eines:
- Statische Analyse des dekompilierten Binaries, des Quellcodes soweit verfügbar, der Konfigurationsdateien und der eingebetteten Ressourcen.
- Dynamische Analyse der laufenden App, Abfangen von Datenverkehr, Manipulation zur Laufzeit, Verhalten bei anormalen Eingaben.
- Eine Live-Sitzung zur Laufzeit auf einem Gerät mit Jailbreak oder Root, in der der Tester die Schutzmechanismen der App tatsächlich in Echtzeit aushebelt, statt nur festzustellen, dass es sie gibt.
Ein Produkt aus automatisiertem Scan plus PDF überspringt Schritt drei vollständig. Es kann Ihnen sagen, dass eine fest eingebaute Zeichenkette wie ein API-Schlüssel aussieht. Es kann Ihnen nicht sagen, ob die Jailbreak-Erkennung einem echten Umgehungsversuch standhält, denn das zeigt sich nur, wenn jemand die App auf einem Telefon mit Jailbreak ausführt und es versucht.
Lassen Sie sich von jedem Anbieter vor der Unterschrift das Inhaltsverzeichnis des Ergebnisdokuments zeigen. Enthält es keine Laufzeitsitzung auf einem Gerät mit Screenshots und konkreten Umgehungstechniken, und lesen sich alle Befunde, als kämen sie von einer Regelliste statt von einem Gerät, dann kaufen Sie einen Scan, keinen Penetrationstest für mobile Apps. Unser eigener Prozess für Sicherheitstests zeigt, wie wir dieses dreiteilige Projekt vor Arbeitsbeginn abgrenzen und strukturieren.
Wann mobile Tests allein nicht ausreichen
Ein Penetrationstest für mobile Apps sagt Ihnen, was ein Angreifer über den Client, das Gerät und den Transport erreicht. Er sagt Ihnen nicht, ob Ihre API eine defekte Autorisierung auf Objektebene, schwache Ratenbegrenzung oder eine Injection-Schwachstelle hat, die ein Angreifer direkt ausnutzen könnte, indem er die App komplett umgeht und per Skript mit Ihrem Backend spricht. Das sind reale Risiken, und sie brauchen ihren eigenen Umfang, keine Fußnote in einem mobilen Bericht.
Wenn ein Compliance-Rahmenwerk oder der Sicherheitsfragebogen eines Unternehmenskunden nach “Sicherheitstests für mobile Apps” fragt, lassen Sie sich schriftlich bestätigen, ob die API als eigener Posten oder als Teil desselben Projekts erwartet wird. Beides einfach anzunehmen ist der Weg, auf dem ein sauberer Bericht am Ende nur die Hälfte dessen abdeckt, was tatsächlich zugesagt war.
Wie QAwerk einen Penetrationstest für mobile Apps durchführt
Wir grenzen jedes Projekt zu Penetrationstests mobiler Apps als eigenen Posten ab, statische und dynamische Analyse plus eine Laufzeitsitzung auf echten Geräten mit Jailbreak und Root, nicht eingefaltet in eine allgemeine Webbewertung und nicht durchgehend automatisiert. Aus demselben Grund bringen unsere Kunden uns Fintech-Apps zur Identitätsprüfung vor einer Compliance-Prüfung für Google Play oder den App Store, und Dating- sowie Social-Apps, die sensiblere personenbezogene Daten speichern, als ihre Teams anfangs erwarten: Der Bericht muss standhalten, wenn jemand anderes ihn genau liest, nicht nur vollständig aussehen.
Dieses Projekt ist Teil unserer breiteren Dienstleistungen für Penetrationstests, abgegrenzt mit derselben transparenten Abrechnung nach Zeit und Aufwand über alle Testarten hinweg, die Ihre App tatsächlich braucht.
Häufig gestellte Fragen
Was sind Penetrationstests für mobile Apps?
Es handelt sich um eine Sicherheitsbewertung des Binaries einer mobilen App, ihrer lokalen Speicherung und ihres Verhaltens auf Geräteebene, klar getrennt vom Testen der Server, mit denen sie sich verbindet. Ein Tester analysiert die App statisch, testet sie dynamisch im laufenden Betrieb und führt eine Live-Sitzung auf einem Gerät mit Jailbreak oder Root durch, um zu bestätigen, welche Schutzmechanismen tatsächlich halten.
Worin unterscheiden sich mobile Penetrationstests von Web-Penetrationstests?
Webtests zielen über das Netzwerk auf serverseitige Logik. Mobile Tests zielen auf ein Binary, das der Angreifer in der Hand hält, und decken lokale Speicherung, fest eingebaute Geheimnisse, Certificate Pinning, Jailbreak-Erkennung und Reverse Engineering ab, wofür es im Web jeweils keine Entsprechung gibt.
Was umfasst ein Penetrationstest für mobile Apps?
Prüfung der lokalen Datenspeicherung, Kontrolle von Keychain und Keystore, Aufspüren fest eingebauter Geheimnisse, Tests zu Certificate Pinning und Abfangen von Datenverkehr, Umgehung der Jailbreak- und Root-Erkennung, Versuche zu Reverse Engineering und Repackaging, sowie Tests der Kommunikation zwischen Apps über Deep Links und exportierte Komponenten.
Deckt ein Penetrationstest für mobile Apps auch die Backend-API ab?
Manche Projekte enthalten einen begrenzten API-Durchgang, aber die API verdient ihren eigenen Umfang, denselben wie bei einer üblichen Webbewertung. Klären Sie das ausdrücklich, wenn eine Compliance-Anforderung oder eine Kundenanfrage von “Sicherheitstests für mobile Apps” spricht.
Wie oft sollte eine mobile App einem Penetrationstest unterzogen werden?
Das hängt von Release-Takt und Risikoprofil ab, nicht von einem festen Kalender. Unser Leitfaden zur Häufigkeit von Penetrationstests erklärt, wie Sie einen Rhythmus festlegen, der zu Ihrer Situation passt.
Sehen Sie, wie wir einer schnell wachsenden Designplattform dabei geholfen haben, durch die Beseitigung kritischer Probleme eine für den Start erforderliche Stabilität zu erreichen
