Session Hijacking ist ein klassisches, aber nach wie vor kritisches Problem. Wird das Sitzungs-Cookie eines Benutzers erbeutet, versucht der Angreifer, die Sitzung mit demselben Token zu übernehmen. Schaut das System nur auf das Vorhandensein des Tokens, prüft es nicht, in welchem IP-, Geräte-, Browser- oder Benutzerkontext dieses Token erzeugt wurde. In diesem Fall wird die Sitzungs-ID allein zur Sicherheitsgrenze.
Auch das Vergessen von Cookie-Sicherheitsflags ist eine verbreitete Schwäche. Ohne HttpOnly können clientseitige Skripte auf das Cookie zugreifen; ohne Secure wird die Transportschicht schwächer; ohne SameSite werden seitenübergreifende Anfragen riskanter. Zu erwarten, dass diese Einstellungen von jedem Anwendungsteam konsistent angewendet werden, ist in großen Unternehmen nicht realistisch.
Auch die Timeout-Verwaltung wird oft unvollständig eingerichtet. Das Idle Timeout bestimmt, wie lange die Sitzung nach der letzten Aktivität offen bleibt; das Absolute Timeout begrenzt hingegen die maximale Lebensdauer ab dem Login-Moment, selbst wenn der Benutzer aktiv ist. Besonders in Finanz-, Gesundheits- und Unternehmensportalen müssen diese beiden Grenzen getrennt verwaltet werden.
Die Kontrolle gleichzeitiger Sitzungen löst sich mit einem Standard-Cookie-System nicht von selbst. Entscheidungen wie, von wie vielen Geräten ein Benutzer sich anmelden darf, ob eine neue Anmeldung die alte Sitzung beenden soll oder ob die neue Anmeldung abgelehnt werden soll, erfordern einen zentralen Session-Store und das Tracking aktiver Sitzungen. In Mehrknotenstrukturen wird dies noch kritischer.
Der TR7-Sitzungsschutz bündelt diesen Bedarf unter einem einzigen Policy-Graph: Session-ID-Erzeugung, Cookie-Sicherheitsflags, IP-/IP+UA-/Composite-Binding, Idle- und Absolute-Timeout, maximale Zahl gleichzeitiger Sitzungen und optionale Cookie-Verschlüsselung vereinen sich im selben Verwaltungsmodell.
TR7 wendet Sitzungsschutz nicht als einzelne Cookie-Einstellung an, sondern als mehrschichtige Richtlinie, die von der Erzeugung über die Verifizierung und Erneuerung bis zur Beendigung reicht.
SAM verwaltet Session-Affinity, Cookie-Name, Cookie-Quelle, Session-Format und Sicherheitsflags gemeinsam. TR7 kann die Session-ID erzeugen oder mit dem vom Backend-Dienst erzeugten Cookie arbeiten; die Formatoptionen UUID, IP+Timestamp+Random, IP+Random oder Custom können verwendet werden.
Nach dem Öffnen der Sitzung kann einer der Binding-Modi IP, IP+UA, Composite oder None angewendet werden. Wird ein Kontextwechsel erkannt, wird ein Session-Mismatch markiert, und die Anwendung kann eine erneute Authentifizierung oder eine zusätzliche Kontrolle verlangen.
Wird die AES-256-CBC-basierte Cookie-Verschlüsselung aktiviert, werden die ausgewählten Cookies clientseitig unlesbar. Durch die aus dem IP+UA-Kontext abgeleitete zusätzliche Bindung wird die Wiederverwendung des Tokens auf einem anderen Client erschwert.
Der Session-Refresh-Vorgang wird mit Redis-Lua-Funktionen atomar ausgeführt. Das Idle Timeout kann bei jeder Aktivität erneuert werden; das Absolute Timeout bleibt an die Login-Zeit gebunden. Auch die Kontrolle der maximalen Zahl gleichzeitiger Sitzungen kann über den zentralen Session-State angewendet werden.
Der Sitzungsschutz bietet für unterschiedliche Sicherheits- und Benutzererlebnis-Anforderungen vorkonfigurierte Profile, Binding-Optionen, Timeout-Verwaltung und Cookie-Sicherheit.
Das default-Profil ist mit IP-Binding, 8 Stunden Idle Timeout und 7 Tagen Absolute Timeout für die unternehmensübliche Standardnutzung ausgelegt. Das session_strict-Profil bietet mit IP+UA-Binding, 30 Minuten Idle, 8 Stunden Absolute Timeout und einer einzigen gleichzeitigen Sitzung strengere Sicherheit. Das session_relaxed-Profil eignet sich mit 7 Tagen Idle und 90 Tagen Absolute Timeout ohne Binding für langlebige SaaS-Sitzungen. Das session_singleDevice-Profil wird mit IP-Binding und einer Richtlinie für eine einzige gleichzeitige Sitzung in Anwendungen verwendet, die eine Lizenz- oder Geräteeinschränkung erfordern.
TR7 zwingt das Session-ID-Format nicht in ein einziges festes Modell. Das ipTimestampRandom-Format bietet mit der Kombination aus IP, Zeit und Zufallswert das starke Standardformat; das uuid-Format erzeugt einen opaken Wert ohne IP. Das ipRandom-Format nutzt IP und Zufallswert; das custom-Format erlaubt dem Operator, einen Session-Schlüssel aus Headern, Cookies oder benutzerdefinierten Variablen zu erzeugen. Diese Flexibilität passt sich an verschiedene Anwendungsarchitekturen an.
Auf der SAM-Ebene kann HttpOnly als minimales Sicherheitsflag konfiguriert werden. Zusätzliche Flags wie Secure, SameSite=Strict oder SameSite=Lax können ebenfalls auf Richtlinienebene hinzugefügt werden. Der Cookie-Max-Age-Wert kann mit dem Absolute Timeout verknüpft werden. So wird nicht von jedem Anwendungsteam erwartet, die Cookie-Sicherheitseinstellungen einzeln fehlerfrei vorzunehmen.
Ist der samCookieSource-Wert TR7, wird das Session-Cookie auf der ADC-Ebene erzeugt. Soll der Backend-Dienst weiterhin sein eigenes Cookie erzeugen, kann ein vom Backend-Dienst stammendes Cookie verwendet werden. Im Hybridmodell wird, wenn das Cookie des Backend-Dienstes vorhanden ist, mit diesem Wert fortgefahren; andernfalls kann TR7 einen neuen Session-Wert erzeugen. Dieser Ansatz passt sich sowohl an neue Anwendungen als auch an Altsysteme an.
Das ip-Binding bewahrt den Quell-IP-Kontext, in dem sich der Benutzer angemeldet hat; es ist in Szenarien mit Unternehmensbüro oder VPN stark. Das ip+ua-Binding bewertet das Paar aus IP und User-Agent gemeinsam und bietet so eine strengere Kontrolle. Das composite-Binding kann mit zusätzlichen Komponenten wie Accept-Language, benutzerdefinierten Headern oder TLS-Fingerabdruck erweitert werden. Der none-Modus verhält sich bei langlebiger Nutzung und häufigen Netzwerkwechseln im SaaS-Umfeld flexibler.
Die Cookie-Verschlüsselung gilt nicht standardmäßig als aktiviert; sie ist ein optionaler Schutz, der für ausgewählte Cookies aktiviert wird. Ist sie aktiv, wird auf der Response-Seite der cookie_encrypt- und auf der Request-Seite der cookie_decrypt-Ablauf angewendet. Durch die Nutzung von Salt, Padding und Base64-Formatierung pro Cookie wird der Wert auf der Client-Seite bedeutungslos. Schlägt die Entschlüsselung fehl, wird der Wert nicht als vertrauenswürdige Sitzungsdaten behandelt, und die Anwendung kann über erneute Authentifizierung oder Ablehnung entscheiden.
sessionIdleTimeout bestimmt, wie lange die Sitzung nach der letzten Aktivität gültig bleibt. sessionAbsoluteTimeout begrenzt hingegen die maximale Sitzungslebensdauer ab dem Login-Moment und verlängert sich nicht fortlaufend durch Aktivität. Diese Trennung ist besonders in Banking-, Unternehmensportal- und sensible Daten enthaltenden Anwendungen kritisch. Benutzererlebnis und Sicherheitsgrenze werden in derselben Richtlinie ausbalanciert.
Mit dem maxConcurrentSessions-Wert wird bestimmt, wie viele aktive Sitzungen ein Benutzer gleichzeitig haben darf. Wird das Limit überschritten, kann mit logout_oldest die älteste Sitzung beendet oder mit deny_new die neue Anmeldung abgelehnt werden. Diese Struktur kann für Einzelgerätelizenzen, Banking-Sicherheit oder Unternehmens-Zugriffskontrolle verwendet werden. Die Liste der aktiven Sitzungen wird im zentralen Session-State verfolgt.
Beim Login wird die Session erzeugt, bei jeder Request kann ein Idle-Refresh erfolgen, bei einem Binding-Mismatch wird die Sitzung als verdächtig markiert und beim Logout wird die Session ungültig gemacht. Dieser Lebenszyklus sorgt dafür, dass die Sitzung nicht nur am Anfang, sondern während der gesamten Nutzungsdauer verwaltet wird. SIEM- und Audit-Streams können aus diesen Ereignissen Sicherheitssignale erzeugen. Besonders bei Untersuchungen von Kontoübernahmen ist der Session-Verlauf wichtig.
Zum Erhalt des Session-State über mehrere TR7-Knoten hinweg können Peer-Synchronisation und ein Redis-basierter zentraler Store gemeinsam genutzt werden. In Failover- oder Rolling-Restart-Szenarien wird das Design so gestaltet, dass die Session-Kontinuität gewahrt bleibt. Auf der Redis-Seite kann die Robustheit des Session-State mit Replikations- und Persistenzoptionen erhöht werden. Diese Struktur verhindert, dass der Sitzungsschutz an einen einzigen Knoten gebunden bleibt.
Der Sitzungsschutz wird gemeinsam mit Cookie-Name, Attribut-Erzeugung, Composite Binding, Audit-Kategorien, Session-Store und Timeout-Fallback-Verhalten betrieben.
Der Standard-Cookie-Name TR7SID kann verwendet werden. Für jeden Pool kann mit samCookieName ein anderer Name definiert werden. Dies wird zur Markenkonformität, für Anwendungsstandards oder zur Anpassung an die bestehende Cookie-Architektur genutzt.
Bei der Erzeugung des Cookie-Werts werden Attribute wie HttpOnly, Secure, SameSite und Max-Age gemäß den Richtlinieneinstellungen hinzugefügt. Diese Attribute können nur gesetzt werden, wenn eine neue Session erzeugt wird. So wird die Cookie-Sicherheit mit einer zentralen Richtlinie standardisiert.
Composite Binding kann standardmäßig mit Komponenten wie Quell-IP und User-Agent aufgebaut werden. Der Operator kann zusätzliche Komponenten wie Accept-Language, Accept-Encoding, benutzerdefinierte Header oder TLS-Fingerabdruck einbeziehen. Diese Berechnung sollte in einer späten Phase erfolgen, nachdem die betreffenden Variablen erzeugt wurden.
Sitzungs- und Zugriffsereignisse können mit Kategorien wie whitelisted, authorized oder unauthorized protokolliert werden. Diese Information erleichtert auf der SIEM-Seite Untersuchungen von Kontoübernahme, Missbrauch und unautorisiertem Zugriff. Für jede Request wird der Benutzer- und Sitzungskontext sichtbarer.
Der AAM-Session-State kann in Redis gehalten werden, und Session-Refresh-Vorgänge werden mit Lua-Funktionen atomar ausgeführt. Dieses Modell holt die klassische Datenbanklatenz aus dem Session-Kontrollpfad heraus. Mit Redis-Features wie AOF und Replikation können Persistenz und Robustheit erhöht werden.
Fehlt die Idle-Timeout-Konfiguration, kann ein Fallback von 1 Stunde verwendet werden. Fehlt das Absolute Timeout, kann ein Fallback-Wert von 24 Stunden angewendet werden. Diese Werte bieten sichere Voreinstellungen, die bei fehlender Konfiguration das Entstehen unbegrenzter Sitzungen verhindern.
Eine Banking-Anwendung möchte den Benutzer womöglich auf einem einzigen Gerät halten und die Sitzung bei 30 Minuten Inaktivität schließen. Das session_strict-Profil wird mit IP+UA-Binding, 30 Minuten Idle, 8 Stunden Absolute Timeout und einer Richtlinie für eine einzige gleichzeitige Sitzung angewendet. Wird eine gestohlene Sitzung in einem anderen Kontext verwendet, wird ein Mismatch-Signal erzeugt.
B2B-SaaS-Benutzer möchten womöglich über Laptop, Telefon und Tablet auf dasselbe Konto zugreifen. Das session_relaxed-Profil wahrt mit langen Idle- und Absolute-Timeout-Werten ohne Binding das Benutzererlebnis. IP-Wechsel oder Gerätevielfalt erzeugen keine unnötige erneute Authentifizierung.
Im Mitarbeiterportal meldet sich der Benutzer über das Büro- oder VPN-Netzwerk an und arbeitet den ganzen Arbeitstag, ohne sich erneut anzumelden. Das default-Profil kann mit IP-Binding, 8 Stunden Idle Timeout und 7 Tagen Absolute Timeout angewendet werden. Ändert sich der IP-Kontext, kann die Anwendung eine erneute Authentifizierung verlangen.
Eine Premium-Anwendung oder ein lizenzierter Dienst möchte womöglich, dass das Konto gleichzeitig nur auf einem einzigen Gerät genutzt wird. Das session_singleDevice-Profil beendet mit max. 1 gleichzeitiger Sitzung und logout_oldest-Verhalten bei einer neuen Anmeldung die alte Sitzung. Lizenz-Sharing und unkontrollierte Mehrfachnutzung werden erschwert.
Session-ID-Erzeugung, Cookie-Sicherheitsflags, IP+UA-Binding, Timeout-Richtlinie und Limit für gleichzeitige Sitzungen unter einem einzigen Policy-Graph. Wir führen Sie mit Ihren eigenen Diensten durch eine Live-Installation.