Tickets im Web

von Dr. Matthias Wübbeling

HTTP kennt kein Gedächtnis. Jede Anfrage trifft den Server als unbeschriebenes Blatt, ohne Kontext, ohne Geschichte, ohne Benutzeridentität. Dass sich Webanwendungen dennoch merken, wer gerade angemeldet ist, verdankt sich nicht dem Protokoll selbst, sondern einer darüber gelegten Schicht: dem Session-Management. Zwei Ansätze dominieren dabei die Praxis – serverseitige Session-IDs und clientseitige JSON Web Tokens.

Wenn Sie sich heute in eine Webanwendung einloggen, passiert das meist innerhalb von wenigen Sekunden. Passwortmanager füllen Ihre Zugangsdaten aus, ein zweiter Faktor ist schnell bestätigt, und schon können Sie die Anwendung benutzen. Aus technischer Sicht beginnt hier jedoch ein nicht unerhebliches Problem, nämlich bei der nächsten Anfrage noch zu wissen, wer Sie sind oder welchem Benutzerkonto die Aktion zuzuordnen ist. Das zugrundeliegende HTTP-Protokoll liefert dafür tatsächlich ohne Weiteres keinen Mechanismus. Es ist zustandslos, was bedeutet, dass jede Anfrage für sich steht. Es gibt keinen direkten Bezug zu einer vorherigen Anfrage und für den Server ist nicht zu erkennen, dass es sich um denselben Benutzer handelt.

Damit eine Anwendung Sie dennoch wiedererkennen kann, muss sie das fehlende Gedächtnis gewissermaßen selbst nachrüsten. Sie braucht einen Mechanismus, der einzelne, voneinander unabhängige Anfragen zu einer Benutzersitzung verbindet. Für Sie fühlt sich das völlig selbstverständlich an, technisch ist es jedoch eine Konstruktion, die aktiv erzeugt und aufrechterhalten werden muss.

In der Praxis haben sich dafür zwei grundlegende Lösungswege etabliert. Entweder behält der Server den Überblick und verwaltet die Sitzungsinformationen selbst oder er verlagert diese Information ganz oder teilweise zum Client und lässt sich bei jeder Anfrage "daran erinnern". Diese beiden Strategien werden durch Session-IDs auf der einen Seite und JSON Web Tokens (JWT) [1] auf der anderen entsprechend umgesetzt.

Session-IDs als eindeutige Kennung

Verwendet eine Anwendung den Session-Ansatz, verbleiben alle Zustandsinformationen auf dem Server. Nach erfolgreicher Anmeldung wird zunächst eine eindeutige, zufällige Kennung erzeugt, die Session-ID. Parallel dazu speichert die Anwendung die zugehörigen Informationen wie Benutzeridentität, Berechtigungen oder weitere kontextspezifische Daten auf dem Server. Der Client erhält nur die Session-ID und sendet sie bei jeder weiteren Anfrage automatisch mit.

Aus Sicht der IT-Sicherheit ergibt sich hier bereits der erste kritische Punkt. Die Session-ID muss auf ausreichend zufälligen Werten basieren. Andernfalls wäre es für Angreifer leicht möglich, gültige zu erraten und so fremde Benutzersitzungen zu übernehmen. Einfache oder schlecht initialisierte Zufallsfunktionen stellen daher durchaus ein Risiko dar.

Auf Seiten der Anwendung besteht die Aufgabe nun darin, bei jeder eingehenden Anfrage zunächst die Session anhand der übermittelten Daten im Header oder der aufgerufenen URL zu identifizieren und zu validieren. Anschließend wird der Benutzerkontext aus den gespeicherten Sitzungsdaten rekonstruiert, sodass die Anfrage im richtigen Kontext weiterverarbeitet werden kann. Die Validierung umfasst dabei mindestens die Existenz der Session sowie die Prüfung ihres Ablaufdatums. Ist die Sitzung abgelaufen, muss sich der Benutzer erneut authentifizieren, bevor er die Anwendung weiter nutzen kann.

Angriffe auf Browsersitzungen

Über diese grundlegenden Prüfungen hinaus empfiehlt es sich unter Umständen, zusätzliche Kontextmerkmale heranzuziehen. Auch wenn sich Merkmale wie der Browser-String leicht manipulieren lassen, können sie helfen, Abweichungen zu erkennen. Gerade vor dem Hintergrund zunehmender Angriffe auf Benutzersitzungen von Webanwendungen ist das relevant. Der Diebstahl von Session-IDs, meist über kompromittierte Cookies, hat in den letzten Jahren an Bedeutung gewonnen. Während Multifaktor-Verfahren klassische Übernahmen von Benutzerkonten erschweren, reicht der Besitz einer gültigen Session-ID in den meisten Fällen aus, um direkt als eingeloggter Benutzer zu agieren.

Einen Aspekt, den Sie in der Praxis möglicherweise schon selbst beobachtet haben, betrifft das Verhalten bei verlorenen oder gelöschten Cookies. Entfernt der Benutzer das Cookie mit der Session-ID, geht die Referenz auf die Sitzung verloren. Auf dem Server bleibt die Sitzung aber weiterhin bestehen, bis sie invalidiert oder durch Ablauf entfernt wird. Die Lebensdauer einer Session auf dem Server ist nicht zwangsläufig an die des Cookies auf Clientseite gekoppelt. Das Schließen des Browsers etwa reicht dann nicht aus. Manche Webanwendungen zeigen dann beim nächsten Login den Hinweis, dass man sich als Benutzer bes- tenfalls aktiv ausloggen soll.

JSON Web Tokens auf Clientseite

