SQL-Injection

Die SQL-Injection ist eine Angriffsklasse, bei der ein Angreifer eigene SQL-Anweisungen in eine Datenbankabfrage einer Anwendung einschleust. Möglich wird das, wenn die Anwendung Eingaben unverkettet in Abfragestrings einfügt, statt sie als Daten zu behandeln.

SQL-Injection ist eine der ältesten und folgenreichsten Schwachstellen im Web und steht seit Jahren in der OWASP Top 10. Erfolgreiche Angriffe können ganze Datenbanken auslesen, manipulieren oder löschen — und reichen je nach Datenbank-Berechtigungen bis zur Übernahme des Servers.

Ein einfaches Beispiel

Angenommen, eine Anwendung baut diese Abfrage:

SELECT * FROM users WHERE name = 'EINGABE' AND pwd = 'EINGABE';

Wird die Eingabe ungeschützt eingesetzt und ein Nutzer übergibt als Namen ' OR '1'='1, entsteht:

SELECT * FROM users WHERE name = '' OR '1'='1' AND pwd = '';

Die Bedingung '1'='1' ist immer wahr — die Authentifizierung kollabiert. Komplexere Varianten lesen Daten aus anderen Tabellen, schreiben oder löschen Datensätze oder geben Strukturinformationen preis.

Varianten

In der Praxis werden mehrere Spielarten unterschieden:

• Klassische Injection — Ergebnisse erscheinen direkt in der Antwort der Anwendung.
• Blind SQL-Injection — die Anwendung liefert keine Daten zurück, der Angreifer schließt aus dem Verhalten (Fehlermeldung, Antwortdauer) auf den Inhalt.
• Time-Based Blind — der Angreifer löst über SLEEP()-ähnliche Funktionen messbare Verzögerungen aus.
• Out-of-Band — Daten werden über DNS- oder HTTP-Anfragen aus der Datenbank heraus an einen vom Angreifer kontrollierten Server geschickt.

Schutzmaßnahmen

Wirksamer Schutz folgt einer einfachen Grundregel: Eingaben gehören niemals als Code in eine Abfrage.

• Prepared Statements / parametrisierte Abfragen — die Datenbank trennt Abfragestruktur und Werte sauber. Eingaben werden als Daten behandelt, nicht als SQL.
• ORMs — moderne Datenzugriffsschichten erzwingen parametrisierte Abfragen und vermeiden manuelles Zusammenbauen.
• Validierung — Typen, Längen und zulässige Werte prüfen, ohne sich darauf als alleinige Verteidigung zu verlassen.
• Geringste Rechte — der Datenbank-Account der Anwendung darf nur das, was die Anwendung tatsächlich braucht. Ein Angriff trifft dann auf eine kleinere Angriffsfläche.
• Fehlermeldungen nicht 1:1 an den Client durchreichen, da sie Strukturinformationen preisgeben.

Verwandte Klassen

Das Grundprinzip — Eingaben werden als ausführbarer Code interpretiert — taucht in verwandten Angriffen wieder auf: Command-Injection in Shell-Aufrufen, LDAP-Injection in Verzeichnisabfragen, NoSQL-Injection in dokumentenorientierten Datenbanken. Die Verteidigungslogik ist überall dieselbe: Daten und Code strikt trennen.