SQL Injection
Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.
Definition
Wird eingesetzt, um Content Management Systeme mit SQL-Datenbank-Anbindung anzugreifen. SQL Injection wird erst durch Ausnutzen
einer Sicherheitslücke möglich, die durch mangelnde Maskierung bzw. Überprüfung in Benutzereingaben entsteht.
Zählt zu den aktiven Angriffen und wird eingesetzt um empfindliche Daten zu stehlen oder gar die Kontrolle über den angegriffenen
Server zu gelangen. Dabei werden SQL-Kommandos entweder eingeschleust oder manipuliert. Der schädliche Code kann auch über die
Parameter einer URL an die Webseite weitergereicht werden.
Beispiel
Laut [9] treten bei .asp und .cfm Skripten am häufigsten Probleme auf, die eine SQL Injection ermöglichen. Bei mangelnder Maskierung könnte man eine SQL Abfrage wie folgt manipulieren. Zu sehen ist nun eine Login-Abfrage in SQL.
SELECT * FROM users WHERE name ='$username' AND password ='$password'
In das Login-Feld könnte folgendes statt einem korrekten Login-Namen eingetragen werden:
"admin'--"
Wenn diese Eingabe ungefiltert in die obige SQL-Abfrage eingetragen wird, sieht der zu verarbeitende Befehl nun wie folgt aus:
SELECT * FROM users WHERE name ='admin'--' AND password ='beliebig'.
Da -- in SQL als Kommentarzeichen gewertet wird, wird also nur noch
SELECT * FROM users WHERE name ='admin'
verarbeitet. D.h. es wird ein einem Angreifer ein passwortloser Zugang zum Server gewährt, da es nicht mehr notwendig ist,
ein Passwort einzugeben. Der Angreifer muss nur einen Benutzernamen kennen oder diesen erraten.
Diese Art der SQL Injection ist zwar simpel, aber anscheinend immer noch aktuell da, laut [9], 2006 das T-Online Karriereform
so einen passwortlosen Zugang erlaubte.
Durchführung
Natürlich ist eine Anwendung die keine Parameter an eine SQL Datenbank übergibt auch nicht gegen SQL Injection anfällig.
Deswegen werden also nur die Webseiten untersucht, die diese mögliche Schwachstelle haben. Vorzugsweise werden dabei Skriptaufrufe
mit den Endungen ".asp" und ".cmf" gesucht, da hier die meisten Probleme zu erwarten sind [9]. Um die Anfälligkeit der so
ausgewählten Seite auf SQL Injection zu prüfen, gibt es zwei Möglichkeit (beide sollten ausprobiert werden).
Der Code kann möglicherweise über die Parameter der URL injiziert werden z.B. bei http://www.seite.com/artikelid.asp?512 über
die Zahl 512
Bei der ersten Variante wird der komplette Wert durch ein einfaches Anführungszeichen ausgetauscht,
d.h. aus „name=value“ wird „name=’“ . Die zweite Variante verlangt das Setzen des
Anführungszeichens in die Mitte von „value“, so dass anschließend eine Parameterübergabe so
aussieht: „name=val’ue“.
Die so veränderte URL wird mit Enter bestätigt, um zu prüfen, ob eine Datenbank-Fehlermeldung
von der betroffenen Seite ausgegeben wird. Die gesuchten Fehlermeldungen können wie folgt
aussehen:
Fehlermeldungsart 1:
Microsoft OLE DB Provider for SQL Server error ’80040e14’
Unclosed quotation mark before the character string
’51 ORDER BY some_name’.
/some_directory/some_file.asp, line 5
Fehlermeldungsart 2:
ODBC Error Code = S1000 (General error)
[Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended
Wie auch schon im Kapitel 2.4 beschrieben wurde, kann die gesuchte Fehlermeldung im HTML Code liegen ohne angezeigt zu werden. Deswegen muss also auch der Code angesehen werden. Am leichtesten ist es nach den Ausdrücken „Microsoft OLEDB“ oder „[ODBC]“ zu suchen. Werden die beschriebenen Fehlermeldungen gefunden, ist nachgewiesen, dass die untersuchte Anwendung für SQL-Injection zugänglich ist.
Beispiel nach [7].
Gegenmaßnahmen
SQL bietet eigene Möglichkeiten, um sich vor SQL Injection Angriffen zu schützen, wie z.B. Stored procedures und
Prepared statements.
Hinzu kommt noch die Möglichkeit, die eigene Homepage mit Hilfe von frei verfügbaren Tools
auf Schwachstellen gegenüber SQL Injection zu durchsuchen. Ein solches Tool ist z.B. der SQL Injection
Bruteforcer „SQLLibf“, das mittels Brute-Force-Angriffen die dynamischen Variablen einer
Seite auf Schwachstellen testet.
(Weitere Tools dieser Art können bei www.astalavista.com gefunden werden.)
Da der Mensch allerdings gerade bei destruktiven Aufgaben weit
mehr kreative Energie aufbringen kann als dieses Tool, kann auch dieses Tool keine absolute
Sicherheit garantieren. So ist zu empfehlen Datenbankabfragen korrekt zu formulieren. Einige
Beispiele (in unterschiedlichen Programmiersprachen), wie man korrekte Abfragen schreibt, sind
in im weiterführenden Link zu finden.
Allgemein lässt sich festhalten, dass es für den Programmierer einer Anwendung nicht reicht,
nur sauber zu programmieren. Er sollte darüber hinaus auch grundsätzlich allen Daten, die in
irgendeiner Form von außen manipuliert worden sein könnten, misstrauen und diese als unsicher
ansehen. Daraus folgt natürlich das alle Daten zunächst auf Gültigkeit geprüft werden müssen -
das gilt auch für die Variablen in den URLs!
Das heißt natürlich auch, dass keine ungefilterten Strings zur Weiterverarbeitung durchgereicht
werden, also z.B. Steuerzeichen durch ihre Escapesequenzen ersetzt werden.
Zwar würde dadurch kein unerwünschter Befehl mehr ausgeführt werden, allerdings hat das Ersetzen
der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt
würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit
hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde.
Listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen
Tags verändert werden. Dabei gibt es das Whitelisting und das Blacklisting. Auch eine
Vermischung dieser beiden Filterarten ist möglich.
weiterführender Link
[[1]] Beispielliste mit sicheren Datenbankabfragen in unterschiedlichen Programmiersprachen.
Quellen
[1] Security Hacks. Abfragedatum: 24.Mai 2007. http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners
[2] Astalavista Group. Abfragedatum: 24.Mai 2007. http://www.astalavista.com
[3] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html
[4] SQL-Injektion. Abfragedatum: 24.Mai 2007. http://de.wikipedia.org/wiki/SQL-Injektion
[5] heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften
Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885
[6] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications.
Abfragedatum: 24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/hacker-protection.html
[7] Bryan Sullivan: Malicious Code Injection: It’s Not Just for SQL Anymore. Abfragedatum:
24.Mai 2007. http://www.spidynamics.com/spilabs/education/articles/code-injection.html
[8] SQL-Injektion. Abfragedatum: 20.Juni 2007. http://de.wikipedia.org/w/index.php?title=SQL-Injektion&diff=33184377&oldid=32572015
[9] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen – Sicherheit von Webanwendungen.
C’t 2006, Heft 26, S. 234ff
[10] Paul Sebastian Ziegler: XSS – Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin
2007, Heft 1, S. 20ff
