SQL-Injection: Wie Sie sich ganz einfach gegen Hacks schützen können

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. [...]

SQL-Injection ist eine der leichtesten Fingerübungen für Hacker (c) Pixabay.com

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


Mehr Artikel

Rüdiger Linhart, Vorsitzender der Berufsgruppe IT der Fachgruppe UBIT Wien. (c) WeinwurmFotografie
Interview

IT-Berufe im Fokus: Innovative Lösungen gegen den Fachkräftemangel

Angesichts des anhaltenden IT-Fachkräftemangels ist schnelles Handeln gefordert. Die Fachgruppe IT der UBIT Wien setzt in einer Kampagne genau hier an: Mit einem breiten Ansatz soll das vielfältige Berufsbild attraktiver gemacht und innovative Ausbildungswege aufgezeigt werden. IT WELT.at hat dazu mit Rüdiger Linhart, Vorsitzender der Berufsgruppe IT der Fachgruppe UBIT Wien, ein Interview geführt. […]

News

ISO/IEC 27001 erhöht Informationssicherheit bei 81 Prozent der zertifizierten Unternehmen

Eine Umfrage unter 200 Personen verschiedener Branchen und Unternehmensgrößen in Österreich hat erstmals abgefragt, inwiefern der internationale Standard für Informationssicherheits-Managementsysteme (ISO/IEC 27001) bei der Bewältigung von Security-Problemen in der Praxis unterstützt. Ergebnis: Rund 81 Prozent der zertifizierten Unternehmen gaben an, dass sich durch die ISO/IEC 27001 die Informationssicherheit in ihrem Unternehmen erhöht hat. […]

News

Public Key Infrastructure: Best Practices für einen erfolgreichen Zertifikats-Widerruf

Um die Sicherheit ihrer Public Key Infrastructure (PKI) aufrecht zu erhalten, müssen PKI-Teams, sobald bei einer Zertifizierungsstelle eine Sicherheitslücke entdeckt worden ist, sämtliche betroffenen Zertifikate widerrufen. Ein wichtiger Vorgang, der zwar nicht regelmäßig, aber doch so häufig auftritt, dass es sich lohnt, PKI-Teams einige Best Practices für einen effektiven und effizienten Zertifikatswiderruf an die Hand zu geben. […]

News

UBIT Security-Talk: Cyberkriminalität wächst unaufhaltsam

Jedes Unternehmen, das IT-Systeme nutzt, ist potenziell gefährdet Opfer von Cyberkriminalität zu werden, denn die Bedrohung und die Anzahl der Hackerangriffe in Österreich nimmt stetig zu. Die Experts Group IT-Security der Wirtschaftskammer Salzburg lädt am 11. November 2024 zum „UBIT Security-Talk Cyber Defense“ ein, um Unternehmen in Salzburg zu unterstützen, sich besser gegen diese Bedrohungen zu wappnen. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*