SQL Server-Sicherheit: Verschlüsselung und SQL Injection

Selbst wenn SQL Injection nur eine Lücke wäre, bei der Daten offen gelegt werden können, wäre das schon schlimm genug. Tatsächlich kann ein versierter Angreifer diesen Fehler jedoch so ausnutzen, dass er fast alles auf dem Server machen kann. Hier ein bösartiges Beispiel eines Stücks SQL, das injiziert werden könnte:

Daraus wird die folgende SQL-Anweisung:

Das Semikolon trennt für SQL Server mehrere Anweisungen, also gibt es hier zwei Anweisungen. Die erste fragt einen nichtexistenten Ansprechpartner ab, die zweite löscht die gesamte Kundentabelle! Der doppelte Bindestrich (–) ist ein SQL Server-Kommentarzeichen, das verhindert, dass das abschließende Anführungszeichen einen Syntaxfehler verursacht.

Mit dieser Variante kann ein Angreifer jede beliebige SQL-Anweisung oder gespeicherte Prozedur auf dem Server ausführen. Mithilfe der erweiterten gespeicherten Prozedur xp_cmdshell kann ein Angreifer sogar Befehle auf Betriebssystemebene ausführen. Dies ist selbstverständlich ein ernstes Problem.

Selbstschutz

Wie schützt man sich also vor einer SQL Injection? Die erste Antwort lautet ganz schlicht: Man darf Benutzereingaben nie direkt in einer WHERE-Klausel verwenden. Stattdessen sollte man gespeicherte Prozeduren mit Parametern benutzen. Im Falle der obigen ASP-Seite würde der entsprechend geänderte Teil so aussehen wie in Listing A.

Selbst wenn man überzeugt ist, dass die eigenen Anwendungen keine solchen Sicherheitslücken aufweisen, sollte man sich immer an das Prinzip halten, nur die notwendigsten Berechtigungen zu vergeben. Das heißt, man sollte die übrigen in dieser Reihe vorgestellten Sicherheitsverfahren anwenden, so dass Anwender nur auf solche Daten zugreifen können, die sie auch benutzen. Auf diese Weise kann selbst eine eventuell übersehene Sicherheitslücke nicht zur Katastrophe führen.