© Enkel/Shutterstock.com
Was wir beim Neuschreiben der Benutzeroberfläche von OTRS gelernt haben

Sicherheit in modernen Frontends


Ende 2017 erhielt die Softwareentwicklungsabteilung von OTRS [1] einen Riesenauftrag: Das gesamte monolithische Webapplikations-Frontend sollte mit moderner Technik neu geschrieben werden. Und zwar in einer wiederverwendbaren Weise, durch Bereitstellung eines eigenen Designsystems.

Viele Themen mussten nun angegangen werden, eines davon war die Implementierung moderner Sicherheitsstandards. Da unser Anspruch die Erstellung von hochwertigem und erweiterbarem Code ist, war schnell klar: Jetzt ist die Zeit, früher gemachte Fehler grundlegend zu korrigieren. Hier ging es vor allem um veraltete Ansätze in Code und Architektur und die Einführung eines Security-First-Konzepts in der gesamten Codebasis.

Das alte Frontend war eine CGI-basierte Perl-Applikation, die auf verschiedenen Webservern betrieben werden konnte und für jede Anfrage eine eigene HTML-Ergebnisseite erzeugte. Dabei wurde Template Toolkit [2] für das Frontend-Rendering verwendet, mit Hilfe von etwas JavaScript-Code für bessere Interaktivität; aus heutiger Sicht sehr ineffizient hinsichtlich der „gefühlten“ Performance und auch sehr aufwendig in der Wartung.

Die frühe Festlegung auf eine Single-Page Application (SPA) legte das Ziel fest; der Weg dahin war allerdings lange nicht klar. Letztlich entschieden wir uns für einen neuen internen Perl-Webserver, basierend auf Mojolicious [3], das über REST eine neue, komponentenbasierte Frontend-Applikation bedient, die in Vue. js [4] geschrieben ist. Es sollte ein von Grund auf neuentwickeltes Designsystem erstellt werden, das zukünftige Entwicklungsaufwände reduziert und die Sicherheit insgesamt verbessert.

Auf diesem Weg haben wir einige Lektionen gelernt. Die wichtigsten werden nachfolgend beschrieben. Vielleicht sind einige davon für die zukünftige Erstellung sicherer Frontends auch für Sie hilfreich.

Authentisierung

Sichere Anmeldung ist ein oft übersehenes Feature, das dennoch von den meisten Webapplikationen für ihre Hauptfunktionalität benötigt wird. Bis heute ist es ein Schwachpunkt in vielen Apps. Das vor allem, weil sich die Landschaft ständig ändert und neue Angriffsvektoren praktisch täglich bekannt werden. Hier empfiehlt es sich, ein etabliertes Framework Ihrer verwendeten Programmiersprache einzusetzen. Das ist allerdings nicht immer möglich, da solche Lösungen manchmal nicht flexibel genug sind oder nicht allen Anforderungen entsprechen. Wenn Sie also eine eigene Authentisierungslösung einbauen müssen, finden Sie nachfolgend einige Standards, die sich in der Praxis bewährt haben.

JSON Web Token

Der junge Webstandard JSON Web Token (JWT) [5] für die Erstellung von Zugangstokens in Webapplikationen hat sich als Standardlösung für viele Fälle bewährt. Derartige Tokens sind manipulationssicher, sehr kompakt und optimal für einfache Identitätsverifikation. Für die Erstellung und Verwendung dieser Tokens gibt es sowohl für die Client- als auch die Serverseite bestehende Lösungen. Obwohl JWT ein kampferprobter und recht sicherer Standard ist, sollten bei der Implementierung einige Richtlinien beachtet werden:

  1. Speichern Sie keine Sitzungszustände in den Tokens. Diese könnten bereits vor dem Ablauf der Tokens veraltet sein, wenn die Sitzung auf dem Server beendet wurde. Verwenden Sie stattdessen zustandslose Tokens und jeweils einen aktuellen Sitzungszustand auf dem Server. Falls die Sitzungsdaten auf dem Client benötigt werden, holen Sie diese lieber bei Bedarf (ggf. mit sicherem Caching- und Updatemechanismus).

  2. Informieren Sie sich gründlich – verwenden Sie keine veralteten Sicherheitsalgorithmen für die Schlüssel. Auch wenn etwas heute sicher ist – schon morgen kann das anders sein.

  3. Verwenden Sie keine Tokens mit langer Gültigkeitszeit oder gar ohne Ablaufdatum. Sicherheit ist immer ein Kompromiss. Stellen Sie aber sicher, dass er zu Ihrem Vorteil wirkt, nicht andersherum.

  4. Fügen Sie das Token nie als URL-Parameter an, wenn Sie es weitergeben müssen. Stattdessen können Sie einen Zugriffsmechanismus mit einem kurzlebigen Token implementieren, das nur einmal verwendet werden kann und anschließend mit dem Zieltoken ersetzt wird.

Zwei-Faktor-Authentisierung

Passwörter sind unsicher. Normalerweise erstellt der Benutzer sein Passwort selbst, und es gibt trotz aktiver Passwortrichtlinien keine Garantie für ausreichende Sicherheit. Das ist einer der Hauptgründe für Zwei-Faktor-Authentisierung, mit der die Anmeldesicherheit verbessert werden soll. Vereinfacht gesagt wird angenommen, dass der Benutzer über ein vertrauenswürdiges Gerät verfügt, das von der Plattform vorab verifiziert wurde, meist eines der allgegenwärtigen Handys. Bei der Anmeldung muss der Benutzer ein zusätzliches, scheinbar zufälliges Token angeben. Nur die Kombination aus Passwort und Token ermöglicht die gültige Identifikation.

Es gibt verschiedene Algorithmen für die Erzeugung solcher Einmaltokens, vor allem der Time-based One-time-Password-(TOTP-)Algorithmus [6] und der HMAC-based One-time-Password-(HOTP-)Algorithmus [7]. Der erste verwendet, wie der Name nahelegt, eine Zeitkomponente bei der Tokenerzeugung. Da diese Tokens nur innerhalb einer kurzen Zeitspanne verwendbar und somit kurzlebig sind, ist er inhärent sicherer. Der zweite Algorithmus verwendet ein zählerbasiertes Verfahren, das den Zähler nach der Verwendung eines darauf basierenden Tokens hochzählt. Beide haben ihre Anwendungsfälle, aber Sie sollten möglichst immer TOTP verwenden.

Bei der Erstellung von API-Endpunkten für die Authentisierung Ihrer Benutzer sollten Sie immer zeitgleich das Passwort und das Token verlangen. Geben Sie dem vermeintlichen Angreifer nie mehr Informationen als nötig. Konkret: Melden Sie niemals zurück, dass ein Passwort nicht korrekt ist. Besser ist es, eher vage Fehlermeldungen zu erzeugen, aus denen nicht geschlossen werden kann, ob nun Benutzername, Passwort oder Token fehlerhaft waren.

Unte...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang