SQL Injection

SQL Injection zählt seit über zwanzig Jahren zu den häufigsten und schädlichsten Web-Schwachstellen. Der Angriff selbst ist erstaunlich einfach, seine Folgen reichen jedoch von einer geleakten Kundendatenbank bis zu einem vollständig übernommenen Server. Im Folgenden erfahren Sie, was genau dahintersteckt, wie ein Angriff abläuft und was Sie dagegen tun.

Was ist SQL Injection?

SQL Injection ist eine Schwachstelle, bei der ein Angreifer eigenen SQL-Code in eine Datenbankabfrage Ihrer Anwendung einschleust. Das gelingt, sobald eine Benutzereingabe (ein Suchbegriff, ein Anmeldename, ein Parameter in der URL) direkt in eine Abfrage eingefügt wird, ohne dass die Anwendung Daten und Befehle voneinander trennt.

Ein Vergleich aus dem Alltag: Sie diktieren einem Kellner eine Bestellung und sagen “einen Kaffee, und ignorieren Sie außerdem alle Bestellungen von Tisch vier”. Ein aufmerksamer Kellner notiert diesen ganzen Satz als Ihre Bestellung. Ein naiver Kellner führt den zweiten Teil als Anweisung aus. Eine Datenbank, die Daten und Befehle nicht trennt, ist dieser naive Kellner: Alles, was hereinkommt, kann zu einem Befehl werden.

Das Wort “Injection” beschreibt genau diese Verwechslung: Der Angreifer schleust eigene Anweisungen in einen Satz ein, den die Entwickler als harmlose Daten gemeint hatten. Die Schwachstelle steckt also nicht in SQL selbst, sondern darin, wie die Anwendung die Abfrage zusammensetzt. Jede Stelle, an der eine Eingabe eine Abfrage, einen Filter oder eine Sortierreihenfolge beeinflusst, ist ein möglicher Angriffspunkt.

Wie funktioniert ein SQL-Injection-Angriff?

Der Kern des Problems liegt darin, dass die Abfrage als Text zusammengesetzt wird, indem man Benutzereingaben aneinanderreiht. Nehmen wir ein klassisches Anmeldeformular, das die eingegebene E-Mail und das Passwort direkt in die Abfrage übernimmt.

Verwundbar:

// Benutzereingaben werden direkt in die Abfrage eingefügt
const email = req.body.email;
const password = req.body.password;

const query =
  "SELECT * FROM users WHERE email = '" + email + "' AND password = '" + password + "'";

const rows = await db.query(query);
if (rows.length > 0) {
  // Zugriff gewährt
}

Gibt ein normaler Benutzer seine E-Mail-Adresse ein, funktioniert das einwandfrei. Ein Angreifer tippt in das E-Mail-Feld jedoch keine Adresse, sondern ' OR '1'='1' --. Die Abfrage, die die Datenbank schließlich zu sehen bekommt, lautet dann:

SELECT * FROM users WHERE email = '' OR '1'='1' --' AND password = '...'

Das eingeschleuste OR '1'='1' ist immer wahr, und der doppelte Bindestrich -- macht den Rest der Zeile zu einem Kommentar, sodass die Passwortprüfung vollständig entfällt. Die Datenbank liefert alle Zeilen zurück, und der Angreifer ist angemeldet, meist als erster Benutzer der Tabelle, und das ist häufig ein Administrator.

Die Lösung besteht darin, Eingaben niemals als Code zu behandeln. Mit einem Prepared Statement (einer parametrisierten Abfrage) senden Sie die Abfrage und die Werte getrennt an die Datenbank. Die Platzhalter ? werden mit Daten gefüllt, die niemals als SQL interpretiert werden.

Sicher:

// Abfrage und Werte gehen getrennt an die Datenbank
const email = req.body.email;
const password = req.body.password;

const query =
  "SELECT * FROM users WHERE email = ? AND password = ?";

const rows = await db.query(query, [email, password]);
if (rows.length > 0) {
  // Zugriff gewährt
}

Jetzt ist ' OR '1'='1' -- einfach eine E-Mail-Adresse, die nicht existiert, und der Anmeldeversuch scheitert, wie er soll. Die Datenbank weiß genau, welcher Teil Befehl und welcher Teil Daten ist, genau die Trennung, die den Angriff unmöglich macht.

