Was ist Session Hijacking?

Veröffentlicht: 26. Juli 2024. Aktualisiert: August 2026. Geprüft vom PKI- und Anwendungssicherheitsteam von Encryption Consulting.

Was ist Session Hijacking?

Session Hijacking ist ein Angriff, bei dem ein Angreifer eine gültige, bereits authentifizierte Websitzung übernimmt, indem er die eindeutige Sitzungskennung stiehlt oder errät, die ein Server zur Erkennung eines angemeldeten Benutzers verwendet. Anschließend nutzt er diese Kennung, um sich als das Opfer auszugeben, ohne jemals ein Passwort eingeben zu müssen. Da die Sitzung vom Server bereits als vertrauenswürdig eingestuft wird, umgeht der Angriff Anmeldeformulare, Passwörter und in vielen Fällen auch die Zwei-Faktor-Authentifizierung vollständig.

Einige Begriffe tauchen in diesem Zusammenhang immer wieder auf, daher lohnt es sich, sie vor dem weiteren Vorgehen klar zu definieren:

• Sitzungs-ID (Sitzungstoken): Eine zufällige Zeichenkette, die ein Server nach dem Login an einen Client sendet, damit dieser denselben Benutzer bei jeder nachfolgenden Anfrage wiedererkennen kann, da HTTP selbst sich zwischen den Anfragen nichts merkt.
• Cookie: Die kleine Datenmenge, die ein Browser speichert und automatisch an eine Website zurücksendet; sie wird am häufigsten verwendet, um die Sitzungs-ID zwischen Browser und Server zu übermitteln.
• TLS (Transportschichtsicherheit): Das Verschlüsselungsprotokoll hinter HTTPS schützt Daten, einschließlich Session-Cookies, während sie über das Netzwerk übertragen werden.
• MITM (Man-in-the-Middle): Eine Angriffsposition, bei der sich der Angreifer zwischen Benutzer und Server befindet und den zwischen ihnen fließenden Datenverkehr lesen oder verändern kann; dies ist eine der Möglichkeiten, wie eine Sitzungs-ID erfasst werden kann.
• XSS (Cross-Site-Scripting): Eine Schwachstelle in Webanwendungen, die es einem Angreifer ermöglicht, ein eigenes Skript im Browser des Opfers auszuführen; wird häufig genutzt, um Session-Cookies auszulesen und zu exfiltrieren.

Session-Hijacking wird auch Cookie-Hijacking oder Cookie-Side-Jacking genannt, da Session-Cookies am häufigsten gestohlen werden. Es ist eng mit einem generischen Man-in-the-Middle-Angriff verwandt, aber nicht identisch: Ein Man-in-the-Middle-Angriff beschreibt die Netzwerkposition des Angreifers, während Session-Hijacking beschreibt, was der Angreifer mit dieser Position macht, nämlich eine aktive Session zu stehlen und wiederzuverwenden. OWASP ordnet fehlerhaftes Session-Management der Kategorie „Identifizierungs- und Authentifizierungsfehler“ zu , einer der wichtigsten Risikokategorien für Webanwendungen.

Wie funktioniert Session Hijacking?

Session Hijacking funktioniert, indem eine gültige Sitzungskennung abgefangen und wiedergegeben wird, bevor der Server Zweifel daran hat, ob sie einem anderen Benutzer gehört. Der Angriff folgt im Allgemeinen denselben fünf Schritten, unabhängig von der verwendeten Abfangtechnik:

1. Aufklärung. Der Angreifer identifiziert eine Zielanwendung und sucht nach Schwachstellen in der Art und Weise, wie diese Sitzungskennungen ausgibt, speichert oder überträgt, wie z. B. fehlende Cookie-Flags oder vorhersehbare ID-Muster.
2. Sitzungs-ID-Erfassung. Der Angreifer erlangt eine aktive Session-ID durch eine von mehreren Methoden: Einschleusen eines Skripts mittels XSS zum Auslesen des Cookies, Abhören unverschlüsselten oder herabgestuften Datenverkehrs in einem gemeinsam genutzten Netzwerk, Verleiten eines Benutzers zur Verwendung einer vom Angreifer bereitgestellten ID (Session-Fixation) oder direktes Erraten einer schwachen ID.
3. Token-Wiederholung. Der Angreifer fügt die gestohlene Session-ID in seinen eigenen Browser oder Client ein, typischerweise durch Setzen des entsprechenden Cookies.
4. Sitzungsidentitätswechsel. Der Server erkennt eine bekannte, noch gültige Sitzungskennung und behandelt die Anfrage so, als käme sie vom legitimen, bereits authentifizierten Benutzer, ohne dass eine erneute Authentifizierung ausgelöst wird.
5. Ausbeutung. Der Angreifer agiert mit den Berechtigungen des Opfers, solange die Sitzung gültig ist, liest Daten, ändert Einstellungen oder initiiert Transaktionen, oft bevor das Opfer oder ein Überwachungssystem etwas Ungewöhnliches bemerkt.