Der Einsatz von JSON Web Tokens verschiebt die Logik der Zustandsverwaltung etwas in Richtung Client. Statt nur eine Referenz auf eine serverseitige Datenstruktur zu speichern, erzeugt die Anwendung jetzt ein Token, der alle notwendigen Informationen selbst enthält. Die Erstellung eines JWT beginnt mit der Definition der Claims, die den Payload bilden [2]. Dazu gehören typischerweise eine Benutzer-ID, Rollen oder Berechtigungen sowie Metadaten wie Ausstellungszeitpunkt und Ablaufzeit. Anschließend wird das Token durch die Anwendung signiert. Hier haben Sie grundsätzlich zwei Ansätze: symmetrische und asymmetrische Verfahren.

Bei symmetrischen Verfahren verwenden Sie ein vorher festgelegtes Geheimnis, das sowohl zum Signieren als auch zum Validieren dient. Der Vorteil liegt in der Einfachheit und Performance, der Nachteil vor allem bei sehr großen Webanwendungen darin, dass alle beteiligten Systeme das gleiche Geheimnis kennen müssen. Sobald dieses kompromittiert wird, ist die gesamte Vertrauenskette gebrochen.

Alternativ kommen asymmetrische Verfahren für die Signatur zum Einsatz. Dabei signiert der für das Login verantwortliche Teil einer Anwendung ein Token mit einem privaten Schlüssel, während die Validierung bei allen anderen Teilen der Anwendung mit dem zugehörigen öffentlichen Schlüssel erfolgen kann. Der private Schlüssel muss dann nur an einer Stelle vorgehalten werden, während der öffentliche Schlüssel problemlos verteilt werden kann. Gerade in den Microservice-Architekturen moderner Webanwendungen ist das ein erheblicher Vorteil.

Nach der Signatur wird das resultierende Token an den Client übergeben. Dieser sendet ihn ab diesem Zeitpunkt bei jeder Anfrage im HTTP-Header oder direkt in der URL mit – analog zur eben beschriebenen Session-ID. Die Anwendung auf dem Server prüft dann die Signatur, validiert die Claims und natürlich die inhärente Ablaufzeit und kann den Benutzer direkt identifizieren.

Auch in diesem Kontext stellt sich die Frage, was passiert, wenn das Token verloren geht oder gelöscht wird. Anders als bei Sessions existiert ja kein serverseitiger Zustand – was natürlich grundsätzlich für die Benutzung der Anwendung schon möglich ist, aber eben nicht im Hinblick auf die Authentifikation des Benutzers. Wenn der Client das Token nicht mehr besitzt, ist er schlicht nicht mehr authentifiziert. Es gibt hier serverseitig auch nichts aufzuräumen, bei langlaufenden Tokens ohne weitere Mechanismen aber eben auch keine Möglichkeit, ein Token aktiv zurückzuziehen.

Lebenszyklus von Identitäten

Wenn Sie tiefer in die Praxis einsteigen, tauchen schnell weitere Fragen auf. Eine davon betrifft den generellen Lebenszyklus von Identitäten im System einer Anwendung. Bei Sessions haben Sie typischerweise zwei Zeitdimensionen: eine festgelegte Lebensdauer und eine Inaktivitätsdauer. Letztere wird oft über sogenannte Sliding Expirations umgesetzt, wo jede Anfrage die Session implizit verlängert. Das ist komfortabel für den Benutzer, kann aber sicherheitsrelevant sein, wenn Sessions praktisch unbegrenzt bestehen bleiben.

Ein weiterer Punkt ist die Session-Rotation. Nach einer erfolgreichen Authentifikation sollten sich die Session-ID erneuern, um Session-Fixation-Angriffe zu verhindern. Das sind Techniken, wo ein Angreifer eine Session-ID erzeugt und das Opfer durch einen manipulierten Link mit dieser Session-ID auf die Webanwendung leitet. Bleibt die Session-ID dieselbe, kennt der Angreifer nach dem Login ein gültige Session-ID des Opfers.

Bei JWT sieht das anders aus. Hier finden Sie häufig zwei unterschiedliche Typen, kurzlebige Access Tokens und langlebige Refresh Tokens. Das Access Token dient der eigentlichen Autorisierung bei der Anwendung, während das Refresh Token nur verwendet wird, um neue Access Tokens zu beziehen, ohne den Benutzer erneut zur Authentifikation zu zwingen. Das klingt zunächst elegant, bringt aber natürlich Risiken mit sich. Wenn ein Refresh Token kompromittiert wird, kann ein Angreifer beliebig neue Tokens erzeugen. Daher sollten Anwendungsentwickler die sogenannte "Refresh Token Rotation" implementieren, bei der jeder Gebrauch eines Tokens einen neuen erzeugt und der alte widerrufen wird.

Fazit

Session-IDs und JWT sind keine austauschbaren Werkzeuge, sondern Ausdruck zweier grundlegend verschiedener Architektursichten. Session-IDs verlagern den Zustand auf den Server – das erleichtert die Kontrolle, fordert aber skalierbaren Speicher und eine durchdachte Invalidierungsstrategie. JWT verteilen den Zustand in signierte Token – das entlastet den Server und passt gut zu Microservice-Architekturen, erfordert aber besondere Sorgfalt beim Umgang mit Refresh Tokens und beim Widerruf kompromittierter Credentials.

Kein Ansatz ist per se überlegen. Entscheidend ist, dass Sie die jeweiligen Schwachstellen kennen und aktiv adressieren: ausreichend zufällige Session-IDs, konsequente Session-Rotation nach dem Login, kurze Access-Token-Laufzeiten und eine implementierte Refresh-Token-Rotation. Session-Management ist kein Detail am Rand der Authentifizierungsarchitektur – es ist deren Fundament. Wer es vernachlässigt, öffnet Angreifern die Hintertür, selbst wenn die Anmeldung selbst noch so sorgfältig abgesichert ist.