SQL Injection in der mobilen Entwicklung: Was es ist, Angriffsmethoden und Schutz

Was ist SQL Injection?

SQL Injection ist eine Schwachstelle, die auftritt, wenn eine Anwendung SQL-Abfragen durch Zeichenkettenverkettung mit Benutzerdaten erstellt. Ein Angreifer übergibt eine speziell konstruierte Zeichenkette in einem Abfrageparameter, die die Struktur des SQL-Befehls ändert. Anstatt Daten zu sein, wird die injizierte Zeichenkette Teil des SQL-Codes, wodurch der Angreifer beliebige Abfragen gegen die Datenbank ausführen kann. Laut dem Verizon Data Breach Report (2025) ist SQL Injection in 8% aller untersuchten Datenlecks vorhanden.

Warum ist SQL Injection immer noch relevant?

Trotz einer bekannten Schwachstelle (erste Erwähnung Ende der 1990er Jahre) wird SQL Injection immer noch in modernen Anwendungen gefunden. Der Grund ist menschliches Versagen: Entwickler schreiben Code mit Zeichenkettenverkettung, Legacy-Code wird nicht refaktoriert und ORM-Frameworks werden falsch verwendet (z. B. Raw-Queries mit Zeichenketteninterpolation). Laut Veracode (2026) enthalten etwa 14% aller gescannten Anwendungen mindestens eine SQLi-Schwachstelle.

Was kann ein Angreifer tun?

Eine erfolgreiche SQL Injection gibt dem Angreifer eine breite Palette von Fähigkeiten: Lesen beliebiger Datenbanktabellen, einschließlich Passwort-Hashes und persönlicher Benutzerdaten; Ändern und Löschen von Datensätzen; Ausführen von Verwaltungsoperationen (DROP TABLE, TRUNCATE); und in einigen Konfigurationen die ferngesteuerte Ausführung von Befehlen über xp_cmdshell (MSSQL) oder INTO OUTFILE (MySQL). Die Folgen reichen von der Offenlegung von Benutzerdaten bis zum vollständigen Verlust der Systemkontrolle.

Arten von SQL-Injektionen

SQL-Injektionen werden nach der Methode der Datenextraktion aus der Datenbank klassifiziert. Die Wahl der Methode hängt davon ab, wie die Anwendung Abfrageergebnisse und Fehlermeldungen verarbeitet. Die OWASP-Klassifizierung identifiziert drei Haupttypen: In-band (Datenextraktion über denselben Kanal), Inferential/Blind (logische Schlussfolgerungen) und Out-of-band (Datenübertragung über einen anderen Kanal).

In-band SQL Injection (Klassisch)

Der häufigste Typ. Ein Angreifer injiziert SQL-Code in einen Abfrageparameter, und das Ergebnis der Injektion ist direkt in der Serverantwort sichtbar. Zwei Untertypen: Error-based (über DB-Fehlermeldungen) und UNION-based (über den UNION SELECT-Operator). Error-based nutzt Informationen aus Fehlermeldungen, wie einen MySQL-Syntaxfehler, der den Tabellennamen oder die Abfragestruktur preisgeben kann. UNION-based ermöglicht es, Ergebnisse legitimer Abfragen mit Daten aus anderen Datenbanktabellen zu kombinieren.

Blind SQL Injection

Wird verwendet, wenn die Anwendung keine Abfrageergebnisse oder Fehlermeldungen anzeigt. Ein Angreifer stellt Ja/Nein-Fragen, indem er Abfragen mit logischen Bedingungen sendet und die Unterschiede in den Serverantworten (z. B. Antwortzeit oder Seiteninhalt) analysiert. Time-based Blind SQLi verwendet Verzögerungsfunktionen (SLEEP, WAITFOR DELAY), um Bedingungen zu bestätigen — wenn die Seite länger lädt, ist die Bedingung wahr. Diese Methode ist sehr langsam — das Extrahieren eines einzelnen Datensatzes kann Stunden dauern.

# Beispiel für Blind SQL Injection (zeitbasiert)
# Wenn SQLi anfällig ist, wird SLEEP(2) ausgeführt, wenn die Bedingung erfüllt ist
import requests
import time

payload = "' OR IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a',SLEEP(2),0) -- "
url = "http://example.com/user?id=1" + payload

start = time.time()
response = requests.get(url)
elapsed = time.time() - start

# Wenn die Antwort nach >2 Sekunden eintrifft — der erste Buchstabe des Passworts ist 'a'
print(f"Time: {elapsed:.2f}s - First letter is 'a'" if elapsed > 2 else "First letter is not 'a'")

Out-of-band SQL Injection

Daten werden nicht über die HTTP-Antwort, sondern über alternative Kanäle übertragen: DNS-Abfragen, HTTP-Anfragen an einen externen Server, SMTP. Wird verwendet, wenn die Anwendung keine Abfrageergebnisse zurückgibt oder Fehler anzeigt. MySQL unterstützt die Funktion LOAD_FILE(), die eine DNS-Abfrage auslösen kann, und MSSQL hat xp_dirtree zum Senden von Daten an einen entfernten SMB-Server. Out-of-band SQL Injection ist effektiv, erfordert aber zusätzliche Angreiferserver-Einrichtung und spezifische DB-Funktionen.

