Sicherheit von Swift-Anwendungen: Die Top-10 Schwachstellen in der Praxis

Sicherheit von Swift-Anwendungen: Die Top-10 Schwachstellen in der Praxis

Die Entwicklung mobiler Anwendungen für iOS und macOS erfordert besondere Aufmerksamkeit für die Sicherheit. Swift ist eine leistungsstarke und moderne Sprache, aber selbst sie schützt den Entwickler nicht vor typischen Fehlern, die zu Datenlecks, Hacking oder finanziellen Verlusten führen können. In diesem Artikel analysieren wir die Top-10 Schwachstellen von Swift-Anwendungen mit realen Codebeispielen und praktischen Empfehlungen zu deren Behebung.

1. SQL-Injection über Core Data und SQLite

Viele Entwickler verwenden rohe SQL-Abfragen in Verbindung mit SQLite. Wenn die Daten des Benutzers nicht maskiert werden, kann ein Angreifer beliebige Abfragen an die Datenbank ausführen.

// ❌ Unsicherer Codelet query = "SELECT * FROM users WHERE name = '\\(userInput)'"

// ✅ Sicherer Code (Verwendung parametrisierter Abfragen)let query = "SELECT * FROM users WHERE name = ?"var statement: OpaquePointer?sqlite3_prepare_v2(database, query, -1, &statement, nil)sqlite3_bind_text(statement, 1, (userInput as NSString).utf8String, -1, nil)

Verwenden Sie parametrisierte Abfragen oder Core Data mit Prädikaten – dies schließt Injection aus.

2. Unsichere Datenspeicherung im Keychain

Der Keychain ist ein sicherer Ort, aber viele Entwickler konfigurieren die Zugriffsattribute falsch. Wenn beispielsweise kSecAttrAccessible nicht angegeben wird, können die Daten nach einem Backup zugänglich sein.

// ❌ Unsicherer Code (nach Backup zugänglich)let query: [String: Any] = [    kSecClass as String: kSecClassGenericPassword,    kSecAttrAccount as String: "token",    kSecValueData as String: tokenData]

// ✅ Sicherer Code (nur wenn Gerät entsperrt)let query: [String: Any] = [    kSecClass as String: kSecClassGenericPassword,    kSecAttrAccount as String: "token",    kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly,    kSecValueData as String: tokenData]

3. Fehlende SSL/TLS-Überprüfung (Man-in-the-Middle)

Bei der Entwicklung wird die Zertifikatsprüfung oft für Tests deaktiviert, aber vergessen, die Einstellungen für die Veröffentlichung zurückzusetzen. Dies ermöglicht einem Angreifer, den Datenverkehr abzufangen.

// ❌ Unsicherer Code (gefährlich für die Produktion)let session = URLSession(configuration: .default, delegate: self, delegateQueue: nil)// Im Delegate:func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {    completionHandler(.useCredential, URLCredential(trust: challenge.protectionSpace.serverTrust!))}

// ✅ Sicherer Code – verwenden Sie die Standardprüfunglet session = URLSession.shared// Oder verwenden Sie ATS (App Transport Security) in Info.plist

Aktivieren Sie App Transport Security (ATS) und deaktivieren Sie es nicht im Release-Build.

4. Datenlecks über Logs und Crashlytics

Entwickler protokollieren oft sensible Daten (Tokens, Passwörter) zum Debuggen. Wenn das Log in einen Drittanbieterdienst (z. B. Firebase Crashlytics) gelangt, können die Daten durchsickern.

// ❌ Unsicherer Codeprint("User token: \\(userToken)")

// ✅ Sicherer Code#if DEBUG    print("User token: [REDACTED]")#endif// Oder verwenden Sie os_log mit Privatsphäre-Levelos_log("User token: %{private}@", log: .default, type: .debug, userToken)

Protokollieren Sie niemals sensible Daten in der Produktion. Verwenden Sie Maskierung oder bedingte Kompilierung.

5. Unsichere Speicherung von Geheimnissen im Code

Das Speichern von API-Schlüsseln, Tokens und Passwörtern direkt im Quellcode ist ein grober Fehler. Selbst wenn der Code verschleiert ist, können Zeichenfolgen leicht aus der Binärdatei extrahiert werden.

// ❌ Unsicherer Codelet apiKey = "sk-1234567890abcdef"

// ✅ Sicherer Code – verwenden Sie serverseitige Authentifizierung// Oder verschlüsseln Sie Schlüssel mit CryptoKitimport CryptoKitlet key = SymmetricKey(data: "server_