Schreiben von sicherem dynamischen SQL in SQL Server (ADO.NET)

Artikel
08/21/2008

Aktualisiert: November 2007

Die Einschleusung von SQL-Befehlen (SQL Injection-Angriff) ist eine Möglichkeit, Anwendungen anzugreifen. Dabei werden anstelle einer gültigen Eingabe Transact-SQL-Anweisungen in den Code eingeschleust. Wenn die Eingabe direkt und ohne Validierung an den Server weitergeleitet wird und die Anwendung den eingeschleusten Code ausführt, können Daten beschädigt oder sogar zerstört werden.

Alle Prozeduren, die SQL-Anweisungen konstruieren, sollten auf Schwachstellen überprüft werden, die die Einschleusung von SQL-Befehlen ermöglichen, da SQL Server alle syntaktisch gültigen Abfragen ungeprüft ausführt. Selbst parametrisierte Daten können von einem geschickten und entschlossenen Angreifer manipuliert werden. Bei Verwendung von dynamischem SQL sollten Sie Ihre Befehle unbedingt parametrisieren und auf keinen Fall Parameterwerte direkt in die Abfragezeichenfolge aufnehmen.

Anatomie eines SQL Injection-Angriffs

Beim Einschleusen wird eine Textzeichenfolge vorzeitig beendet, und es wird ein neuer Befehl angefügt. Da der eingeschleuste Befehl zusätzliche Zeichenfolgen enthalten kann, die vor dessen Ausführung angefügt wurden, beendet der Angreifer die eingeschleuste Zeichenfolge mit einer Kommentarmarkierung ("--"). Der Text, der dieser Kommentarmarkierung folgt, wird bei der Ausführung ignoriert. Durch Eingabe eines Semikolons (;) als Trennzeichen können auch mehrere Befehle eingeschleust werden.

Sofern der SQL-Code syntaktisch korrekt ist, kann die Manipulation nicht programmgesteuert erkannt werden. Sie müssen daher alle Benutzereingaben validieren und Code sorgfältig prüfen, der konstruierte SQL-Befehle im verwendeten Server ausführt. Verketten Sie nie Benutzereingaben, die nicht validiert wurden. Die Zeichenfolgenverkettung ist der primäre Ansatzpunkt für die Einschleusung von Skriptcode.

Beachten Sie Folgendes:

Erstellen Sie keine Transact-SQL-Anweisungen direkt aus Benutzereingaben. Validieren Sie Benutzereingaben mit gespeicherten Prozeduren.
Validieren Sie Benutzereingaben durch Prüfen des Typs, der Länge, des Formats und des Bereichs. Verwenden Sie die Transact-SQL-QUOTENAME()-Funktion, um Systemnamen zu maskieren, oder die REPLACE()-Funktion, um Zeichen in einer Zeichenfolge zu maskieren.
Implementieren Sie für jede Anwendungsebene mehrere Validierungsschichten.
Prüfen Sie die Größe und den Datentyp der Eingabe, und sorgen Sie für die Einhaltung der festgelegten Grenzwerte. Dies kann helfen, vorsätzliche Pufferüberläufe zu verhindern.
Prüfen Sie den Inhalt von Zeichenfolgenvariablen, und akzeptieren Sie nur erwartete Werte. Lehnen Sie Einträge ab, die Binärdaten, Maskierungssequenzen und Kommentarzeichen enthalten.
Validieren Sie beim Arbeiten mit XML-Dokumenten alle eingegebenen Daten anhand ihres Schemas.
Sorgen Sie dafür, dass in Umgebungen mit mehreren Ebenen alle Daten vor dem Eintritt in die vertrauenswürdige Zone validiert werden.
In Feldern, aus denen Dateinamen konstruiert werden können, dürfen die folgenden Zeichenfolgen nicht akzeptiert werden: AUX, CLOCK$, COM1 bis COM8, CON, CONFIG$, LPT1 bis LPT8, NUL und PRN.
Verwenden Sie für die Typprüfung und die Längenvalidierung SqlParameter-Objekte mit gespeicherten Prozeduren und Befehlen.
Verwenden Sie im Clientcode Regex-Ausdrücke, um ungültige Zeichen herauszufiltern.

Strategien bei der Verwendung von dynamischem SQL