Die folgende Tabelle ordnet die gebräuchlichsten Eroberungstechniken ihrer jeweiligen Funktionsweise und der einzelnen Verteidigungsstrategie zu, die sie am direktesten abwehrt.

Angriffstechnik	Funktionsweise	Primäre Verteidigung
Cross-Site-Scripting (XSS)	Ein Angreifer schleust ein Skript in eine anfällige Seite ein; das Skript liest den Session-Cookie über JavaScript aus und sendet ihn an den Angreifer.	Das HttpOnly-Cookie-Flag sorgt dafür, dass clientseitige Skripte das Cookie überhaupt nicht lesen können. Hinzu kommen eine strenge Eingabebereinigung und eine Content Security Policy.
Session-Sniffing (Netzwerkaufzeichnung)	Ein Angreifer im selben unverschlüsselten oder herabgestuften Netzwerk erfasst mithilfe von Paketmitschnittwerkzeugen Session-Cookies während der Übertragung.	TLS ist überall aktiviert, das Secure-Cookie-Flag ist gesetzt und HSTS verhindert jeglichen Fallback auf einfaches HTTP.
Sitzungsfixierung	Der Angreifer übermittelt dem Opfer im Voraus eine bekannte Sitzungs-ID und verwendet diese dann wieder, sobald sich das Opfer damit authentifiziert hat.	Die Sitzungs-ID muss bei jeder Authentifizierung und Berechtigungsänderung neu generiert werden; eine vom Client bereitgestellte Sitzungs-ID wird vor dem Login niemals als gültig akzeptiert.
Vorhersagbare oder durch Brute-Force-Methode ermittelte Sitzungs-ID	Der Angreifer rät oder durchläuft schwache Sitzungskennungen mit niedriger Entropie, bis eine mit einer aktiven Sitzung übereinstimmt.	Generieren Sie Sitzungs-IDs mit einem kryptografisch sicheren Zufallszahlengenerator mit mindestens 64 Bit Entropie.
Man-in-the-Browser (Sitzungs-Malware)	Malware auf dem Gerät des Opfers liest oder manipuliert Sitzungsdaten direkt, unabhängig von Netzwerk- oder Serverkontrollen.	Endpunktschutz, kurze Sitzungslebensdauern und erneute Authentifizierung für sensible Aktionen, um die Möglichkeiten eines kompromittierten Endpunkts einzuschränken.
Websiteübergreifende Anfrage ohne SameSite	Eine bösartige Website löst Anfragen aus, die mit dem bereits vorhandenen Session-Cookie des Opfers mitlaufen, da der Browser dieses automatisch sendet.	SameSite=Strict oder Lax für den Session-Cookie, damit dieser nicht an seitenübergreifende Anfragen angehängt wird.

Ein praktisches Beispiel für die weitreichenden Folgen von Session Hijacking: CVE-2024-53704 , Anfang 2025 bekannt geworden, war eine Sicherheitslücke in der SonicOS SSL VPN-Komponente von SonicWall, die es einem nicht authentifizierten Angreifer ermöglichte, aktive VPN-Sitzungen zu übernehmen und so Zugriff auf die Lesezeichen in Virtual Office, die NetExtender-Konfiguration und den privaten Netzwerkzugang des Opfers zu erlangen. Die Zero Day Initiative stufte die Schwachstelle auf einen kritischen CVSS-Wert von 9.8 hoch. Wochen nach Veröffentlichung eines Patches waren Tausende von internetfähigen Geräten immer noch nicht gepatcht – ein deutliches Zeichen dafür, dass Session Hijacking kein rein theoretisches Problem von Webanwendungen ist, sondern eine reale Ursache für Sicherheitslücken in Unternehmensnetzwerken darstellt.

