SQL-Injection
SQL-Injection injiziert schadhaften SQL-Code in Datenbank-Queries über ungefilterte User-Inputs. Ermöglicht Datenbank-Auslesung, -Löschung, Authentication-Bypass.
detaillierte erklärung
SQL-Injection (SQLi) ist eine Injection-Schwachstelle, bei der Angreifer SQL-Befehle in Eingabefelder einschleusen, die ungefiltert in Queries eingebaut werden. Beispiel: SELECT * FROM users WHERE username = 'admin' AND password = 'x' OR '1'='1' -- '. Das OR '1'='1' macht die Bedingung immer wahr, -- kommentiert den Rest aus. Typen: 1) In-Band SQLi - Ergebnis direkt sichtbar (Error-based via Fehlermeldungen, Union-based via UNION SELECT). 2) Inferential SQLi (Blind) - kein direktes Feedback, nur True/False-Verhalten (Boolean-based, Time-based via SLEEP()). 3) Out-of-Band - Daten via DNS/HTTP exfiltriert. Konsequenzen: Kompletter Datenbankzugriff, Admin-Account-Übernahme, Datenlöschung, Server-Kompromittierung via xp_cmdshell (MS SQL). Schutzmaßnahmen: Prepared Statements / Parameterized Queries (trennen Code von Daten), Input-Validation (Whitelist), Least-Privilege (DB-User braucht nicht DROP/CREATE-Rechte), Web Application Firewall (WAF).
warum ist das wichtig?
SQL-Injection ist seit Jahren in den OWASP Top 3 - du musst verstehen, wie Prepared Statements schützen und wie du SQLi-Tests mit sqlmap durchführst. Essentiell für jede Web-Security-Prüfung (CEH, OSCP-Web).
häufige fehler
- ⚠Input-Escaping reicht - Nein, Blacklist-Escaping ist bypassbar (Encoding, Obfuscation), nur Prepared Statements sind sicher
- ⚠Nur Login-Formulare sind anfällig - Nein, jede Stelle mit DB-Query (Search, Profile-Update, URL-Parameter)
- ⚠Nur String-Inputs sind anfällig - Nein, auch numerische Parameter (SELECT * FROM users WHERE id = 5 OR 1=1)