Wie Sie SQL-Injection erkennen und verhindern

Was ist SQL Injection

SQL Injection (SQLi) ist eine der ältesten und gefährlichsten Angriffsarten auf Webanwendungen. Der Angriff funktioniert so, dass ein Angreifer bösartigen SQL-Code in Eingabefelder (Formulare, URL-Parameter, Cookies) einschleust, die die Anwendung zur Erstellung von SQL-Abfragen an die Datenbank verwendet. Wenn die Anwendung die Nutzereingaben nicht validiert und säubert, bevor sie sie in die SQL-Abfrage einbettet, kann der Angreifer die Abfrage manipulieren, um Daten aus der Datenbank zu lesen, zu ändern oder zu löschen.

Laut der OWASP Top 10-Liste gehören Injection-Angriffe seit Jahren zu den drei kritischsten Web-Schwachstellen. Ein erfolgreicher SQL-Injection-Angriff kann zum Diebstahl der gesamten Datenbank (Benutzerkonten, Passwörter, persönliche Daten), zur Modifikation oder Löschung von Daten, zur Umgehung der Authentifizierung (Anmeldung ohne Passwort), zur Ausführung von Betriebssystembefehlen des Servers und zur vollständigen Kompromittierung des Servers führen.

Wie SQL Injection funktioniert

Grundprinzip

Stellen Sie sich ein Login-Formular vor, das Benutzernamen und Passwort prüft. Die Anwendung erstellt eine SQL-Abfrage, die etwa so aussieht: SELECT * FROM users WHERE username = 'eingegebener_name' AND password = 'eingegebenes_passwort'. Wenn die Anwendung die Nutzereingabe einfach ohne Prüfung in die Abfrage einfügt, kann der Angreifer in das Feld für den Benutzernamen einen Spezialwert eingeben, der die Logik der Abfrage ändert. Beispielsweise kann eine Eingabe, die ein Apostroph gefolgt von SQL-Code enthält, das String-Literal schließen und eine Bedingung hinzufügen, die immer wahr ist, wodurch die Passwortprüfung umgangen wird.

SQL-Injection-Angriffstypen

Es gibt mehrere Arten von SQL-Injection-Angriffen. In-Band SQLi ist der häufigste Typ, bei dem der Angreifer denselben Kommunikationskanal zum Senden des Angriffs und Empfangen der Ergebnisse verwendet. Er wird in Error-Based SQLi (verwendet Datenbankfehlermeldungen zur Informationsgewinnung) und Union-Based SQLi (verwendet den UNION-Operator zur Kombination der Ergebnisse einer bösartigen Abfrage mit einer legitimen) unterteilt. Blind SQLi ist ein Typ, bei dem der Angreifer keine direkten Ergebnisse sieht, aber Informationen aus dem Verhalten der Anwendung ableiten kann. Boolean-Based Blind SQLi sendet Abfragen, die true oder false zurückgeben, und schließt aus dem Unterschied in der Antwort Zeichen für Zeichen auf Daten. Time-Based Blind SQLi verwendet SQL-Pausenfunktionen (SLEEP, WAITFOR DELAY), um festzustellen, ob eine Bedingung wahr ist, basierend auf der Antwortzeit. Out-of-Band SQLi verwendet einen anderen Kanal zur Datenextraktion, wie DNS- oder HTTP-Anfragen, die die Datenbank an den Server des Angreifers sendet.

Erkennung von SQL-Injection-Schwachstellen

Manuelles Testen

Der einfachste Weg, SQL-Injection-Schwachstellen zu testen, ist das Einfügen spezieller Zeichen in Eingabefelder. Ein Apostroph (') ist der erste Test – wenn die Anwendung einen Datenbankfehler zurückgibt, besteht eine potenzielle Schwachstelle. Zwei Apostrophe ('') sollten keinen Fehler verursachen, wenn der erste einen verursacht hat. SQL-Kommentare (-- oder #) können verwendet werden, um den Rest der Abfrage zu kommentieren. Logische Operatoren (OR 1=1, AND 1=2) können Boolean-Based-Schwachstellen aufdecken. Der SLEEP-Befehl ('; WAITFOR DELAY '0:0:5'--) deckt Time-Based-Schwachstellen auf, wenn die Seite verzögert antwortet.

Automatisierte Tools

Für systematisches Testen verwenden Sie spezialisierte Tools. SQLMap ist das bekannteste Open-Source-Tool zur automatischen Erkennung und Ausnutzung von SQL-Injection-Schwachstellen – es unterstützt alle SQLi-Typen und die meisten Datenbanken. Burp Suite Professional verfügt über einen integrierten Scanner für SQL Injection und andere Web-Schwachstellen. OWASP ZAP ist eine kostenlose Alternative zu Burp Suite mit solidem SQLi-Scanner. Acunetix und Netsparker sind kommerzielle Web-Vulnerability-Scanner mit erweiterter SQLi-Erkennung.

