Black Box Webservice API Penetrationstests sind eine dumme Idee

APIs von Webservices spielen in Penetrationstests eine immer größere Rolle. Viele Webanwendungen bestehen heute aus einem JavaScript-Frontend, das JSON- oder XML-Anfragen an das Backend sendet, die Antworten interpretiert und grafisch aufbereitet im Browser darstellt. Noch mehr Mobile Apps sind im Kern lediglich komplexere Anzeigeprogramme, die ebenfalls Anfragen an das Backend senden und dann in der App darstellen. Eigentlich nichts, das ein Browser auch könnte, aber schöner und flexibler in der Darstellung. Ein Penetrationstest dieser Anwendungen konzentriert sich vor allem auf das Backend bzw. die Webservice API, die vom Frontend oder der Mobile App genutzt wird.

Speziell bei Mobile Apps gehen überraschend viele Entwickler davon aus, dass ein Angriff auf das Backend eine Manipulation der Mobile App voraussetzt, was häufig ein Telefon mit Jailbreak oder Root-Zugriff oder die App als unverschlüsseltes Paket voraussetzt. Diese Annahme ist jedoch falsch. Ein Angreifer wird typischerweise zuerst die Kommunikation der App abhören und mit den Aufrufen ein Reverse Engineering der API-Endpunkte durchführen. Der Angreifer kann anschließend mit Burp Suite, ZAP oder eigenen Tools Angriffe durchführen, ohne durch eventuelle Datenprüfung im Frontend gehindert zu werden.

Unterschied Black Box Test und White Box Test

Infrastruktur-Penetrationstests, speziell aus dem Internet, werden oft als Black Box Tests durchgeführt. Ein Black Box Test ist dadurch definiert, dass die Angreifer keine oder nur minimale Informationen über die anzugreifende Infrastruktur erhalten und sich alle Möglichkeiten selbst erarbeiten müssen. Der Gedanke dahinter ist, dass ein echter Angreifer ebenfalls nicht über detaillierte Informationen verfügt und der Penetrationstest deshalb realistischer sein soll. Das Gegenteil davon ist ein White Box Test, bei dem die Angreifer umfangreiche Informationen wie Netzpläne oder sogar Systemkonfigurationen erhalten, vergleichbar mit einem Angriff eines informierten Innentäters.

„Der Feind kennt das System“

Anders als bei Infrastruktur-Penetrationstests, für die ein Black Box Penetrationstest zumindest Sinn ergibt, sind Black Box Tests von Webservice APIs keine gute Idee.

Um überhaupt Angriffe durchführen zu können, müssen die Penetrationstester die Webservice API kennen, d.h. mittels Reverse Engineering entweder der Mobile App oder der Netzwerkkommunikation die API-Endpunkte und die gültigen Parameter herausfinden. Das kann bei einer einfachen API wenige Stunden, bei einer komplexen API auch mehrere Tage Zeit in Anspruch nehmen. Das ist einerseits Zeit, die für konkrete Sicherheitstests verloren ist, andererseits gibt es keine Garantie, dass die Webservice API vollständig ermittelt wurde und keine wichtigen APIs, im schlimmsten Fall genau die mit den Schwachstellen, nicht entdeckt wurden.

Wenn die Sicherheit der API darauf beruht, dass ein Angreifer die Endpunkte und ihre Funktion nicht kennt, spricht man von „Security through Obscurity“

Von Auguste Kerckhoff stammt der im Jahr 1883 für kryptographische Systeme formulierte Satz „Es darf nicht der Geheimhaltung bedürfen und soll ohne Schaden in Feindeshand fallen können.“ Bekannter ist vielleicht die Kurzfassung „Der Feind kennt das System“ von Claude Shannon aus dem Jahr 1949. Das gleiche gilt auch für Webservice APIs. Wenn die Sicherheit der API darauf beruht, dass ein Angreifer die Endpunkte und ihre Funktion nicht kennt, spricht man von „Security through Obscurity“, ein Prinzip, das im Laufe der Zeit grundsätzlich zum Scheitern verurteilt ist.

Penetrationstests von Webservice APIs

Penetrationstests von Webservice APIs sollten deshalb immer als White Box Penetrationstests durchgeführt werden. Die Penetrationstester sollten immer eine vollständige Beschreibung der Webservice API erhalten, idealerweise als maschinenlesbares Swagger-File oder ähnliches. Diese API-Definitionen können dann in Penetrationstest-Tools wie die Burp Suite oder ZAP eingelesen werden, um effizient Fuzzing und andere Angriffe durchführen zu können.

Penetrationstests von Webservice APIs sollten deshalb immer als White Box Penetrationstests durchgeführt werden.

In Penetrationstests stellen wir leider regelmäßig fest, dass zwar verstanden wird, warum ein White Box Test notwendig ist. Die Dokumentation ist jedoch oft unvollständig, veraltet oder anderweitig fehlerhaft. Teilweise fehlen komplette API-Endpunkte, noch häufiger ist die Dokumentation mindestens seit zwei oder drei Versionen veraltet und damit unvollständig.

In Penetrationstests ist eine unvollständige oder fehlerhafte Dokumentation jedoch ein Problem. Nicht dokumentierte API-Endpunkte werden nicht geprüft. Fehler in der Dokumentation kosten viel Zeit durch Prüfung warum Fehler auftreten, Rückfragen bei den Entwicklern und Zeit bis zur Klärung. Wieder alles Zeit, die für die eigentlichen Sicherheitstests fehlt.

Stellen Sie aktuelle und vollständige Dokumentation bereit

Wenn Sie einen Penetrationstest einer Webservice API planen, stellen Sie deshalb unbedingt zusammen mit Ihren Entwicklern eine vollständige Dokumentation der API mit allen Endpunkten bereit und prüfen Sie Aktualität der vorhandenen Dokumente, speziell der übergebenen Parameter und Datentypen.

Planen Sie außerdem vor dem Penetrationstest eine Demonstration der API durch einen Ihrer Entwickler ein, damit sich die Penetrationstester eine Vorstellung der korrekten Funktionsweise der API machen können. Bei dieser Gelegenheit können die Tester auch Rückfragen stellen, die direkt mit dem Entwickler geklärt werden können. Auch das spart Zeit, die für Tests zur Verfügung steht.

Sprechen Sie uns an, wir helfen Ihnen gerne bei der Planung und/oder Ausschreibung eines Penetrationstests.