Das gemeinsame Muster aller Injection-Arten
Ob SQL, Command, NoSQL, Template oder LDAP Injection – das Grundproblem ist immer gleich: Nutzereingaben werden nicht als Daten behandelt, sondern als Befehle interpretiert.
Die wichtigste Lehre lautet also: Trenne strikt zwischen Daten und Code.
Parametrisierung ist der Goldstandard
Die sicherste Methode gegen Injection ist die Verwendung von parametrisierten Abfragen oder Prepared Statements.
Beispiel: SQL
❌ Unsicher:
$query = "SELECT * FROM users WHERE name = '" . $username . "'";
✅ Sicher:
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?");
$stmt->execute([$username]);
Beispiel: NoSQL (MongoDB)
❌ Unsicher:
db.users.find({ username: req.body.username });
✅ Sicher (Schema-Validierung):
db.users.find({ username: String(req.body.username) });
Das Prinzip: Eingaben werden nicht als Teil des Befehls interpretiert, sondern als Wert gebunden.
Input-Validierung und Whitelisting
Parametrisierung ist die erste Verteidigungslinie. Zusätzlich gilt: Eingaben validieren.
- Whitelist statt Blacklist: Lieber erlaubte Muster definieren (
^[a-zA-Z0-9]+$) als versuchen, böse Zeichen zu blocken. - Typ-Prüfung: Wenn eine Zahl erwartet wird, Eingaben strikt in Integer konvertieren.
- Längenbeschränkung: Kein 10.000-Zeichen-Input in einem „Name“-Feld.
Beispiel: Eine Ping-Funktion sollte nur IPv4-Adressen akzeptieren – alles andere wird blockiert.
Least Privilege in allen Schichten
Egal ob Datenbank, LDAP oder Betriebssystem: Der technische Benutzer sollte so wenig Rechte wie möglich haben.
- SQL-Datenbank: App-User darf SELECT und INSERT, aber kein DROP TABLE.
- Betriebssystem: Webserver läuft nicht als root.
- LDAP: Bind-User darf nur in einem bestimmten Bereich lesen, nicht Admin-Rechte nutzen.
So bleibt der Schaden begrenzt, selbst wenn ein Angriff gelingt.
Escaping als Zusatzmaßnahme
Escaping ist nützlich, aber kein Ersatz für Parametrisierung.
- HTML-Escaping verhindert XSS.
- SQL-Escaping (
mysqli_real_escape_string) kann helfen, ist aber fehleranfällig. - Bei Template-Engines sollte Autoescaping aktiviert sein.
Regel: Parametrisierung zuerst, Escaping als Ergänzung.
Logging, Monitoring und Tests
Injection lässt sich nicht nur durch präventive Maßnahmen abwehren – auch das Erkennen von Angriffen ist wichtig.
- Logging: Unerwartete Inputs (z. B.
{{7*7}},' OR '1'='1) im Log speichern. - Monitoring: Alerts auslösen bei ungewöhnlich vielen Fehlern oder langen Response-Zeiten (→ Time-Based Injection).
- Tests:
- Automatisiert mit Tools wie OWASP ZAP oder SQLMap.
- Manuell in Code Reviews: „Wird Input hier direkt in einen Befehl eingebaut?“
Typische Entwickler-Fehler vermeiden
- „Das Formular ist intern, da kommt kein Angreifer ran.“ – Falsch, interne Nutzer können neugierig sein.
- „Wir escapen einfach alles.“ – Unsicher, weil leicht fehleranfällig.
- „UUIDs oder Hashes reichen als Schutz.“ – Sie erschweren Angriffe, verhindern sie aber nicht.
Ressourcen zum Weiterlernen
- OWASP Injection Cheat Sheet
- PortSwigger Web Security Academy: Interaktive Labs zu SQLi, NoSQLi, SSTI usw.
- OWASP Juice Shop: Absichtlich unsichere Web-App mit vielen Injection-Beispielen.
- PayloadAllTheThings (GitHub): Riesige Sammlung von Injection-Payloads für Tests.
Was du mitnehmen solltest
- Injection entsteht immer dann, wenn Eingaben nicht strikt von Befehlen getrennt sind.
- Parametrisierung ist die wichtigste Verteidigung – kombiniert mit Whitelisting und Least Privilege.
- Escaping, Logging und Monitoring ergänzen den Schutz.
- Sicherheit ist kein Einmal-Fix, sondern ein Prozess: Code Reviews, Tests und Schulungen halten das Risiko gering.
Damit ist unsere Blogserie über Injection komplett: Vom Grundprinzip über SQLi, Command & NoSQL bis zu Template- und LDAP-Injection – und wie man sich dagegen schützt.
Schreibe einen Kommentar