Relationale Datenbankmanagementsysteme (RDBMS) wie Oracle, MySQL, PostgreSQL und Microsoft SQL Server gehören laut dem aktuellen DB-Engines-Ranking zu den populärsten im Markt. Da sie als sehr zuverlässig gelten und Inkonsistenzen in den Datensätzen vermeiden, sind sie seit Jahrzehnten als etablierter Standard für Datenbanken in den meisten Unternehmen gesetzt.
Um die Daten darin abzufragen und zu bearbeiten, kommt in der Regel die Datenbanksprache Structured Query Language (SQL) zum Einsatz. So kommunizieren Anwender beispielsweise über eine Maske für Produktsuche in einem Webshop mit einem Server. Dieser fragt wiederum eine Datenbank ab und spielt die erhaltenen Informationen an den Webshop als Suchergebnis zurück.
Auf diesem Weg sind die in der Datenbank gespeicherten Daten anfällig für sogenannte SQL-Injection (SQLi), die beliebigen Code in Abfragen einschleust. So ist es möglich, Informationen unerlaubt auszulesen oder zu verändern. Im schlimmsten Fall erlangen die Eindringlinge Kontrolle über die gesamte Datenbank.
Foto: Maxx-Studio - shutterstock.com
Simpler Dauerbrenner
Die Angriffsmethode wurde 1998 entdeckt und gilt seitdem als eine der hartnäckigsten Bedrohungen. Nicht zu Unrecht. So wurde im März 2019 eine Lücke in der Onlineshop-Software Magento entdeckt und geschlossen, über die Kundendaten aus den Datenbanken der Händler ausgelesen werden konnten. 2018 gab es auf der Webseite des kanadischen Internet Service Poviders Altima ein Glitch (ein Software- oder Programmierfehler, der zu Fehlverhalten von Computerprogrammen führt). Darüber war es möglich, mit einer sogenannten blinden SQL-Injection (dazu später mehr) auf eine umfangreiche Kundendatenbank zuzugreifen.
Ein Grund, warum SQL-Injection bei Hackern so beliebt ist, könnte darin liegen, dass es eine sehr einfache Attacke ist. Auf der 26. DEF CON Hackerkonferenz, die 2018 in Las Vegas stattfand, konnte ein elfjähriges Kind eine Kopie der Website für die Darstellung der Wahlergebnisse im US-Staat Florida in nur zehn Minuten via SQLi hacken und manipulieren.
Auf der anderen Seite sind die Maßnahmen zur Verteidigung ebenso simpel wie wirksam. Im Folgenden werden verschiedene Arten von SQLi beschrieben und Möglichkeiten zur Abwehr vorgestellt.
Typen von SQL-Injection
Egal um welchen Typus von SQL-Injection es sich handelt, bei jedem schleust der Angreifer beliebigen SQL-Code in die Datenbankabfrage einer Web-Applikation ein. Dies kann auf verschiedenen Wegen passieren.
Die einfachste Angriffsform erfolgt über eine Nutzereingabe. Web-Applikationen akzeptieren Input normalerweise über ein Formular. Das Frontend leitet dann die Eingabe an die Datenbank im Backend zur Verarbeitung weiter. Wenn die Web-Anwendung dabei den Input nicht bereinigt, ist es möglich, über injizierte SQL-Eingaben Datenbankinhalte zu löschen, zu kopieren oder zu verändern.
Angreifer können auch Cookies verändern, so dass sie die Abfrage der Web-Anwendung infizieren. Cookies speichern Informationen zum Client-Status auf der lokalen Festplatte. In der Regel laden Web-Applikationen Cookies, um diese Informationen zu verarbeiten. Ein böswilliger Nutzer oder Malware kann sie dahingehend modifizieren, dass sie SQL-Befehle in die Backend-Datenbank einspeisen. Gleiches ist über Server-Variablen wie HTTP-Header möglich. Gefälschte Header, die beliebige SQL enthalten, können diesen Code in die Datenbank einschleusen, wenn die Web-Applikation auch diesen Input nicht bereinigt.
Unter den Typus der blinden SQL-Injection fallen Angriffe auf Web-Anwendungen, die zwar SQLi nicht aktiv abwehren, jedoch die Ergebnisse der Injektion nicht sichtbar ausgeben. Sie zeigen stattdessen entweder keine offensichtliche Reaktion, oder beispielsweise allgemeine Fehlermeldungen an, dass die Syntax der SQL-Abfrage nicht korrekt ist. Die Seite liefert in diesem Fall zwar keine Daten, sie stellt sich aber abhängig von den Ergebnissen einer in der legitimen SQL eingeschleusten logischen Anweisung minimal anders dar.
Die Informationen werden bei dieser Methode also nicht direkt, sondern über eine Reihe von Wahr-oder-Falsch-Anfragen identifiziert und aus der Datenbank abgezogen. Diese Methode gilt als sehr zeitaufwändig. Sobald aber die Schwachstelle und die gewünschten Informationen gefunden sind, kann die Attacke über eine Reihe von Tools automatisiert werden.
SQL-Injection-Angriffe zweiter Ordnung gehören zu den hinterhältigsten, da sie nicht sofort, sondern zu einem späteren Zeitpunkt in Aktion treten. Solche schädlichen, aber vorerst inaktiven SQL-Kommandos können von der Anwendung korrekt kodiert und als valide SQL in der Datenbank gespeichert werden. Führt daraufhin ein anderer Teil der Applikation, der womöglich nicht gegen SQLi geschützt ist, die gespeicherte SQL-Anweisung in einem anderen Kontext aus, startet der zeitversetzte Angriff.
Beispiel einer einfachen SQL-Injection-Attacke
Angenommen, ein Unternehmen hat eine Web-Anwendung gebaut, in der Kunden über die Eingabe ihrer Kundennummer ihr Profil aufrufen können. Das Frontend der App leitet die eingegebene Nummer in das Backend. Die Datenbank führt dort einen SQL-Aufruf aus und liefert das Resultat zurück an die Anwendung, die es dem Nutzer anzeigt.
Unser Nutzer gibt also im Frontend seine Nummer 1234567 ein.
Die Abfrage im Backend könnte in etwa so aussehen:
SELECT *
FROM customers
WHERE customer_id = '1234567'
Nehmen wir an, der Nutzer gibt stattdessen folgende Kundenummer in ein Feld des Web-Formulars ein:
1234567'; DELETE * customers WHERE '1' = '1
Die Datenbank im Backend würde dann diese SQL ausführen:
SELECT *
FROM customers
WHERE customer_id = '1234567';
DELETE *
FROM customers
WHERE 'x' = 'x'
Datenbanken führen mehrere SQL Statements der Reihe nach aus, wenn sie durch ein Semikolon (;) getrennt sind. Wird die Eingabe nicht hinsichtlich des einfachen Anführungszeichens (') bereinigt, können Angreifer die gesamte Tabelle löschen.
Das ist ein bewusst einfaches Beispiel, aber jede SQLi funktioniert nach demselben Prinzip: Durch unbereinigten Input über eine Web-Anwendung wird in der Datenbank beliebiger SQL-Code ausgeführt.
Foto: Joe Techapanupreeda - shutterstock.com
Feuer mit Feuer bekämpfen
Da SQLi-Angriffe relativ einfach gestrickt sind, dauerte es nicht lange, bis sie automatisiert wurden. Tools wie SQLninja, SQLmap oder Havij stehen sowohl Angreifern, als auch Verteidigern zur Verfügung. Damit können Unternehmen ihre Web-Anwendungen auf Schwachstellen gegen SQLi hin testen.
SQLmap ist zum Beispiel eine gute Option, da es beinahe jede größere Datenbank unterstützt, darunter MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2 und SAP MaxDB. Es ist für alle gängigen Betriebssysteme verfügbar und erkennt die bekanntesten Injection-Schlupflöcher in Web-Anwendungen. Damit lässt sich schnell feststellen, ob die Maßnahmen, den Input zu reinigen, auch tatsächlich wirken.
SQL-Injection entdecken
Um SQL-Injection-Angriffe zu entdecken, bieten sich zwei Möglichkeiten an. Eine Web Application Firewall (WAF) kann eingehenden Traffic gemäß vorher festgelegter Regeln auf manipulative Eingaben untersuchen und gegebenenfalls abwehren.
Allerdings ist diese Schutzmaßnahme nicht immer wirksam. Ende 2022 entdeckten Security-Forscher eine neue SQLi-Variante, mit der WAFs von mehreren Anbietern umgangen werden können. (Lesen Sie dazu auf unserer Schwesterpublikation CSO: "Neue SQL-Injection-Angriffe können WAFs austricksen")
In Bezug auf die Überwachung der Datenbank selbst ist ein Intrusion Detection System (IDS) nützlich. Ein netzwerkbasiertes IDS überwacht alle Verbindungen zur Datenbank und schlägt bei verdächtigen Aktivitäten Alarm. Ein Host-basiertes IDS behält die Log-Dateien des Web-Servers im Blick und meldet Unregelmäßigkeiten.
SQL-Injection verhindern
Eine umfassende und detaillierte Beschreibung aller einschlägigen Schutzmaßnahmen finden Sie im SQL Injection Prevention Cheat Sheet von OWASP. Im Folgenden stellen wir eine Auswahl der wichtigsten vor.
Wie bei dem Großteil aller Angriffsflächen auf die Unternehmens-IT gilt auch hier: Eine gute Patch-Hygiene löst viele Probleme. Regelmäßig werden Schwachstellen von Anwendungen und Datenbanken aufgedeckt und behoben, die Hacker für SQL-Injection nutzen können. Daher ist es wichtig, Patches und Updates stets aktuell zu halten.
Für den grundlegenden Schutz gilt es, den Datenbankzugriff über SQL derart zu regeln, dass ausnahmslos alle Eingaben vor der Ausführung bereinigt werden. Das bedeutet, ungewöhnliche Schriftzeichen, die auf eine Manipulation hindeuten, nicht zu erlauben. Zudem ist es ratsam, Maßnahmen wie Escape-Sequenzen einzusetzen, die sicherstellen, dass Eingaben nicht versehentlich als Kommandos übernommen werden. Darüber hinaus empfiehlt es sich, alle Eingaben nach Kontext zu filtern. Eine Telefonnummer sollte beispielsweise nur nummerische Eingaben erlauben. Sogenannte Prepared Statements verhindern, dass der Zweck einer Abfrage verändert wird, selbst wenn ein Angreifer anderslautende Kommandos eingibt.
Für den Fall, dass trotz der Reinigung ein Schlupfloch besteht, gilt es, die Account-Privilegien von Datenbanknutzern zu beschränken. Dabei sollte das Prinzip der minimalen Berechtigungen angewandt werden. Die Applikation besitzt dabei gerade so viel Handlungsspielraum, dass sie ihre Aufgabe erfüllt - keine darüber hinaus. So kann die Web-Anwendung beispielsweise lediglich Lese- aber keine Schreibrechte erhalten. Zudem sollten Befehle wie "DROP TABLES", der die gesamte Datenbank löscht, nicht ausführbar sein.
Auch Stored Procedures, also Funktionen, die mit einem einzelnen Aufruf eine Abfolge gespeicherter Befehle in der Datenbank ausführen, machen SQLi schwerer - wenn auch nicht ganz unmöglich. Muss die Web-Anwendung nur wenige SQL-Abfragen ausführen, sollten dafür Stored Procedures geschrieben werden. In der Regel ist nur der Datenbankadministrator berechtigt, sie zu erstellen und zu bearbeiten. Dabei gilt es darauf zu achten, dass viele Datenbanken bereits vorgefertigte Stored Procedures besitzen, die den Angreifern wahrscheinlich bekannt sind. Wenn diese nicht absolut notwendig sind, sollten sie entfernt werden.
Sorgfalt ist der beste Schutz
SQL-Injection ist einer der simpelsten Angriffsvektoren auf Unternehmensdaten und daher können ihn auch wenig versierte Angreifer ausnutzen, um großen Schaden anzurichten. Genau so einfach ist es aber auch für Unternehmen, diese offene Flanke zu schließen. Dazu gilt es lediglich, die Kommunikation zwischen Web-Anwendung und Datenbank mit ein wenig Sorgfalt einzurichten und ein paar Schutzmaßnahmen zu implementieren.