Einschleusung von SQL-Befehlen
Die Einschleusung von SQL-Befehlen ist eine der häufigsten Ursachen für Datenverletzungen. Ein solcher Angriff besteht im Kern darin, dass ein SQL-Befehl an das Back-End eines Formularfelds im Web- oder Anwendungs-Front-End angefügt wird (üblicherweise über eine Website). Dabei wird beabsichtigt, das ursprüngliche SQL-Skript zu unterbrechen und stattdessen das SQL-Skript auszuführen, das in das Formularfeld eingeschleust wurde. Die Einschleusung von SQL-Befehlen kommt am häufigsten vor, wenn dynamisch generierter SQL-Code in einer Clientanwendung vorhanden ist. Ein Angriff durch Einschleusung von SQL-Befehlen ist also im Prinzip nur möglich, wenn in der Clientanwendung und den gespeicherten Datenbankprozeduren schlechte Programmiermethoden zum Einsatz kommen. Viele Entwickler wenden bereits bessere Verfahren an, doch die Einschleusung von SQL-Befehlen ist dennoch ein Problem, da immer noch viele Legacyanwendungen im Einsatz sind, aber auch neue Anwendungen, bei denen die Einschleusung von SQL-Befehlen während der Entwicklung nicht berücksichtigt wurde.
Nehmen Sie beispielsweise an, dass die Front-End-Webanwendung eine dynamische SQL-Anweisung erstellt:
SELECT * FROM Orders WHERE OrderId=25
Diese T-SQL-Anweisung wird erstellt, wenn der Benutzer auf der Unternehmenswebsite den Bestellverlauf öffnet und „25“ in das Formularfeld für die Bestell-ID eingibt. Nehmen Sie jedoch an, der Benutze gäbe nicht nur eine ID ein, sondern beispielsweise 25; DELETE FROM Orders;.
In diesem Fall würde die an die Datenbank gesendete Abfrage wie folgt lauten:
SELECT * FROM Orders WHERE OrderID=25; DELETE FROM Orders;
Die Abfrage im obigen Beispiel weist die SQL-Datenbank mithilfe des Semikolons (;) an, dass die Anweisung beendet ist und die nächste Anweisung ausgeführt werden soll. Die Datenbank verarbeitet dann wie angewiesen die nächste Anweisung, was dazu führen würde, dass alle Zeilen aus der Tabelle „Orders“ gelöscht werden.
Die erste SELECT-Abfrage wird jedoch normal ausgeführt, ohne dass Fehler generiert werden. Wenn Sie nun die Tabelle „Orders“ aufrufen, stellen Sie jedoch fest, dass keine Zeilen vorhanden sind. Die zweite Abfrage im Batch, die alle Zeilen löscht, wurde ebenfalls ausgeführt.
Eine Möglichkeit, Angriffe durch Einschleusung von SQL-Befehlen zu verhindern, besteht darin, den Text von Parametern oder in Formularfelder eingegebene Werte auf verschiedene Schlüsselwörter zu überprüfen. Diese Lösung bietet jedoch nur einen minimalen Schutz, da es viele verschiedene Möglichkeiten gibt, diese Angriffe zu erzwingen. Zu diesen Einschleusungstechniken zählt das Übergeben von Binärdaten, die dann von der Datenbank-Engine in eine Textzeichenfolge zurückkonvertiert werden, um diese anschließend auszuführen. Führen Sie den folgenden T-SQL-Code aus, um ein einfaches Beispiel für dieses Problem zu sehen.
DECLARE @v VARCHAR(255)
SELECT @v = cast(0x73705F68656C706462 AS VARCHAR(255))
EXEC (@v)
Wenn Daten von einem Benutzer (Kunde oder Mitarbeiter) akzeptiert werden, kann beispielsweise sichergestellt werden, dass der Wert nicht für einen Angriff durch Einschleusung von SQL-Befehlen verwendet wird, indem überprüft wird, ob die eingegebenen Daten den erwarteten Datentyp aufweisen. Wenn eine Zahl erwartet wird, sollte die Clientanwendung dafür sorgen, dass tatsächlich eine Zahl zurückgegeben wird. Wenn eine Textzeichenfolge erwartet wird, müssen Sie sicherstellen, dass diese die richtige Länge hat und keine Binärdaten enthält. Die Clientanwendung muss in der Lage sein, alle Daten zu überprüfen, die vom Benutzer übermittelt werden. Diese Überprüfung kann erfolgen, indem Sie den Benutzer über das Problem informieren und es ihm ermöglichen, es zu korrigieren, oder indem ein Fehler zurückgegeben und verhindert wird, dass Befehle an die Datenbank oder das Dateisystem gesendet werden.
Das Korrigieren des Anwendungscodes sollte immer höchste Priorität haben. In manchen Fällen ist das jedoch nicht möglich. Mit Advanced Threat Protection können Sie jedoch eine zusätzliche Schutzebene für vertrauliche Daten hinzufügen.