SQL Injection

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 0 (nicht überprüft)

Umfang: 4 (unwichtige Fakten fehlen)

Quellenangaben: 4 (fast vollständig vorhanden)

Quellenarten: 2 (befriedigend)

Konformität: 3 (gut)

Definition

SQL Injection 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 Rütten, Glemser (2006) 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. Das heißt,. 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 Rütten, Glemser (2006), 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 Rütten, Glemser (2006). 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 B. Sullivan.

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.

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.

Quellen

• Sima (2006): Caleb Sima; Locking the Door Behind You: Hacker Protection for Your Web Applications; http://www.developerfusion.com/article/5381/locking-the-door-behind-you-hacker-protection-for-your-web-applications/; 2006; Quellengüte: 2 (Web)
• Sullivan (2006): Bryan Sullivan; Malicious Code Injection: It's Not Just for SQL Anymore; http://www.learn.geekinterview.com/it/security/malicious-code-injection-it-s-not-just-for-sql-anymore.html; 2006; Quellengüte: 2 (Web)
• Rütten, Glemser (2006): Christiane Rütten und Tobias Glemser; Gesundes Misstrauen – Sicherheit von Webanwendungen; in: c't; Nummer: 26; Seite(n): 234-239; Verlag: Heise Zeitschriften Verlag; Web-Link; 2006; Quellengüte: 5 (Artikel)
• Ziegler (2007): Paul Sebastian Ziegler; XSS – Cross-site scripting; in: hakin9 - Hard Core IT Security Magazin; Nummer: 1; Seite(n): 20ff; Web-Link; 2007; Quellengüte: 5 (Artikel)
• Wikipedia:SQL-Injektion
• Security Hacks. Abfragedatum: 24.Mai 2007. http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners
  
• Astalavista Group. Abfragedatum: 24.Mai 2007. http://www.astalavista.com
• XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai 2007. http://ha.ckers.org/xss.html
• heise Security news – Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften Verlag. Abfragedatum: 24.Mai 2007. http://www.heise.de/security/news/meldung/89885

Siehe auch

• Wikipedia: Beispielliste mit sicheren Datenbankabfragen in unterschiedlichen Programmiersprachen
• Cross Site Scripting
  
• Code Injection
  
• Whitelisting
  
• Blacklisting
  
• Stored Procedure
  
• Prepared Statement