Probleme beim Security-Test von Vaadin-Anwendungen (Teil 1)

Java & Architektur, Forschung & Entwicklung, Wissenschaftliche Arbeiten, IT-Sicherheit, Mobile- und Weblösungen

Vaadin wird als Java-Webframework oft für die Entwicklung von Enterprise-Anwendungen eingesetzt. Hier gilt es, Daten zu schützen und die Anwendungen auf Sicherheitslücken zu untersuchen. Gängige Vulnerability-Scanner, wie OWASP ZAP, unterstützen jedoch keine Vaadin-Anwendungen. Wir zeigen im ersten Teil unserer Blogreihe, warum das so ist.

Sicherheit in Vaadin-Anwendungen

Da die Vaadin-Plattform professionell für Enterprise-Anwendungen entwickelt wird, sind bereits einige Sicherheitsvorkehrungen implementiert. Die Plattform bietet automatischen Schutz gegen einige bekannte Sicherheitslücken, die im direkten Zusammenhang mit dem Frontend stehen. Es wird nur vor clientseitigen Sicherheitslücken geschützt, weil der Entwickler lediglich über Schnittstellen auf den Vaadin-Client zugreift und daher die Schutzmechanismen immer angewendet werden können. Da der Backend-Code individuell ausgestaltet wird, kann dort kein zusätzlicher Schutz gegeben werden. Vaadin schützt z. B. automatisch vor Cross-Site Request Forgery, indem alle Requests zwischen Client und Server einen CSRF-Token enthalten. Außerdem werden alle HTML-Sonderzeichen in Benutzereingaben maskiert, damit XSS-Attacken nicht möglich sind. Weiterhin wird der Client-Zustand mit dem Server-Zustand synchronisiert, sodass falsche Requests nicht verarbeitet werden, wenn der Client nicht wirklich im Browser angezeigt wird. Die Webkomponenten von Vaadin stellen zudem sicher, dass keine unerwarteten Werte eingegeben werden, indem auf dem Server alle möglichen Werte hinterlegt werden.

Wie bereits erwähnt, bietet Vaadin aber keinen vollumfassenden Schutz. Im Backend muss der Entwickler selbst Sicherheitsvorkehrungen treffen, um z. B. SQL-Injection-Lücken zu verhindern. Zudem ist es möglich, manche Schutz-Features zu deaktivieren. Außerdem ist man nicht verpflichtet, die Webkomponenten von Vaadin zu verwenden. Externe Webkomponenten können weniger Schutz bieten. Zuletzt können logische Schwachstellen, wie z. B. fehlende Authentifizierung oder die Verwendung unsicherer Übertragungsprotokolle, von Vaadin nicht verhindert werden.

Problematik beim automatischen Schwachstellenscan

Da Vaadin nicht vor allen Sicherheitslücken schützen kann, ist es nötig, Anwendungen auf Schwachstellen zu analysieren. Um möglichst alle Schwachstellen aufzudecken, muss die Anwendung manuell getestet werden. Da dies allerdings sehr aufwendig ist, kann der Prozess durch Vulnerability-Scanner unterstützt werden. Vulnerability-Scanner senden viele speziell generierte Serveranfragen an die zu testende Anwendung und analysieren die Antwort auf Hinweise darauf, dass eine Schwachstelle ausgenutzt wurde. Es hat sich jedoch herausgestellt, dass Vulnerability-Scanner für Vaadin-Anwendungen keine zufriedenstellenden Ergebnisse liefern, weil der Vaadin-Client nicht standardkonform mit dem Server kommuniziert.

Wir haben die Kommunikation zwischen Vaadin-Client und Server genauer im Test mit OWASP ZAP untersucht, um die Ursachen festzustellen. Dabei wurden nur Vaadin-Versionen über 10 betrachtet, da mit Vaadin 10 grundlegende Erneuerungen vorgenommen wurden. Die durchgeführte Untersuchung zeigt, dass zwei Funktionsweisen einen automatischen Schwachstellenscan verhindern. Der erste Grund ist, dass kein sinnvoller Seitenbaum erstellt wird und HTML-Formulare nicht gefunden werden. Generell ist es nicht einfach, alle Unterseiten einer Single-Page-Anwendung (SPA) zu finden. Dennoch liefert der AJAX-Spider von OWASP ZAP zufriedenstellende Ergebnisse für die meisten SPAs. Das Hindernis bei Vaadin ist die Verwendung der Shadow-DOM-Funktionalität, die von den Webkomponenten verwendet wird. Mithilfe von Shadow-DOMs können HTML-Elemente unter einem Root-Element angeordnet und vom Rest der Seite abgekapselt werden. JavaScript und CSS der Seite beeinflussen nur noch die Root-Elemente, während auf die anderen Elemente nicht mehr zugegriffen werden kann. Dadurch werden viele Elemente, insbesondere Eingabefelder, nicht gefunden.

Zweitens bereitet die Funktionsweise des Data Bindings und das Kommunikationsverfahren von Vaadin Probleme. Es ist problematisch, dass Vaadin keine HTML-Formulare benutzt. So generiert jede Eingabe und jeder Klick eine neue Serveranfrage, um bspw. on-the-fly Eingabevalidierung zu betreiben. Deshalb sind z. B. für ein Log-in-Formular drei Anfragen nötig: für das Feld Benutzername, das Feld Passwort und den Login Button. Viele andere Anwendungen würden ein Log-in-Formular als HTML-Formular darstellen und daher nur eine Anfrage abschicken. Dies ist auch der einzige Ansatz, den OWASP ZAP kennt. Daher ist das Tool nicht in der Lage, mehrere Anfragen abzusenden, um ein Eingabeformular auf Sicherheitslücken zu testen.

Nachdem die Ursachen für die Inkompatibilität von Vaadin-Anwendungen und Vulnerability-Scannern festgestellt wurden, wurde ein Konzept entworfen, wie die Probleme gelöst werden können. Im zweiten Teil unserer Blogreihe stellen wir Euch dieses Konzept vor.