Penetrationstests für Webapplikationen

Gut gesucht ist halb gefunden

Safuat Hamdy

Das versuchte Manipulieren von Webanwendungen durch Sicherheitsexperten ist ein gängiges Mittel, um ihr Sicherheitsniveau einzuschätzen und gegebenenfalls den Handlungsbedarf zu bestimmen. Entwickler und Betreiber dieser Anwendungen können durch geeignete Vorbereitungen solche Tests unterstützen. Tipps und Hinweise eines Penetrationstesters.

Bevor Anwendungen auf Webseiten „scharf geschaltet“ werden, lassen die Betreiber sie häufig von Experten auf Sicherheitslücken überprüfen. Mit diesen sogenannten Penetrationstests (auch Einbruchs- oder Pentests genannt) kann man das Sicherheitsniveau bestimmen und notfalls nachbessern. Entwickler und Betreiber solcher Anwendungen können dazu beitragen, diese Tests besser zu unterstützen.

Der Artikel beschreibt, mit welchen Maßnahmen man zuverlässigere Einschätzungen vornehmen kann und welche Vorbereitungen der Betreiber treffen kann. Die Grundlage dafür sind Erfahrungen aus zahlreichen Penetrationstests des Autors, bei denen gelegentlich die Möglichkeit für einen aussagekräftigen Test unnötig eingeschränkt wurde.

Unter einem Penetrationstest versteht man im Allgemeinen die systematische Suche nach bekannten und offensichtlichen Schwachstellen anhand eines Prüfplans wie beispielsweise des OWASP Testing Guide [1], des OWASP ASVS Level 1 [2] oder der Methodik aus dem Web Application Hacker’s Handbook [3, Kapitel 21]. Diese Form des Penetrationstests ist wirtschaftlich machbar und wird gerade deshalb in den meisten Fällen von Kunden in Anspruch genommen.

Vertiefende Tests würden es beispielsweise erfordern, die zu untersuchende Webanwendung oder Teile davon nachzustellen und ihr mit Debuggern und ähnlichen Werkzeugen zu Leibe zu rücken. Es versteht sich von selbst, dass der Aufwand für so ein Vorgehen ungleich größer ist und daher auch praktisch nicht nachgefragt wird. Dementsprechend wird diese aufwendige Form im Folgenden nicht weiter betrachtet.

Testkonten müssen realistisch sein

Die meisten für einen Angreifer „interessanten“ Anwendungen erfordern eine Anmeldung und verfügen über eine Benutzerverwaltung. Für einen Test sollten also verschiedene Testkonten bereitstehen. Doch selbst da gilt es, einige Fallstricke zu vermeiden. Es reicht nämlich nicht, dem Tester die Anwendung hinzustellen, ein Testkonto einzurichten und ihn beginnen zu lassen. Ein Test etwa nach OWASP Testing Guide beleuchtet viele Facetten der Anwendung. Um alle anwendungsspezifischen Workflows angemessen durchlaufen zu können und die Testabdeckung zu maximieren, sollten die Konten möglichst realistisch angelegt und mit Testdaten ausgestattet sein.

Die folgenden Beispiele illustrieren das Problem:

1. Eine E-Commerce-Plattform erfordert an einer Stelle Zahlweginformationen, etwa Kreditkartendaten, die verarbeitet werden, um eine Bestellung auszulösen. Die Kreditkartendaten werden dabei auf Gültigkeit geprüft. Was soll der Tester an dieser Stelle tun? Wenn er nicht seine persönlichen Daten verwenden möchte, dann ist an dieser Stelle Schluss und der weitere Workflow bleibt für ihn unerreichbar. Dasselbe gilt für Workflows wie das Verfolgen von Bestellungen, das Stornieren oder das Veranlassen einer Rücksendung.

2. Eine Onlinebanking-Plattform erfordert für einige Workflows wie Auslösen einer Überweisung oder Anlegen einesDauerauftrags eine TAN. Außerdem braucht der Tester ein Zielkonto für die Testüberweisungen. Ihm wurde aber beides nicht zur Verfügung gestellt. Wesentliche Teile der Anwendungslogik kann er folglich nicht auf Schwachstellen prüfen.

