URL dieser Newsmeldung:

Webanwendungen enthalten wie alle anderen Programme auch mehr oder weniger viele Schwachstellen, von denen viele schon in vorherigen Folgen von About Security vorgestellt wurden. Die entscheidenden Fragen sind: Welche Schwachstellen gibt es und wo befinden sie sich? Ab dieser Folge geht es um die Suche nach Schwachstellen in Webanwendungen, sowohl manuell als auch durch Schwachstellen-Scanner.

Die einzigen wesentlichen Unterschiede zwischen einer manuellen Suche und der Arbeitsweise eines Schwachstellen-Scanners sind die menschliche Intuition und die Unermüdlichkeit des Rechners: Ein Schwachstellen-Scanner nutzt mehr oder weniger dieselben Arbeitsweisen wie ein Mensch, kann aber Schwachstellen nur aufgrund vorgegebener Regeln erkennen, während ein Mensch auch vollkommen neue Schwachstellen finden kann. Dafür ermüdet der Rechner nicht so schnell wie ein Mensch. Im Folgenden wird die manuelle Suche nach Schwachstellen beschrieben und mit der typischen Arbeitsweise eines Schwachstellen-Scanners verglichen. Bei sich bietender Gelegenheit wird auch auf mögliche maschinelle Unterstützung bei der manuellen Suche hingewiesen.

Wie findet man Schwachstellen prinzipiell?

Die Antwort auf diese Frage ist eigentlich ganz einfach: Entweder, man prüft den Quellcode auf Programmierfehler, die zu einer Schwachstelle führen, d.h. im Wesentlichen fehlende oder unzureichende Prüfungen von Eingabewerten. Oder man gibt für alle in der Webanwendung verwendeten Parameter mögliche Angriffsmuster ein und schaut, was passiert. Natürlich kann man auch beide Ansätze kombinieren. Hier soll es hauptsächlich um die Analyse vorhandener Webanwendungen gehen, und zwar der Vollständigkeit halber von Anfang an.

Schritt 1: Informationen sammeln

Am Anfang jedes Angriffs und jeder Suche nach Schwachstellen steht das Sammeln von Informationen über die anzugreifende bzw. zu testende Webanwendung. Beim Test der eigenen Anwendung könnte man darauf verzichten, weil man die entsprechenden Informationen schon besitzt. Trotzdem lohnt es sich, diesen Schritt zumindest theoretisch nachzuvollziehen. Aus dem einfachen Grund, weil ein Angreifer so anfangen würde und man dadurch erfährt, was der Angreifer auch erfahren würde - obwohl er es vielleicht eigentlich gar nicht sollte.

Gesucht werden die Informationen hauptsächlich an 4 Stellen:

• Kommentare im HTML-Code
• Sensitive Informationen im HTML-Code
• Fehlermeldungen der Webanwendung
• Fehlermeldungen des Webservers und HTTP-Responses

Schritt 1a: Den Aufbau der Webanwendung ermitteln

Zuerst müssen alle verwendeten Ressourcen und Parameter ermittelt werden. Dazu können entweder Webcrawler wie z.B. wget genutzt oder alle Seiten manuell durchgegangen werden. Da bei der automatisierten Suche unter Umständen sehr viele Dubletten gefunden werden, ist eine manuelle Suche bei nicht zu großen Websites oft zielführender. Dabei gewinnt man gleich einen Überblick über die Anwendung, den man sich ansonsten aus dem Crawler-Ergebnis erst erarbeiten müsste. Der Nachteil der manuellen Suche ist, dass ein übersehener Link dazu führt, dass die Seiten hinter diesem Link nicht erfasst und dadurch später auch nicht untersucht werden.

Das Vorgehen bei der manuellen Suche ist nahliegend: Ausgehend von der Startseite werden alle Links zu weiteren Seiten angeklickt und dabei die erreichbaren Seiten und die übergebenen Parameter dokumentiert. Während die GET-Parameter direkt in der URL gelesen werden können, müssen die POST-Parameter und Cookies über einen Webproxy wie z.B. Paros sichtbar gemacht werden.

Nutzt die Anwendung verschiedene Benutzerrollen, z.B. für Gäste, normale Benutzer und Administratoren, fängt man mit der niedrigsten Rolle an und arbeitet sich dann bis zur höchsten durch.

Ein Schwachstellen-Scanner arbeitet ähnlich: Entweder werden die Seiten von einem Webcrawler durchsucht, oder die Aktionen eines Testbenutzers werden über einen Proxy aufgezeichnet. Der Nachteil bei der Aufzeichnung über einen Proxy ist derselbe wie bei einer manuellen Suche: Nur die tatsächlich durchgeführten Aktionen werden erfasst. Wird eine Aktion beim Test vergessen oder absichtlich ausgelassen, werden die zugehörigen HTTP-Requests nicht erfasst und dem entsprechend die aufgerufene Seite und zugehörige Folgeseiten später auch nicht geprüft.

Die nächsten manuellen Schritte überspringt ein Schwachstellen-Scanner im Allgemeinen. Stattdessen beginnt er gleich damit, alle erfassten Seiten und Parameter der Reihe nach zu testen. Die meisten Scanner besitzen dafür eine mehr oder weniger große Datenbank mit bekannten Exploits, die sie durchprobieren können. Alternativ können sie auch eine Reihe typischer falscher Werte an die Webanwendung senden und deren Reaktion auswerten (Fuzzing). Außerdem wird z.B. geprüft, ob unauthorisierte Zugriffe auf vertrauliche Informationen, z.B. Konfigurationsdateien, möglich sind.

In der nächsten Folge geht es weiter um das Sammeln von Informationen über die zu testende Webanwendung.

Carsten Eilers