Dienstag, 9. November 2010


Topthema

Donnerstag, 15. Januar 2009 | Topthema

About Security #188: Schwachstellen-Suche: Scriptcode Injection (2)

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/046855)

Das Einschleusen von Schadcode in Skriptsprachen wurde in About Security #187 beschrieben, in dieser Folge geht es zuerst um die Suche nach entsprechenden Schwachstellen.

Schwachstellen finden

Da sich die Funktionen zur dynamischen Ausführung von Code in den verschiedenen Skriptsprachen weitgehend gleichen, reichen für die Schwachstellensuche einige wenige Testmuster aus. Trotzdem ist es in manchen Fällen notwendig, die verwendete Syntax zu ermitteln und das Verhalten des untersuchten Systems zu berücksichtigen. Zum Beispiel unterstützt Java selbst keine dynamische Codeausführung, einige JSP-Implementierungen dagegen schon. Beim Test der eigenen Anwendung weiß man, das die verwendete JSP-Implementierung entsprechende Funktionen zur Verfügung stellt und daher nach entsprechenden Schwachstellen gesucht werden muss. Bei einem Black-Box-Test, bei dem vorab keine Informationen über das zu untersuchende System zur Verfügung stehen, gehört zum Sammeln der Informationen über die Webanwendung auch die Prüfung, welche Technologien verwendet werden und welche Besonderheiten diese aufweisen.

Parameter prüfen

Generell kommen wieder alle vom Benutzer manipulierbaren Parameter als mögliche Angriffspunkte in Frage. Schon beim Sammeln der Informationen sollten die besonders verdächtigen Parameter ermittelt werden.

Als Test eignet sich besonders ein allgemein gültiger Befehl, der keine Änderungen auf dem Server bewirken kann. Gut geeignet sind z.B. echo für PHP/Perl und response.write für ASP, die ihre Parameter ausgegeben. Als Testmuster für PHP-Anwendungen ist auch phpinfo() geeignet, dessen bekannte Ausgabe sofort auffällt. Als Testmuster können zum Beispiel die folgenden Werte dienen:

;echo%20123456
echo%20123456
:response.write%20123456
response.write%20123456

Danach wird geprüft, ob irgendwo nur 123456, d.h. ohne den Rest der Eingabe, ausgegeben wird. Ist das der Fall, ist die Anwendung wahrscheinlich angreifbar.

Wird 123456 nicht ausgegeben, wird nach einer Fehlermeldung gesucht, die auf eine dynamische Ausführung des Testmusters hinweist. Evtl. muss die Syntax des Testmusters angepasst werden.

Besteht der Verdacht, das die Anwendung angreifbar ist, wird wie bei der Suche nach Command-Injection-Schwachstellen ein Test mit Zeitverzögerung gestartet (siehe About Security #185), z.B.

system('ping%20-i%2030%20127.0.0.1')
Scriptcode Injection verhindern

Der beste Schutz vor dem Einschleusen von Skriptcode besteht wie immer darin, keine vom Benutzer manipulierbaren Parameter für die dynamische Codeausführung zu verwenden. Lässt sich das aus zwingenden Gründen nicht vermeiden, müssen die Parameter besonders gründlich überprüft werden. Wann immer möglich, sollte die Eingabe mit einer Whitelist zulässiger Werte verglichen und nur erwünschte Werte übernommen werden. Die zweitbeste Lösung besteht in einer Beschränkung der Eingabe auf harmlose Wertbereiche, z.B. nur alphanumerische Zeichen ohne Whitespace-Zeichen wie Leer- und Tabulatorzeichen.

XPath-Injection
About Security: Die komplette Serie

Code Injection ist nicht nur in klassischen Skriptsprachen möglich, eine weiter Bedrohung für Webanwendungen ist z.B. die XPath-Injection.

XPath ist eine Sprache zur Abfrage von XML-Daten aus eine XML-Datei. XPath kann direkt für eine Abfrage genutzt werden, Bestandteil einer XSLT-Transformation sein oder für eine XQuery an ein XML-Dokument verwendet werden. XPath-Injection ist das XML-Pendant zur SQL-Injection (siehe About Security #166 ff): Statt SQL-Befehle in eine SQL-Abfrage werden XPath-Ausdrücke in die XPath-Abfrage eingeschleust.

Dabei hat XPath-Injection zwei Vorteile gegenüber SQL-Injection:

  • XPath ist ein einheitlicher Standard, während es für SQL verschiedene "Dialekte" gibt - eine XPath-Injection funktioniert für jede beliebige XPath-Implementierung.
  • Mit XPath kann auf nahezu jeden Teil des XML-Dokuments zugegriffen werden, es gibt keine Zugriffskontrollen mit verschiedenen Benutzern und Rechten. Während bei SQL-Injection das Ergebnis von den Rechten des aktuellen Benutzers abhängig ist, kann bei XPath-Injection immer das gesamte XML-Dokument ausgespäht werden.
Ein einfaches Beispiel

Als Beispiel soll eine Webanwendung dienen, deren Benutzerdaten in einem XML-Dokument gespeichert sind. Die Benutzerdaten bestehen aus Elementen mit dem Namen 'benutzer', die jeweils die 3 Sub-Elemente 'name', 'passwort' und 'userid' enthalten.

Mit der Abfrage

string(//user[name/text()='joe' and passwort/text()='qwertz']/userid/text())

erhält man die User-ID des Benutzers mit dem Namen joe und dem Passwort qwertz. Diese Abfrage kann auch verwendet werden, um die User-ID eines beliebigen Benutzers zu ermitteln, wobei Name und Passwort direkt aus den Eingaben des Benutzers übernommen werden. Ein Angreifer kann nun z.B. als Namen

' or 1=1 or ''='

eingeben, wodurch die Semantik der ursprünglichen XPath-Abfrage so geändert wird, das immer die erste User-ID ausgegeben wird. Der Angreifer kann sich so als Benutzer mit der ersten User-ID einloggen. Wie bei einer SQL-Injection sind auch bei einer XPath-Injection weitere Angriffe möglich. Wird das Ergebnis der XPath-Abfrage nicht ausgegeben, kann der Angreifer analog zu einer Blind SQL-Injection (siehe About Security #175) eine 'Blind XPath-Injection' durchführen, mit der sich das gesamte XML-Dokument ermitteln lässt.

In der nächsten Folge erfahren Sie, wie Sie XPath-Injection-Schwachstellen finden können.

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