Kontakt
Telefon & 24/7-Notfall-Hotline+49 2932 465265-0 E-Mailinfo@rootsektor.deMo–Fr 08:00–17:00 Uhr · außerhalb der Geschäftszeiten: 24/7-Notfall-Hotline
Pentest-Angebot anfordern Notfall meldenPenetration Testing
iOS & Android – App, Gerät und API im Blick
Ihre App läuft auf Geräten, die Sie nicht kontrollieren, und spricht mit Schnittstellen, deren Datenverkehr sich mitlesen und manipulieren lässt. Mit einem App-Penetrationstest prüfen wir iOS- und Android-Apps samt Backend nach OWASP MASVS und MASTG und zeigen Ihnen, wo Daten, Konten und Geschäftslogik angreifbar sind.
Definition
Ein App-Penetrationstest – auch Mobile App Pentest oder kurz App-Pentest genannt – ist eine überwiegend manuelle Sicherheitsprüfung Ihrer iOS- und Android-Anwendung aus der Perspektive eines Angreifers. Wir untersuchen die App selbst, ihr Verhalten zur Laufzeit, die Daten, die sie auf dem Gerät hinterlässt, und die Schnittstellen, mit denen sie kommuniziert. Ziel ist es, ausnutzbare Schwachstellen zu finden und zu belegen, bevor Kriminelle darauf stoßen.
Mobile Apps unterscheiden sich grundlegend von Webanwendungen. Eine App aus dem App Store oder von Google Play kann jede Person herunterladen, zerlegen und auf einem gerooteten oder gejailbreakten Gerät nach Belieben manipulieren. Alles, was im Client steckt – API-Schlüssel, versteckte Funktionen, Root- und Jailbreak-Erkennung, Certificate Pinning –, lässt sich mit Zeit und Know-how auslesen, analysieren oder aushebeln. Entscheidend ist deshalb, ob Ihr Backend auch dann sicher bleibt, wenn die App nicht mehr „mitspielt“.
Wir arbeiten nach dem OWASP Mobile Application Security Verification Standard (MASVS) und dem zugehörigen Testleitfaden MASTG. Die acht Kontrollbereiche des MASVS bilden das Gerüst unserer Prüfung: Datenspeicherung (MASVS-STORAGE), Kryptografie (MASVS-CRYPTO), Authentifizierung (MASVS-AUTH), Netzwerkkommunikation (MASVS-NETWORK), Plattform-Interaktion (MASVS-PLATFORM), Codequalität (MASVS-CODE), Manipulationsschutz (MASVS-RESILIENCE) und Datenschutz (MASVS-PRIVACY). Zusätzlich ordnen wir Befunde den Risiken der OWASP Mobile Top 10 zu.
Besonders wichtig ist ein App-Pentest, wenn Ihre App personenbezogene, finanzielle oder gesundheitsbezogene Daten verarbeitet, Zahlungen auslöst, Geräte steuert oder Beschäftigten Zugriff auf interne Systeme gibt. Die Ergebnisse helfen Ihnen, Anforderungen aus Art. 25 und Art. 32 DSGVO, ISO/IEC 27001:2022 (Anhang A 8.29) oder – für Finanzunternehmen – DORA nachweisbar zu erfüllen. Hersteller von Gesundheits-Apps orientieren sich zusätzlich an der BSI TR-03161; ein vorgelagerter Pentest deckt Lücken auf, bevor sie in einer formalen Prüfung auffallen.
Der beste Zeitpunkt für den Test liegt vor dem ersten Store-Release und nach jeder größeren Änderung – etwa an Login, Bezahlfunktion, eingebundenen SDKs oder API. So fließen die Ergebnisse direkt in den nächsten Build ein, und Sie vermeiden teure Nachbesserungen nach dem Launch.
Unser Vorgehen
Wir kombinieren statische und dynamische Analyse. Zuerst zerlegen wir das App-Paket (IPA, APK oder AAB), dekompilieren bzw. disassemblieren den Code, werten AndroidManifest, Info.plist und Entitlements aus und suchen nach fest einkodierten Secrets, verwendeten Bibliotheken, Debug-Funktionen und versteckten Endpunkten.
Anschließend läuft die App auf präparierten Testgeräten – gerootet bzw. gejailbreakt, bei Bedarf auch im Auslieferungszustand. Mit Instrumentierungs-Frameworks wie Frida beobachten und verändern wir das Verhalten zur Laufzeit, umgehen Certificate Pinning sowie Root- und Jailbreak-Erkennung und leiten den gesamten Datenverkehr über einen Intercepting Proxy. Nach jedem Arbeitsschritt prüfen wir, welche Spuren die App auf dem Gerät hinterlassen hat.
Den Schwerpunkt legen wir dorthin, wo der größte Schaden entstehen kann: auf die Backend-APIs. Mit Testkonten unterschiedlicher Rollen prüfen wir, ob sich fremde Daten abrufen, Preise verändern oder Freigaben umgehen lassen – unabhängig davon, was die Oberfläche der App erlaubt. Unsere zertifizierten Pentest-Fachleute und Security Researcher dokumentieren dabei jeden Schritt nachvollziehbar.
Typische Schwachstellen
Zugangstoken, personenbezogene Daten oder Dokumente landen unverschlüsselt in SharedPreferences, NSUserDefaults, SQLite-Datenbanken, Caches oder Logdateien. Auf einem kompromittierten Gerät oder über ein Backup sind sie leicht auszulesen.
API-Schlüssel, Cloud-Zugangsdaten oder private Schlüssel im App-Paket sind nach dem Dekompilieren schnell gefunden. Oft öffnen sie direkten Zugriff auf Cloud-Speicher, Datenbanken oder kostenpflichtige Drittdienste.
Die API vertraut der App und prüft nicht, ob ein Datensatz wirklich zum angemeldeten Konto gehört. Schon das Ändern einer ID in der Anfrage liefert dann fremde Kundendaten (Broken Object Level Authorization).
Token ohne Ablaufzeit, Refresh-Token, die nach dem Logout gültig bleiben, oder ein biometrischer Login, der nur ein lokales „Ja“ abfragt. Ist die Biometrie nicht kryptografisch an Keychain bzw. Keystore gebunden, genügt zur Umgehung ein einziger Hook zur Laufzeit.
Fehlerhafte Zertifikatsprüfung, erlaubter Klartextverkehr durch Ausnahmen in App Transport Security oder der Network Security Configuration, fehlendes Pinning bei Apps mit hohem Schutzbedarf. Im öffentlichen WLAN lässt sich der Datenverkehr dann mitlesen und manipulieren.
Exportierte Android-Komponenten wie Activities oder Content Provider, Deep Links oder URL-Schemes, die ohne Prüfung Aktionen auslösen, sowie WebViews mit JavaScript-Brücken in nativen Code. Andere Apps auf demselben Gerät können diese Wege missbrauchen.
Veraltete Bibliotheken mit bekannten Schwachstellen oder Analytics- und Werbe-SDKs, die mehr Daten übertragen als dokumentiert. Das ist ein Sicherheits- und zugleich ein Datenschutzproblem.
Bei Banking-, Bezahl- oder Lizenz-Apps werden fehlende Obfuskierung, leicht umgehbare Root-Erkennung oder fehlende Integritätsprüfungen zum Risiko – etwa wenn manipulierte Kopien der App in Umlauf geraten.
Testperspektive
Wie viele Informationen wir vorab erhalten, bestimmt Tiefe und Effizienz des Tests. Wir beraten Sie, welche Variante zu Ihrem Ziel passt.
Ohne Vorwissen
Wir starten nur mit der öffentlich verfügbaren App – wie ein Angreifer, der sie aus dem Store lädt.
Empfohlen
Sie stellen Test-Builds, Testkonten für alle Rollen und eine API-Dokumentation bereit – für die meisten Apps der effizienteste Weg.
Mit Quellcode
Zusätzlich sichten wir Quellcode und Architektur und finden so auch Schwachstellen, die im laufenden Betrieb kaum sichtbar sind.
Ablauf
Wir richten den Test an Ihrem Release-Zyklus aus, damit die Ergebnisse rechtzeitig in den nächsten Build einfließen. Methodisch folgt er unserem bewährten Vorgehen im Penetration Testing.
Wir klären Plattformen, App-Versionen, Rollen, Testumgebung und Schutzbedarf und legen fest, ob zusätzlich die Resilienz gegen Reverse Engineering geprüft wird. Innerhalb von 24 Stunden (werktags) nach dem Scoping erhalten Sie ein Festpreisangebot.
Wir zerlegen IPA und APK, werten Manifest, Info.plist, Berechtigungen und Bibliotheken aus und suchen nach Secrets, schwacher Kryptografie und versteckten Endpunkten.
Auf präparierten Testgeräten beobachten und manipulieren wir die App zur Laufzeit und prüfen Datenablage, Interprozesskommunikation, Biometrie und Schutzmechanismen.
Wir fangen den Datenverkehr ab und testen Autorisierung mit mehreren Rollen, Eingabevalidierung und Geschäftslogik – auch an Endpunkten, die die App selbst nicht aufruft.
Sie erhalten eine Management Summary, technische Befunde mit CVSS-Bewertung und konkrete Maßnahmen für iOS, Android und Backend. Auf Wunsch besprechen wir die Ergebnisse mit Ihrem Team.
Steht der korrigierte Build bereit, prüfen wir die behobenen Schwachstellen kostenlos erneut. Nach Abschluss des Tests erhalten Sie zudem eine Prüfbescheinigung.
Ergebnisbericht
Jeder Befund ist so dokumentiert, dass Ihr Entwicklungsteam ihn nachvollziehen und beheben kann – mit betroffener Plattform und Version, Reproduktionsschritten, Belegen und einer konkreten Empfehlung. Die Management Summary fasst Risiken und Prioritäten so zusammen, dass Entscheidungen möglich sind, ohne jeden einzelnen Request zu lesen.
Planen Sie den Pentest vor dem Store-Release ein. Wir stimmen Testfenster und Build mit Ihrem Entwicklungsteam ab, damit Schwachstellen behoben sind, bevor Ihre Nutzenden die App installieren.
FAQ
Ihre Frage ist nicht dabei? Rufen Sie uns an: +49 2932 465265-0 oder schreiben Sie an info@rootsektor.de.
Ja, wir prüfen beide Plattformen – einzeln oder gemeinsam. Weil iOS und Android unterschiedliche Sicherheitsmechanismen mitbringen, etwa Keychain und Keystore oder App Transport Security und Network Security Configuration, testen wir plattformspezifische Punkte getrennt. Die gemeinsame Backend-API prüfen wir nur einmal, das spart Aufwand.
Ja, denn dort liegen oft die folgenreichsten Schwachstellen. Wir rufen die Endpunkte Ihrer App auch mit manipulierten Parametern, fremden Objekt-IDs und den Rechten anderer Rollen auf. Nutzen auch Webanwendungen oder Partner dieselbe Schnittstelle, lohnt sich ein eigenständiger API-Penetrationstest.
Idealerweise Test-Builds beider Plattformen – für iOS einen Ad-hoc- oder Development-Build als IPA, für Android eine APK oder ein AAB –, Testkonten für jede Rolle und Zugriff auf eine Test- oder Staging-Umgebung. Eine API-Dokumentation, etwa im OpenAPI-Format, beschleunigt den Test. Für einen White-Box-Test kommen Quellcode und Architekturunterlagen hinzu.
Ja. Der MASVS definiert, welche Sicherheitsanforderungen eine App erfüllen sollte, der MASTG beschreibt, wie man sie prüft. Je nach Schutzbedarf richten wir die Prüftiefe an den MAS-Profilen L1 (grundlegende Sicherheit), L2 (erhöhter Schutzbedarf) und R (Resilienz gegen Reverse Engineering und Manipulation) aus.
Ja. Cross-Platform-Frameworks haben eigene Besonderheiten: Flutter-Apps ignorieren beispielsweise die Proxy-Einstellungen des Systems und bringen einen eigenen TLS-Stack mit, React-Native-Apps enthalten ihre Logik als JavaScript-Bundle oder Hermes-Bytecode. Wir berücksichtigen das in Analyse und Werkzeugwahl – ebenso bei .NET MAUI, Ionic oder Capacitor.
Zwingend ist das nicht, aber oft sinnvoll. Wir prüfen gern beides: die Schutzmechanismen selbst auf Umgehbarkeit und – in einem Build ohne diese Schutzschicht – die eigentliche App-Logik. So fließt die Testzeit in die Schwachstellen, die wirklich zählen.
Am besten, wenn der Funktionsumfang für das Release feststeht, aber noch Zeit für Korrekturen bleibt – also vor der Einreichung bei Apple bzw. Google. Ein erneuter Test lohnt sich, wenn sicherheitsrelevante Funktionen hinzukommen, etwa Single Sign-on, eine Wallet-Anbindung oder Gerätefunktionen wie NFC. Für Apps mit sensiblen Daten empfehlen wir zusätzlich eine regelmäßige Prüfung, z. B. jährlich.
Dauer und Aufwand hängen vom Funktionsumfang, von der Anzahl der Rollen und Plattformen sowie von der gewünschten Prüftiefe ab. Nach dem Scoping erhalten Sie innerhalb von 24 Stunden (werktags) ein Festpreisangebot – ohne versteckte Kosten und mit kostenlosem Retest.
Beschreiben Sie uns kurz Ihre App, die Plattformen und Ihren geplanten Release-Termin. Wir melden uns für ein unverbindliches Erstgespräch und senden Ihnen nach dem Scoping innerhalb von 24 Stunden (werktags) ein Festpreisangebot.
This page is also available in English.