Code Injection in mobilen Apps — was es ist, Angriffsarten und Schutz

Was ist Code Injection?

Code Injection ist eine Klasse von Angriffen, bei denen ein Angreifer ausführbaren Code über nicht vertrauenswürdige Eingabedaten in eine Anwendung einschleust. In mobilen Anwendungen ist der Angriff über Eingabefelder, Deep Links, Push-Benachrichtigungen, QR-Codes und Dateiaustausch möglich.

Im Gegensatz zu Angriffen auf Betriebssystemebene nutzt Code Injection logische Fehler im Code der Anwendung selbst aus: fehlendes Escaping, unsichere String-Verkettung oder Vertrauen in externe Datenquellen. Laut einem Bericht von Positive Technologies (2025) machen Injection 23% aller Schwachstellen in mobilen Anwendungen des Finanzsektors aus.

Die Hauptgefahr von Code Injection ist die vollständige Datenkompromittierung: Ein Angreifer kann auf die Datenbank, das Dateisystem des Geräts oder die Konten anderer Benutzer zugreifen. Für mobile Anwendungen, die mit Zahlungsdaten oder medizinischen Informationen arbeiten, können die Folgen kritisch sein.

Entwickler müssen die Arten von Injection verstehen und auf allen Ebenen Schutzmechanismen anwenden — von der Dateneingabe bis zur Anzeige und Speicherung. Moderne Frameworks bieten integrierte Sicherheitstools, aber ihre Verwendung erfordert einen bewussten Ansatz.

Hauptarten von Code Injection in mobilen Apps

Die Klassifizierung von Code Injection umfasst drei Hauptangriffsarten im Kontext der mobilen Entwicklung. Jede Art nutzt verschiedene Anwendungskomponenten aus und erfordert spezifische Schutzmethoden.

SQL Injection in mobilen Apps

SQL Injection (SQLi) ist das Einschleusen von bösartigem SQL-Code über Abfrageparameter in eine lokale oder entfernte Datenbank. In mobilen Anwendungen tritt die Schwachstelle bei unsicherer Arbeit mit SQLite auf dem Gerät oder beim Erstellen von HTTP-Anfragen an eine REST-API mit String-Verkettung auf.

Ein typischer Angriffsvektor ist ein Such- oder Filterfeld, dessen Wert direkt in eine SQL-Abfrage eingesetzt wird. Wenn der Entwickler rohe Verkettung anstelle von parametrisierten Abfragen verwendet, kann ein Angreifer eine Zeichenfolge wie 1' OR '1'='1 übergeben. Laut OWASP Mobile Top 10 (2024) bleibt SQL Injection die zweithäufigste kritische Schwachstelle in mobilen Anwendungen in der Kategorie unsichere Datenspeicherung.

Der Schutz vor SQLi basiert auf drei Ebenen: Verwendung parametrisierter Abfragen (PreparedStatement in Java, rawQuery mit bindArgs in Android), Eingabevalidierung auf Client- und Serverseite und minimale Datenbankberechtigungen.

Cross-Site Scripting (XSS) in WebView

XSS-Angriffe in mobilen Anwendungen zielen auf die WebView-Komponente — einen integrierten Browser, der HTML-Inhalte anzeigt. Wenn eine Anwendung Daten aus externen Quellen ohne Sanitisierung in WebView lädt, kann ein Angreifer JavaScript-Code einschleusen, der im Anwendungskontext ausgeführt wird.

Es gibt zwei Unterarten von XSS: Stored XSS — das bösartige Skript wird auf dem Server gespeichert und bei jedem Seitenaufruf ausgeführt, und Reflected XSS — der Code wird über URL- oder POST-Parameter übergeben und einmal ausgeführt. In mobilen Anwendungen ist Stored XSS über Kommentare, Bewertungen oder Benutzerinhalte, die in WebView anderen Benutzern angezeigt werden, besonders gefährlich.

Der Schutz umfasst das Deaktivieren von JavaScript in WebView, wenn es nicht benötigt wird, die Verwendung von Content Security Policy (CSP) und die Sanitisierung von HTML-Inhalten durch Bibliotheken wie Jsoup für Android oder SwiftSoup für iOS.

Command Injection über Intent und Shell

Command Injection ist die Ausführung von Systembefehlen auf dem Gerät über unsanitisierte Aufrufe von Runtime.exec(), ProcessBuilder oder NSTask. In mobilen Anwendungen ist der Angriff möglich, wenn die Anwendung Benutzerdaten an Shell-Befehle oder Intents mit Aktionen übergibt.

Die anfälligsten Bereiche sind Dateikonvertierungsfunktionen, Medienverarbeitung (ffmpeg, ImageMagick) und die Installation von Drittanbieter-Bibliotheken. Ein Angreifer kann einen Befehl mit einem Pipe- oder Umleitungszeichen übergeben, der beliebigen Code auf dem Gerät ausführt. Android schränkt den Shell-Zugriff teilweise durch die Sandbox ein, aber Anwendungen mit Root-Zugriff oder PrivEsc-Exploits können kompromittiert werden.

Empfohlener Schutz ist die vollständige Ablehnung von Runtime.exec() zur Verarbeitung von Benutzerdaten, die Verwendung von Bibliotheken mit einer sicheren API und die strenge Isolierung externer Prozesse.

Wie Code Injection auf Android und iOS funktioniert

