Laufen Sitzungen Ihrer selbst gehosteten App wirklich wie vorgesehen ab? Eine praktische Prüfliste

Warum das Sitzungsverhalten nach der Anmeldung wichtig ist

Bei der Authentifizierung wird festgestellt, dass sich ein Benutzer angemeldet hat. Eine Sitzung ermöglicht es der Anwendung, diesen Benutzer wiederzuerkennen, während er zwischen Seiten wechselt oder später zur App zurückkehrt. Bleibt eine Sitzung länger als beabsichtigt nutzbar, kann jemand mit Zugriff auf den Browser oder auf kopierte Sitzungsdaten möglicherweise weiterhin das Konto verwenden.

Ein konfiguriertes Zeitlimit beweist nicht, dass alle relevanten Abläufe wie erwartet zum Sitzungsende führen. Abmeldung, Passwortänderung, Kontodeaktivierung und Single Sign-on können unterschiedliche Systemkomponenten betreffen. Betrachten Sie das Sitzungsverhalten als Lebenszyklus, den es zu bewerten und erneut zu testen gilt, nicht als einzelne Einstellung, die man nur finden muss.

Als Prüfpunkte empfiehlt [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html), den Ablauf von Sitzungen serverseitig durchzusetzen und eine Sitzung bei der Abmeldung des Benutzers ungültig zu machen. [NIST](https://pages.nist.gov/800-63-4/sp800-63b/session/) empfiehlt, dass Sitzungscookies zum Ende der Gültigkeitsdauer einer Sitzung oder kurz danach ablaufen. Diese allgemeinen Empfehlungen belegen nicht, dass jede Anwendung dieselben Kontrollen bietet oder dass für jeden Ablauf ein universell vorgeschriebenes Ergebnis gilt.

Anmeldung, Sitzungsdauer, Inaktivitätszeitlimit und gespeicherte Geräte unterscheiden

Verwenden Sie vor der Prüfung der Einstellungen einheitliche Begriffe. Die Anmeldung ist der Authentifizierungsschritt. Eine Sitzung ist die fortlaufende Wiedererkennung dieser Anmeldung durch die Anwendung. Eine Sitzung kann über mehrere Mechanismen abgebildet oder aufrechterhalten werden. Daher zeigt der im Browser angezeigte Ablaufzeitpunkt eines Cookies allein nicht unbedingt, ob der Server die Sitzung noch akzeptiert.

Ein Inaktivitätszeitlimit begrenzt eine Sitzung nach einer bestimmten Zeit ohne Aktivität. Ein maximales Sitzungsalter, manchmal auch absolute Gültigkeitsdauer genannt, begrenzt die Gültigkeit unabhängig von der Aktivität. Gehen Sie nicht davon aus, dass Aktivität ein absolutes Zeitlimit zurücksetzt oder dass eine Einstellung namens „Sitzungszeitlimit“ eine bestimmte Bedeutung hat. Prüfen Sie die Dokumentation der Anwendung und testen Sie das Verhalten.

Eine Option wie „Angemeldet bleiben“ oder „Gerät speichern“ kann das Nutzungserlebnis beim späteren Besuch verändern. Finden Sie heraus, ob sie in der betreffenden Anwendung eine Sitzung wiederherstellt, bestimmte Authentifizierungsschritte überspringt oder etwas anderes bewirkt. Dokumentieren Sie ihr Verhalten separat und behandeln Sie sie nicht als dasselbe wie ein Inaktivitätszeitlimit.

Anforderungen an realen Arbeitsabläufen und Risiken ausrichten

Legen Sie Anforderungen danach fest, wie die Anwendung genutzt wird und welche Informationen oder Aktionen eine unbeaufsichtigte oder weiterhin gültige Sitzung zugänglich machen könnte. Für einen gemeinsam genutzten Arbeitsplatz, den Zugriff auf vertrauliche Geschäftsdaten oder die Möglichkeit, folgenreiche Änderungen vorzunehmen, können andere Erwartungen gelten als für eine App, die kurzzeitig auf einem privaten Gerät genutzt wird.

Halten Sie das erwartete Verhalten schriftlich fest, bevor Sie mit dem Testen beginnen. Legen Sie beispielsweise fest, was Ihre Organisation nach Inaktivität, beim Erreichen des maximalen Sitzungsalters, nach einer ausdrücklichen Abmeldung und nach der Deaktivierung eines Kontos erwartet. Definieren Sie auch für Passwortänderungen und SSO-Ereignisse das gewünschte Ergebnis, statt anzunehmen, die Anwendung oder der Identitätsanbieter werde es automatisch herbeiführen.

Die hier angeführten Leitlinien legen keinen einzigen Zeitlimitwert fest, der für jede Anwendung und jeden Arbeitsablauf gilt. Treffen Sie die Entscheidung ausdrücklich als Abwägung zwischen Sicherheit und Benutzerfreundlichkeit und dokumentieren Sie Ausnahmen, etwa bei Arbeitsabläufen, für die Benutzer eine Sitzung während einer längeren Aufgabe geöffnet lassen müssen.

• Auf welche Daten und Aktionen kann in der App zugegriffen werden, und was könnte eine unbeaufsichtigte Sitzung ermöglichen?
• Arbeiten Benutzer wahrscheinlich an gemeinsam genutzten oder unbeaufsichtigten Geräten?
• Was sollte nach Inaktivität geschehen, und welches maximale Sitzungsalter ist noch akzeptabel?
• Welche Ereignisse sollten den Zugriff beenden: Abmeldung, Passwortänderung, Kontodeaktivierung oder eine Änderung beim Identitätsanbieter?
• Gibt es eine Option für gespeicherte Geräte, und ist ihr Verhalten für Ihren Anwendungsfall akzeptabel?

Die Dokumentation der Anwendung auf tatsächlich verfügbare Kontrollen prüfen

Durchsuchen Sie die offizielle Dokumentation nach Angaben zu Sitzungsablauf, Inaktivitätszeitlimit, maximaler Gültigkeitsdauer, Abmeldung, Sitzungswiderruf, gespeicherten Geräten und SSO. Prüfen Sie die Dokumentation für die von Ihnen eingesetzte Anwendung und Version. Leiten Sie eine Funktion weder aus einem ähnlich benannten Produkt noch aus einer Einstellung in einer anderen App ab.

Halten Sie fest, ob jede Kontrolle konfigurierbar ist, wo sie konfiguriert wird und ob die Dokumentation eine serverseitige Durchsetzung beschreibt. Äußert sie sich nicht zu einem bestimmten Ablauf, kennzeichnen Sie ihn als ungeklärt und testen Sie ihn oder fragen Sie den Anbieter beziehungsweise Maintainer. Der Ablauf eines Cookies und eine serverseitige Regel zur Sitzungsgültigkeit sind miteinander verbundene, aber unterschiedliche Prüfpunkte.

Die OWASP- und NIST-Empfehlungen oben beziehen sich auf serverseitigen Sitzungsablauf, Ungültigmachung bei der Abmeldung und Cookie-Ablauf. Sie legen nicht fest, welches Verhalten bei Passwortänderungen, Kontodeaktivierung, maximalem Sitzungsalter oder Sitzungen beim Identitätsanbieter für Ihre konkrete Anwendung gilt. Überprüfen Sie diese Fälle anhand der Anwendungsdokumentation und Ihrer eigenen Anforderungen.

• Dokumentieren Sie die beschriebene Bedeutung jeder Zeitlimit-Einstellung, einschließlich der Frage, ob Aktivität das Zeitlimit zurücksetzt.
• Suchen Sie nach einer dokumentierten Möglichkeit, aktive Sitzungen zu beenden oder zu widerrufen, und halten Sie deren Geltungsbereich fest.
• Prüfen Sie, ob sich das Sitzungsverhalten bei lokalen Konten und SSO-Benutzern unterscheidet.
• Notieren Sie Titel, Version oder Datum der Dokumentation, sofern verfügbar, sowie das Datum Ihrer Prüfung.

Praktische Tests des Sitzungslebenszyklus durchführen

Verwenden Sie nach Möglichkeit ein Testkonto und eine Nicht-Produktionsumgebung. Wenn Sie in der Produktionsumgebung testen müssen, planen Sie die Arbeit so, dass andere Benutzer nicht beeinträchtigt und reale Kontozugriffe nicht unbeabsichtigt verändert werden. Verwenden Sie für das Testkonto keine sensiblen Daten und nehmen Sie keine Sitzungsdaten oder andere Geheimnisse in Screenshots oder gemeinsam genutzte Notizen auf.

Melden Sie sich für den Inaktivitätstest an, lassen Sie die App für das konfigurierte Intervall ungenutzt und versuchen Sie anschließend, eine geschützte Seite aufzurufen oder eine harmlose Aktion auszuführen. Prüfen Sie die Erwartung an das maximale Sitzungsalter separat: Halten Sie die Sitzung gemäß Ihrem Testplan aktiv und beobachten Sie, ob sie beim angegebenen Grenzwert endet. Dokumentieren Sie die verstrichene Zeit und die Anzeige für den Benutzer.

Melden Sie sich ab und versuchen Sie anschließend, mit derselben Browserumgebung erneut eine geschützte Seite aufzurufen. Halten Sie fest, ob die alte Sitzung weiterhin Zugriff auf geschützte Inhalte ermöglicht. Eine Weiterleitung zur Anmeldeseite allein ist kein schlüssiger Beleg, wenn geschützte Inhalte über einen anderen Weg weiterhin zugänglich sind.

Testen Sie Passwortänderung und Kontodeaktivierung als getrennte Ereignisse. Stellen Sie bei jedem Ereignis fest, ob bestehende Sitzungen weiterhin funktionieren, ob sich die Änderung nur auf künftige Anmeldungen auswirkt und ob das Verhalten Ihrer schriftlich festgehaltenen Anforderung entspricht. Definieren Sie das erwartete Ergebnis selbst: Die oben angeführten Primärquellen schreiben für diese Fälle kein universelles Ergebnis vor.

Führen Sie eine harmlose, autorisierte Testaktion aus, um den Zugriffsstatus zu bestätigen. Ist das Ergebnis unklar, wiederholen Sie den Test in einer sauberen Browsersitzung und konsultieren Sie die Dokumentation oder den Support der Anwendung.

Prüfungen für SSO und lokale Konten wiederholen

Wenn die Anwendung sowohl lokale Anmeldungen als auch Single Sign-on unterstützt, testen Sie beide Wege getrennt. Anwendung und Identitätsanbieter können jeweils eigene Sitzungen haben. Das Beenden der einen Sitzung beweist für sich genommen nicht, dass auch die andere beendet wurde. Ebenso führt die Abmeldung von einer Anwendung nicht zwangsläufig dazu, dass der Benutzer auch beim Identitätsanbieter abgemeldet wird.

Dokumentieren Sie bei SSO Ablauf und Ergebnis für die Abmeldung von der Anwendung, die Abmeldung beim Identitätsanbieter, Passwortänderungen und Kontodeaktivierungen. Prüfen Sie, was passiert, wenn der Benutzer zur App zurückkehrt und versucht, eine bereits geöffnete App-Seite zu verwenden. Wiederholen Sie die relevanten Tests für lokale Konten, ohne anzunehmen, dass das SSO-Verhalten auch dort gilt.

Bietet der Identitätsanbieter oder die Anwendung Kontrollen zum Widerruf von Sitzungen, dokumentieren Sie, was diese laut Beschreibung widerrufen sollen, und bestätigen Sie die Wirkung in einem Test. Ist das Verhalten weder dokumentiert noch testbar, führen Sie es als ungelöste Lücke auf.

Erwartetes Verhalten und Nachweise in einer Sitzungstestmatrix festhalten

Eine kompakte Matrix macht aus einmaligen Prüfungen wiederholbare Betriebsnachweise. Trennen Sie das erwartete vom beobachteten Ergebnis: Das erwartete Ergebnis gibt Ihre Richtlinie wieder, das beobachtete Ergebnis zeigt, was die App während des Tests tatsächlich getan hat.

Nehmen Sie Anwendung und Version, Authentifizierungsweg, Testdatum, relevante Konfiguration, Testkonto, Schritte, gegebenenfalls verstrichene Zeit, beobachtetes Ergebnis sowie den Status „bestanden“, „nicht bestanden“ oder „ungeklärt“ auf. Vermerken Sie die konsultierte Dokumentation und die nächsten Schritte für offene Punkte. Dokumentieren Sie keine Passwörter, Sitzungstoken oder anderen Zugangsdaten.

Wiederholen Sie die Matrix nach wesentlichen Änderungen an der Anwendungskonfiguration, der Authentifizierungseinrichtung oder der Bereitstellung. Der Zeitplan dafür ist eine betriebliche Entscheidung Ihres Teams; die hier zitierten Quellen schreiben kein Intervall für erneute Tests vor.

• Inaktivität: erwartete Beendigungsbedingung, getestetes Inaktivitätsintervall und ob geschützter Zugriff weiterhin möglich war.
• Maximales Sitzungsalter: erwartetes Limit, ob die Sitzung während des Tests aktiv blieb, beobachteter Beendigungszeitpunkt und Ergebnis.
• Abmeldung: erwartete Ungültigmachung und Ergebnis beim erneuten Verwenden derselben Browserumgebung.
• Passwortänderung: erwartete Auswirkung auf bestehende Sitzungen und Ergebnis für das getestete Konto.
• Kontodeaktivierung: erwartete Auswirkung und Ergebnis bei bestehenden sowie neuen Zugriffsversuchen.
• SSO und lokale Anmeldung: jeden zutreffenden Anmeldeweg testen und festhalten, zu welchem System die Sitzung gehörte.
• Lücken: nicht dokumentierte Kontrollen, nicht überprüfbare Ergebnisse und zuständige Person für die Nachverfolgung.

Zuständigkeiten zwischen Anwendung, Identitätsanbieter und Hosting festlegen

Gehen Sie nicht davon aus, dass eine einzelne Partei den gesamten Sitzungslebenszyklus kontrolliert. Ordnen Sie jedes erwartete Verhalten der Komponente zu, über die es in Ihrer Bereitstellung konfiguriert oder überprüft werden kann. Die genaue Aufgabenverteilung hängt von Anwendung, Identitätsanbieter, Hosting-Modell und den geltenden Vereinbarungen ab.

Der Anwendungsverantwortliche sollte die Zugriffsrichtlinie dokumentieren, das Verhalten der Anwendung überprüfen und entscheiden, wie mit ungelösten Lücken umzugehen ist. Stimmen Sie sich bei SSO-Abläufen mit dem Administrator des Identitätsanbieters ab, um dessen Sitzungs- und Kontokontrollen zu verstehen, und testen Sie anschließend das Gesamterlebnis. Legen Sie die Aufgabenverteilung ausdrücklich fest, statt sich auf die Annahme zu verlassen, SSO oder das Hosting kümmere sich um den Widerruf.

Trennen Sie Hosting-Aufgaben von Anwendungszugriff und Kontoverwaltung. Benötigt Ihre Organisation eine Sitzungskontrolle, die die Anwendung nicht bietet, betrachten Sie Infrastrukturverwaltung nicht als Ersatz, es sei denn, eine dokumentierte und getestete Kontrolle erfüllt die Anforderung. Dokumentieren Sie die Lücke und entscheiden Sie, ob Sie die Konfiguration ändern, eine geeignete Kontrolle ergänzen, eine andere Anwendung oder ein anderes Bereitstellungsmodell wählen oder das verbleibende Risiko akzeptieren.

• Benennen Sie die verantwortliche Person für die Zeitlimit-Richtlinie und die Genehmigung von Ausnahmen.
• Benennen Sie die Person, die das Sitzungsverhalten auf Anwendungsebene konfiguriert und testet.
• Legen Sie bei SSO fest, wer den Identitätsanbieter verwaltet und welche Verhaltensweisen diese Person bestätigen kann.
• Dokumentieren Sie Hosting-Aufgaben getrennt von Anwendungszugriff und Kontoverwaltung.
• Führen Sie jedes nicht überprüfte Verhalten als offenen Punkt mit einer Entscheidung oder einem Folgeschritt.