Sicherheit in der mobilen Entwicklung: Was es ist, welche Bedrohungen es gibt und wie man sich schützt

Hauptbedrohungen: OWASP Mobile Top 10

Was ist OWASP Mobile Top 10?

OWASP (Open Web Application Security Project) ist eine gemeinnützige Organisation, die ein Ranking der gefährlichsten Schwachstellen der mobilen Sicherheit veröffentlicht. OWASP Mobile Top 10 ist eine Liste, die Entwicklern hilft zu verstehen, worauf sie sich zuerst konzentrieren sollten. In der Version 2024 führen Probleme im Zusammenhang mit unsicherer Speicherung, schwacher Authentifizierung und unsicherer Netzwerkkommunikation die Rangliste an.

M1: Unsichere Datenspeicherung — das häufigste Problem: Passwörter, Tokens und persönliche Daten verbleiben in SharedPreferences, NSUserDefaults oder lokalen Dateien ohne Verschlüsselung. M2: Schwache Authentifizierung — fehlende serverseitige Überprüfung, schwache Passwörter. M3: Unsichere Netzwerkkommunikation — fehlendes HTTPS oder falsche SSL-Zertifikatsprüfung. M4 und M5 beziehen sich auf Kryptographie und falsche API-Nutzung.

M6: Unsichere Autorisierung — ein Benutzer kann auf Daten eines anderen Benutzers zugreifen, indem er eine ID in einer Anfrage ersetzt. M7: Code-Injection (SQL Injection, XSS). M8: App-Manipulation — Repackaging, Code-Ersetzung. M9 und M10 — Datenlecks durch Drittanbieter-Bibliotheken und Reverse Engineering. Für jede dieser Bedrohungen gibt es bewährte Gegenmaßnahmen, und bei IT Sectr wenden wir sie seit 2017 in allen Projekten an.

Man-in-the-Middle (MITM)-Angriffe

MITM-Angriff tritt auf, wenn ein Angreifer den Datenverkehr zwischen der Anwendung und dem Server abfängt. Dies ist durch DNS-Spoofing, ARP-Spoofing oder die Verbindung zu einem ungesicherten WLAN-Netzwerk möglich. Zum Schutz werden SSL/TLS-Zertifikate und Certificate Pinning verwendet.

Certificate Pinning ist ein Mechanismus, bei dem die Anwendung überprüft, ob das Serverzertifikat mit einem im Anwendungscode vorab gespeicherten Zertifikat übereinstimmt. Selbst wenn ein Angreifer das Zertifikat über einen Proxy (z. B. Burp Suite) austauscht, wird die Anwendung die Verbindung ablehnen. Pinning gibt es in zwei Arten: Public Key Pinning und Certificate Hash Pinning.

Verschlüsselung und Hashing: AES, RSA, SSL/TLS

Symmetrische Verschlüsselung: AES

AES (Advanced Encryption Standard) ist ein symmetrischer Verschlüsselungsalgorithmus, die Grundlage der Datensicherheit auf dem Gerät. AES verwendet denselben Schlüssel zum Verschlüsseln und Entschlüsseln von Daten. AES unterstützt Schlüssel mit 128, 192 oder 256 Bit. In der mobilen Entwicklung wird AES-256 zum Verschlüsseln von Daten auf dem Gerät verwendet: Dateien, Cache, Einträge in der lokalen Datenbank.

AES-Modi: GCM (empfohlen) — bietet Datenauthentifizierung, CBC — Basismodus mit Blockverkettung, ECB — unsicher, nicht verwenden. Für iOS ist AES über CommonCrypto (CCOptions) verfügbar, für Android — über Cipher in der Java Cryptography Architecture (JCA). Wichtig: Der Verschlüsselungsschlüssel darf niemals im Anwendungscode gespeichert werden — verwenden Sie Keychain/Keystore.

Asymmetrische Verschlüsselung: RSA — verwendet ein Schlüsselpaar (öffentlich und privat). RSA wird zum Verschlüsseln kleiner Datenmengen verwendet — typischerweise zum Austausch eines symmetrischen Schlüssels zwischen Client und Server. Die minimale RSA-Schlüssellänge beträgt 2048 Bit (4096 empfohlen). Auf iOS ist RSA über das Security Framework (SecKeyCreateRandomKey) verfügbar, auf Android — über KeyPairGenerator im Android Keystore.