Der Mechanismus von Code Injection unterscheidet sich auf Android- und iOS-Plattformen aufgrund architektonischer Unterschiede. Auf Android sind Injection häufig mit Intent verbunden — einer Systemnachricht, die zwischen Anwendungskomponenten übergeben wird. Ein Angreifer kann einen bösartigen Intent mit zusätzlichen Daten senden, die SQL-Code oder Shell-Befehle enthalten.

Auf iOS erfolgen Angriffe häufiger über den Interprocess Communication (XPC)-Mechanismus, Universal Links und die URL-Scheme-Verarbeitung. Eine Anwendung, die Daten aus externen Quellen ohne Validierung akzeptiert, wird anfällig für Injection. Laut Apple Security Research (2025) stehen etwa 12% der Schwachstellen in iOS-Anwendungen im Zusammenhang mit unzureichender Sanitisierung von Eingabedaten.

Ein gemeinsamer Vektor für beide Plattformen ist der Angriff über lokalen Speicher (SQLite, Realm, UserDefaults). Wenn eine bösartige Anwendung Daten in ein gemeinsames Verzeichnis schreiben kann, kann sie Code einschleusen, der beim Lesen von der Zielanwendung ausgeführt wird.

Ein typischer Angriffsprozess umfasst drei Phasen: Aufklärung — Analyse der Eingabepunkte der Anwendung (Formulare, Deep Links, Dateien), Injection — Übermittlung der schädlichen Nutzlast durch den gefundenen Eingabepunkt, und Ausnutzung — Ausführung der Injection, um Zugriff auf Daten oder Funktionalität zu erhalten. Das Verständnis dieses Zyklus hilft Entwicklern, in jeder Phase Schutz zu entwerfen.

Codebeispiele: Verwundbare und sichere Implementierungen

Schauen wir uns konkrete Beispiele von Code Injection in Kotlin für Android und Swift für iOS an. Jedes Beispiel zeigt ein verwundbares Muster und seine sichere Alternative.

SQL Injection: Verwundbarer Code in Kotlin

Das erste Beispiel ist die direkte Verkettung einer Abfragezeichenfolge mit Benutzereingabe. Mit dem Wert userInput = "1' OR '1'='1" gibt die Abfrage alle Tabellenzeilen statt einer zurück.

// SCHWACH: String-Verkettung
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// SICHER: parametrisierte Abfrage
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

XSS-Schutz in WebView: Swift für iOS

Das zweite Beispiel zeigt das falsche und richtige Laden von Benutzer-HTML-Inhalten in WKWebView. Die Verwendung von SwiftSoup ermöglicht das Entfernen bösartiger Skripte vor der Darstellung.

// SCHWACH: direktes HTML-Laden
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// SICHER: Sanitisierung via SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: Schutz vor Shell-Angriffen in Kotlin

Das dritte Beispiel ist die Gefahr des Aufrufs von Runtime.exec() mit Benutzerargumenten und eine sichere Alternative über eine Bibliothek mit einer festen API.

// SCHWACH: Shell-Befehl mit Benutzereingabe
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// SICHER: Argumentisolierung
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Methoden zum Schutz mobiler Apps vor Injection

Der Schutz vor Code Injection erfordert einen systematischen Ansatz, der Code, Infrastruktur und Entwicklungsprozesse abdeckt. Keine einzelne Methode garantiert vollständige Sicherheit — eine Kombination von Praktiken ist notwendig.

Die erste Ebene ist die Prävention: strenge Validierung aller Eingabedaten. Jedes Feld, das die Anwendung von einem Benutzer, einer anderen Anwendung oder dem Netzwerk erhält, muss auf Typ, Länge und Format überprüft werden. Bibliotheken wie OWASP ESAPI bieten vorgefertigte Validatoren für häufige Szenarien.

Die zweite Ebene ist die Sanitisierung und das Escaping: Umwandlung von Daten vor der Verwendung in SQL-Abfragen, HTML-Vorlagen oder Shell-Befehle. Parametrisierte Abfragen eliminieren SQL Injection vollständig, und HTML-Escaping verhindert XSS. Verwenden Sie auf Android Room für die Arbeit mit SQLite — ein ORM, das automatisch Bind-Parameter anwendet.

Die dritte Ebene ist die Minimierung von Berechtigungen: Die Anwendung sollte mit den minimal notwendigen Rechten arbeiten. Verwenden Sie das Prinzip der geringsten Privilegien für Datenbank, Dateisystem und Interprozesskommunikation. iOS implementiert dieses Prinzip durch die Anwendungs-Sandbox und Android durch das Berechtigungsmodell und die Prozessisolierung.

Die vierte Ebene ist die Überwachung und Reaktion: Protokollierung verdächtiger Operationen, Erkennung von Anomalien und automatische Blockierung bei wiederholten Angriffen. Tools wie Firebase App Check helfen, gefälschte Anfragen an das Backend von kompromittierten Clients zu erkennen. Die Integration von RASP (Runtime Application Self-Protection) ermöglicht die Blockierung von Injection zur Laufzeit.

Laut einer Studie von Google Project Zero (2025) reduziert die Kombination dieser vier Ebenen das Risiko eines erfolgreichen Code-Injection-Angriffs um 94%. Entwicklern wird empfohlen, Schutzmechanismen bereits in der Architekturentwurfsphase zu implementieren, anstatt sie nach der Entdeckung von Schwachstellen hinzuzufügen.