Anzeichen einer Kompromittierung

Wenn Sie vermuten, dass Ihre Website bereits Ziel eines SQL-Injection-Angriffs war, prüfen Sie Folgendes: ungewöhnliche Einträge in Webserver-Logs (URLs mit SQL-Schlüsselwörtern), neue oder geänderte Benutzerkonten in der Datenbank (insbesondere Admin-Konten), geänderte Daten ohne Ihr Wissen, neue Dateien auf dem Server (Web-Shells) und erhöhten Traffic zu bestimmten Seiten mit ungewöhnlichen Parametern. Überprüfen Sie auch die Datenbank-Log-Dateien auf unerwartete Abfragen.

Prävention – Prepared Statements

Was sind Prepared Statements

Prepared Statements (parametrisierte Abfragen) sind der effektivste Schutz vor SQL Injection. Statt die Nutzereingabe direkt als Text in die SQL-Abfrage einzufügen, trennt ein Prepared Statement die Struktur der Abfrage von den Daten. Zuerst wird die Struktur der Abfrage mit Platzhaltern für Daten definiert, dann werden die Daten separat gesendet. Die Datenbank behandelt die Daten ausschließlich als Werte, niemals als SQL-Code, wodurch Injection unmöglich wird.

Implementierung in verschiedenen Sprachen

PHP mit PDO (PHP Data Objects) verwendet die prepare()-Methode zur Vorbereitung von Abfragen mit Platzhaltern (:username, :password) und execute() mit einem Array von Werten. MySQLi Extension unterstützt Prepared Statements mit ?-Platzhaltern und bind_param() zum Binden von Werten mit Datentypen. Python mit sqlite3 oder psycopg2 verwendet ?- oder %s-Platzhalter. Java verwendet die PreparedStatement-Klasse mit setString()-, setInt()-Methoden. Node.js-Bibliotheken wie mysql2 und pg unterstützen parametrisierte Abfragen mit ?- oder $1-Platzhaltern. Unabhängig von der Programmiersprache ist das Prinzip dasselbe – verketten Sie niemals Nutzereingaben mit SQL-Abfragen als Strings.

Zusätzliche Präventionsmethoden

Eingabevalidierung

Neben Prepared Statements validieren Sie Nutzereingaben immer. Whitelist-Validierung erlaubt nur erwartete Werte – wenn ein Feld eine Zahl enthalten soll, prüfen Sie vor der Verarbeitung, dass es tatsächlich eine Zahl ist. Für Textfelder begrenzen Sie erlaubte Zeichen, Eingabelänge und Format (Regex). Verlassen Sie sich niemals nur auf client-seitige Validierung (JavaScript), da der Angreifer sie umgehen kann – die Validierung muss auf dem Server implementiert sein.

Stored Procedures

Stored Procedures sind SQL-Code, der auf dem Datenbankserver gespeichert und ausgeführt wird. Wenn sie ordnungsgemäß geschrieben sind (ohne dynamisches SQL innerhalb der Procedure), bieten sie eine zusätzliche Schutzebene, weil die Anwendung die Procedure mit Parametern aufruft, anstatt rohe SQL-Abfragen zu senden. Stored Procedures sind jedoch an sich keine Sicherheitsgarantie – wenn die Procedure intern dynamische Abfragen aus Parametern erstellt, besteht die Schwachstelle weiterhin.

ORM (Object-Relational Mapping)

ORM-Bibliotheken wie Eloquent (Laravel), SQLAlchemy (Python), Hibernate (Java) und TypeORM (Node.js) verwenden automatisch Prepared Statements für alle Abfragen, wodurch die meisten SQL-Injection-Risiken eliminiert werden. Die meisten ORMs erlauben jedoch rohe SQL-Abfragen für komplexe Operationen – in diesen Fällen müssen Sie manuell Prepared Statements verwenden. ORM ersetzt nicht das Wissen über SQL-Sicherheit, reduziert aber die Angriffsfläche erheblich.

Prinzip der geringsten Privilegien

Konfigurieren Sie die Datenbank so, dass die Anwendung ein Konto mit minimal erforderlichen Privilegien verwendet. Eine Webanwendung benötigt normalerweise SELECT-, INSERT-, UPDATE- und DELETE-Privilegien für bestimmte Tabellen. Vergeben Sie keine DROP-, ALTER-, CREATE- oder FILE-Privilegien an das Anwendungskonto. Wenn ein Angreifer SQL Injection erfolgreich ausführt, verhindern eingeschränkte Privilegien das Löschen von Tabellen, die Modifikation der Datenbankstruktur und den Zugriff auf das Server-Dateisystem.