Beim Ausführen dynamisch erstellter SQL-Anweisungen in Ihrem prozeduralen Code wird die Besitzkette unterbrochen, sodass SQL Server die Berechtigungen des Aufrufers anhand der Objekte prüfen muss, auf die die dynamischen SQL-Anweisungen zugreifen.

In SQL Server 2000 müssen Sie zur Verwendung von dynamischen SQL-Anweisungen Berechtigungen für die zugrunde liegenden Tabellen gewähren, wodurch Ihre Anwendung anfällig für Angriffe durch Einschleusen von SQL-Befehlen wird.

Seit SQL Server 2005 gibt es zwei neue Methoden, Benutzern mithife von gespeicherten Prozeduren und benutzerdefinierten Funktionen, die dynamisches SQL ausführen, den Zugriff auf Daten zu gewähren.

Identitätswechsel mit der Transact-SQL-EXECUTE AS-Klausel (siehe Anpassen von Berechtigungen mit Identitätswechsel in SQL Server (ADO.NET))
Signieren gespeicherter Prozeduren mit Zertifikaten (siehe Signieren gespeicherter Prozeduren in SQL Server (ADO.NET))

EXECUTE AS

Die EXECUTE AS-Klausel ersetzt die Berechtigungen des Aufrufers durch die Berechtigungen des in der EXECUTE AS-Klausel angegebenen Benutzers. Geschachtelte gespeicherte Prozeduren oder Trigger werden im Sicherheitskontext des Proxybenutzers ausgeführt. Bei Anwendungen, die sich auf zeilenbasierte Sicherheit stützen oder eine Überwachung verlangen, kann dies zum Abbruch führen. Einige Funktionen, die die Identität des Benutzers zurückgeben, geben den in der EXECUTE AS-Klausel angegebenen Benutzer und nicht den ursprünglichen Aufrufer zurück. Der Ausführungskontext geht erst dann wieder auf den ursprünglichen Aufrufer über, wenn die Ausführung der Prozedur abgeschlossen wurde oder wenn eine REVERT-Anweisung ausgegeben wird.

Signieren mit Zertifikaten

Bei der Ausführung einer mit einem Zertifikat signierten gespeicherten Prozedur werden die dem Zertifikatsbenutzer gewährten Berechtigungen mit den Berechtigungen des Aufrufers zusammengeführt. Der Ausführungskontext bleibt identisch. Der Zertifikatsbenutzer nimmt nicht die Identität des Aufrufers an. Für das Signieren gespeicherter Prozeduren müssen verschiedene Schritte ausgeführt werden. Jedes Mal, wenn die Prozedur geändert wird, muss sie neu signiert werden.

Datenbankübergreifender Zugriff

Bei der Ausführung dynamisch erstellter SQL-Anweisungen funktioniert die datenbankübergreifende Besitzverkettung nicht. Dieses Problem können Sie in SQL Server 2005 umgehen, indem Sie eine gespeicherte Prozedur erstellen, die auf die Daten in einer anderen Datenbank zugreift, und die Prozedur mit einem Zertifikat signieren, das in beiden Datenbanken vorhanden ist. Die Benutzer können dann auf die von der Prozedur verwendeten Datenbankressourcen zugreifen, ohne dass ihnen Zugriffsrechte für die Datenbank oder andere Berechtigungen erteilt werden müssen.

Externe Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

Ressource	Beschreibung
Gespeicherte Prozeduren und SQL Injection in der SQL Server 2008-Onlinedokumentation	In diesen Themen wird beschrieben, wie Sie gespeicherte Prozeduren erstellen können und wie die Einschleusung von SQL-Befehlen funktioniert.
Gespeicherte Prozeduren und SQL Injection in der SQL Server 2005-Onlinedokumentation	In den Themen wird beschrieben, wie Sie gespeicherte Prozeduren erstellen können und wie die Einschleusung von SQL-Befehlen bei SQL Injection-Angriffen funktioniert.
Gespeicherte Prozeduren und Verwenden von Besitzketten in der SQL Server 2000-Onlinedokumentation	In diesen Themen wird beschrieben, wie Sie in SQL Server 2000 gespeicherte Prozeduren erstellen und Besitzketten verwenden können.
Neue SQL-Abschneidungsangriffe und wie man sie vermeidet im MSDN Magazine.	Beschreibt den Umgang mit Begrenzern und Bezeichnern, Praktiken zur Einschleusung von SQL-Befehlen (SQL Injection) sowie Angriffe, bei denen Codeänderungen durch Abschneidung vorgenommen werden.