Konzept für das Penetrationtesting von Vaadin-Anwendungen (Teil 2)

IT-Sicherheit, Mobile- und Weblösungen

vaadin-Beitrag1

Gängige Vulnerability-Scanner, wie OWASP ZAP, sind nicht in der Lage, Vaadin-Anwendungen auf Sicherheitslücken zu untersuchen. Dies liegt an dem Aufbau der Vaadin-Anwendungen. In diesem Teil der Blogreihe erläutern wir eine Kompatibilitätsschicht, die das Scannen von Vaadin-Anwendungen dennoch ermöglicht.

Im ersten Blogbeitrag dieser Serie haben wir erklärt, wieso Vaadin-Anwendungen nicht mit Vulnerability-Scannern auf Sicherheitslücken untersucht werden können. Die Scanner können mit der Funktionsweise von Vaadin nicht umgehen. Das heißt aber nicht, dass automatische Scans von Vaadin-Anwendungen grundsätzlich nicht möglich sind. Stattdessen muss ein Weg gefunden werden, der es Scannern erlaubt, Vaadin-Anwendungen zu „verstehen“.

Im Rahmen der Abschlussarbeit von Tamara Gunkel wurde eine Hilfsanwendung namens „PenTest4Vaadin“ entwickelt, die auf dieses Problem eingeht. Das Tool wurde als eigenständiges Programm entworfen, damit es generisch ist und in Kombination mit beliebigen Vulnerability-Scannern eingesetzt werden kann. PenTest4Vaadin sitzt als „Middleware“ zwischen der zu scannenden Vaadin-Anwendung (=Testanwendung) und dem Scanner. In unserem Beispiel OWASP ZAP. Sämtliche Kommunikation zwischen OWASP ZAP und der Testanwendung wird über die Hilfsanwendung abgewickelt. Dies ermöglicht es der Hilfsanwendung, OWASP ZAP vorzutäuschen, dass die Vaadin-Anwendung wie eine klassische Webanwendung funktioniert.

Im Folgenden wird das Konzept detailliert beschrieben. Abbildung 1 zeigt, dass PenTest4Vaadin in der Mitte (in blau dargestellt) zwischen Vaadin-Anwendung (links) und OWASP ZAP (rechts) vermittelt. Genauer betrachtet besteht PenTest4Vaadin aus drei Komponenten: dem Form Selector, der Datenbank und dem Scan Helper.

Bevor der Anwender einen Scan durchführen kann, muss zuerst der Form Selector benutzt werden. Dieser ist mit Unterstützung des Benutzers dafür zuständig, alle Seiten und Formulare zu indizieren. Der Form Selector öffnet einen Browser und injiziert ein Skript in die aufgerufene Webseite. Das Skript ermöglicht es dem Benutzer, zu einzelnen Unterseiten der Webseite zu navigieren und die Formulare auszuwählen, die gescannt werden sollen. Dieser Schritt wurde bislang nicht automatisiert, weil es nicht trivial ist, Eingabeformulare in Vaadin-Anwendungen zu finden. Dies liegt daran, dass sich durch die HTML-Struktur nicht erkennen lässt, welche Felder gemeinsam ein Formular bilden. Der Form Selector unterstützt Shadow DOMs und daher kann der Benutzer die Eingabefelder der Webkomponenten auswählen.

Die Eingabeformulare und zugehörigen URLs werden in einer Datenbank gespeichert, die als Kommunikationspunkt zwischen dem Form Selector und dem Scan Helper dient. Die Datenbank fasst einzelne Eingabefelder zu Formularen zusammen. Der Form Selector exportiert anschließend eine Datei mit anwendungsspezifischen „Pseudo“-URLs, die auf Eingabeformulare deuten. Da die Eingabeformulare benannt sind, kann ein Benutzer diese URLs leicht einer Seite und einem Formular zuordnen. Die URLs enthalten für jedes Eingabeelement des dazugehörigen Formulars einen GET-Parameter.

Diese URLs werden in Schritt 5 in OWASP ZAP importiert, wodurch OWASP ZAP einen Seitenbaum erstellt, der dem einer statischen Webseite ähnelt. Mit diesem Seitenbaum kann OWASP ZAP arbeiten und z. B. einen aktiven Scan ausführen. Da der Seitenbaum bereits erstellt wurde, muss kein Spider mehr ausgeführt werden.

Sobald OWASP ZAP Anfragen an die Testanwendung verschickt, kommt der Scan Helper zum Einsatz. Da die Anfragen an die Pseudo-URLs gerichtet sind, müssen diese wieder in die richtigen URLs bzw. Events übersetzt werden. Der Scan Helper sucht das angefragte Formular in der Datenbank und führt die dazugehörigen Aktionen mit den übergebenen Parametern nacheinander aus. Der Seitenquelltext nach der letzten Aktion wird zurückgegeben, weil normalerweise nach dem Absenden eines Formulars ein neues HTML-Dokument als Antwort versendet wird. Die Antwort wird ggf. modifiziert, damit Fehlermeldungen besser zum Vorschein kommen, die sonst im Quelltext untergehen würden. Da nur eine Antwort zurückgegeben wird, kann OWASP ZAP diese weiterverwenden und auf Schwachstellen analysieren.

Der Scan Helper muss mithilfe eines Browsers mit dem Frontend der Testanwendung interagieren. Vaadin synchronisiert Client und Server, weshalb direkte Serveranfragen nicht möglich sind. Der Scan Helper erzeugt daher JavaScript Code, der im Browser ausgeführt wird und Eingabefelder ausfüllt sowie auf Buttons klickt. Die Verwendung des Frontends hat den Nachteil, dass die clientseitige Validierung nicht umgangen werden kann. Dies ist in Bezug auf die Vaadin Webkomponenten nicht schlimm, da diese die Eingaben ohnehin serverseitig validieren. Deshalb würde das Umgehen der clientseitigen Validierung keinen Vorteil bringen. Wenn man hingegen eigene Komponenten verwendet, die nur clientseitige, aber keine serverseitige Validierung implementieren, können Sicherheitslücken im Backend Code nicht gefunden werden. Derzeit beschränkt sich die Funktionalität des Tools auf die Analyse von HTML-Formularen. Formulare bieten die größte Angriffsstelle für Angreifer, weil die meisten Sicherheitslücken über Benutzereingaben ausgenutzt werden können.

Die Anwendung PenTest4Vaadin ist OpenSource und steht unter BSD-3 Lizenz auf Github zur Verfügung.