WAF-Schutz vor SQL Injection

Wie eine WAF SQLi erkennt

Eine Web Application Firewall (WAF) analysiert HTTP-Anfragen und blockiert solche, die SQL-Injection-Muster enthalten. Die WAF erkennt SQL-Schlüsselwörter an unerwarteten Stellen (SELECT, UNION, DROP in URL-Parametern), Spezialzeichen, die in SQLi-Angriffen verwendet werden (Apostrophe, Kommentare, logische Operatoren), bekannte SQLi-Payloads aus der Signaturdatenbank und Anomalien in der Anfragestruktur, die auf einen Injection-Versuch hindeuten.

Einschränkungen der WAF

Eine WAF ist kein Ersatz für sicheren Code. Erfahrene Angreifer können die WAF umgehen, indem sie Encoding-Techniken (URL-Encoding, Unicode, Double Encoding), Kommentare und Leerzeichen zur Umgehung von Signaturen, alternative SQL-Syntaxen, die die WAF nicht erkennt, und schrittweises Testen verwenden, um festzustellen, welche Regeln die WAF nutzt. Die WAF ist eine zusätzliche Schutzebene (Defense in Depth), aber der Hauptschutz muss im Anwendungscode durch Prepared Statements und Eingabevalidierung bestehen.

SQL Injection in WordPress

WordPress-Schutzmechanismen

Der WordPress-Core verwendet die Methode $wpdb->prepare() für alle Datenbankabfragen, was die WordPress-Implementierung von Prepared Statements ist. Diese Methode verwendet Sprintf-Style-Platzhalter (%s für Strings, %d für Integer, %f für Float-Werte) und entwertet Werte automatisch. Schwachstellen treten jedoch am häufigsten in Plugins und Themes auf, die $wpdb->prepare() nicht verwenden oder Abfragen durch manuelles String-Verketten erstellen.

Schutz der WordPress-Website

Zum Schutz einer WordPress-Website vor SQL Injection aktualisieren Sie WordPress-Core, Plugins und Themes regelmäßig, da Sicherheitspatches häufig SQLi-Schwachstellen adressieren. Verwenden Sie nur Plugins und Themes aus vertrauenswürdigen Quellen (WordPress.org-Repository, bekannte kommerzielle Anbieter). Installieren Sie ein Sicherheits-Plugin (Wordfence, Sucuri, iThemes Security), das WAF-Schutz beinhaltet. Siehe auch unseren Leitfaden zum Schutz der Website vor Hackern. Entfernen Sie ungenutzte Plugins und Themes, da auch deaktivierte Plugins ausgenutzt werden können. Beschränken Sie den Datenbankzugriff – WordPress braucht nur einen Benutzer mit Zugriff auf seine Datenbank.

Häufige Fehler, die die Website angreifbar machen

• Dynamisches SQL im Code: Das Verketten von Nutzereingaben mit SQL-Abfragen als String ist die Hauptursache für SQL-Injection-Schwachstellen. Verwenden Sie immer Prepared Statements.
• Vertrauen in client-seitige Validierung: JavaScript-Validierung kann umgangen werden – jede Validierung muss auf dem Server existieren.
• Detaillierte Fehlermeldungen: Das Anzeigen von SQL-Fehlern an Nutzer gibt die Datenbankstruktur preis und erleichtert den Angriff. Loggen Sie Fehler in der Produktion intern und zeigen Sie Nutzern generische Nachrichten an.
• Veraltete Software: Alte Versionen von CMS, Frameworks und Bibliotheken haben oft bekannte SQLi-Schwachstellen mit öffentlich verfügbaren Exploits.
• Ein Datenbankbenutzer für alles: Die Verwendung des Root-Kontos für die Anwendung gibt dem Angreifer im Falle eines erfolgreichen Angriffs die volle Kontrolle über die Datenbank.

Fazit

SQL Injection ist eine ernsthafte Bedrohung, die Ihre Website und Benutzerdaten vollständig kompromittieren kann. Die Prävention ist relativ einfach – verwenden Sie Prepared Statements für alle Datenbankinteraktionen, validieren Sie Nutzereingaben auf dem Server, wenden Sie das Prinzip der geringsten Privilegien an und halten Sie die Software aktuell. Eine WAF bietet eine zusätzliche Schutzebene, ersetzt aber keinen sicheren Code. Beim BeoHosting-Hosting-Dienst kommen alle Server mit konfigurierter ModSecurity-WAF, die SQL-Injection-Versuche erkennt und blockiert, aber wir empfehlen, dass auch Ihr Code Best Practices für sichere Programmierung befolgt.