SQL-Injection
Angriffstechnik, bei der manipulierte SQL-Befehle über Benutzereingaben in eine Datenbank eingeschleust werden, um Daten auszulesen, zu verändern oder zu löschen.
SQL-Injection (SQLi) ist eine Angriffstechnik, bei der ein Angreifer manipulierte SQL-Befehle über Eingabefelder, URL-Parameter oder API-Schnittstellen in eine Datenbankanfrage einschleust. Die Anwendung behandelt die Eingabe fälschlicherweise als Teil des SQL-Befehls statt als Daten. Das Ergebnis reicht vom unbefugten Auslesen sensibler Daten über das Manipulieren oder Löschen ganzer Tabellen bis hin zur vollständigen Übernahme des Datenbankservers. SQL-Injection zählt seit Jahren zu den kritischsten Schwachstellen in der OWASP Top 10.
Funktionsweise
Der Kern einer SQL-Injection liegt in der fehlenden Trennung zwischen Code und Daten. Wenn eine Webanwendung Benutzereingaben direkt in eine SQL-Abfrage einbaut — etwa einen Loginnamen in ein SELECT-Statement — kann ein Angreifer die Abfragelogik verändern. Ein klassisches Beispiel ist die Eingabe ' OR 1=1 -- in ein Loginformular: Die Bedingung wird immer wahr, der Kommentar schneidet den Rest der Abfrage ab, und der Angreifer erhält Zugriff ohne gültiges Passwort. In der Praxis sind die Techniken deutlich ausgefeilter, aber das Grundprinzip bleibt identisch.
Typen von SQL-Injection
Es gibt drei Hauptkategorien, die sich in der Art der Datenexfiltration unterscheiden. Bei der klassischen In-Band-SQLi sieht der Angreifer die Ergebnisse direkt in der HTTP-Antwort — entweder als Union-based SQLi, bei der Ergebnisse an eine bestehende Abfrage angehängt werden, oder als Error-based SQLi, bei der Datenbankfehlermeldungen verwertbare Informationen preisgeben. Blind SQLi liefert keine sichtbare Ausgabe: Der Angreifer erschließt Informationen durch Boolean-based-Techniken (unterschiedliche Antworten je nach wahr/falsch) oder Time-based-Techniken (messbare Verzögerungen durch SLEEP-Befehle). Out-of-Band SQLi nutzt alternative Kanäle wie DNS-Anfragen, um Daten aus abgeschotteten Umgebungen zu exfiltrieren.
Schutzmaßnahmen
Die wirksamste Gegenmaßnahme sind Prepared Statements mit parametrisierten Abfragen. Dabei werden Benutzereingaben konsequent als Daten behandelt und nie als ausführbarer Code interpretiert. Stored Procedures bieten einen ähnlichen Schutz, sofern sie intern keine dynamischen Abfragen zusammenbauen. Eingabevalidierung mit strikten Allowlists ergänzt diese Maßnahmen, ersetzt sie aber nicht — Blocklisten einzelner Sonderzeichen lassen sich in der Praxis fast immer umgehen. Auf Datenbankebene sollte die Anwendung nur mit minimalen Rechten arbeiten (Least Privilege), sodass selbst eine erfolgreiche Injection keinen Zugriff auf administrative Funktionen erhält.
Erkennung und Monitoring
Web Application Firewalls (WAFs) erkennen gängige SQLi-Muster in HTTP-Requests und blockieren sie, bevor sie die Anwendung erreichen. Sie sind eine sinnvolle zusätzliche Schutzschicht, ersetzen aber keine sichere Programmierung — erfahrene Angreifer können WAF-Regeln durch Encoding-Tricks, Kommentare oder alternative SQL-Syntax umgehen. Auf Datenbankebene hilft das Monitoring ungewöhnlicher Abfragen: Massenhafte UNION SELECT-Statements, SLEEP-Aufrufe oder Zugriffe auf Systemtabellen wie information_schema sind starke Indikatoren für einen laufenden SQLi-Angriff. Ein SIEM kann diese Signale mit Webserver-Logs korrelieren und automatisiert Alarm schlagen.
Moderne Angriffsflächen
SQL-Injection ist keineswegs ein Relikt vergangener Tage. Wir finden in Assessments regelmäßig SQLi-Schwachstellen in Legacy-Anwendungen, eigenentwickelter Software und Drittanbieter-Plugins. Besonders kritisch sind ORM-Umgehungen, bei denen Entwickler trotz Object-Relational Mapping auf Raw-Queries zurückgreifen, sowie Second-Order-Injections, bei denen gespeicherte Eingaben erst bei späterer Verarbeitung zur Injection führen. Auch REST- und GraphQL-APIs sind betroffen, wenn Backend-Filter nicht parametrisiert sind.
Automatisierte SQLi-Tools
Werkzeuge wie sqlmap automatisieren das Auffinden und Ausnutzen von SQL-Injection-Schwachstellen und senken die Einstiegshürde für Angreifer erheblich. Sie erkennen den Datenbanktyp automatisch, identifizieren verwundbare Parameter und extrahieren Daten systematisch — inklusive Passwort-Hashes und Datenbankstruktur. In Penetrationstests sind diese Tools Standard, um die tatsächliche Ausnutzbarkeit einer Schwachstelle zu demonstrieren. Gleichzeitig unterstreicht ihre Verfügbarkeit, warum präventive Maßnahmen wie Prepared Statements nicht verhandelbar sind.
Relevanz für KMUs
Für mittelständische Unternehmen ist SQL-Injection besonders gefährlich, weil viele Geschäftsanwendungen — von Webshops über Kundenportale bis zu internen Verwaltungstools — auf relationalen Datenbanken basieren. Ein erfolgreicher Angriff kann personenbezogene Daten offenlegen und damit DSGVO-Meldepflichten auslösen. Regelmäßige Penetrationstests decken SQLi-Schwachstellen auf, bevor Angreifer sie finden. Ergänzend hilft konsequentes Patch-Management bei Drittanbieter-Software, da bekannte SQLi-Lücken häufig über öffentliche Exploits ausgenutzt werden.