Wie funktioniert eine SQL-Injektion?

Der Mechanismus der SQL Injection basiert darauf, dass SQL Anführungszeichen für Zeichenkettenliterale verwendet. Wenn eine Anwendung Benutzereingaben direkt ohne Escape in eine SQL-Abfrage einfügt, kann ein Angreifer die Zeichenkette „schließen“ und beliebigen SQL-Code hinzufügen. Zum Beispiel verwandelt in der Abfrage SELECT * FROM users WHERE name = '$input' das Einfügen von ' OR '1'='1 sie in SELECT * FROM users WHERE name = '' OR '1'='1', was alle Benutzer zurückgibt.

Klassisches Beispiel: Authentifizierungsumgehung

Betrachten Sie ein Anmeldeformular mit der Abfrage SELECT * FROM users WHERE username = '$user' AND password = '$pass'. Wenn ein Angreifer admin' -- in das Benutzernamenfeld eingibt und das Passwort leer lässt, wird die resultierende Abfrage zu SELECT * FROM users WHERE username = 'admin' -- ' AND password = ''. Die -- Zeichen kommentieren den Rest der Abfrage aus und deaktivieren die Passwortprüfung. Der Server gibt den Admin-Benutzerdatensatz zurück, und der Angreifer meldet sich an, ohne das Passwort zu kennen.

# Beispiel für SQL Injection — Authentifizierungsumgehung
# ANFÄLLIGER CODE: direkte Zeichenkettenverkettung
def login_vulnerable(username, password):
    query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
    cursor.execute(query)
    return cursor.fetchone() is not None

# username = "admin' --" macht die Passwortprüfung zunichte
# SICHERE VERSION: parametrisierte Abfrage
def login_secure(username, password):
    query = "SELECT * FROM users WHERE username = %s AND password = %s"
    cursor.execute(query, (username, password))
    return cursor.fetchone() is not None

UNION-based: Lesen anderer Tabellen

Der UNION SELECT-Operator ermöglicht es, Ergebnisse von zwei SELECT-Abfragen zu kombinieren. Wenn ein Angreifer einen anfälligen Parameter findet, fügt er UNION SELECT mit einer Abfrage aus einer anderen Tabelle hinzu. Beispiel: ' UNION SELECT username, password FROM admins --. Die Erfolgsbedingung ist, dass die Anzahl der Spalten in beiden Abfragen übereinstimmen muss. Die Spaltenanzahl wird durch ORDER BY bestimmt (Einfügen von ' ORDER BY 1--, dann 2, 3... bis ein Fehler auftritt). Kennt der Angreifer die Spaltenanzahl, fügt er UNION SELECT mit derselben Anzahl von Feldern ein.

SQL Injection in mobilen Anwendungen

Mobile Anwendungen sind sowohl auf der Serverseite (API) als auch auf der Clientseite — in lokalen Datenbanken (SQLite, Realm) — von SQL Injection betroffen. Während die serverseitige SQLi in mobilen APIs Webanwendungen ähnelt, schaffen lokale Datenbanken einen zusätzlichen Vektor. Wenn eine Anwendung Daten in SQLite speichert und Abfragen mit Zeichenkettenverkettung ausführt, können bösartige Daten, die über die API in die lokale Datenbank gelangen, bei der späteren Verarbeitung SQLi auslösen.

SQL Injection in SQLite auf Android/iOS

Die lokale SQLite-Datenbank auf einem Gerät ist ebenfalls anfällig für SQL Injection, wenn die Anwendung Abfragen durch Zeichenkettenverkettung erstellt. Content Providers auf Android und Core Data auf iOS verwenden standardmäßig Parametrisierung, aber Raw-Queries erfordern die Aufmerksamkeit des Entwicklers. SQLite unterstützt keine mehrfachen durch Semikolon getrennten Abfragen, was die Möglichkeiten des Angreifers einschränkt, aber nicht vor dem Lesen von Daten durch WHERE-Bedingungen schützt. Verwenden Sie immer selectionArgs in Android und NSPredicate mit Parametern in iOS.

SQL Injection über die API einer mobilen Anwendung

Die API, mit der eine mobile Anwendung kommuniziert, ist genauso anfällig wie jeder Webserver. Mobile Entwickler gehen oft davon aus, dass SQLi nur ein Backend-Problem ist, aber die Schwachstelle tritt am API-Endpunkt auf, der Parameter vom Client akzeptiert. Die Trennung der Verantwortlichkeiten schützt nicht: Wenn der Backend-Entwickler vergessen hat, die Abfrage zu parametrisieren, wird die mobile App des Benutzers zum Angriffsvektor. Fordern Sie vom Backend die Verwendung von ORM oder Prepared Statements.