Wie sollte man Sitzungs- und Token-Sensitivität klassifizieren?

Nicht jede Sitzung birgt das gleiche Risiko, daher sollten die Schutzmaßnahmen dem Umfang der von einer gehackten Sitzung offengelegten Informationen angepasst sein. Klassifizieren Sie Sitzungen in Risikostufen, bevor Sie deren Dauer oder die Häufigkeit der erneuten Authentifizierung festlegen.

Sitzungsebene	Beispiel	Empfohlene Handhabung
Öffentlich / anonym	Durchstöbern einer öffentlichen Marketing-Website oder Wissensdatenbank	Minimaler Sitzungsstatus; geringes Risiko bei Abfangen
Standard authentifiziert	Benutzerprofil anzeigen, Einstellungen für nicht-finanzielle Konten	Standardmäßige Leerlaufzeitüberschreitung, Secure- und HttpOnly-Cookie-Flags
Sensible / regulierte Daten	Sitzungen, die personenbezogene Daten, PCI-Karteninhaberdaten oder geschützte Gesundheitsdaten berühren	Kurze Leerlaufzeitüberschreitung, SameSite=Streng, Überwachung auf Anomalien
Privilegiert / administrativ	Administrationskonsolen, Zahlungsauslösung, Schnittstellen zur Schlüsselverwaltung	Kürzeste Lebensdauer, obligatorische erneute Authentifizierung für sensible Aktionen, Sitzungs-ID-Rotation bei Berechtigungsänderung

Wie verschlüsselt man Sitzungstoken und wählt einen sicheren Speicher?

Verschlüsseln Sie jedes Session-Token während der Übertragung mit TLS und speichern Sie es in einem HTTP-Only-Cookie (Secure-Cookie) anstatt an einem Ort, auf den JavaScript oder der lokale Speicher zugreifen können. Im Gegensatz zu gespeicherten Kartendaten gibt es für Session-IDs keine sinnvolle Tokenisierungsoption; die entscheidende Frage ist vielmehr, wo und wie das Token nach seiner Ausstellung gespeichert wird. Eine falsche Entscheidung in diesem Punkt ermöglicht die meisten Hijacking-Techniken überhaupt erst.

• Transport: Erzwingen Sie TLS 1.2 oder höher bei jeder Anfrage, die einen Session-Cookie enthält, und verwenden Sie HSTS, damit Browser nicht auf einfaches HTTP zurückgreifen, selbst wenn ein Link oder eine Weiterleitung dorthin verweist.
• Speicherort: Verwenden Sie einen HttpOnly-Cookie, nicht localStorage or sessionStorage, für das Session-Token, da alles, was von JavaScript gelesen werden kann, auch von einer XSS-Payload gelesen werden kann.
• Cookie-Flags: kompensieren Secure (nur HTTPS), HttpOnly (kein JavaScript-Zugriff) und SameSite=Strict or Lax (keine automatische seitenübergreifende Anbindung) bei jedem Session-Cookie, gemäß der OWASP-Sitzungsmanagement-Spickzettel.
• Entropie und Länge: Die Sitzungs-IDs werden mit einem kryptografisch sicheren Zufallszahlengenerator erzeugt, der mindestens 64 Bit Entropie liefert. OWASP merkt an, dass ein Angreifer bei realistischen Rateraten Hunderte von Jahren bräuchte, um dies durch Brute-Force-Angriffe zu erraten.
• Präfixe für Cookie-Namen: Sofern unterstützt, verwenden Sie die __Host- Präfix, das den Browser zwingt, Folgendes zu erzwingen Secure, kein domänenübergreifender Geltungsbereich, und Path=/ auf dem Keks.

Die Zertifikats- und Schlüsselinfrastruktur bildet die Grundlage all dessen: Die TLS-Terminierung ist nur so vertrauenswürdig wie die zugrunde liegenden Zertifikate und privaten Schlüssel. CertSecure Manager automatisiert die Verwaltung des Zertifikatslebenszyklus, sodass TLS-Endpunkte niemals mit einem abgelaufenen oder falsch konfigurierten Zertifikat ausgeführt werden. HSM-as-a-Service schützt die privaten Schlüssel der TLS-Terminierung in Hardware und nicht in Software, die ein kompromittierter Server offenlegen könnte.

