SQL Injection

SQL Injection (SQLi) ist eine der ältesten und gefährlichsten Sicherheitslücken in Webanwendungen. Bei diesem Angriff schleusen Angreifer schadhaften SQL-Code in Eingabefelder ein, um unbefugt auf Datenbanken zuzugreifen, Daten zu manipulieren oder zu löschen. Die OWASP (Open Web Application Security Project) listet SQL Injection seit Jahren unter den kritischsten Sicherheitsrisiken für Webanwendungen.

SQL Injection funktioniert, weil viele Anwendungen Benutzereingaben direkt in SQL-Abfragen einbauen, ohne diese vorher zu prüfen oder zu bereinigen. Stell dir vor, ein Login-Formular nimmt deinen Benutzernamen und baut daraus eine Datenbankabfrage. Wenn niemand prüft, ob du tatsächlich nur einen Namen eingegeben hast, kannst du stattdessen SQL-Befehle einschleusen, die die Abfrage verändern.

So funktioniert ein SQL-Injection-Angriff

Um SQL Injection zu verstehen, schauen wir uns ein typisches Beispiel an. Eine Webanwendung hat ein Login-Formular, das Benutzername und Passwort abfragt. Im Hintergrund wird folgende SQL-Abfrage ausgeführt:

SELECT * FROM users WHERE username = 'eingabe' AND password = 'passwort';

Ein Angreifer gibt nun als Benutzernamen nicht einen normalen Namen ein, sondern:

admin' --

Die resultierende SQL-Abfrage sieht dann so aus:

SELECT * FROM users WHERE username = 'admin' -- ' AND password = 'beliebig';

Das Doppelminus (--) ist ein SQL-Kommentar. Alles danach wird ignoriert, also auch die Passwortprüfung. Der Angreifer erhält Zugang zum Admin-Konto, ohne das Passwort zu kennen. Mit diesem einfachen Trick umgeht er die komplette Authentifizierung.

Arten von SQL-Injection-Angriffen

Je nach Angriffstechnik und Rückmeldung der Anwendung unterscheidet man verschiedene SQL-Injection-Typen. Das Verständnis dieser Varianten hilft dir, Sicherheitslücken besser zu erkennen und zu beheben.

In-Band SQL Injection (klassisch)

Bei der klassischen SQL Injection erhält der Angreifer die Ergebnisse direkt in der Antwort der Webanwendung. Eine verbreitete Technik ist die UNION-basierte Injection: Der Angreifer nutzt den UNION-Operator, um zusätzliche Abfragen anzuhängen und Daten aus anderen Tabellen auszulesen.

SELECT name, preis FROM produkte WHERE id = 1 UNION SELECT username, password FROM users --

Diese Abfrage hängt die Benutzer-Tabelle an die Produktabfrage an. Die Benutzernamen und Passwörter erscheinen dann in der normalen Produktansicht.

Blind SQL Injection

Bei Blind SQL Injection zeigt die Anwendung keine Fehlermeldungen oder Abfrageergebnisse direkt an. Der Angreifer muss stattdessen indirekt auf den Erfolg seiner Abfragen schließen. Es gibt zwei Hauptvarianten:

• Boolean-Based: Der Angreifer stellt Ja/Nein-Fragen an die Datenbank und beobachtet, ob sich die Seite ändert. Zeigt die Seite bei 1=1 (wahr) andere Inhalte als bei 1=2 (falsch), ist die Anwendung anfällig.
• Time-Based: Der Angreifer fügt Befehle ein, die die Datenbank verzögern (z.B. SLEEP(5)). Dauert die Antwort länger, weiß er, dass sein Code ausgeführt wurde.

Stored SQL Injection (Second-Order)

Bei Stored SQL Injection wird der schadhafte Code zunächst in der Datenbank gespeichert und erst später ausgeführt. Ein Angreifer trägt beispielsweise einen manipulierten Namen bei der Registrierung ein. Wenn ein Administrator später die Benutzerliste abruft, wird der eingebettete SQL-Code ausgeführt. Diese Variante ist besonders tückisch, weil zwischen Einschleusung und Ausführung Zeit vergeht.

Mögliche Schäden durch SQL Injection

Die Auswirkungen einer erfolgreichen SQL Injection können verheerend sein. Je nach Datenbankberechtigungen und Systemkonfiguration kann ein Angreifer:

• Daten auslesen: Kundendaten, Passwörter, Geschäftsgeheimnisse, personenbezogene Daten (Verstoß gegen DSGVO)
• Daten manipulieren: Preise ändern, Kontodaten fälschen, Berechtigungen erweitern
• Daten löschen: Komplette Datenbanken leeren (DROP TABLE)
• Systembefehle ausführen: Bei manchen Datenbanksystemen können Angreifer über SQL auch Betriebssystembefehle ausführen
• Weitere Systeme angreifen: Die kompromittierte Datenbank als Sprungbrett für Angriffe auf andere Server nutzen