// Beispiel für SQL Injection in lokaler SQLite auf Android
// ANFÄLLIGER CODE: direkte Verkettung
fun getUserVulnerable(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = $userId", null
    )
}

// SICHERE VERSION: Parametrisierung über selectionArgs
fun getUserSecure(db: SQLiteDatabase, userId: String): Cursor {
    return db.rawQuery(
        "SELECT * FROM users WHERE id = ?",
        arrayOf(userId)
    )
}

Methoden zur Verhinderung von SQL Injection

Der Schutz vor SQL Injection basiert auf einem einfachen Prinzip: Vertrauen Sie niemals Benutzereingaben in SQL-Abfragen. Die einzige zuverlässige Methode ist die Abfrageparametrisierung (Prepared Statements), bei der SQL-Code und Daten getrennt übergeben werden. Alle anderen Methoden — Escaping, Validierung, WAF — sind zusätzliche Sicherheitsschichten, ersetzen aber nicht die Parametrisierung. Laut OWASP (2025) verhindert Parametrisierung 100% der SQL Injection-Angriffe.

Prepared Statements (Parametrisierte Abfragen)

Bei Verwendung von Prepared Statements wird die SQL-Abfrage zuerst vom DB-Server ohne Daten kompiliert, und dann werden die Parameterwerte getrennt übergeben. Die Datenbank behandelt Parameter als Daten, nicht als ausführbaren Code. Selbst wenn ein Angreifer ' OR '1'='1 übergibt, interpretiert die Datenbank dies als Zeichenkettenwert, nicht als SQL-Code. Prepared Statements werden von allen modernen Sprachen und Frameworks unterstützt: PDO in PHP, PreparedStatement in Java, cursor.execute in Python.

ORM-Frameworks und Query Builder

Moderne ORMs (Hibernate, Entity Framework, SQLAlchemy, Room) verwenden bei der Ausführung von Abfragen automatisch Parametrisierung, es sei denn, der Entwickler wechselt zu Raw-Queries. Allerdings schützen ORMs nicht vollständig: Konstrukte wie @Query(value = "SELECT * FROM users WHERE name = :name", nativeQuery = true) in JPA erfordern die Übergabe von Parametern über benannte Parameter, nicht durch Verkettung. Query Builder (Knex, jOOQ) parametrisieren Abfragen standardmäßig ebenfalls, wenn keine Raw-Methoden verwendet werden.

Zeichenketten-Escaping (nicht als primäre Methode empfohlen)

Das Escaping von Sonderzeichen (mysql_real_escape_string) ist eine veraltete Methode, die nicht vor allen Arten von SQL Injection schützt. Das Problem: Das Escaping hängt von der Kodierung ab und kann bei Verwendung von Multibyte-Kodierungen (z. B. GBK in asiatischen Systemen) umgangen werden. Verwenden Sie Escaping nur in Legacy-Code, wo Parametrisierung nicht möglich ist, und immer in Kombination mit strenger Eingabetyp-Validierung.

Prinzip der geringsten Privilegien für die DB

Das Anwendungskonto sollte minimal notwendige Berechtigungen haben: SELECT, INSERT, UPDATE, DELETE — nur auf Tabellen, die die Anwendung tatsächlich benötigt. Untersagen Sie die Verwendung von DROP, TRUNCATE, CREATE für das Anwendungskonto. Dies begrenzt den Schaden selbst bei einer erfolgreichen SQL Injection: Der Angreifer kann keine Tabellen löschen oder administrative Operationen ausführen.

Werkzeuge zur Erkennung von SQL-Injektionen

Regelmäßige SQL Injection-Tests sollten Teil der sicheren Entwicklungspipeline sein. Eine Kombination aus statischer Analyse, dynamischem Scannen und manuellen Penetrationstests liefert die besten Ergebnisse. Laut dem Synopsys Cybersecurity Report (2025) finden automatisierte Scanner bis zu 70% der SQLi-Schwachstellen, aber komplexe Blind-Angriffe erfordern manuelle Tests.

• sqlmap — das beliebteste Tool zur automatischen Erkennung und Ausnutzung von SQL Injection
• OWASP ZAP — ein kostenloser DAST-Scanner mit aktiven SQLi-Scanmodulen
• Burp Suite Scanner — ein professionelles Tool mit automatischer SQL Injection-Erkennung
• SonarQube — statische Code-Analyse auf Schwachstellen, einschließlich SQLi-Muster
• CodeQL — semantische Code-Analyse zum Auffinden von SQL-Injektionen im Quellcode

Für mobile Anwendungen ist auch die Analyse der lokalen SQLite wichtig: Überprüfen Sie alle rawQuery-Aufrufe, ContentProvider-Abfragen und Room-Abfragen mit rawQuery. Tools: Android Studio Lint (erkennt SQLi in SQLite), MobSF (Mobile Security Framework) für die automatische statische und dynamische Analyse von APK/IPA. Es wird auch empfohlen, API-Endpunkte über sqlmap mit Proxy-Abfang des Datenverkehrs der mobilen Anwendung zu testen.