Hashing und SSL/TLS

Hashing (SHA-256, SHA-3) ist eine irreversible Umwandlung von Daten in eine Zeichenfolge fester Länge. Hashes werden zur Überprüfung der Datenintegrität und zur Passwortspeicherung verwendet. Für Passwörter verwenden Sie unbedingt bcrypt, scrypt oder Argon2 — einfaches SHA-256 ist anfällig für Rainbow-Table-Angriffe. SSL/TLS ist ein Protokoll zur Verschlüsselung des Netzwerkverkehrs zwischen Client und Server. Der moderne Standard ist TLS 1.3, das Perfect Forward Secrecy (PFS) bietet.

TLS 1.3 ist schneller als seine Vorgänger: Der Handshake dauert einen Round Trip statt zwei. Auf Android wird die minimale TLS-Version über SSLSocket konfiguriert, auf iOS — über ATS (App Transport Security), das standardmäßig TLS 1.2 oder höher erfordert. ATS kann nur für bestimmte Domänen mit Begründung deaktiviert werden.

Sichere Speicherung: Keychain und Keystore

iOS: Keychain

Keychain (Schlüsselbund) ist ein geschützter Speicher in iOS / macOS für Passwörter, Verschlüsselungsschlüssel, Zertifikate und Tokens. Daten in der Keychain werden mit einem für jedes Gerät eindeutigen Hardwareschlüssel verschlüsselt. Der Zugriff auf die Keychain wird über das Security Framework (SecItemAdd, SecItemCopyMatching) gesteuert. Die Keychain wird automatisch gesperrt, wenn das Gerät gesperrt wird, und wird mit der Secure Enclave verschlüsselt.

Android: Keystore

Android Keystore ist ein Systemspeicher für kryptografische Schlüssel, der von der Anwendung isoliert ist. Ab Android 6.0 (API 23) verwendet der Keystore Hardware-Unterstützung (TEE — Trusted Execution Environment) auf Geräten mit einem Sicherheitschip. Schlüssel im Keystore verlassen niemals den geschützten Bereich — die Anwendung erhält nur einen Handle für Verschlüsselungs- und Signierungsoperationen.

SharedPreferences und NSUserDefaults sind nicht für die Speicherung vertraulicher Daten ausgelegt — sie speichern Informationen im Klartext. Verwenden Sie für den Datenschutz EncryptedSharedPreferences (Android) oder verschlüsseln Sie Daten vor dem Speichern in UserDefaults (iOS). Bei IT Sectr verwenden wir immer Keychain und Keystore für Zugriffstoken und Passwörter.

Authentifizierung: OAuth 2.0, JWT und Biometrie

OAuth 2.0 und OpenID Connect

OAuth 2.0 ist ein delegiertes Autorisierungsprotokoll, das sicheren Zugriff auf Benutzerressourcen ohne Übertragung des Passworts ermöglicht. In mobilen Anwendungen wird am häufigsten der Authorization Code Flow mit PKCE (Proof Key for Code Exchange) verwendet. PKCE verhindert das Abfangen des Autorisierungscodes — eine verbindliche Anforderung für mobile Anwendungen.

OpenID Connect (OIDC) ist eine Erweiterung auf Basis von OAuth 2.0 zur Benutzerauthentifizierung. OIDC fügt ein ID Token im JWT-Format hinzu, das Benutzerinformationen (Name, E-Mail, ID) enthält. Der OAuth 2.0 + OIDC-Ablauf umfasst: Weiterleitung des Benutzers zur Login-Seite, Erhalt eines Autorisierungscodes, Austausch des Codes gegen Tokens (Access + Refresh + ID), Verwendung des Access Tokens für API-Anfragen.

JWT: Access, Refresh und Session Tokens

JWT (JSON Web Token) ist ein kompaktes, URL-sicheres Token-Format, das Claims im JSON-Format enthält. JWT besteht aus drei Teilen: Header (Typ und Signaturalgorithmus), Payload (Daten) und Signatur. Access Token ist ein kurzlebiges Token (15–60 Minuten) für den API-Zugriff. Refresh Token ist ein langlebiges Token (Tage/Wochen) zum Erhalten eines neuen Access Tokens ohne erneute Anmeldung.