3. Eine Handelsplattform sieht vor, dass an einer Stelle im Workflow eine (echte) Bestellung ausgelöst wird. Der Tester wird daher gebeten, bestimmte Workflows nur bis zu einem gewissen Punkt und andere überhaupt nicht auszuprobieren.

4. Für eine Hosting-Plattform können Kunden verschiedene kostenpflichtige Module oder Pakete buchen, die für das Testkonto aber nicht a priori zur Verfügung gestellt wurden. Das Buchen eines Moduls erfordert es, einen Bestellprozess (mit echten Daten) zu durchlaufen. Diese Module eröffnen weitere Workflows, die abermals unerreichbar sind, das heißt, auch in diesem Fall muss der Penetrationstest unvollständig bleiben.

5. Eine Onlineplattform bietet ihren Kunden verschiedene Dokumente zum Herunterladen an. Der Zugriff auf die Dokumente ist unter anderem dadurch geschützt, dass die URL pseudozufällig und somit für einen Angreifer schwer zu erraten ist. Im Testkonto wird genau ein Dokument zur Verfügung gestellt. Erst viel später stellt sich nebenbei heraus, dass es mit der Zufälligkeit nicht weit her ist und dass durch Erraten des Benennungsschemas weitere Dokumente gefunden werden können.

Diese Beispiele zeigen, dass auch ein Penetrationstest etwas Planung seitens der Auftraggeber und der Entwickler erfordert. In allen genannten Fällen lautet die Lösung „Dummydaten mit Sonderbehandlung“, aber dazu später mehr.

In dieselbe Richtung gehen einige Erlebnisse, bei denen echte Konten zum Test zur Verfügung standen, natürlich mit echten (personenbezogenen!) Daten. Die damit einhergehenden Anweisungen gingen in einem Fall etwa in die Richtung von „nur gucken, nichts anfassen“, in anderen Fällen erfolgte die Übergabe ohne weiteren Kommentar. Dinge anzufassen, ist der Kern eines Penetrationstests, und dabei kann bisweilen auch etwas zu Bruch gehen. Ein echter Angreifer wird darauf nur so weit Rücksicht nehmen, wie es ihm nützt.

Tücken der Testumgebung

Abgesehen davon ist es strafbar, Kundendaten, insbesondere personenbezogene Daten, ohne rechtliche Grundlage oder Zustimmung einem Dritten bereitzustellen. Ein gewissenhafter Tester sollte den Auftraggeber darauf hinweisen und den Test unter solchen Bedingungen verweigern.

Dies führt unmittelbar zum Thema Testumgebung. Ein Tester-Mantra lautet, dass Tests und besonders Penetrationstests unbedingt in einer repräsentativen Testumgebung erfolgen sollten. Allzu oft wird eine entsprechende Anfrage jedoch damit quittiert, dass es keine Testumgebung gebe und dass auf der Produktivumgebung zu testen sei. Wie man damit ins Schleudern geraten kann, sieht man etwa an den folgenden zwei Fallbeispielen:

6. In mehreren Fällen konnte man innerhalb der Anwendungen als Benutzer Objekte anlegen. Dieser Vorgang ließ sich in der Regel mittels geeigneter Werkzeuge, etwa mit dem Burp Intruder, automatisieren. In keinem der beobachteten Fälle war auch nur ein Hauch von Widerstand, etwa in Form einer Beschränkung, festzustellen (s. Prüfpunkt BUSLOGIC-005 im Testing Guide). Will man als Penetrationstester an diesen Stellen einen realistischen Angreifer simulieren, gerät man gelegentlich in Versuchung, das Skript zum Erstellen neuer Objekte erst einmal laufen zu lassen und nach einer Woche nachzusehen, wie die Anwendung dann aussieht.

7. In mehreren Fällen war durch bestimmte Manipulationen Zugriff auf echte Kundendaten möglich, in einem Fall sogar Vollzugriff. In solchen Fällen kann durchaus etwas abhandenkommen oder verändert werden – wehe dem Auftraggeber, der in dieser Situation keine aktuellen Backups griffbereit hat.

Wie also sieht eine gute Vorbereitung für einen Webanwendungs-Penetrationstest aus? Was müsste ein Entwickler oder ein Betreiber tun, um den maximalen Mehrwert aus einem solchen Test herauszuholen?