Welche Zugriffskontrollen begrenzen den Schaden durch eine gestohlene Sitzung?

Kurze Sitzungsdauern und die obligatorische erneute Authentifizierung für sensible Aktionen schränken die Möglichkeiten eines Angreifers selbst nach erfolgreichem Diebstahl einer Sitzungs-ID ein. Gemäß NIST SP 800-63B sollte die Häufigkeit der erneuten Authentifizierung mit dem Sicherheitsniveau skalieren: Bei AAL1 mindestens einmal alle 30 Tage; bei AAL2 mindestens alle 12 Stunden oder nach 30 Minuten Inaktivität, je nachdem, was zuerst eintritt; bei AAL3 mindestens alle 12 Stunden oder nach 15 Minuten Inaktivität, wobei für die erneute Authentifizierung beide Authentifizierungsfaktoren erforderlich sind. Die allgemeinen Richtlinien von OWASP verfolgen einen ähnlichen Ansatz: Leerlauf-Timeouts von 2 bis 5 Minuten für Anwendungen mit hohem Risiko und 15 bis 30 Minuten für Anwendungen mit geringerem Risiko, mit einem absoluten Sitzungs-Timeout von 4 bis 8 Stunden unabhängig von der Aktivität, der serverseitig durchgesetzt und nicht dem Client überlassen wird.

Neben Timeouts sollte vor wichtigen Aktionen wie dem Ändern der E-Mail-Adresse oder des Passworts, dem Hinzufügen einer Zahlungsmethode, der Gewährung von Administratorrechten oder dem Export sensibler Daten eine erneute Authentifizierungsanforderung, beispielsweise die erneute Passworteingabe oder eine zusätzliche MFA-Abfrage, erforderlich sein. Eine gestohlene Sitzung, die diese zweite Hürde nicht überwindet, ist für einen Angreifer deutlich weniger nützlich, selbst wenn das zugrunde liegende Token gültig ist.

Wie sieht eine gute Session-Lifecycle-Governance aus?

Die Steuerung des Sitzungslebenszyklus bedeutet, die Ausstellung, Rotation und Ungültigmachung als bewusste, erzwungene Schritte und nicht als Nebeneffekte des Anmeldeformulars zu behandeln. Drei Momente sind dabei besonders wichtig:

• Ausgabe: Generieren Sie bei erfolgreicher Anmeldung eine brandneue Sitzungs-ID mit hoher Entropie; verwenden oder erweitern Sie niemals eine Sitzungs-ID vor der Authentifizierung zu einer authentifizierten Sitzungs-ID, denn genau das wird bei der Sitzungsfixierung ausgenutzt.
• Drehung: Die Sitzungs-ID sollte nach jeder Änderung der Berechtigungsstufe, wie z. B. einer Passwortzurücksetzung, einem Rollenwechsel oder einer Step-up-Authentifizierung, mithilfe von Framework-Aufrufen wie beispielsweise neu generiert werden. session_regenerate_id(true) in PHP oder einem entsprechenden Aufruf zur Session-Invalidierung in Ihrem Framework.
• Ungültigkeit: Die Sitzung sollte beim Abmelden sowohl auf Client- als auch auf Serverseite gelöscht werden. Außerdem sollte auf jeder authentifizierten Seite ein sichtbarer Abmelde-Button bereitgestellt werden. Sitzungen sollten serverseitig nach Ablauf einer bestimmten Zeit beendet werden, anstatt sich auf das Ablaufdatum des Cookies zu verlassen, da ein gestohlener Cookie die clientseitige Uhr nicht berücksichtigt.

Wie sollten Wiederherstellung und Reaktion auf Sicherheitsvorfälle aussehen, wenn eine Systemübernahme festgestellt wird?

Wird ein Session-Hijacking-Versuch bestätigt, werden alle aktiven Sitzungen des betroffenen Kontos sofort ungültig gemacht und eine erneute Authentifizierung erzwungen, bevor einer Sitzung wieder vertraut wird. Eine praktische Reaktionssequenz sieht dann wie folgt aus:

