blueredix logo
SCAN Schwachstellenscans auf Abruf ab 149 €
info vuln-class-sqli

SQL-Injection, verständlich erklärt

SQL-Injection erlaubt Angreifern, die Fragen umzuschreiben, die Ihre Anwendung an die Datenbank stellt. Im Erfolgsfall: jeder Datensatz aus jeder Tabelle, manchmal auch das Betriebssystem darunter.

Worum es geht

Eine Datenbank-Query ist die Frage, die Ihre Anwendung an die Datenbank stellt, etwa “gib mir die Nutzerin, deren Name Alice ist”. Die Anwendung baut die Query üblicherweise zur Laufzeit aus einer festen Vorlage und Benutzereingaben zusammen.

SQL-Injection entsteht, wenn die Benutzereingabe direkt in die Vorlage geklebt wird. Eingaben mit Query-Syntax werden so Teil der Frage, statt als Daten behandelt zu werden. Konkret: was die Anwendung als “gib mir die Nutzerin Alice” gemeint hat, macht der Angreifer zu “gib mir alle Nutzerinnen”.

Klassisches Mini-Beispiel. Die Anwendung tut:

"SELECT * FROM users WHERE name = '" + name + "'"

Der Angreifer tippt als Name ' OR '1'='1. Die Query wird zu:

SELECT * FROM users WHERE name = '' OR '1'='1'

und liefert alle Datensätze der Tabelle zurück.

Warum das wichtig ist

Was ein Angreifer aus einer erfolgreichen SQL-Injection gewinnt:

  • Jeden Datensatz jeder Tabelle lesen. Kundenlisten, Passwort-Hashes, Zahlungsdetails, interne Notizen. Fast jede Schlagzeile vom Typ “X Millionen Credentials geleakt” geht entweder auf eine SQL-Injection oder ein gestohlenes Backup zurück.
  • Sich als beliebige Person einloggen. Mit bekanntem Benutzernamen lässt sich eine Eingabe basteln, die den Passwort-Check unabhängig vom echten Passwort bestehen lässt.
  • Daten zerstören oder verfälschen. Eine geschickt formulierte Eingabe kann ein DROP TABLE oder ein UPDATE ohne Bedingungen auslösen.
  • Auf das Betriebssystem überspringen. Einige Datenbanken (älteres Microsoft SQL Server mit aktiviertem xp_cmdshell, PostgreSQL mit Schreibrechten auf Dateien) lassen aus SQL heraus Shell-Befehle laufen. Der Sprung von SQL-Injection zur vollen Server-Übernahme ist nicht selten.

Der Fix ist seit den frühen 2000ern bekannt und liegt jedem modernen Datenbank-Treiber bei. Dass SQL-Injection trotzdem unter den drei häufigsten Ursachen für Web-Breaches bleibt, liegt hauptsächlich an Legacy-Code, der nie migriert wurde, plus ein paar typischen Abkürzungen unter Termindruck.

Wie das im eigenen Code behoben wird

Die einzige Antwort heißt parametrisierte Queries (auch Prepared Statements), eine Schreibweise, in der Vorlage und Daten strikt getrennt bleiben, sodass Benutzereingaben nie Teil der Query-Syntax werden.

# Falsch: Eingabe in den Query-String gemischt
db.execute("SELECT * FROM users WHERE name = '" + name + "'")

# Richtig: Eingabe separat als Parameter übergeben
db.execute("SELECT * FROM users WHERE name = %s", (name,))

// Falsch
db.query(`SELECT * FROM users WHERE name = '${name}'`)

// Richtig
db.query('SELECT * FROM users WHERE name = $1', [name])

Konkret zu prüfen für Ihre Entwickler:innen:

  • Suchfilter und LIKE-Muster. Weiterhin parametrisieren; den Wert vor der Übergabe als Parameter in % einwickeln, nicht in die Vorlage kleben.
  • Dynamische Spalten- oder Tabellennamen. Parametrisierung greift hier nicht. Allowlist-Logik nutzen (nur bestimmte bekannte Spaltennamen werden akzeptiert) und den geprüften Wert direkt in die Vorlage einsetzen.
  • Raw-SQL-Escape-Hatches in ORMs. Die meisten Frameworks haben einen “Raw-Query”-Modus für Sonderfälle. Die Codebasis danach durchsuchen und jeden Treffer prüfen.
  • Stored Procedures mit EXEC oder EXECUTE. Sie umgehen oft die Framework-Parametrisierung. Separat reviewen.

Zusätzliche Schichten als Auffangnetz, falls die Parametrisierung einmal versagt:

  • Datenbank-Accounts mit minimalen Rechten. Die Anwendung verbindet mit einem Account, der nur das Nötige darf: SELECT und INSERT auf den eigenen Tabellen, sonst nichts. Kein DROP, keine Shell-Funktionen, kein Lesen fremder Tabellen.
  • WAF-Regeln als Backstop (Cloudflare, AWS WAF, ModSecurity). Sie ersetzen Parametrisierung nicht, kaufen aber Zeit, wenn ein 0-Day in einer Drittkomponente auftaucht.

Wie blueredix SQL-Injection meldet

Der Scanner versucht nicht aktiv, SQL in Ihre Live-Anwendung zu injizieren. Das ist eine potenziell datenzerstörende Operation und autorisierten Penetrationstests vorbehalten.

Was wir melden:

  • CVEs in Drittanbieter-Software (CMS, E-Commerce-Plattformen, Plugins, Admin-Panels), deren Beschreibung SQL-Injection nennt. Diese laufen über das normale CVE-Schema und verlinken zurück auf Wie man eine CVE liest.
  • Bekannte Muster in erkannten JavaScript-Bibliotheken mit dokumentierter SQL-Injection-Historie und verfügbarer Fix-Version.

Für einen echten Test der SQL-Injection-Resilienz Ihres eigenen Codes ist ein manueller Penetrationstest oder ein Werkzeug wie sqlmap (in einer Nicht-Produktionsumgebung, mit Berechtigung) der nächste Schritt.

Mehr dazu