Mit Google fortfahren
SQL-Injection einfach erklärt und verhindern
Eine SQL-Injection entsteht, wenn eine Anwendung eine Eingabe als Teil eines SQL-Befehls ausführt, obwohl sie nur als Datenwert gedacht war. Der wichtigste Schutz besteht darin, SQL-Code und Eingabedaten durch parametrisierte Abfragen konsequent zu trennen.
Auf dieser Seite lernst du, eine unsichere Abfrage zu erkennen, ihren Fehler zu erklären und passende Schutzmaßnahmen auszuwählen.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Wie entsteht eine SQL-Injection?
SQL steht für Structured Query Language. Anwendungen verwenden diese Sprache, um Daten in relationalen Datenbanken zu lesen oder zu verändern.
Problematisch wird es, wenn ein Programm einen SQL-Befehl direkt aus festem Programmtext und einer Benutzereingabe zusammensetzt:
text studentId = Eingabe abfrage = "SELECT * FROM students WHERE studentId = " + studentId
Bei der Eingabe 117 entsteht die erwartete Abfrage:
sql SELECT * FROM students WHERE studentId = 117;
Eine manipulierte Eingabe kann jedoch zusätzliche SQL-Logik einschleusen. Die Datenbank erhält dann beispielsweise:
sql SELECT * FROM students WHERE studentId = 117 OR 1=1;
Da 1=1 für jede Tabellenzeile wahr ist, kann die Bedingung alle Datensätze auswählen. Der entscheidende Fehler liegt nicht in SQL selbst, sondern in der Anwendung: Sie hat Daten und Programmcode vermischt.
SQL-Injection
Eine SQL-Injection ist das Einschleusen von SQL-Bestandteilen über eine Eingabe, sodass eine Anwendung unbeabsichtigte Datenbankbefehle oder veränderte Abfragen ausführt.
Eine Eingabe darf den Wert eines Parameters liefern, aber niemals die Struktur des SQL-Befehls verändern.
Welche Schäden sind möglich?
Die Folgen hängen von der konkreten Schwachstelle, den Datenbankrechten und der Umgebung ab. Eine SQL-Injection führt daher nicht automatisch zur vollständigen Systemübernahme.
Mögliche Auswirkungen sind:
- vertrauliche Datensätze unbefugt lesen;
- Daten einfügen, verändern oder löschen;
- Benutzerkonten oder Berechtigungen manipulieren;
- Informationen über die Datenbankstruktur gewinnen;
- in besonders ungünstigen Umgebungen weitere Systeme gefährden.
Minimale Berechtigungen begrenzen den Schaden. Ein Anwendungskonto, das nur bestimmte Datensätze lesen darf, kann nicht ohne Weiteres Tabellen löschen oder administrative Aufgaben ausführen.
Eine Schulbibliotheks-Anwendung benötigt für ihre Suchfunktion nur lesenden Zugriff auf freigegebene Buchtitel. Ihr Datenbankkonto sollte deshalb keine Benutzerkonten ändern und keine Tabellen löschen dürfen. Selbst bei einem Fehler bleiben dadurch viele gefährliche Operationen gesperrt.
Wie verhindern parametrisierte Abfragen den Fehler?
Bei einer parametrisierten Abfrage wird die SQL-Struktur unabhängig von der Eingabe festgelegt. Ein Platzhalter kennzeichnet die Stelle, an der später ein Wert eingesetzt wird.
Unsicher ist die direkte Verkettung:
text sql = "SELECT * FROM students WHERE studentId = " + eingabe
Sicherer ist das Prinzip einer parametrisierten Verarbeitung:
text sql = "SELECT * FROM students WHERE studentId = ?" ausführen(sql, parameter=[eingabe])
Der genaue Platzhalter und die Aufrufweise unterscheiden sich je nach Programmiersprache und Datenbankbibliothek. Das Prinzip bleibt gleich: Die Abfrage wird als SQL-Code vorbereitet, die Eingabe getrennt als Datenwert übergeben.
Selbst wenn ein Parameter SQL-ähnliche Zeichen enthält, soll er dadurch nicht zu einem neuen Teil des Befehls werden. Voraussetzung ist, dass die verwendete Bibliothek die Parameter tatsächlich bindet und die Anwendung nicht an anderer Stelle wieder SQL-Text zusammensetzt.
Prepared Statement plus gebundener Parameter: Die Datenbank kennt die Befehlsstruktur, bevor sie den Eingabewert verarbeitet.
Welche weiteren Schutzschichten gehören dazu?
Parametrisierte Abfragen schützen die Trennung von Code und Daten. Weitere Maßnahmen erfüllen andere Aufgaben:
- Eingabevalidierung: Akzeptiert nur Werte im erwarteten Format, etwa eine positive ganze Zahl für eine ID. Sie ergänzt parametrisierte Abfragen, ersetzt sie aber nicht.
- Sichere Fehlerbehandlung: Zeigt Nutzern keine internen SQL-Befehle, Tabellennamen oder Datenbankdetails. Fehler werden intern protokolliert und nach außen allgemein verständlich gemeldet.
- Minimale Rechte: Begrenzt, was das Datenbankkonto überhaupt tun darf.
- Rollenbasierte Zugriffskontrolle: Erlaubt Funktionen nur den dafür vorgesehenen Rollen.
- Aktuelle Software: Schließt bekannte Sicherheitslücken in Anwendung, Bibliotheken und Datenbankserver.
- Web Application Firewall: Kann bekannte verdächtige Muster vor der Anwendung filtern. Sie hängt von ihrer Konfiguration ab und ersetzt keinen sicheren Programmcode.
Escaping ist von der jeweiligen Datenbank und ihrem Kontext abhängig und kann leicht fehlerhaft eingesetzt werden. Wo Werte parametrisiert werden können, ist die Parameterbindung deshalb die verlässlichere Grundentscheidung.
HTTPS schützt Daten während der Übertragung. Es verhindert jedoch nicht, dass eine Anwendung eine bereits empfangene Eingabe unsicher in einen SQL-Befehl einbaut. Transportverschlüsselung und Schutz vor SQL-Injection lösen unterschiedliche Probleme.
Wie lassen sich Angriffsarten und Hinweise einordnen?
SQL-Injection kann sich auf unterschiedliche Weise bemerkbar machen:
- Bei In-Band SQLi gelangen Informationen über denselben Kommunikationsweg zurück, etwa durch Fehlermeldungen oder kombinierte Abfrageergebnisse.
- Bei blinder SQLi erscheinen Daten nicht direkt. Unterschiede im Seiteninhalt, im Verhalten oder in der Antwortzeit können Wahr/Falsch-Ergebnisse verraten.
- Bei Out-of-Band SQLi werden Daten über einen anderen Kanal übertragen. Das setzt unter anderem voraus, dass der Datenbankserver passende ausgehende Verbindungen herstellen kann.
Ungewöhnliche Fehlermeldungen, veränderte Ergebnisse, auffällige Anfragen oder reproduzierbare Verzögerungen können Hinweise sein. Ein einzelnes Symptom beweist jedoch weder eine SQL-Injection noch die Identität einer angreifenden Person.
Eine Seite reagiert einmal langsam. Das genügt nicht für die Diagnose „zeitbasierte SQL-Injection“: Auch Netzlast oder ein langsamer Server können die Verzögerung erklären. Erst ein kontrolliert reproduzierbares Muster zusammen mit weiteren technischen Befunden wäre aussagekräftiger.
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- SQL-Injection verhindern
- Ursache: Vermischung von Eingabe und SQL-Code
- Grundschutz: parametrisierte Abfragen
- Ergänzung: Eingaben validieren
- Schadensbegrenzung: minimale Rechte
- Informationsschutz: sichere Fehlermeldungen
- Zusatzschutz: aktuelle Software und WAF
- Diagnose: mehrere Befunde gemeinsam auswerten
Abschluss-Check
Du kannst eine SQL-Injection nun am entscheidenden Muster erkennen: Eine Eingabe wird zum Teil des Befehls. Prüfe bei Datenbankzugriffen deshalb zuerst die Trennung von SQL-Struktur und Parametern und danach die ergänzenden Schutzschichten.