1. Widerrufen Sie serverseitig alle aktiven Sitzungen und Token, die mit dem betroffenen Konto verknüpft sind, nicht nur die eine Sitzung, bei der die Anomalie auftrat.
2. Erzwingen Sie einen Passwort-Reset und rotieren Sie, sofern verfügbar, alle verknüpften API-Schlüssel oder langlebigen Token, die das Konto ausgegeben hat.
3. Überprüfen Sie das Aktivitätsprotokoll des Kontos auf Aktionen, die während des Übernahmezeitraums durchgeführt wurden, und machen Sie alle unautorisierten Aktionen rückgängig oder melden Sie diese.
4. Prüfen Sie, ob ein Angriffsvektor vorliegt, z. B. eine nicht behobene XSS-Schwachstelle, ein fehlendes Cookie-Flag oder ein kompromittierter Endpunkt, und schließen Sie diesen, bevor Sie den normalen Zugriff wiederherstellen.
5. Benachrichtigen Sie den betroffenen Benutzer und befolgen Sie, falls regulierte Daten offengelegt wurden, die Meldepflichten Ihrer Organisation im Falle einer Datenschutzverletzung gemäß dem geltenden Rahmenwerk.

Wie überwacht man anomales Sitzungsverhalten?

Die kontinuierliche Überwachung erkennt Angriffsversuche, die die Kontrollmechanismen umgehen, indem sie auf Verhaltensweisen achtet, die eine legitime Sitzung nicht aufweisen würde. Zu den nützlichen Signalen gehören:

• Eine einzige Sitzungs-ID wurde von zwei geografisch weit voneinander entfernten IP-Adressen innerhalb eines unrealistisch kurzen Zeitfensters verwendet.
• Ein plötzlicher Wechsel des Benutzeragenten oder des Geräte-Fingerabdrucks mitten in der Sitzung, ohne entsprechende neue Anmeldung.
• Eine authentifizierte Sitzung, die plötzlich Aktionen mit hohen Berechtigungen ausführt, die sie zuvor noch nie für dieses Konto ausgeführt hat.
• Wiederholte, schnell aufeinanderfolgende Versuche, die Sitzungs-ID zu erraten, oder fehlerhafte Sitzungstoken, die den Anmelde- oder Sitzungsvalidierungsendpunkt erreichen, sind ein Zeichen für Brute-Force-Angriffe.
• Datenverkehr zu bekannten Session-Hijacking-Tooling-Mustern, die von Intrusion-Detection- und -Prevention-Systemen anhand bekannter Angriffssignaturen erkannt werden können.

Nichts davon ersetzt die Prävention; es ist die Ebene, die davon ausgeht, dass die Prävention gelegentlich fehlschlägt und die Zeit verkürzt, in der ein Angreifer eine aktive, unbemerkte Sitzung hat.

Wie lässt sich Sitzungssicherheit den Compliance-Anforderungen zuordnen?

Die Sitzungsverwaltung ist in den meisten Sicherheitsframeworks keine optionale Zusatzfunktion, sondern eine klar definierte Anforderung. Die folgende Tabelle ordnet die oben genannten Kontrollen den jeweiligen Anwendungsfällen zu.

Kontrolle	OWASP	NIST SP 800-63B	PCI-DSS 4.0
Sitzungs-ID-Entropie und -Generierung	Sitzungsverwaltung – Kurzanleitung: 64+ Bit Entropie mittels CSPRNG	Sitzungsgeheimnisse, die an zugelassene kryptografische Authentifikatoren gebunden sind	Anforderung 6, sichere Entwicklungs- und Kryptografiepraktiken
Cookie-Sicherheitsattribute	Sicher, HttpOnly, SameSite erforderlich für Session-Cookies	Nicht cookiespezifisch, erfordert aber geschützte Sitzungsbindungen.	Anforderung 6.2, sichere Codierung zur Vermeidung von Sitzungsfehlern
Leerlauf und absolute Zeitüberschreitung	2 bis 5 Minuten Leerlaufzeit für Apps mit hohem Speicherbedarf; 4 bis 8 Stunden absolute Laufzeit	Erneute Authentifizierung nach 15 bis 30 Minuten Leerlauf, abhängig von der AAL	Anforderung 8.2.8: Nach 15 Minuten Inaktivität erneute Authentifizierung.
Erneute Authentifizierung für sensible Aktionen	Verstärken Sie die Authentifizierung vor Aktionen mit hoher Auswirkung.	Vollständige Reauthentifizierung mit beiden Faktoren bei AAL3	Anforderung 8, starke Authentifizierungskontrollen für den Benutzerzugriff
Sitzungsungültigmachung beim Abmelden	Serverseitige Zerstörung, nicht nur clientseitig	Sitzungsbeendigung beim Abmelden erwartet	Anforderung 8: Zugriff wird widerrufen, wenn er nicht mehr benötigt wird

