Was ist SQL Injection?

SQL Injection entsteht, wenn eine Anwendung nicht vertrauenswürdige Eingaben in eine SQL-Anweisung einsetzt, statt sie ausschließlich als Daten zu behandeln. Ein Angreifer verändert damit die Abfragelogik, liest Datensätze, umgeht Prüfungen oder manipuliert und löscht Daten. Bei ungünstiger Datenbankkonfiguration reicht der Angriff unter Umständen über die Datenbank hinaus.

Die Schwachstelle beschränkt sich nicht auf Login-Formulare. Suchfelder, Sortierparameter, API-Filter, Berichtsgeneratoren und Hintergrundimporte können ebenfalls Einstiegspunkte sein. Fehlerfreie beziehungsweise blinde SQL Injection nutzt Unterschiede in Antworten oder Laufzeiten und bleibt im Seiteninhalt möglicherweise unsichtbar.

Wie lässt sich SQL Injection verhindern?

• - Für jeden Datenwert parametrisierte Abfragen beziehungsweise Prepared Statements verwenden.
• - Bezeichner wie auswählbare Spaltennamen über eine Positivliste begrenzen; sie lassen sich meist nicht als Werte binden.
• - Dem Datenbankkonto nur die Berechtigungen geben, die die Anwendung tatsächlich benötigt.
• - Eingaben validieren und detaillierte Datenbankfehler als zusätzliche Maßnahme unterdrücken.

Codebeispiel: Stringverkettung und Prepared Statement

Verwundbar: Die Eingabe wird Teil der SQL-Syntax.

$email = $_GET['email'];
$sql = "SELECT id, email FROM users WHERE email = '$email'";
$user = $pdo->query($sql)->fetch();

Sicher: SQL-Struktur und Daten werden getrennt übertragen.

$statement = $pdo->prepare(
    'SELECT id, email FROM users WHERE email = :email'
);
$statement->execute(['email' => $_GET['email']]);
$user = $statement->fetch();

Parameterbindung ist die eigentliche Behebung. Manuelles Escaping und Sperrlisten bekannter Zeichen bleiben fehleranfällig. Dynamische Spalten oder Sortierrichtungen werden nicht gebunden, sondern über eine feste Zuordnung ausgewählt.

Sind ORMs automatisch sicher?

ORMs binden normale Werte sicher. Raw Expressions, per String aufgebaute Sortierung und eigene Abfragen können SQL Injection jedoch wieder ermöglichen. Entscheidend ist, ob eine nicht vertrauenswürdige Eingabe Teil der SQL-Syntax wird.

Welche Arten von SQL Injection gibt es?

Bei einer In-Band-SQL-Injection erscheinen Daten oder Datenbankfehler direkt in der Antwort. UNION-Abfragen können Ergebnisse einer zweiten Abfrage anhängen. Eine blinde SQL Injection verrät Informationen über unterschiedliche Antworten oder bewusst ausgelöste Verzögerungen. Out-of-Band-Techniken übertragen Daten über DNS oder andere externe Verbindungen. Welche Variante möglich ist, hängt von Datenbank, Treiber, Abfrage und Berechtigungen ab.

Konkretes Beispiel

Baut eine Anwendung SELECT * FROM users WHERE email = 'EINGABE' per String zusammen, kann ein Apostroph die Datenebene verlassen und die SQL-Syntax verändern. Das konkrete Angriffsmuster ist weniger wichtig als die Ursache: Eingabe und Befehl wurden vermischt. Bei einem Prepared Statement sendet der Treiber Abfragestruktur und Parameter getrennt. Der Wert bleibt ein Wert, selbst wenn er SQL-Zeichen enthält.

Auswirkungen und Reichweite

Mögliche Folgen reichen vom Auslesen einzelner Tabellen über die Umgehung eines Logins bis zur vollständigen Veränderung oder Löschung von Daten. Besitzt das Datenbankkonto weitreichende Rechte, können gespeicherte Prozeduren, Dateizugriffe oder Betriebssystemfunktionen den Schaden vergrößern. Segmentierung und restriktive Datenbankkonten begrenzen den Radius, beheben die Injection selbst aber nicht.

Wie wird SQL Injection zuverlässig getestet?

Tests betrachten alle Datenquellen, nicht nur sichtbare Formulare: JSON-Felder, Header, Cookies, gespeicherte Werte und asynchron verarbeitete Importe gehören dazu. Auffällige Fehler, veränderte Ergebnismengen und reproduzierbare Zeitunterschiede sind Hinweise, aber noch kein Beweis. Im Code wird zusätzlich nach dynamischen Abfragen, Raw Expressions und variablen Spaltennamen gesucht. Ein sicherer Test verwendet minimale Nachweise und vermeidet verändernde Payloads auf Produktivdaten.