Session Token ist ein traditioneller Ansatz, bei dem der Server die Sitzung in einer Datenbank oder Redis speichert und der Client eine zufällige Kennung erhält. In der mobilen Entwicklung wird JWT bevorzugt: Es erfordert keine serverseitige Sitzungsspeicherung, enthält alle Informationen in sich selbst und ist einfach zu überprüfen. JWT kann jedoch nicht sofort widerrufen werden — dies ist ein Kompromiss, der durch eine kurze Lebensdauer des Access Tokens und die Verwendung von Refresh Tokens gelöst wird.

Biometrische Authentifizierung

Face ID und Touch ID auf iOS, Fingerprint Auth auf Android — biometrische Authentifizierungsmethoden, die einzigartige physische Merkmale des Benutzers verwenden. Auf iOS funktioniert Biometrie über LocalAuthentication (LAContext), auf Android — über BiometricPrompt (Android 9+) oder FingerprintManager (veraltet). Biometrie wird zum Entsperren der App, zur Zahlungsbestätigung und zum Zugriff auf geschützte Daten verwendet.

Wichtige Nuancen: Biometrie ist eine bequeme UX, aber kein Ersatz für die Server-Authentifizierung. Nach erfolgreicher biometrischer Verifizierung sollte die Anwendung ein Access Token vom Server anfordern. Auf Android muss überprüft werden, dass das Gerät Class 3 (Strong) Biometrie verwendet, nicht nur kamerabasierte Gesichtserkennung (Class 1).

Code-Schutz: ProGuard, R8 und Root Detection

Obfuskation: ProGuard und R8

ProGuard ist ein Werkzeug zur Obfuskation, Komprimierung und Optimierung von Java-Bytecode für Android, das die Codesicherheit gegen Reverse Engineering erhöht. R8 ist sein Nachfolger, der seit Android Studio 3.4 in Gradle integriert ist. R8 führt vier Aufgaben aus: Komprimierung (entfernt ungenutzte Klassen und Methoden), Optimierung (inlinet Methoden, vereinfacht Code), Obfuskation (benennt Klassen und Methoden in kurze Namen um) und Vorverifizierung (Bytecode-Prüfung).

DexGuard ist eine kommerzielle Version von ProGuard mit erweitertem Schutz: Zeichenkettenverschlüsselung, Ressourcen-Obfuskation, Repackaging-Schutz, APK-Integritätskontrolle. Für die meisten Projekte ist R8 ausreichend, aber für Finanz- und Bankenanwendungen bietet DexGuard eine zusätzliche Sicherheitsebene. R8 wird über build.gradle aktiviert: minifyEnabled = true und proguardFiles.

Root- und Jailbreak-Erkennung

Root Detection (Android) und Jailbreak Detection (iOS) sind Mechanismen, die prüfen, ob auf dem Gerät Superuser-Rechte erlangt wurden. Auf kompromittierten Geräten kann der Prozessspeicher gelesen, der Datenverkehr abgefangen und Code ersetzt werden. Zur Überprüfung auf Android werden das Vorhandensein der SU-Binärdatei, Testsignaturschlüssel und nicht standardmäßige Build-Flags verwendet.

RASP (Runtime Application Self-Protection) ist eine Technologie, die die Anwendung während der Ausführung schützt. RASP erkennt Versuche des Debuggings, Repackaging, der Code-Injection und beendet die Anwendung bei Erkennung von Bedrohungen. Beispiele für RASP-Lösungen: Dexter, Guardsquare, Promon. RASP arbeitet zur Laufzeit und reagiert auf Anomalien — im Gegensatz zur statischen Obfuskation, die Code vor der Ausführung schützt.

Reverse Engineering ist der Prozess der Wiederherstellung des Quellcodes aus einer kompilierten Anwendung. Werkzeuge: JADX (APK-Decompiler), Ghidra, IDA Pro, Hopper. Schutz vor Reverse Engineering ist eine Kombination aus Obfuskation, Zeichenkettenverschlüsselung, Integritätsprüfung und Root Detection. Vollständiger Schutz existiert nicht — das Ziel ist es, Reverse Engineering für den Angreifer teuer genug zu machen.