Einschränkungen

Keine einzelne Maßnahme kann das Risiko von Session-Hijacking vollständig eliminieren. TLS schützt zwar Session-Cookies während der Übertragung, bietet aber keinen Schutz vor XSS-Schwachstellen, die Cookies direkt im Browser auslesen. Cookie-Flags wie HttpOnly und SameSite verhindern zwar bestimmte Diebstahltechniken, können aber eine Session nicht stoppen, die durch bereits auf dem Gerät des Opfers laufende Malware gestohlen wurde. Kurze Timeouts und erneute Authentifizierung reduzieren zwar das Zeitfenster für Angriffe, stellen aber eine zusätzliche Belastung für legitime Nutzer dar. Zu lange Timeouts verleiten Nutzer dazu, auf Workarounds zurückzugreifen, beispielsweise auf einem gemeinsam genutzten Gerät dauerhaft angemeldet zu bleiben. Die Überwachung auf anomales Verhalten hilft, Lücken in der Prävention zu schließen, ist aber probabilistisch und nicht sicher. Ein geduldiger Angreifer, der den üblichen Standort und das Gerät des Opfers imitiert, kann die Überwachung eine Zeit lang umgehen. Betrachten Sie diese Maßnahmen als aufeinander aufbauende Prozesse und nicht als Einzellösung. Überprüfen Sie sie regelmäßig, wenn sich das Bedrohungsmodell Ihrer Anwendung ändert.

Was würde Encryption Consulting empfehlen?

Beginnen Sie mit den Kontrollmechanismen, die die gängigsten Erfassungsmethoden vollständig blockieren, und ergänzen Sie diese anschließend durch Monitoring und Governance, anstatt alles gleichzeitig umzusetzen. In der Praxis empfehlen wir unseren Kunden folgende Vorgehensweise: Erzwingen Sie TLS flächendeckend mit automatisiertem Zertifikatslebenszyklusmanagement, damit abgelaufene oder falsch konfigurierte Zertifikate keine Sicherheitslücke für Downgrade-Angriffe darstellen; legen Sie Secure, HttpOnly und SameSite als grundlegende, nicht verhandelbare Konfigurationsänderung für jedes Session-Cookie fest; generieren Sie Session-IDs bei der Anmeldung und bei jeder Berechtigungsänderung neu; und passen Sie Leerlauf-Timeouts und Anforderungen für die erneute Authentifizierung an die Sensibilitätsstufe der jeweiligen Session an, anstatt einen unternehmensweiten Standardwert zu verwenden.

Wenn das zugrundeliegende Problem in der fragmentierten Zertifikats- und Schlüsselverwaltung vieler Anwendungen liegt, anstatt im Sitzungscode einer einzelnen Anwendung, bietet PKI-as-a-Service Teams eine verwaltete Möglichkeit, die TLS-Zertifikate auszustellen und zu rotieren, die verschlüsselte Sitzungen überhaupt erst ermöglichen. So muss nicht jedes Anwendungsteam die Verwaltung des Zertifikatslebenszyklus selbst neu entwickeln. Für Organisationen, die dies intern verwalten, behandelt unser zugehöriger Leitfaden zu den häufigsten SSL/TLS-Angriffen und wie die Verwaltung des Zertifikatslebenszyklus zu deren Minderung beiträgt, die Transportschichtseite dieses Problems detaillierter. Dieser Beitrag konzentriert sich auf die Zertifikats- und Protokollangriffe, die dem Abfangen vorausgehen oder es ermöglichen, während dieser Beitrag sich darauf konzentriert, was mit der Sitzung selbst geschieht, sobald ein Angreifer Zugriff erlangt hat. Lesen Sie die beiden Beiträge daher zusammen und nicht als Duplikate.

Fazit

