Mittwoch, 23. November 2011


Topthema

Donnerstag, 11. September 2008 | Topthema

About Security #172: Schwachstellen-Suche: SQL-Injection mit Filter

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/045102)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Um SQL-Injection zu verhindern, muss man sich nur an den alten Grundsatz "Traue nie dem Client" halten: Alle Benutzereingaben m�ssen gepr�ft und gefiltert werden. Welche M�glichkeiten es daf�r gibt und wie ein Angreifer die Filter austricksen kann, erfahren Sie in dieser Folge.

Der einfachste Fall: Zahlen

Der einfachste Fall sind Parameter, die nur Zahlen enthalten d�rfen. Die Eingaben k�nnen dann einfach in Werte aus dem passenden Bereich, z.B. Integer, umgewandelt werden, und eventuell eingeschleuster Schadcode wird eliminiert. Je nach Anwendungsfall muss der sich ergebende Zahlenwert noch auf seine G�ltigkeit im Rahmen der Anwendung gepr�ft werden, um keine unerw�nschten Fehlermeldungen zu erzeugen.

Etwas schwieriger: Buchstaben

Auch Parameter, die nur Buchstaben und bestimmte, genau definierte, harmlose Sonderzeichen wie z.B. ein Leerzeichen enthalten d�rfen, lassen sich recht einfach pr�fen und gegebenenfalls filtern. �ber regul�re Ausdr�cke kann gepr�ft werden, ob die Eingabe wirklich nur die gew�nschten Zeichen enth�lt, und alle unerw�nschten Zeichen k�nnen gel�scht werden.

Gef�hrlich: Eingaben mit potenziell gef�hrlichen Sonderzeichen

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

Parameter, die f�r SQL-Injection verwendbare Sonderzeichen enthalten k�nnen, sind schwieriger zu pr�fen und zu filtern. Filter, die bestimmte Zeichen l�schen oder maskieren, k�nnen unter Umst�nden vom Angreifer ausgetrickst werden. Wie beim Verhindern von Cross-Site-Scripting gilt daher, dass besser eine Positivliste zul�ssiger Werte verwendet werden sollte. Und ebenso wie f�r Cross-Site-Scripting gibt es auch f�r SQL-Injection Cheat-Sheets mit M�glichkeiten, Filter zu umgehen. Die Version von ha.ckers.org enth�lt zus�tzlich eine Kodierfunktion, um ASCII-Text in verschiedene andere Formate umzuwandeln.

Filter umgehen: Erste Beispiele

Wird das einfache Anf�hrungszeichen ' ausgefiltert, verhindert das keine Angriffe in numerische Parameter (About Security #168): Wird der betreffende Parameter f�r die SQL-Abfrage nicht in ' eingeschlossen, muss der Angreifer auch keine '-Zeichen schlie�en.

Wird das Kommentarzeichen -- ausgefiltert, mit dem der Angreifer auf seinen eingeschleusten Schadcode folgende Teile der SQL-Abfrage auskommentiert, k�nnte versucht werden, den eingeschleusten Code so zu formulieren, dass auch ohne Auskommentieren eine g�ltige SQL-Anweisung entsteht. Statt
nix' or 1=1--
k�nnte z.B.
nix' or 'a'='a
verwendet werden (About Security #166).

Wird eine einfache Blacklist verwendet, um unerw�nschte Schl�sselw�rter auszufiltern, reicht oft eine �nderung der Schreibweise oder Codierung, um den Filter zu umgehen. Wird beispielsweise das Schl�sselwort SELECT ausgefiltert, kann stattdessen oft eine Variante wie sElEcT, SELSELECTECT, %53%45%4c%45%43%54 oder %2553%2545%254c%2545%2543%2554 verwendet werden.

Leerzeichen ersetzen

Werden Leerzeichen ausgefiltert, k�nnen sie durch Kommentare ersetzt werden. Aus dem Beispiel zur Abfrage der Datenbankversion aus About Security #171,

nix' UNION SELECT NULL, @@version, NULL--

wird dann z.B.

nix'/*bla*/UNION/*bla*/SELECT/*bla*/NULL,/*bla*/@@version,/*bla*/NULL--
About Security: Die komplette Serie

Der SQL-Interpreter behandelt die Kommentare wie Whitespace-Zeichen. In MySQL k�nnen Kommentare sogar innerhalb von Schl�sselw�rtern verwendet werden - f�r einen Angreifer eine ideale M�glichkeit, um manche Filter zu umgehen:

nix' UNI/*bla*/ON SELE/*bla*/CT NULL, @@version,NULL--

wird von MySQL genauso ausgef�hrt wie die nicht verunstaltete Abfrage.

Gefilterte Strings tarnen

Werden von der Webanwendung bestimmte Strings ausgefiltert, die f�r den SQL-Injection-Angriff ben�tigt werden, k�nnen sie dynamisch in der Abfrage zusammengesetzt werden. Wird der f�r das letzte Beispiel in About Security #170 ben�tigte String passwort ausgefiltert, kann er in MySQL z.B. als concat('pas','swort') geschrieben werden. Aus

entwickler.press' UNION SELECT benutzername, passwort, id FROM benutzer--

wird dann

entwickler.press' UNION SELECT benutzername, concat('pas','swort'), id FROM benutzer--

Meist stellen die Datenbanken mehrere Funktionen zur Manipulation von Strings bereit, die alle verwendet werden k�nnen, um einen gefilterten String an der Pr�ffunktion vorbeizuschleusen.

Filter durch dynamische Ausf�hrung unterlaufen

Erlaubt die Datenbank die dynamische Ausf�hrung von SQL-Anweisungen, indem eine Funktion mit einem die SQL-Anweisung darstellenden String aufgerufen wird, k�nnen auch dar�ber Filter umgangen werden. In MS-SQL wird daf�r die Funktion exec() verwendet, z.B. so:

exec('select * from benutzer')

In MS-SQL k�nnen Strings �ber + miteinander verbunden werden. Eine Blacklist, die Schl�sselw�rter wie SELECT oder unerw�nschte Strings wie den Tabellennamen benutzer enth�lt, k�nnte also durch Eingabe von exec('se'+'lect * from ben'+'utzer')umgangen werden.

In der n�chsten Folge erfahren Sie, wieso das oft zur Verhinderung von SQL-Injection-Angriffe verwendete Escapen von Sonderzeichen wie dem ' nicht zwingend zum Erfolg f�hrt.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - �bersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren