Wie kann man moderne Web Applikationen richtig absichern?
Die mangelnde Sicherheit von Webanwendungen ist eines der Hauptprobleme in vielen Unternehmen. In diesem Artikel gehen wir auf dieses Problem ein und schlagen mögliche Lösungen vor.
Die IT Sicherheit ist heutzutage eines der wichtigsten Themengebiete in unserer vernetzten Welt und gehört in jede IT Strategie. Dies wird Ihnen auch jeder IT Berater sehr eindrücklich sagen. Wie sieht es dann sicherheitstechnisch mit Web Applikationen aus?
Mit einer Standardsoftware kann man gewissermassen einen Teil der Verantwortung bei deren Hersteller sehen. Doch wenn Ihr Unternehmen ein eigenes Team an Softwareentwicklern hat, welches im Rahmen eigener IT Projekte Web Applikationen als Individualsoftware für Ihre Kunden oder die eigene Nutzung entwickelt, dann sieht die Welt schon ganz anders aus!
Hier müssen Sie schon bei der Analyse der Business Architektur an die Sicherheit denken, und dieser Bedarf an Sicherheitsbewusstsein zieht sich dann wie ein roter Faden durch die gesamte Softwareentwicklung. Erlaubt die Architektur Ihrer Web Applikation die Implementierung der nötigen Sicherheitsvorkehrungen? Wie sicher wird das Datenbanksystem sein, welches Sie im Auge haben? Und, ganz wichtig; welches Framework bietet das nötige Mass an Sicherheit?
Die Analsye der Business Architektur
Vorsicht, also Vorbereitung, ist besser als Nachsicht. Die erste Phase bei der Digitalisierung von Business Prozessen ist eine analyse der Business Architektur, mit dem Ziel eine eigene Security Architecture zu erstellen. Diese sollte definieren wie die Daten, welche von dem neuen System der Web Applikation gesammelt, gespeichern und bearbeitet werden sollen, zu schützen sind.
Hier muss man verstehen, wie das Verhalten der diversen Stakeholder ist, insbesondere das der Anwender. Was sind Ihre sicherheits-relevanten Bedürfnisse. Und wer benötigt überhaupt den Zugriff auf das Frontend der Web Applikation; als Anwender, und auf deren Backend; als Admin? Welche Zugriffsrechte benötigen diese Personenkreise?
Hier hilft es, sich die Business Process Models, die man in dieser Phase erstellt, genau anzusehen, um sicherheitskritische Schritte zu identifizieren und zu markieren. Auch sollte man eine Risiko-Analyse erstellen: Was passiert zum Beispiel bei einem Daten? Welche Daten sind als besonders schützenswert zu erachten?
Wenn das Unternehmen bereits eine Enterprise Information Security Architektur (EISA) besitzt, dann sollte die eigene Security Architecture an diese angeglichen werden. Ganz wichtig: Man sollte früh genug den Datenschutzbeauftragten des Unternehmens miteinbeziehen! Dieser möchte nämlich keine bösen Überraschungen erleben…
Eine sichere Software Architektur
Mit dem Kennen der Sicherheitsanforderungen ist man nun in der Lage, die Security Architecture zu erstellen. Man ermittelt somit welche Security Frameworks, Modelle, Protokolle und Methoden nötig sind, um die Sicherheitsanforderungen zu erfüllen. Diese Punkte müssen als nächstes Teil der Gesamtsoftwarearchitektur des Systems werden, beziehungsweise die anderen Komponenten müssen mit diesen in Einklang gebracht werden. Der Sicherheit sollte hier an erster Stelle stehen.
Auch bei demm Entwickeln und Anwenden der Softwarearchitektur für eine Web Applikation sollten agile Prinzipien angewandt werden. Nur so kann optimal sichergestellt werden, dass man auch auf der softwarearchitektonischen Ebene effektiv auf Änderungen reagieren kann. Dies ist besonders wichtig, wenn Sicherheit im Spiel ist.
Die Wahl des Frameworks
Eine sehr wichtige Entscheidung ist die Wahl der Frameworks, welche bei der Entwicklung der Web Applikation eingesetzt werden sollen. Eine Best Practice ist es, jedes der in Frage kommenden Frameworks der aktuellen Open Web Application Security Project (OWASP) Top Ten Liste entgegenzustellen. Diese Liste beinhaltet die aktuellen top zehn Sicherheitsrisiken in Bezug auf Web Applikationen. Die Aufgabe wäre es dann zu sehen, wie, und vor allem wie effektiv, jedes dieser Risiken berücksichtigt wird.
Jedes Web Application Framework bietet eigene Mechanismen, wenn es um die Wahrung der Sicherheit geht. Entscheidend ist jedoch nicht nur das Framework, sondern die Frage, ob Ihr Entwicklungsteam dessen Mechanismen auch effektiv nutzen kann. Die Mentalität “Die Security Features des Frameworks wird uns schon schützen” ist hier eher schädlich; am Ende liegt die Verantwortung immer bei dem Entwickler. Hier kann nur Erfahrung und gutes Training helfen.
Vaadin, ein Full-Stack Framework, bietet hier einige Vorzüge, auf die der Artikel nun näher eingehen wird.
Vaadin ist Open Source
Dies bedeutet, das ein jeder von uns Einsicht in den Programmcode des Vaadin Frameworks bekommen kann. So können auch Sicherheitsexperten diesen Code validieren und auf Schwachstellen überprüfen. Etwas, das Vaadin vor jedem Merge in einem internen Code Review natürlich auch selbst tut.
Agile Entwicklung und eigene Test-Tools
Vaadins Entwicklungstools, wie der Vaadin Designer und Vaadin TestBench, unterstützen die Arbeit von agilen Entwicklungsteams, inlkusive den Testern. Und Agilität und gute Tests sind oft vernachlässigter Faktoren im Thema IT Sicherheit.
Agilität erlaubt frühzeitige Reaktionen auf entdeckte Sicherheitsdefizite und Sicherheitslücken, sowie neue Sicherheitsanforderungen auf der Kundenseite. Und natürlich ist es hilfreich, wenn die eigenen Tester die Sicherheitslücken aufdecken, statt wenn externe Personen oder der IT Audit dies tun.
Alle Enden abgedeckt
Die Tatsache, dass Vaadin als Full-Stack Framework sowohl das Front-End als auch das Back-End abdeckt, und zwar auch IT sicherheitstechnisch, ist generell sehr sehr wichtig. Man muss sich keine Sorgen darüber machen, dass es zwischen zwei unterschiedlichen Frameworks auf Client- und Server-Seite irgendwelche Lücken gibt.
Mit Vaadin entwickelte Applikationen benötigen keine öffentlichen Web Services. Die gesamte Kommunikation läuft über einen einzigen HTTP Request Handler, welcher die RPC Requests der Servlet Java API verarbeitet. Dies bedeutet weniger Angriffspunkte, da keine Business Logik als Web Service exponiert wird.
Für jeden Client einer Vaadin Web Applikation wird deren Zustand direkt auf dem Server gespeichert. Nicht auf der Client-Seite. Nicht in irgendeiner Datenbank. Aus der Sicherheitsperspektive bedeutet dies, dass eine direkte Veränderung des Zustands nur von dem Server durchgeführt werden kann. Eine Manipulation des Zustandes auf der Client-Seite kann nicht stattfinden.
Die Befehle vom Client können serverseitig validiert werden, bevor diese eine Veränderung des Zustands herbeiführen (siehe unten). Auch das Business Model und die Logik der UI bleiben sicher auf dem Server. Eine Vaadin Web Applikation würde diese Strukturen nie gegenüber dem Browser offenlegen, sie bietet stattdessen einen einzigen sicheren Endpunkt für die Kommunikation zwischen Client und Server..
Dies ist bei den JavaScript Frameworks Angular und React anders. Hier wird der Zustand von einem Store, wie ngrx für Angular oder Redux für React, in dem RAM Speicher des Rechners verwaltet, auf dem der Client läuft.
Wie sieht es mit den klassischen Angriffen aus?
Cross-Site Scripting und SQL Injections sind IT Sicherheitsrisiken, die es seit Geburt der modernen Web Applikation zu verhindern gilt. Wenn man als Vaadin Entwickler einigen Richtlinien folgt, dann wird man mit diesen schnell fertig.
Um unsere Arbeit hier zu vereinfachen beinhaltet Vaadin bereits Schutzmechanismen gegen Cross-Site Scripting Angriffe, nämlich browser APIs, welche dazu führen, dass der Client Browser die Inhalte als Text anstatt als HTML rendert. So kann beispielsweise verhindert werden, dass man aus Versehen <script> tags in dem DOM einfügt, wenn ein Binding unsicherer String-Werte durchgefürt wird.
Da einige Vaadin Komponenten HTML für bestimmte Attribute explizit zulassen muss der Entwickler bei der Verwendung dieser Komponenten einen Mechanismus implementieren, der Cross-Site Scripting Payloads verhinder. Dies kann relativ simpel mit JSoup und dessen Jsoup.clean Methode erreicht werden.
Auch gegen SQL Injections kann man sich mit einfachen Mitteln und Regeln schützen. Wenn man seine Vaadin Applikation mit Spring Boot entwickelt, dann ist man auf einer sehr sicheren Seite, da dieses Spring Framework Modul dies mit Prepared Statements, der NamedParameterJdbcTemplate Klasse, Bound Parameters und Stored Procedures sehr vereinfacht. Aber auch wenn man mit reinem JDBC arbeitet kann man mit prepared statements SQL Injections effektiv verhindern.
Bewährte Praktiken für die Sicherheit
Als Vaadin Entwickler sollte man immer gewissen Best Practices folgen, um die IT Sicherheit zu wahren. Zu diesen gehören:
- Vertrauliche Daten haben in den Projekt Dateien nichts zu suchen. Also keine hart-kodierten Passwörter, die man dann auch noch per Git Commit ins Repository schickt! Auch sollte man Informationen, wie die Datenbank URI, deren Benutzer sowie dessen Passwort, niemals in der application.properties Datei ablegen.
- Auch sollte man als Entwickler immer seine Server Endpunkte auf Sicherheit trimmen, dies bedeutet auch dass diese nur über HTTPS kommunizieren sollten. Diese Funktionalität ist bei Vaadin bereits eingebaut und muss im Code im Normalfall nicht berücksichtigt werden.
- Wenn man JDBC in Reinform verwendet, dann ist man als Entwickler selbst in der Pflicht, die nötigen Massnahmen gegen SQL Injections zu implementieren. Dies geht am besten mit Prepared Statements.
- Testen, testen, testen! Es ist auch nicht verkehrt, ein externes Unternehmen mit einem Penetration-Test zu beauftragen, bevor ein System live geht.
Fazit
Dies waren jetzt einige der Vorzüge, die Vaadin einem Entwicklungsteam bietet, welches grossen Wert auf die IT Sicherheit seiner Web Applikationen legt. Konkret in die Praxis geht es in diesem Artikel, der die sichere Entwicklung mit Spring Boot behandelt.
- Microservices - 18.01.2024
- IT-Sicherheitsrisiken - 22.12.2023
- Java Champion - 06.12.2023
- Microservices - 18.01.2024
- IT-Sicherheitsrisiken - 22.12.2023
- Java Champion - 06.12.2023