Teil 6 – Mobile & API Security

Mobile-Apps und APIs gehören heute zusammen wie Frontend und Backend — wo die App die Oberfläche ist, sind APIs oft die Geschäftslogik. Beide Bereiche haben eigene Fallstricke. In diesem Teil beschreibe ich typische Schwachstellen, wie du sie verantwortungsvoll prüfst, welche Tools sich eignen und wie man sinnvolle, nicht-destruktive Tests durchführt.

Warum Mobile & API-Security speziell behandeln?

• Mobile-Apps verschleiern häufig Logik auf dem Gerät, speichern lokal sensible Daten und sprechen mit APIs, die die eigentliche Funktionalität bereitstellen.
• Moderne Angriffe zielen deshalb oft nicht auf die App-Oberfläche, sondern auf die API (Broken Auth, Excessive Data, IDOR).
• Mobilgeräte bringen zusätzliche Besonderheiten: lokale Speicherung (SQLite, Keychain/Keystore), WebViews, Deep Links, Intents und native-Bibliotheken — alles potenzielle Angriffspunkte.

Typische Schwachstellen bei Mobile-Apps

1. Insecure Data Storage
   • Sensible Daten (Tokens, PII, Keys) unverschlüsselt in SharedPreferences, SQLite oder im Filesystem abgelegt.
   • Prüfen: Suche nach persistierten Tokens, unverschlüsselten DB-Dateien oder Exportierten Backups.
2. Improper Platform Usage
   • Falsche Nutzung von iOS Keychain oder Android Keystore; falsche Intent- oder URL-Handling (Deep Link Hijacking).
   • Prüfen: Analyse von Manifest/Plist, Berechtigungen, Exported Components.
3. Weak Authentication & Session Management
   • Tokens ohne Ablauf, kein Refresh/Revoke, JWTs mit langen Lebenszyklen oder fehlender Signaturprüfung.
   • Prüfen: Token-Handling, Rotation, Logout-Verhalten.
4. Insecure Communication
   • Fehlende TLS, schwache Cipher, kein Certificate Validation oder fehlende Pinning.
   • Prüfen: Mit Proxy TLS-Verbindungen analysieren; prüfen, ob App Verbindungen mit ungültigen/selbst-signierten Zertifikaten zulässt.
5. Code-Leaks & Reverse Engineering
   • Hardcodierte API-Keys, Endpoints oder Geheimnisse im APK/IPA.
   • Prüfen: Statische Analyse (strings, resources), Decompiling (jadx, apktool).
6. WebView- & JavaScript-Integration
   • WebView, das unsichere Interfaces (addJavascriptInterface) exponiert oder Inhalte aus unsicheren Quellen lädt.
   • Prüfen: Identifiziere WebViews, analysiere auf JS-Interfaces.
7. Insecure Third-Party Libraries
   • Veraltete libs mit bekannten CVEs oder falsch konfigurierte SDKs (Analytics, Crash-Reporting).
   • Prüfen: Library-Versionen in Manifest/Gradle/iOS Podfiles.

Typische API-Schwachstellen

1. Broken Object Level Authorization (IDOR)
   • APIs prüfen nicht, ob der anfragende Nutzer berechtigt ist, auf eine Ressource zuzugreifen. Test: ID-Tampering.
2. Broken Authentication / Session Management
   • Schwache Passwortablagen, fehlende MFA, keine Token-Invaliderung nach Logout.
3. Excessive Data Exposure
   • Endpunkte liefern mehr Felder als nötig (z. B. Passworthashes, interne Flags).
   • Prüfen: Responses kontrollieren; Parameter fields/expand testen.
4. Mass Assignment
   • API akzeptiert und persistiert Felder, die der Client nicht setzen dürfen (z. B. isAdmin).
   • Prüfen: Sende zusätzliche Felder im JSON-Body.
5. Rate Limiting / Bruteforce-Schutz fehlt
   • Endpunkte erlauben automatisierte Massenanfragen (Account Enumeration, Passwort-Raten).
6. JWT / Token-Probleme
   • Unsichere Algorithmen (alg: none), fehlende Signature-Prüfung, fehlende Iss/Aud-Kontrollen.