Schutzmaßnahmen gegen SQL Injection

SQL Injection lässt sich mit den richtigen Programmiertechniken zuverlässig verhindern. Die wichtigste Maßnahme sind Prepared Statements, ergänzt durch weitere Schutzmechanismen.

Prepared Statements (parametrisierte Abfragen)

Prepared Statements sind der wirksamste Schutz gegen SQL Injection. Bei dieser Technik wird die SQL-Struktur von den Benutzerdaten getrennt. Die Datenbank erhält zuerst die Abfrage mit Platzhaltern, dann die Werte. Die Datenbank behandelt die Werte dadurch immer als Daten, niemals als ausführbaren Code.

Hier ein Beispiel in PHP mit PDO:

// UNSICHER - anfällig für SQL Injection
$sql = "SELECT * FROM users WHERE username = '" . $_POST['user'] . "'";

// SICHER - mit Prepared Statement
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$_POST['user']]);

Auch andere Programmiersprachen bieten Prepared Statements: In Java mit JDBC, in Python mit DB-API, in C# mit ADO.NET. Die OWASP SQL Injection Prevention Cheat Sheet bietet Beispiele für alle gängigen Sprachen.

Weitere Schutzmaßnahmen

Neben Prepared Statements solltest du weitere Maßnahmen umsetzen, um die Informationssicherheit deiner Anwendung zu erhöhen:

• Eingabevalidierung: Prüfe Benutzereingaben auf erlaubte Zeichen, Länge und Format. Eine Postleitzahl sollte nur Ziffern enthalten, eine E-Mail-Adresse muss ein bestimmtes Format haben.
• Principle of Least Privilege: Der Datenbankbenutzer der Anwendung sollte nur die minimal notwendigen Rechte haben. Eine Webanwendung braucht selten DROP- oder DELETE-Rechte auf allen Tabellen.
• Fehlerbehandlung: Zeige Benutzern niemals technische Fehlermeldungen mit SQL-Details an. Diese helfen Angreifern, ihre Attacken zu verfeinern. Logge Fehler serverseitig und zeige dem Benutzer nur generische Meldungen.
• Web Application Firewall (WAF): Eine WAF kann bekannte SQL-Injection-Muster erkennen und blockieren. Sie ist eine sinnvolle Ergänzung, ersetzt aber nicht sichere Programmierung.

SQL Injection erkennen und testen

Um Schwachstellen in deinen eigenen Anwendungen zu finden, gibt es verschiedene Testmethoden. Wichtig: Teste nur Anwendungen, für die du eine Berechtigung hast. Unautorisierte Tests sind strafbar.

• Manuelle Tests: Gib in Eingabefelder Sonderzeichen wie ', ", --, ; DROP TABLE ein und beobachte die Reaktion
• Automatisierte Scanner: Tools wie OWASP ZAP oder SQLMap prüfen Webanwendungen automatisch auf SQL-Injection-Schwachstellen
• Code-Review: Durchsuche den Quellcode nach direkter String-Verkettung in SQL-Abfragen
• Statische Code-Analyse: Tools wie SonarQube erkennen unsichere Datenbankzugriffe automatisch

SQL Injection in der Praxis

SQL Injection ist ein zentrales Thema in der IT-Sicherheit. Wer als Fachinformatiker für Anwendungsentwicklung Webanwendungen entwickelt, muss sichere Datenbankzugriffe beherrschen. Prepared Statements sollten zur Standardpraxis gehören. Auch Fachinformatiker für Systemintegration benötigen dieses Wissen, um Web Application Firewalls zu konfigurieren und Sicherheitsaudits durchzuführen.

Trotz des Alters dieser Angriffsmethode bleiben SQL-Injection-Schwachstellen weit verbreitet. Die OWASP listet Injection-Angriffe seit über 20 Jahren unter den Top-10-Sicherheitsrisiken. Viele erfolgreiche Hackerangriffe auf Unternehmen und Behörden nutzen diese Lücke.

Quellen und weiterführende Links

• OWASP SQL Injection - Umfassende Referenz der Open Web Application Security Project
• OWASP SQL Injection Prevention Cheat Sheet - Praktische Anleitungen zur Absicherung
• PHP-Dokumentation zu SQL Injection - Offizielle PHP-Sicherheitshinweise
• Microsoft Learn: SQL Injection - Microsoft-Dokumentation
• Wikipedia: SQL-Injection - Allgemeine Einführung