Welche Auswirkungen hat SQL Injection?

Der Schweregrad hängt davon ab, was die Abfrage darf und wie die Datenbank eingerichtet ist, doch die Reichweite ist groß. Im günstigsten Fall liest ein Angreifer Daten aus, die nicht für ihn bestimmt sind: Kundendaten, Passwort-Hashes, Bestellhistorie. Mit einer angepassten Abfrage kann er Datensätze auch ändern oder löschen, Preise manipulieren oder sich selbst Administratorrechte verschaffen.

Häufig bleibt es nicht dabei. Über die Authentifizierungsumgehung aus dem Beispiel meldet sich ein Angreifer ohne gültige Zugangsdaten an. In bestimmten Konfigurationen reicht die Auswirkung bis zum darunterliegenden System: das Auslesen von Serverdateien, das Ablegen einer Web-Shell oder das Ausführen von Betriebssystembefehlen. Damit wird aus einem “Datenleck” eine “vollständige Übernahme”, mit allen rechtlichen und Reputationsfolgen.

Ein zusätzliches Risiko besteht darin, dass eine erfolgreiche SQL Injection selten auffällige Spuren hinterlässt: Die Abfrage kommt über ein legitimes Eingabefeld herein und sieht in den Protokollen wie normaler Datenverkehr aus. Angreifer nutzen diese Unauffälligkeit, um über längere Zeit Daten abzugreifen. Weil die Schwachstelle vom bloßen Einsehen von Daten bis zur Ausführung von Code auf dem Server reicht, bewegt sich der Schweregrad von hoch bis kritisch.

Wie erkennen Sie SQL Injection?

Ein erstes Signal ist klassisch: Geben Sie ein einzelnes Anführungszeichen (') in ein Eingabefeld ein und prüfen Sie, ob die Anwendung einen Datenbankfehler zurückgibt. Eine sichtbare SQL-Fehlermeldung verrät, dass Ihre Eingabe die Abfrage erreicht. Modernere Fälle sind subtiler: bei Blind SQL Injection gibt es keine Fehlermeldung, und ein Tester misst stattdessen das Verhalten: eine Abfrage, die die Antwort absichtlich verzögert, oder eine Bedingung, die das Ergebnis gerade noch verändert oder eben nicht.

Automatisierte Scanner und Werkzeuge wie sqlmap finden viele dieser Fälle, übersehen aber die Schwachstellen, die hinter der Authentifizierung, in komplexen Abläufen oder in Eingaben zweiter Ordnung stecken. Ein gründlicher Penetrationstest verbindet daher Automatisierung mit manueller Untersuchung. Genau diese Art von Schwachstelle spürt AssistSec bei einer Sicherheitsuntersuchung gezielt auf und reproduziert sie nachvollziehbar, damit Sie wissen, welche Abfragen sich tatsächlich missbrauchen lassen.

Wie verhindern Sie SQL Injection?

• Verwenden Sie immer parametrisierte Abfragen oder Prepared Statements. Das ist die wichtigste Maßnahme und behebt das Problem an der Wurzel.
• Setzen Sie auf ein ausgereiftes ORM oder einen Query-Builder und vermeiden Sie es, rohes SQL selbst zusammenzusetzen. Fügen Sie dennoch einzelne Fragmente hinzu, parametrisieren Sie auch diese.
• Wenden Sie das Prinzip der geringsten Rechte an. Lassen Sie die Anwendung mit einem Datenbankbenutzer verbinden, der nur das darf, was nötig ist, kein DROP, kein Zugriff auf Systemtabellen.
• Validieren Sie Eingaben nach Typ und Format als zusätzliche Schicht: Erwarten Sie eine Zahl, akzeptieren Sie nur eine Zahl. Das ergänzt die Parametrisierung, ersetzt sie aber nicht.
• Zeigen Sie niemals rohe Datenbankfehler an den Benutzer; protokollieren Sie sie intern. Fehlermeldungen sind ein Geschenk für den Angreifer.
• Setzen Sie eine Web Application Firewall als zusätzliche Schicht ein, verlassen Sie sich aber nicht auf sie als einzige Verteidigung.
• Lassen Sie den Code regelmäßig testen. Ein gezielter Penetrationstest und ein Code-Review fangen die Fälle ab, die Scanner überspringen.