Session-Hijacking gelingt nicht durch das Knacken eines Passworts, sondern durch Ausnutzen des Vertrauens, das ein Server in eine Session-ID setzt. Die Verteidigung ist mehrschichtig und nicht monolithisch: Sessions werden während der Übertragung mit TLS verschlüsselt, Cookies mit den Flags Secure, HttpOnly und SameSite geschützt, Sessions werden kurz gehalten und für sensible Aktionen erneut authentifiziert, Session-IDs werden bei jeder Berechtigungsänderung rotiert und Anomalien, die trotz dieser Maßnahmen unentdeckt bleiben, werden überwacht. Keine einzelne Maßnahme kann alle Sicherheitslücken schließen. Genau deshalb muss die Session-Sicherheit als vollständiger Lebenszyklus – von der Ausstellung bis zur Ungültigmachung – betrachtet werden und darf nicht einmalig konfiguriert und dann sich selbst überlassen werden.

Häufig gestellte Fragen

Ist Session Hijacking dasselbe wie Session Fixation? Nein. Session Fixation ist eine spezielle Technik, um eine Session zu übernehmen: Der Angreifer legt dem Opfer im Voraus eine bekannte Session-ID zu und wartet, bis sich dieses damit authentifiziert. Session Hijacking hingegen ist das umfassendere Ergebnis, die Übernahme einer beliebigen gültigen Session. Dies kann durch Fixation, XSS-basierten Cookie-Diebstahl, Netzwerk-Sniffing oder verschiedene andere Techniken erreicht werden.

Verhindert HTTPS allein Session-Hijacking? Nein. TLS schützt zwar den Session-Cookie während der Übertragung im Netzwerk und verhindert so das Abfangen von Datenverkehr, bietet aber keinen Schutz gegen Session-Cookies, die clientseitig durch eine XSS-Schwachstelle oder bereits auf dem Gerät des Nutzers vorhandene Schadsoftware gestohlen wurden. HTTPS ist daher notwendig, aber allein nicht ausreichend.

Wie lange sollte ein Session-Cookie gültig sein? Das hängt davon ab, worauf die Session zugreifen kann. OWASP empfiehlt generell ein Timeout von 2 bis 5 Minuten für Anwendungen mit hohem Sicherheitsrisiko und 15 bis 30 Minuten für Anwendungen mit geringerem Risiko, bei einer absoluten Session-Lebensdauer von 4 bis 8 Stunden unabhängig von der Aktivität. Die Anforderung 8.2.8 von PCI DSS 4.0 fordert ausdrücklich eine erneute Authentifizierung nach 15 Minuten Inaktivität für betroffene Systeme.

Schützt Multi-Faktor-Authentifizierung (MFA) vor Session-Hijacking? MFA schützt lediglich den Login selbst, nicht aber eine bereits bestehende Sitzung. Sobald ein Benutzer authentifiziert ist und ein Session-Cookie existiert, kann ein Angreifer, der dieses Cookie stiehlt, eine bereits authentifizierte Sitzung imitieren und muss die MFA-Prüfung gar nicht erst durchlaufen. Genau deshalb sind Sitzungslebensdauer, -rotation und erneute Authentifizierung für sensible Aktionen als separate Sicherheitsebene neben MFA so wichtig.

Was ist der erste Schritt bei Verdacht auf einen aktiven Session-Hijacking-Angriff? Die betroffene Session und alle anderen aktiven Sessions dieses Kontos müssen serverseitig sofort ungültig gemacht und eine erneute Anmeldung erzwungen werden. Die alleinige Bearbeitung der verdächtigen Session reicht nicht aus, wenn der Angreifer auch andere gültige Token desselben Kontos abgefangen hat oder wiederverwenden könnte.

Referenzen

• OWASP, Kurzanleitung zur Sitzungsverwaltung
• OWASP, Top 10: A07:2021 Identifizierungs- und Authentifizierungsfehler
• NIST, SP 800-63B Richtlinien für digitale Identität, Authentifizierung und Lebenszyklusmanagement
• PCI Security Standards Council, Häufig gestellte Fragen zur PCI-DSS-Anforderung 8.2.8
• Bischof Fox Analyse von CVE-2024-53704, SonicWall SSL VPN Session Hijacking
• MDN Web Docs, Set-Cookie-Header, einschließlich des SameSite-Attributs