SQL-Injection ist heutzutage eine der wohl leichtesten Fingerübungen für jeden noch so unerfahrenen Hacker. Zum Glück lassen sich solche Angriffe auch genauso leicht präventiv verhindern. [...]
Was ist SQL-Injection?
Structured Query Language (SQL) Injektion ist eine Form des Cyberangriffs, die einem Angreifer die vollständige Kontrolle über Ihre Webanwendungsdatenbank ermöglichen kann, wenn er es schafft, beliebiges SQL in eine Datenbankabfrage einzufügen.
Wie von „Little Bobby Drop Tables“ in XKCD 327 verewigt, wurde SQL Injection (SQLi) erstmals im Jahre 1998 entdeckt, und plagt seither Webanwendungen aller Art über das Internet. Sogar die Top-Ten-Liste von OWASP listet SQLi an der Spitze der größten Bedrohungen für die Sicherheit von Webanwendungen auf.
Die guten Nachrichten? SQL-Injektion ist die wohl am einfachsten zu meisternde Herausforderung für Angreifer und Verteidiger gleichermaßen. Denn es handelt sich bei SQLi eben nicht um ein hochmodernes NSA Shadow Brokers Kit, sondern um eine Vorgehensweise, die so einfach ist, dass sie theoretisch sogar von einem Dreijährigen angewendet werden kann. Eine kinderleichte Fingerübung – und Ihre Webanwendung derart anzupassen, dass das Risiko eines SQLi-Angriffs gemindert wird, ist so einfach, dass es wie grobe Fahrlässigkeit wirkt, wenn Sie sich bis jetzt nicht darum gekümmert haben.
Typen von SQL-Injection
Mittlerweile gibt es viele verschiedene Arten von SQL-Injection, doch sie alle involvieren einen Angreifer, der beliebiges SQL in eine Webanwendungs-Datenbankabfrage einfügt. Die einfachste Form der SQL-Injection erfolgt daher über die Benutzereingabe. Normalerweise unterstützten Webanwendungen sogenannte User Inputs über ein dafür vorgesehenes Formular, während das Frontend die darin erfolgten Benutzereingaben dann zur Verarbeitung an die jeweilige Backend-Datenbank sendet. Wenn eine Webanwendung nicht dazu in der Lage ist, diese User Inputs zu bereinigen, kann ein Angreifer so einfach einen SQL-Code seiner Wahl in die Backend-Datenbank einschleusen und damit den Inhalt dieser Datenbank löschen, kopieren oder sogar ändern.
Ein Angreifer kann auch Cookies ändern, um die Datenbankabfrage einer Webanwendung zu vergiften. Cookies speichern Client-Statusinformationen lokal, die wiederum von Webanwendungen abgerufen werden, um die darin enthaltenen Informationen zu verarbeiten. Böswillige Nutzer und Malware können Cookies so abändern, dass über sie SQL in die Backend-Datenbank injiziert wird.
Servervariablen wie HTTP-Header können ebenfalls als Angriffsvektor einer SQL-Injection verwendet werden. Gefälschte Header, die beliebiges SQL enthalten, können diesen Code dann in die Datenbank einspeisen, sollte die Webanwendung solche Eingaben ebenfalls nicht bereinigen können.
SQL-Injection-Angriffe zweiter Ordnung sind von allen die wohl hinterhältigsten, da sie nicht darauf ausgelegt sind, sofort ausgeführt zu werden, sondern erst viel später in Kraft treten. Ein Entwickler, der alle Eingaben für einen sofortigen Angriff korrekt bereinigt hat, ist möglicherweise trotzdem noch anfällig für SQLi zweiter Ordnung, wenn die korrupten Daten in einem anderen Kontext verwendet werden.
SQL-Injection-Test
SQL-Injection ist als Technik mittlerweile sehr viel älter als die meisten menschlichen Hacker, die SQLi heute noch verwenden. SQLi-Angriffe sind rudimentär und außerdem längst automatisiert. Tools wie SQLninja, SQLmap und Havij machen es heutzutage einfach, seine eigenen Webanwendungen zu testen; doch auch Angreifern wird es leicht gemacht.
Vor zehn Jahren tobte ein SQLi-Wurm über das Internet wie ein Sturm. Und auch heute hat sich daran nicht viel geändert: Trotz der weit verbreiteten Sensibilität für SQL-Injection bleibt ein großer Prozentsatz von Webanwendungen bis heute anfällig.
Mithilfe von automatisierten Testingtools können Sie Angreifern, die auf der Suche nach leichter Beute sind, immer einen Schritt voraus sein. Wenn Sie Ihre Webanwendungen mit einem Tool wie SQLmap testen, können Sie schnell erkennen, ob Ihre bisherigen Maßnahmen ausreichend sind. SQLmap unterstützt nahezu jede der heute verwendeten großen Datenbanken und kann die meisten bekannten SQL-Injection-Schwachstellen erkennen und ausnutzen.
Ein Beispiel für SQL-Injection
Sehen wir uns einen grundlegenden SQL-Injection-Angriff genauer an. Angenommen, Sie haben eine Webanwendung erstellt, mit der Kunden ihre Kunden-IDs eingeben und darüber ihre Kundenprofile abrufen können. Das Frontend der Webanwendung leitet die vom Benutzer eingegebene Kundennummer an die Backend-Datenbank weiter. Die Datenbank führt wiederum eine SQL-Abfrage aus und gibt die Ergebnisse an die Web-Anwendung zurück, die die Ergebnisse dann dem Endbenutzer anzeigt.
Die Backend-Datenbankabfrage sieht etwa so aus:
SELECT *
FROM customers
WHERE customer_id = ‚1234567‘
Angenommen, ein Benutzer hat die folgende customer_id in das Webformularfeld eingegeben:
1234567; DELETE * customers WHERE ‚1‘ = ‚1
Die Backend-Datenbank würde dann gehorsam die folgende SQL ausführen:
SELECT *
FROM customers
WHERE customer_id = ‚1234567‘;
DELETE *
FROM customers
WHERE ‚x‘ = ‚x‘
Denken Sie daran, dass Datenbanken mehrere SQL-Anweisungen in einer Zeile ausführen, wenn sie durch ein Semikolon getrennt sind. Wenn die Benutzereingabe für das einfache Anführungszeichen “ ‚ “ nicht bereinigt wird, kann ein Angreifer die gesamte Tabelle löschen. In dem Fall haben Sie hoffentlich ein paar ordentliche Backups in der Hinterhand.
Dies war ein bewusst einfach gewähltes Beispiel, doch es gibt viele verschiedene Angriffsvektoren für eine SQL-Injection und sie alle funktionieren nach dem gleichen Prinzip: Wenn eine Webanwendung die Eingabe nicht bereinigt, kann ein SQL-Code aus der Ferne ausgeführt werden.
Erkennen von SQL-Injection
Die Eindämmung von SQL-Injection-Angriffen ist zwar nicht besonders schwierig, doch selbst die klügsten und wohlmeinendsten Entwickler machen irgendwann Fehler. Die SQL-Erkennung ist daher eine der wichtigsten Komponenten zur Minderung des Risikos eines SQL-Injection-Angriffs. Eine Webanwendungsfirewall (WAF) kann grundlegende SQL-Injection-Angriffe erkennen und blockieren, Sie sollten sich jedoch nicht als einzige vorbeugende Maßnahme auf sie verlassen.
Intrusion Detection Systems (IDS), sowohl netzwerk- als auch hostbasiert, können auf SQL Injection-Angriffe abgestimmt werden. Netzwerkbasierte IDS können alle Verbindungen zu Ihrem Datenbankserver überwachen und verdächtige Aktivitäten kennzeichnen. Ein hostbasiertes IDS kann Web-Server-Protokolle überwachen und warnen, wenn etwas Ungewöhnliches passiert.
Letztendlich weiß man jedoch bereits eine Menge über SQL-Injection und sie ist leicht vermeidbar, weshalb die Priorität bei der Risikominderung in erster Linie die Verhinderung von SQL-Injection-Angriffen sein sollte.
Prävention von SQL-Injection
Hören Sie auf Little Bobby Tables und bereinigen Sie Ihre Datenbankeingaben. Jede Eingabe in Ihre Webanwendungsdatenbank sollte von Grund auf als nicht vertrauenswürdig angesehen und entsprechend behandelt werden. Hören Sie auch auf die Experten von OWASP, wenn sie sagen: „Es ist ein bisschen peinlich, dass es heutzutage so viele erfolgreiche SQL-Injection-Angriffe gibt, weil es mittlerweile extrem einfach ist, SQL Injection-Schwachstellen in Ihrem Code zu vermeiden.“
Der SQL-Injection-Leitfaden von OWASP geht darauf noch tiefer ein, als wir es hier können. Um einer SQLi-Attacke vorzubeugen, so OWASP, müssen Entwickler lernen, Input-Validierungen auf eine Whitelist zu setzen (statt auf eine Blacklist), vorbereitete Anweisungen mit parametrisierten Abfragen zu verwenden und allen User-Input von Grund auf abzulehnen.
Beschränken Sie auch Kontoberechtigungen. Nehmen wir beispielsweise eine Sicherheitslücke: Was passiert, wenn ein Entwickler ein einzelnes Benutzereingabefeld nicht bereinigen kann? So etwas kann passieren, schließlich sind Entwickler auch nur Menschen. Bereinigen Sie die Eingabe, aber seien Sie auch darauf vorbereitet, dass etwas durchrutschen könnte. Begrenzen Sie daher die Kontoberechtigungen des Datenbanknutzers. Ist Ihre Webanwendung beispielsweise nur lesbar? Müssen Sie DROP TABLES Privilegien haben? Wahrscheinlich nicht. Hier gilt das Prinzip des geringsten Privilegs. Geben Sie der Webanwendung die Mindestberechtigungen für die Ausführung, nicht mehr.
Gespeicherte Prozeduren können SQLi ebenfalls sehr viel schwieriger machen – wenn auch nicht unmöglich. Wenn Ihre Webanwendung nur eine Handvoll SQL-Abfragen ausführen muss, erstellen Sie eine Liste von gespeicherten Prozeduren, um diese Abfragen auszuführen. In der Regel verfügt nur der Datenbankadministrator über die Berechtigungen zum Erstellen oder Ändern gespeicherter Prozeduren. Beachten Sie jedoch, dass viele Datenbanken standardmäßig mit gespeicherten Standardprozeduren kommen. Angreifer wissen das. Ziehen Sie in Betracht, diese standardmäßigen gespeicherten Prozeduren zu entfernen, sofern Sie sie nicht wirklich benötigen.
Mindest-Sorgfaltspflicht
SQL-Injection ist die geringste Herausforderung für Hacker in der Webanwendungssicherheit. Dieser Angriffsvektor kann von unerfahrenen oder stillosen Angreifern leicht missbraucht werden, was durch ein Mindestmaß an Sorgfaltspflicht leicht verhindert werden kann. Im Jahr 2018 gibt es einfach keine Entschuldigung mehr dafür, dass eine Webanwendung noch anfällig für SQL-Injection ist.
*J. M. Porup ist Senior Writer für CSOonline.com
Be the first to comment