entwickler.com

Ab dieser Folge geht es in About Security um die Sicherheit von Webanwendungen. Zuerst erfahren Sie etwas über das Einschleusen von SQL-Code in Datenbankabfragen – die SQL Injection.

Was ist SQL Injection?

Die Structured Query Language (SQL) ist eine Abfragesprache für relationale Datenbanken. Viele Webanwendungen verwenden zur Speicherung von Informationen eine solche Datenbank. Unabhängig davon, ob es sich um einen Webshop mit einer Artikeldatenbank, ein Forensystem mit Benutzerdaten oder ein Content-Management-System mit Texten handelt, bieten diese meist eine oder mehrere Möglichkeiten für den Benutzer, um Daten aus der Datenbank abzufragen. Diese Abfragen werden intern in SQL formuliert. Dabei werden vorgegebene Teile mit den Benutzereingaben zu einer kompletten Abfrage kombiniert. Werden die vom Benutzer gelieferten Eingaben nicht ausreichend geprüft, kann ein Angreifer beliebige SQL-Befehle in die Abfragen einschleusen. Dieses Einschleusen von Code wird als SQL Injection bezeichnet.

Einige Beispiele

Ein Forensystem speichert die Benutzerinformationen in der Tabelle Benutzer der Datenbank Forum. Die Tabelle hat die Spalten BenutzerNr, BenutzerName, RealName, Ort, Status und Passwort. Dabei soll Status die Werte normal für einfache Benutzer und admin für Benutzer mit Administratorrechten annehmen können.

Der SQL-Befehl

SELECT * FROM Benutzer WHERE Ort = 'Berlin'

gibt die Einträge aus der Tabelle Benutzer aus, die in der Spalte Ort den Wert Berlin aufweisen.

Um die Abfrage flexibler zu gestalten, wird statt des konstanten Werts meist eine Variable verwendet:

SELECT * FROM Benutzer WHERE Ort = ''

Solange nur Eingaben wie Berlin, Hamburg, ... enthält, passiert nichts Unerwünschtes. Ein bösartiger Benutzer könnte jedoch auch versuchen, SQL-Befehle einzuschleusen. Die Eingabe

Berlin'; DROP TABLE Benutzer -- 

würde zu folgendem SQL-Befehl führen:

SELECT * FROM Benutzer WHERE Ort = 'Berlin'; DROP TABLE Benutzer --'

Das Semikolon ist ein Trennzeichen, die Zeichenfolge -- leitet einen Kommentar ein. Damit werden folgende SQL-Befehle ausgeführt:

SELECT * FROM Benutzer WHERE Ort = 'Berlin'

gibt wie gehabt die Einträge aus der Tabelle Benutzer aus, die in der Spalte Ort den Wert Berlin aufweisen.

DROP TABLE Benutzer

löscht die Tabelle Benutzer, sofern die Webanwendung die notwendigen Rechte dazu hat.

--'

sorgt dafür, dass das letzte Quote-Zeichen ignoriert wird und keinen Fehler verursacht.

Beim Aufruf mit der Eingabe

Berlin'; UPDATE Benutzer SET Status = 'admin' WHERE BenutzerName = 'Angreifer

ergeben sich folgende Befehle:

SELECT * FROM Benutzer WHERE Ort = 'Berlin';
UPDATE Benutzer SET Status = 'admin' WHERE BenutzerName = 'Angreifer'

Damit kann sich der Angreifer Administratorrechte für das Forensystem verschaffen. Voraussetzung dafür ist, dass er Kenntnisse über die Datenbankstruktur besitzt. Bei Open-Source-Software kann er diese im Sourcecode nachlesen, bei Closed-Source-Software kann er selbst provozierte Fehlermeldungen ausnutzen, um sich die nötigen Informationen zu verschaffen.

Mit der Eingabe

' OR 1=1 -- 

erhält man

SELECT * FROM Benutzer WHERE Ort = '' OR 1=1 --'

Damit würde die gesamte Tabelle Benutzer ausgegeben.

Auch der direkte Aufruf von Systembefehlen ist möglich. Für den MS-SQL-Server unter Windows 2000 würde die Eingabe

' exec master..xp_cmdshell 'net user boese boese/ADD

zur Abfrage

SELECT * FROM Benutzer WHERE Ort = '' 
exec master..xp_cmdshell 'net user boese boese/ADD'

führen. Der MS-SQL-Server erkennt den hinteren Teil des Befehls als Extended Stored Procedure (ESP) und führt sie auf dem Server aus. Die Funktion xp_cmdshell übergibt ihren Parameter an die DOS-Kommandozeile. Diese legt auf dem System den Benutzer boese mit dem Passwort boese an. Darüber kann der Angreifer dann auf das System zugreifen.

Um Benutzername und Passwort beim Einloggen zu prüfen, könnte folgende Abfrage mit den Benutzereingaben und verwendet werden:

SELECT COUNT(*) FROM Benutzer WHERE BenutzerName='' AND Passwort=''

Um sich als beliebiger Benutzer anzumelden, kann ein Angreifer irgendeinen Benutzernamen, im Beispiel bob, und das Passwort

' OR 1=1 --

eingeben. Dies ergibt

SELECT COUNT(*) FROM Benutzer WHERE BenutzerName='bob' AND Passwort='' OR 1=1 --'

Statt nach Benutzernamen und passendem Passwort sucht diese Abfrage nur nach dem Benutzernamen bob. Existiert dieser Benutzername, ist der Angreifer danach als bob angemeldet.

Dies ist nur eine kleine Auswahl möglicher Angriffe über SQL-Injection. Wie Sie sehen, kann eine kleine Nachlässigkeit bei der Prüfung von Benutzereingaben unter Umständen schwerwiegende Folgen haben. In der nächsten Folge erfahren Sie, wie Sie SQL Injection verhindern können.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen"

• About Security #11: SQL Injection
• About Security #12: SQL Injection verhindern
• About Security #13: Mit Stored Procedures gegen SQL-Injection
• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #16: Skriptcode einschleusen
• About Security #17: HTTP Request Smuggling
• About Security #18: Spielarten des HTTP Request Smuggling, 1
• About Security #19: Spielarten des HTTP Request Smuggling, 2
• About Security #20: HTTP Request Smuggling erkennen und verhindern
• About Security #21: HTTP Response Splitting, 1
• About Security #22: HTTP Response Splitting, 2
• About Security #23: Caches vergiften
• About Security #24: Caches indirekt vergiften
• About Security #25: Entführen von Webseiten
• About Security #26: Gefahren für Webanwendungen
• About Security #27: Gefahren für Webserver
• About Security #28: Standorte für Webserver