Glossar · einfach erklärt

SQL-Injection

SQL-Injection schleust Datenbankbefehle über Eingabefelder ein — seit Jahrzehnten bekannt und immer noch in den Top-Risiken.

SQL-Injection (SQLi) ist das Einschleusen von Datenbankbefehlen über Eingaben einer Anwendung: Wird Nutzereingabe ungeprüft in SQL-Abfragen eingebaut, kann ein Angreifer die Abfrage umschreiben — Daten auslesen, verändern, löschen oder die Authentifizierung umgehen.

Trotz jahrzehntelanger Bekanntheit gehört SQLi weiter zu den OWASP-Top-Risiken: Altanwendungen, zusammengekaufte Systeme und schnelle Erweiterungen liefern verwundbaren Code nach — und automatisierte Scanner finden ihn zuverlässig.

Wie SQL-Injection funktioniert

Das klassische Beispiel: Ein Login baut die Abfrage aus Benutzereingaben zusammen. Die Eingabe eines präparierten Ausdrucks macht die Passwortprüfung wahr — der Angreifer ist angemeldet. Fortgeschrittene Varianten lesen per UNION fremde Tabellen aus oder arbeiten blind über Zeitverzögerungen, wenn die Anwendung keine Fehler verrät.

Die saubere Lösung liegt im Code: parametrisierte Abfragen (Prepared Statements) trennen Befehl und Daten strikt — Eingaben können die Abfrage dann nicht mehr verändern. Eine WAF ergänzt als zweite Schicht: Sie blockt bekannte Injektionsmuster und schirmt frisch gemeldete Lücken ab, bis der Code gepatcht ist.

Schutz in der Tiefe

Prepared Statements überall — keine zusammengesetzten SQL-Strings.
Minimalrechte für Datenbankkonten der Anwendung: nur nötige Tabellen und Operationen.
WAF mit Managed Rules als Schutzschicht vor Alt- und Fremdcode.
Fehlermeldungen kargen halten: keine SQL-Details an den Client.

Häufige Fragen zu SQL-Injection

Warum gibt es SQL-Injection immer noch?

Weil verwundbarer Code langlebig ist: Altanwendungen, Plugins, zugekaufte Systeme und Eile produzieren weiter zusammengesetzte Abfragen. Angreifer scannen automatisiert danach — die Lücke von gestern ist morgen gefunden. Deshalb braucht es Code-Hygiene plus Schutzschicht.

Verhindert eine WAF SQL-Injection zuverlässig?

Sie blockt bekannte Muster sehr wirksam und schirmt neue CVEs per virtuellem Patchen ab — ein entschlossener Angreifer mit Zeit kann Filter aber umgehen. Die WAF ist die wichtige zweite Schicht; die erste bleibt sauberer Code mit parametrisierten Abfragen.

Was sind Prepared Statements?

Abfragen mit Platzhaltern, bei denen die Datenbank Befehl und Daten getrennt erhält: Die Struktur der Abfrage steht fest, Eingaben werden nur noch als Werte behandelt. Damit ist klassische SQL-Injection konstruktiv ausgeschlossen — in praktisch jeder Sprache verfügbar.

Was ist Blind SQL-Injection?

Eine Variante ohne sichtbare Fehlermeldungen: Der Angreifer stellt Ja-Nein-Fragen über das Verhalten der Anwendung — etwa Antwortzeiten mit eingeschleusten Verzögerungen — und rekonstruiert Daten Bit für Bit. Langsamer, aber genauso wirksam und automatisierbar.

Wie finde ich SQLi-Lücken in meinen Anwendungen?

Durch Kombination: automatisierte Scanner für die Breite, Penetrationstests für die Tiefe, Code-Reviews an den Datenbankzugriffen. Für Systeme, die man nicht ändern kann, gilt: hinter die WAF, Rechte minimieren und Zugriff auf das Nötigste beschränken.