7. Insecure Directories / Unauthenticated Endpoints
   • Admin/Debug-Endpunkte offen oder schlecht abgesichert.

Tools & Methodik (konkret)

Für Mobile (Device & App-Analyse)

• Android-Emulator / iOS-Simulator — sichere Testumgebung.
• apktool / jadx / class-dump — statische Analyse / Decompilation.
• mobSF (Mobile Security Framework) — automatisiertes Static+Dynamic Analysis-Framework.
• Frida / Objection — dynamische Instrumentierung, Hooking, Runtime-Manipulation.
• mitmproxy / Burp Suite — HTTP/HTTPS-Proxying; für iOS/Android Traffic-Inspection.
• adb / ideviceinstaller — App-Installation, Logcat, Dateisystemzugriff (Android).
• Xcode / Hopper / Ghidra — für native-Binary-Analyse (iOS/Android native libs).

Für APIs

• Postman / Insomnia / curl — manuelle API-Exploration.
• Burp Suite — Proxy + Intruder/Repeater zum Testen von Parameter-Tampering und Raten.
• sqlmap / ffuf — spezifische Tests (nur mit Zustimmung).
• OWASP Amass / Nuclei / custom scripts — zur Automation und Massenprüfung (bedacht einsetzen).
• JWT.io / jwt-cli — Analyse von JWTs.

Verantwortungsvolles Testen — Do’s & Don’ts

• Do: Immer Testkonten verwenden (einen normalen User-Account statt realer Nutzer), niemals Daten exfiltrieren.
• Do: In Produktivumgebungen sehr vorsichtig sein; automatisierte Scans oft verboten.
• Do: Proxy-Fingerprints respektieren — einige Apps erkennen Proxies / Debugging-Tools und reagieren unterschiedlich. Notiere das im Report.
• Don’t: Keine Live-Benutzer stören — kein massenhaftes Triggern von Notifications, UI-Aktionen oder Datenlöschungen.
• Don’t: Keine Ausnutzung von gefundenen Secrets — melde sie, aber missbrauche sie nicht.

Konkrete Prüfabläufe (Beispiele)

Mobile — TLS/Pinning-Check (kurz)

1. Emulatior starten, App installieren.
2. Proxy (mitmproxy/Burp) konfigurieren; SSL-CA im Emulator installieren.
3. Beobachten: Lässt App Verbindungen mit dem Proxy zu? Wenn ja, TLS-Validation fehlt.
4. Wenn nicht: App könnte Pinning nutzen — analysiere mit Frida, um Pinning-Checks zu umgehen (nur in Testumgebung).

API — IDOR-Check

1. Erstelle zwei Test-Accounts A und B.
2. Mit A eine Ressource anlegen (z. B. /user/123/profile).
3. Mit B versuchen, /user/123/profile zu lesen/ändern.
4. Wenn Zugriff möglich ist, dokumentiere die Schritte, Zeiten, Response-Codes und Beispiel-Requests.

Reporting: Was bei Mobile/API-Reports wichtig ist

• Endpoint / App-Version / Build: Exakte Version, OS, Device/Emulator.
• Schritte zur Reproduktion: Requests (Header + Body), Payloads, Screenshots/Logs.
• Nachweis, nicht Ausnutzung: PoC, das den Zugriff/Fehler belegt, ohne Daten zu exfiltrieren.
• Impact-Bewertung: Welche Daten könnten betroffen sein? Welche Aktionen wären möglich?
• Fix-Vorschläge: z. B. „Speichere Tokens im Keystore/Keychain“, „Implement Token-Rotation + Revocation“, „Whitelist outbound hosts“, „validate JWT alg & claims“.

Praxisübungen (sicher)

1. Setup: Erstelle einen Android-Emulator, installiere eine Demo-App (z. B. OWASP MobileGoat oder eine eigene kleine App).
2. Intercept: Richte mitmproxy ein und untersuche alle API-Calls. Dokumentiere unverschlüsselte Daten oder fehlende Pinning.
3. Static-Check: Decompile die App mit jadx, suche nach API_KEY, token, password.
4. API-Tests: Mit Postman Testaccount erstellen, ID-Tampering ausprobieren, Rate-Limit-Verhalten checken (vorsichtig).