Was ist Session Fixation? Wie Angreifer Benutzersitzungen kapern

Session Fixation ermöglicht es Angreifern, authentifizierte Konten zu kapern, indem sie vor dem Login eine bekannte Sitzungs-ID erzwingen. Die wichtigste Abwehrmaßnahme: Sitzungs-IDs bei jedem Login neu generieren.

Was ist Session Fixation?

Session Fixation ist eine Schwachstelle in Webanwendungen, die es einem Angreifer ermöglicht, eine gültige Benutzersitzung zu kapern, indem er eine fehlerhafte Verwaltung von Sitzungskennungen ausnutzt. Der Kernfehler ist einfach: Wenn sich ein Benutzer authentifiziert, weist die Anwendung keine neue Sitzungs-ID zu. Das bedeutet, dass ein Angreifer, der die Sitzungskennung vor der Authentifizierung kennt oder kontrolliert, diese verwenden kann, um auf die authentifizierte Sitzung zuzugreifen, als wäre er der legitime Benutzer.

MITRE CWE definiert die Schwachstelle formal: „Die Authentifizierung eines Benutzers oder das anderweitige Etablieren einer neuen Benutzersitzung, ohne eine bestehende Sitzungskennung ungültig zu machen, gibt einem Angreifer die Möglichkeit, authentifizierte Sitzungen zu stehlen.“ Für Sie bedeutet das nahezu vollständige Kontoübernahme, oft ohne dass das Opfer etwas bemerkt.

Session Fixation unterscheidet sich von Session Hijacking, auch wenn beide Begriffe oft verwechselt werden. OWASP zieht eine klare Grenze: Session Fixation beginnt, bevor sich das Opfer anmeldet, während Session Hijacking nach dem Bestehen einer aktiven authentifizierten Sitzung erfolgt. Bei einem Fixation-Angriff kennt der Angreifer die Sitzungs-ID bereits, weil er sie gesetzt hat. Bei einem Hijacking-Angriff muss der Angreifer die Sitzungs-ID einer aktiven Sitzung abfangen oder vorhersagen.

Attribut	Session Fixation	Session Hijacking
Angriffszeitpunkt	Bevor sich das Opfer authentifiziert	Nachdem sich das Opfer authentifiziert hat
Kentniss der Sitzungs-ID	Angreifer setzt oder kennt die ID im Voraus	Angreifer muss die ID abfangen oder vorhersagen
Primäre Gegenmaßnahme	Sitzungs-ID-Regeneration beim Login	Token-Verschlüsselung, sichere Übertragung

Diese Unterscheidung ist für Ihre Sicherheitskontrollen entscheidend. Wenn Ihre Anwendung Sitzungs-IDs nach dem Login regeneriert, verhindern Sie Fixation-Angriffe. Verschlüsselt sie nur Sitzungstoken während der Übertragung, adressieren Sie Hijacking, lassen Fixation aber offen. Wenn Sie verstehen, wie der Angriff technisch funktioniert, erkennen Sie, warum dieser Unterschied so kritisch ist.

Wie funktioniert Session Fixation?

Session Fixation folgt einem vierstufigen Angriffsablauf, dokumentiert von sowohl MITRE CWE als auch OWASP WSTG.

• Schritt 1: Sitzungsakquise. Der Angreifer besucht die Zielanwendung und erhält eine gültige Sitzungs-ID vor der Authentifizierung. Beispielsweise könnte der Server JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 zurückgeben. In Anwendungen mit einem permissiven Sitzungsannahmemechanismus kann der Angreifer einen beliebigen Sitzungs-ID-Wert angeben, den die Anwendung ohne Prüfung akzeptiert.
• Schritt 2: Sitzungsübergabe. Der Angreifer übermittelt die bekannte Sitzungs-ID an das Opfer. Dies kann über eine manipulierte URL, eine Cross-Site-Scripting-Payload, ein injiziertes META-Tag oder HTTP-Response-Splitting erfolgen. Ziel ist es, dass der Browser des Opfers beim Zugriff auf die Zielanwendung die vom Angreifer kontrollierte Sitzungs-ID sendet.
• Schritt 3: Authentifizierung des Opfers. Das Opfer klickt auf den manipulierten Link oder besucht die Anwendung über den Übertragungsmechanismus des Angreifers und meldet sich normal an. Die Anwendung validiert die Zugangsdaten und gewährt Zugriff. Sie versäumt es jedoch, die Sitzungs-ID nach erfolgreicher Anmeldung zu regenerieren und arbeitet weiterhin mit dem gleichen Bezeichner, den der Angreifer bereits kennt.
• Schritt 4: Kontoübernahme. Der Angreifer sendet Anfragen an die Anwendung unter Verwendung der bekannten Sitzungs-ID. Der Server behandelt diese Anfragen, als kämen sie vom authentifizierten Opfer. MITRE merkt an, dass dies „nahezu uneingeschränkten Zugriff auf das Konto des Opfers für die Lebensdauer der Sitzung“ ermöglicht.

Über die vier Kernschritte hinaus kann Session Fixation je nach Zugriffsrechten des Angreifers und Konfiguration der Zielanwendung über verschiedene Methoden erfolgen.

Fünf primäre Angriffsvektoren

1. URL-Parameter-Injektion ist der einfachste Vektor. Der Angreifer bettet die Sitzungs-ID als URL-Query-Parameter ein und übermittelt den Link per Phishing oder E-Mail: https://vulnerable-app.com/login?sessionid=ATTACKER_KNOWN_ID. Burp Scanner klassifiziert „Session token in URL“ als CWE-384.
2. Cookie-Injektion via XSS nutzt JavaScript, das im Browser des Opfers ausgeführt wird, um das Session-Cookie zu setzen: document.cookie = "sessionid=ATTACKER_KNOWN_ID";. MITRE bestätigt, dass Cross-Site Scripting eine der beiden häufigsten Techniken zur Übermittlung von Session-Fixation-Payloads ist.
3. META-Tag-Injektion platziert ein HTML-Tag, das den Browser anweist, ein Cookie zu setzen: <meta http-equiv="Set-Cookie" content="sessionid=ATTACKER_KNOWN_ID">. OWASP merkt an, dass dieser Ansatz schwerer zu verhindern ist als JavaScript-Injektion, da „es unmöglich ist, die Verarbeitung dieser Tags in Browsern zu deaktivieren.“
4. HTTP-Response-Header-Injektion nutzt Response-Splitting-Schwachstellen, um einen Set-Cookie-Header direkt in eine Serverantwort zu injizieren und so die kontrollierte Sitzungs-ID ohne clientseitiges Scripting zu platzieren.
5. Cross-Subdomain-Cookie-Fixation nutzt gemeinsam genutzte Domain-Architekturen aus. MITRE dokumentiert dies direkt: Wenn bank.example.com und recipes.example.com die gleiche Top-Level-Domain teilen, kann eine Schwachstelle in der Rezepte-Anwendung eine Sitzungs-ID fixieren, die für alle Anwendungen auf example.com verwendet wird. Die Vielzahl der Übermittlungsvektoren erklärt, warum Session Fixation weiterhin in Produktivsystemen auftritt.

Ursachen von Session Fixation

Die Hauptursachen von Session Fixation sind gut dokumentiert, und jede stellt eine Lücke dar, die Sie und Ihr Entwicklungsteam schließen können.

Fehlende Regeneration der Sitzungs-ID nach Authentifizierung

Dies ist die Hauptursache, die von jeder maßgeblichen Quelle im Artikel genannt wird. Der OWASP-Leitfaden formuliert es direkt: „Wenn eine Anwendung ihr Session-Cookie nach erfolgreicher Benutzer-Authentifizierung nicht erneuert, könnte eine Session-Fixation-Schwachstelle vorliegen.“

Das OWASP Cheat Sheet spezifiziert, dass die Regeneration der Sitzungs-ID beim Login, bei Passwortänderungen, Berechtigungsänderungen und Rollenwechseln zwingend erforderlich ist. Der CVE-2022-24895-Eintrag dokumentiert, dass Symfonys NONE-Session-Migrationsstrategie dieselbe Sitzung nach Authentifizierung beibehält, Fixation-Angriffe ermöglicht und eine HOHE Schwere aufweist.

Permissive Annahme von Sitzungs-IDs

Das OWASP Session Management Cheat Sheet definiert zwei Mechanismen zur Behandlung von Sitzungs-IDs. Ein permissiver Mechanismus akzeptiert jeden vom Benutzer gesetzten Sitzungs-ID-Wert als gültig und erstellt dafür eine neue Sitzung. Ein strikter Mechanismus akzeptiert nur Sitzungs-IDs, die zuvor von der Anwendung generiert wurden. Wenn Ihre Anwendung den permissiven Mechanismus verwendet, ermöglichen Sie Angreifern, beliebige Werte zu setzen, ohne zuvor eine serverseitig ausgestellte ID zu erhalten.

Vorhersagbare Sitzungskennungen

MITRE identifiziert vorhersagbare Sitzungskennungen als beitragenden Faktor, verwandt mit CWE-340 (Erzeugung vorhersagbarer Zahlen oder Kennungen). Wenn Sitzungs-IDs Mustern folgen oder schwache Zufallswerte nutzen, können Angreifer gültige Werte vorhersagen, ohne eine vom Server beziehen zu müssen.

Permissiver Cookie-Domain-Scope

Das Setzen des Domain-Cookie-Attributs auf eine Top-Level-Domain, z. B. Domain=example.com statt Domain=app.example.com, führt dazu, dass Cookies über alle Subdomains übertragen werden. Eine Schwachstelle in einer Subdomain wird so zum Fixation-Einstiegspunkt für jede Anwendung auf dieser Domain.

HTTP-zu-HTTPS-Übergang ohne Sitzungsregeneration

OWASP WSTG-SESS-03 identifiziert dieses spezifische Szenario: Seiten, die eine Sitzungskennung über HTTP ausgeben und dann auf ein HTTPS-Login-Formular umleiten, ohne die Sitzungs-ID nach der Authentifizierung neu auszustellen, setzen die Pre-Auth-ID dem Abhören auf Netzwerkebene aus. Der Angreifer fängt die ID über die unsichere Verbindung ab und wartet, bis sich das Opfer authentifiziert. Diese Ursachen treten selten isoliert auf, und das Verständnis der formalen Klassifizierung durch die Standardisierungsgremien hilft Ihnen, die Behebung zu kommunizieren und zu priorisieren.

OWASP-Klassifizierung von Session Fixation

Session Fixation ist formal in drei maßgeblichen Standardisierungssystemen klassifiziert: der MITRE Common Weakness Enumeration, den OWASP Top 10 und dem OWASP Web Security Testing Guide. Unter OWASP A07 fällt sie in die Kategorie Authentifizierungsfehler, zusammen mit verwandten Schwachstellen, die denselben Behebungsumfang teilen. Jede Klassifizierung richtet sich an ein anderes Publikum und signalisiert eine andere Maßnahme.

CWE-384: Formale Schwachstellenkennung

MITRE CWE-384 ist die primäre Klassifizierung für Session Fixation und definiert die Schwachstelle als Authentifizierung eines Benutzers ohne Ungültigmachung der bestehenden Sitzungskennung. Ihr Profil in der MITRE-Taxonomie:

• Schwachstellentyp: Basisschwachstelle innerhalb der Kategorie Sitzungsanmeldeinformationen
• Häufige Konsequenzen: Privilegiengewinn oder Übernahme der Identität des Opfers; vollständige Kontoübernahme für die Lebensdauer der Sitzung
• Wahrscheinlichkeit der Ausnutzung: Mittel – erfordert Übermittlung einer bekannten Sitzungs-ID an das Opfer vor dem Login
• Plattformbereich: Sprachunabhängig; gilt unabhängig vom Web-Stack oder Framework
• CWE Top 25 Status: Seit 2019 in den Top 25; bleibt eine aktiv verfolgte Schwachstelle in der Ausgabe 2023

Diese Eigenschaften machen CWE-384 zu einem konsistenten Signal in Schwachstellenscannern und Bewertungsframeworks, wo es direkt auf Testfälle zur Behandlung des Sitzungslebenszyklus abbildet.

OWASP Top 10 und Teststandards

CWE-384 ist abgebildet auf A07:2025 — Authentication Failures in den OWASP Top 10. Diese Klassifizierung hat eine wichtige Implikation: Session Fixation wird als Authentifizierungssteuerungsfehler behandelt, nicht als Cookie-Fehlkonfiguration. Diese Unterscheidung platziert sie klar in Login-Flow-Reviews und Maßnahmen zur Härtung der Authentifizierung, nicht nur in Cookie-Konfigurationsprüfungen.

Referenz	System	Zweck
CWE-384	MITRE CWE	Formale Schwachstellenverfolgung; genutzt von SAST/DAST-Tools und CVE-Einträgen
A07:2025	OWASP Top 10	Signal zur Risikopriorisierung; grenzt die Überprüfung auf Authentifizierungskontrollen ein
WSTG-SESS-03	OWASP WSTG	Maßgebliches Black-Box-Testverfahren und Pass/Fail-Kriterien
Session Management Cheat Sheet	OWASP CheatSheets	Entwicklerorientierte Präventionsreferenz für Regeneration, Cookie-Scope und Strict Mode

Diese vier Referenzen liefern Ihnen das Vokabular, die Testfälle und die Behebungsleitlinien, um Session Fixation in jedem bestehenden Sicherheitsprogramm zu adressieren. Mit dem Klassifizierungskontext lohnt es sich, zu betrachten, was tatsächlich passiert, wenn die Schwachstelle erfolgreich ausgenutzt wird.

Auswirkungen und Risiko von Session Fixation

Session Fixation ermöglicht die vollständige Kontoübernahme für die Lebensdauer der kompromittierten Sitzung. Sobald ein Angreifer eine authentifizierte Sitzungs-ID besitzt, agiert er mit allen Privilegien des Opfers: Lesen sensibler Daten, Initiieren von Transaktionen, Ändern von Kontoeinstellungen und Eskalation von Rechten, falls das Opfer Administratorrechte hat.

OWASP-Klassifizierung und Schweregrad

CWE-384 fällt unter OWASP A07. Die Kategorie A07:2025 weist einen durchschnittlichen gewichteten Ausnutzbarkeitswert von 7,69 auf, abgebildet auf 7.147 Gesamt-CVEs über getestete Anwendungen hinweg. Die Gesamtzahl der CVEs in der Kategorie A07 stieg zudem zwischen den Ausgaben 2021 und 2025, was eine Ausweitung und keine Verkleinerung der Angriffsfläche widerspiegelt.

CVSS-Bereich

Bestätigte Session-Fixation-CVEs reichen von Medium bis Kritisch. Die höchstbewerteten Fälle betreffen meist Szenarien, in denen Fixation eine nicht authentifizierte Kontoübernahme in weit verbreiteten Authentifizierungs-Plugins oder Frameworks ermöglicht. Ein wichtiger Aspekt für Sie als Praktiker: Session-Fixation-CVEs zeigen häufig Bewertungsunterschiede zwischen NIST NVD und Anbieter-CNAs. Beispielsweise erhielt CVE-2019-17563 (Apache Tomcat) von NIST eine KRITISCHE Bewertung, von Apache jedoch „Low“, da das Ausnutzungsfenster als „zu eng für eine praktikable Ausnutzung“ beschrieben wurde.

Kombinierte Risikofaktoren

Session Fixation ist selten ein isoliertes Risiko. CVE-2024-56529 (Mailcow) zeigt, dass der Angriff speziell dann gelingt, wenn HSTS im Browser des Opfers deaktiviert ist. Ein Microsoft-Research-Papier, vorgestellt auf der IEEE S&P 2015, dokumentierte, dass Cookie-Injektion Standard-Sitzungsregenerationsmechanismen auf realen Websites umgehen konnte. Wenn Defense-in-Depth-Kontrollen gleichzeitig versagen, kann sich eine Session-Fixation-Schwachstelle schnell eskalieren. Die Frage, wer verwundbar ist, geht über reine Webanwendungen hinaus.

Wie Angreifer Session Fixation ausnutzen

Angreifer nutzen Session Fixation in Szenarien aus, die von gezieltem Phishing bis zu opportunistischem Session Poisoning reichen.

Phishing-basierte URL-Injektion

Der Angreifer erstellt eine URL mit einer bekannten Sitzungs-ID und übermittelt sie per Phishing oder Social Engineering. Die URL wirkt legitim, da sie auf die echte Anwendungsdomain verweist. Das Opfer klickt auf den Link, meldet sich normal an und authentifiziert unwissentlich eine vom Angreifer kontrollierte Sitzung. Dies ist das häufigste Szenario für URL-basierte Sitzungs-ID-Übertragung.

Ausnutzung öffentlicher Terminals

MITRE CWE-384 dokumentiert ein kanonisches Szenario: Ein Angreifer erstellt eine Sitzung an einem öffentlichen Terminal, notiert die Sitzungskennung, setzt den Browser auf die Login-Seite zurück und wartet, bis der nächste Benutzer sich authentifiziert. Die Anwendung verwendet weiterhin die bestehende Sitzungs-ID, was dem Angreifer „nahezu uneingeschränkten Zugriff auf das Konto des Opfers für die Lebensdauer der Sitzung“ gibt.

Nicht zielgerichtetes Session Poisoning

CVE-2022-30769 (ZoneMinder) zeigte einen Angriff, bei dem ein Angreifer ein Session-Cookie „vergiften“ konnte, das vom nächsten angemeldeten Benutzer übernommen wurde. Dies erforderte keine gezielte Auswahl eines bestimmten Opfers. Die vergiftete Sitzung wurde von jedem übernommen, der sich als nächstes authentifizierte. In gemeinsam genutzten Umgebungen wie Überwachungsplattformen ist dieses Muster besonders gefährlich.

Ausnutzung von Race Conditions

CVE-2013-2067 (Apache Tomcat) offenbarte eine Race Condition bei der FORM-Authentifizierung. Durch wiederholtes Senden von Anfragen für authentifizierte Ressourcen, während ein Opfer das Login-Formular ausfüllte, konnte ein Angreifer eine Anfrage einschleusen, die mit den Zugangsdaten des Opfers ausgeführt wurde. Apache bewertete dies als „Important“.

Cross-Subdomain-Angriffe

In Multi-Anwendungsarchitekturen mit gemeinsam genutzter Top-Level-Domain nutzen Angreifer eine schwach gesicherte Anwendung aus, um ein Session-Cookie auf die Elterndomain zu fixieren. Jede andere Anwendung auf dieser Domain akzeptiert dann die fixierte Sitzungs-ID. Dieses Szenario ist in Unternehmensumgebungen mit mehreren internen Tools auf einer gemeinsamen Domain häufig. Zu wissen, wer betroffen ist, hilft Ihnen, gezielt nach diesen Schwachstellen zu suchen.

Wer ist von Session Fixation betroffen?

Session Fixation betrifft jede Anwendung, die Benutzersitzungen über Kennungen verwaltet und diese nach der Authentifizierung nicht regeneriert. Die CVE-Dokumentation und MITRE verweisen auf mehrere strukturell risikoreiche Kategorien.

• Webanwendungen mit URL-basierten Sitzungskennungen sind am direktesten exponiert. Die Übertragung der Sitzungs-ID per URL ermöglicht es Angreifern, eine kontrollierte Sitzungs-ID über einen manipulierten Link einzuschleusen, ohne dass eine weitere Schwachstelle erforderlich ist.
• CMS- und Authentifizierungs-Plugin-Ökosysteme sind wiederholt betroffen. CVE-2024-13279 (Drupal TFA, laut CISA), CVE-2010-1434 (Joomla!), CVE-2012-5391 (MediaWiki) und CVE-2019-8116 (Magento) zeigen, dass Authentifizierungs-Module auf CMS-Plattformen ein kritisches Session-Fixation-Risiko einführen, wenn keine Sitzungsregeneration erzwungen wird.
• J2EE/Java EE-Anwendungen haben eine der umfangreichsten dokumentierten CVE-Serien. Apache Tomcat allein weist CVEs von 2013 bis 2025 auf, darunter CVE-2013-2067, CVE-2014-0033, CVE-2015-5346, CVE-2019-17563 und CVE-2025-55668.
• Multi-Anwendungs-Architekturen mit gemeinsamer Domain sind von Natur aus verwundbar. SaaS-Plattformen mit Mandanten-Subdomains und Unternehmensanwendungsportfolios mit gemeinsamer Top-Level-Domain sind durch Cross-Subdomain-Fixation gefährdet, wie MITRE direkt dokumentiert.
• ICS/SCADA-Plattformen stellen eine aufkommende Angriffsfläche dar. CVE-2025-70973 (ScadaBR 1.12.4, veröffentlicht März 2026) zeigt Session Fixation in industriellen Steuerungssystemen, konsistent mit CWE-384-Zuordnungen zu CWE-1364 (ICS Communications: Zone Boundary Failures) und CWE-1366 (ICS Communications: Frail Security in Protocols).
• Enterprise-Workflow-Plattformen sind ebenfalls dokumentiert exponiert. CVE-2022-38369 (Apache IoTDB) und CVE-2022-38054 (Apache Airflow) zeigen, dass Workflow-Automatisierungstools nicht immun sind. Die Breite der betroffenen Kategorien macht reale Fallstudien zu einem nützlichen Ansatz, um das Auftreten dieser Schwachstellen in der Praxis zu verstehen.

Praxisbeispiele für Session Fixation

Session Fixation wurde in einer Vielzahl von Produktivsystemen bestätigt, von Enterprise-Java-Frameworks bis zu industriellen Steuerungsplattformen. Die folgenden Beispiele zeigen, wie sich derselbe zugrundeliegende Fehler je nach Umgebung unterschiedlich auswirkt.

Apache Tomcat FORM-Authentifizierungs-Race-Condition (CVE-2013-2067)

Dies bleibt die wirkungsvollste Tomcat-Session-Fixation-CVE, von Apache als „Important“ eingestuft. Betroffen waren Tomcat 6.0.21 bis 6.0.36 und 7.0.0 bis 7.0.32. Die Schwachstelle nutzte eine Race Condition in der FORM-Authentifizierung aus. Ein Angreifer konnte wiederholt Anfragen für authentifizierte Ressourcen senden, während ein Opfer das Login-Formular ausfüllte, und so eine Anfrage einschleusen, die mit den Zugangsdaten des Opfers ausgeführt wurde. Ironischerweise wurde die Option zur Änderung der Sitzungs-ID bei Authentifizierung erst mit Tomcat 6.0.21 eingeführt. Diese CVE stellte einen Fehler im eigenen Fixation-Schutz von Tomcat dar.

Symfony-Framework CSRF-Token-Bypass (CVE-2022-24895)

Symfony-Versionen 2.0.0 bis 6.2.5 waren von einer HOCH eingestuften Schwachstelle betroffen. Das Framework regenerierte die Sitzungs-ID beim Login, behielt jedoch die übrigen Sitzungsattribute, einschließlich CSRF-Token, bei. Diese partielle Regeneration ermöglichte es Angreifern auf derselben Seite, den CSRF-Schutz durch eine Session-Fixation-Variante zu umgehen. Die Lehre: Nur die Sitzungs-ID zu regenerieren reicht nicht aus. Eine vollständige Invalidierung und Neuerstellung der Sitzung ist erforderlich.

ScadaBR Industrial Control System (CVE-2025-70973)

Veröffentlicht im März 2026, folgt diese Schwachstelle in ScadaBR 1.12.4 dem klassischen Session-Fixation-Muster. Die Anwendung weist nicht authentifizierten Benutzern ein JSESSIONID-Session-Cookie zu und regeneriert die Sitzungskennung nach erfolgreicher Authentifizierung nicht. Eine vor dem Login erstellte Sitzung wird nach der Anmeldung authentifiziert. Diese CVE ist bemerkenswert, da sie aktives Session-Fixation-Risiko in ICS/SCADA-Umgebungen zeigt.

ZoneMinder nicht zielgerichtetes Session Poisoning (CVE-2022-30769)

ZoneMinder 1.36.12 und frühere Versionen erlaubten es einem Angreifer, ein Session-Cookie zu vergiften, das vom nächsten Benutzer übernommen wurde, der sich authentifizierte. Dies erforderte keine gezielte Auswahl eines bestimmten Opfers und ist besonders gefährlich in gemeinsam genutzten Überwachungsumgebungen, in denen mehrere Operatoren Zugriff auf dieselbe Plattform haben.

PHP Session Adoption (CVE-2011-4718)

Das PHP-Session-Modul war „adoptiv“, d. h. es akzeptierte Sitzungs-IDs aus externen Quellen. Die PHP RFC stellte fest, dass „die Verwendung von session_regenerate_id() Session Adoption/Fixation NICHT verhindern kann“, ohne auch session.use_strict_mode zu aktivieren. PHP 5.5.2 führte session.use_strict_mode als Lösung ein, aber selbst mit aktiviertem Strict Mode konnten benutzerdefinierte Save Handler verwundbar bleiben. Der vollständige historische Verlauf dieser Vorfälle zeigt, wie lange diese Schwachstellenklasse bereits besteht.

Session-Fixation-Timeline und Historie

Session Fixation ist seit 2002 formal dokumentiert, und die CVE-Datenbank zeigt, dass sie weiterhin in neuen und alten Codebasen aktiv ist. Die folgende Timeline zeigt wichtige Offenlegungsereignisse und Framework-Reaktionen.

Jahr	Ereignis
Dez 2002	Mitja Kolšek (ACROS Security) veröffentlicht „Session Fixation Vulnerability in Web-based Applications“ und benennt Session Fixation als vierte Angriffsklasse gegen Sitzungskennungen
2006	CVE-2006-1228 (Drupal 4.5.x/4.6.x): URL-basierte Session-ID-Fixation
Juli 2006	MITRE fügt CWE-384 zur Common Weakness Enumeration (Draft 3) hinzu
Feb 2008	Oracle/BEA WebLogic Server Advisory BEA08-196.00: Session Fixation ermöglicht Privilegieneskalation
2009	CVE-2009-1580 (SquirrelMail); Black Hat USA dokumentiert CWE-384 in BitTorrent-Tracker-Communities
2010	CVE-2010-1434 (Joomla! 1.5.0 bis 1.5.15): CVSS 7.5 HOCH
Dez 2011	CVE-2011-4718 (PHP Session Adoption): betrifft PHP 5.0.0 bis 5.5.1
Mai 2013	CVE-2013-2067 (Apache Tomcat 6.x, 7.x): FORM-Auth-Race-Condition, Apache „Important“
2015	Microsoft Research (IEEE S&P) dokumentiert Cookie-Injektion, die weit verbreitete Regenerationsmechanismen umgeht
2019	CWE-384 gelangt in die Top 25
Dez 2019	CVE-2019-17563 (Apache Tomcat): NIST 9.8 KRITISCH vs. Apache „Low“
2022	CVE-2022-24895 (Symfony): partielle Regenerationsumgehung
Jan 2025	CVE-2024-56529 (Mailcow): Session Fixation bei deaktiviertem HSTS
Aug 2025	CVE-2025-55668 (Apache Tomcat 9.x/10.x/11.x): CVSS 6.5 MODERAT
Mär 2026	CVE-2025-70973 (ScadaBR 1.12.4) und CVE-2026-25101 (Bludit): neue CVEs bestätigen die fortbestehende Schwachstellenklasse

Die Timeline umfasst über zwei Jahrzehnte ohne Anzeichen einer Verlangsamung. Session Fixation ist keine historische Schwachstelle. Sie tritt weiterhin in neuen und alten Codebasen auf, von Enterprise-Frameworks bis zu ICS-Plattformen. Wenn Sie wissen, wie Sie Ihre eigenen Anwendungen überprüfen, können Sie den nächsten Schritt gehen.

Wie erkennt man Session Fixation?

Session Fixation ist eine der leichter zu bestätigenden Schwachstellen: Der Kerntest erfordert lediglich das Erfassen einer Sitzungskennung vor dem Login, die Authentifizierung und den anschließenden Vergleich des Werts. Die folgenden Ansätze decken manuelle Überprüfung, Cookie-Attribut-Inspektion, automatisiertes Scannen und WAF-basierte Identifikation ab.

Manuelles Penetration Testing (OWASP WSTG-SESS-03)

Das maßgebliche Testverfahren stammt aus dem OWASP WSTG. Für Sie ist der Black-Box-Test unkompliziert.

1. Erfassen Sie die Sitzungs-ID vor der Authentifizierung. Besuchen Sie die Anwendung und notieren Sie den Wert des Session-Cookies (z. B. JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1).
2. Authentifizieren Sie sich unter Verwendung der erfassten Sitzungs-ID. Übermitteln Sie gültige Zugangsdaten mit dem ursprünglichen Session-Cookie.
3. Vergleichen Sie die Sitzungs-ID-Werte. Gibt der Server nach erfolgreicher Authentifizierung dieselbe Sitzungs-ID zurück, ist die Anwendung verwundbar.

Für Anwendungen ohne vollständige HSTS-Implementierung beschreibt WSTG-SESS-03 eine zweite Strategie: Erzwingen Sie, dass alle Cookies, die nicht nach dem Login frisch ausgestellt wurden, aus einer separaten Maschine in den Browser des Opfers gelangen, und prüfen Sie, ob diese Cookies nach der Authentifizierung Zugriff auf die Sitzung des Opfers gewähren.

Cookie-Attribut-Überprüfung

Prüfen Sie Ihre Session-Cookies auf Härtungsindikatoren. Das __Host-Präfix bietet Integrität gegen netzwerkbasierte Session Fixation. Das __Secure-Präfix zeigt partielle Härtung an. Führen Sie WSTG-SESS-03 aus, um zu überprüfen, ob HttpOnly-, Secure- und SameSite-Attribute korrekt konfiguriert sind.

DAST-Scanning

OWASP ZAP bietet sowohl aktive als auch passive Scanmodi mit Unterstützung für Sitzungsmanagement, einschließlich Cookies, Tokens und anderer Mechanismen. Die Analyse von ZAP zur Sitzungs- und Authentifizierungsdurchsetzung hilft Ihnen,  gebrochene Authentifizierung und Session-Fixation-Bugs zu finden. Burp Suite Professional deckt Test-Workflows für das Sitzungsmanagement ab und fungiert als dynamischer Web-Schwachstellenscanner für das Sitzungsmanagement.

WAF-basierte Identifikation

Das OWASP Cheat Sheet nennt ModSecurity in Kombination mit dem OWASP Core Rule Set als Gegenmaßnahme gegen Session-Fixation-Angriffe. Dieser WAF-basierte Ansatz wird empfohlen, wenn Quellcode nicht verfügbar ist, nicht geändert werden kann oder wenn vollständige Anwendungsanpassungen umfangreiche Neuentwicklung erfordern würden. Eine effektive Überprüfung sollte direkt zur Prävention führen, und die erforderlichen Kontrollen sind klar definiert.

Wie verhindert man Session Fixation?

Die Prävention konzentriert sich auf eine nicht verhandelbare Anforderung: Die Anwendung muss bei jedem Authentifizierungsereignis eine neue Sitzungs-ID ausstellen und jede Sitzungskennung ablehnen, die nicht vom Server selbst generiert wurde. Die folgenden Kontrollen adressieren diese Anforderung auf Anwendungsebene, Framework-Ebene, Cookie-Konfiguration und Netzwerkarchitektur.

Kontrollen auf Anwendungsebene

• Sitzungs-IDs nach Authentifizierung regenerieren. Dies ist die wichtigste Kontrolle. OWASP WSTG-SESS-03 formuliert die Anforderung klar: „Die Anwendung sollte immer zuerst die bestehende Sitzungs-ID ungültig machen, bevor ein Benutzer authentifiziert wird, und bei erfolgreicher Authentifizierung eine neue Sitzungs-ID bereitstellen.“ Die Regeneration ist bei jeder Privilegienänderung zwingend, einschließlich Login, Passwortänderungen, Berechtigungsänderungen und Rollenwechseln.
• Striktes Sitzungsmanagement verwenden. Konfigurieren Sie Ihre Anwendung so, dass nur serverseitig generierte Sitzungs-IDs akzeptiert werden. Lehnen Sie beliebige vom Client übermittelte Sitzungs-ID-Werte ab. PHP führte session.use_strict_mode in Version 5.5.2 speziell zu diesem Zweck ein.
• Sitzungen vollständig invalidieren. CVE-2022-24895 (Symfony) zeigte, dass partielle Sitzungsregeneration nicht ausreicht. Die Regeneration der Sitzungs-ID bei Beibehaltung anderer Sitzungsattribute wie CSRF-Token schafft eine Restschwachstelle. Eine vollständige Invalidierung und Neuerstellung der Sitzung ist erforderlich.

Framework-spezifische Implementierung

Framework	Bestehende Sitzung invalidieren	Neue Sitzung erstellen
J2EE	HttpSession.invalidate()	request.getSession(true)
ASP.NET	Session.Abandon()	Response.Cookies.Add(new HttpCookie(...))
PHP	session_start()	session_regenerate_id(true)

Spring Security schützt automatisch vor Session Fixation, indem beim Login eine neue Sitzung erstellt oder die Sitzungs-ID geändert wird. Es stehen vier konfigurierbare Strategien zur Verfügung: changeSessionId() (empfohlen), migrateSession(), newSession(), und none() (nicht empfohlen).

Cookie-Sicherheitskonfiguration

Befolgen Sie die Anforderungen aus NIST SP 800-63B:

• Secure-Flag: MUSS gesetzt sein (Cookies werden nur über HTTPS übertragen)
• Domain und Path: MUSS auf das minimal notwendige Scope beschränkt werden
• HttpOnly-Flag: SOLLTE gesetzt sein (verhindert JavaScript-Zugriff)
• SameSite=Lax oder Strict: SOLLTE gesetzt sein (laut NIST SP 800-63B v4-Entwurf)
• __Host-Präfix mit Path=/: SOLLTE gesetzt sein (laut NIST SP 800-63B v4-Entwurf)

Die kombinierte Anwendung dieser Flags verhindert die häufigsten netzwerkbasierten und Cross-Site-Fixation-Szenarien und erschwert es Angreifern erheblich,  Cookie-Injektion durchzuführen.

Kontrollen auf Architekturebene

Mischen Sie keine Anwendungen mit unterschiedlichen Sicherheitsniveaus auf derselben Domain. Implementieren Sie vollständiges HSTS einschließlich Subdomains, um netzwerkbasierte Fixation zu verhindern. Setzen Sie ModSecurity mit dem OWASP Core Rule Set für WAF-Schutz ein, wenn Änderungen auf Anwendungsebene nicht sofort möglich sind. Prävention und Überprüfung funktionieren am besten mit den richtigen Werkzeugen.

Tools zur Erkennung und Prävention

Die Identifikation und Verhinderung von Session Fixation erfordert Tools auf drei Ebenen: dynamische Scanner, die reale Angriffsbedingungen simulieren, Framework-eigene Schutzmechanismen, die sichere Defaults auf Codeebene erzwingen, und Verhaltensanalysen, die Fixation-basierte Angriffe auf authentifizierte Sitzungen erkennen. Die folgenden Tools decken alle drei Bereiche ab.

DAST- und Penetration-Testing-Tools

• OWASP ZAP ist ein kostenloses, Open-Source-Tool für dynamisches Application Security Testing. Laut offizieller Dokumentation nutzt ZAP aktive und passive Scanmodi, um Schwachstellen im Sitzungsmanagement, einschließlich Session Fixation, zu finden.
• Burp Suite Professional bietet Session-Testing-Workflows und Scanner-Regeln zur Identifikation von Schwachstellen im Umgang mit Session-Tokens. Die manuellen Testfunktionen ermöglichen es, das WSTG-SESS-03-Verfahren mit vollständiger Request/Response-Transparenz durchzuführen.
• ModSecurity mit OWASP Core Rule Set bietet WAF-basierte Gegenmaßnahmen gegen Session Fixation, einschließlich Identifikation und Durchsetzung von Sicherheits-Cookie-Attributen, Sticky-Session-Tracking und Sitzungs-ID-Erneuerung bei Privilegienänderungen.

Framework-Sicherheitsfunktionen

Spring Securitys integrierter Session-Fixation-Schutz, PHPs session.use_strict_mode und session_regenerate_id() sowie ASP.NET's Session.Abandon() bieten alle native Prävention. Sie sollten sicherstellen, dass diese Funktionen in Ihren Deployments aktiviert und korrekt konfiguriert sind, anstatt sich auf Standardeinstellungen zu verlassen.

Verwandte Schwachstellen

Session Fixation tritt nicht isoliert auf. Mehrere eng verwandte Schwachstellen teilen Übertragungsmechanismen, Ausnutzungsbedingungen oder Risikoverstärker mit CWE-384. Sie als Gruppe zu verstehen, führt zu einem stärkeren Behebungsumfang als Session Fixation allein zu behandeln.

• Cross-Site Scripting (CWE-79) dient als Übertragungsmechanismus für Session Fixation. Reflektiertes XSS kann JavaScript injizieren, das ein kontrolliertes Session-Cookie im Browser des Opfers setzt. Die Behebung von XSS schließt einen der wichtigsten Fixation-Übertragungskanäle.
• Cross-Site Request Forgery (CWE-352) wird oft mit Session Fixation verwechselt, funktioniert aber anders. CSRF nutzt die automatische Cookie-Übertragung des Browsers, um Anfragen aus einer authentifizierten Sitzung zu fälschen. Der Angreifer muss die Sitzungs-ID nicht kennen oder kontrollieren. CWE-352 belegte Platz 9 in den CWE Top 25 2023.
• Improper Authentication (CWE-287) ist eng mit Session Fixation verwandt und fällt in dieselbe OWASP-A07-Kategorie für Authentifizierungsfehler. CWE-287 umfasst alle Formen gebrochener Authentifizierung und belegte Platz 13 in den CWE Top 25 2023 mit 10 Einträgen im CISA Known Exploited Vulnerabilities-Katalog.
• Insufficient Session Expiration (CWE-613)](https://www.sentinelone.com/cybersecurity-101/cybersecurity/enterprise-application-security/) verstärkt das Risiko von Session Fixation, indem das Zeitfenster verlängert wird, in dem eine fixierte Sitzungs-ID gültig bleibt. Lange Session-Timeouts geben Angreifern mehr Zeit, eine fixierte Sitzung auszunutzen.
• Generation of Predictable Numbers (CWE-340) kann Session Fixation über eine CanFollow-Beziehung in der MITRE-Taxonomie vorausgehen. Vorhersagbare Sitzungskennungen senken die Hürde für Fixation-Angriffe, da gültige Sitzungs-ID-Werte erraten werden können. Die Behandlung von Session Fixation in Isolation deckt selten die gesamte Risikofläche ab; die Überprüfung dieser verwandten Schwachstellen im selben Zyklus schließt die Lücken, die Fixation für den Erstzugriff nutzt.

Verwandte CVEs

CVE-ID	Beschreibung	Schweregrad	Betroffenes Produkt	Jahr
CVE-2026-23796	Sitzungskennung wird nach Login nicht regeneriert; Angreifer setzt Sitzungs-ID des Opfers vor Authentifizierung und kapert die Sitzung nach dem Login	Ausstehend	OpenSolution: Quick.Cart	2026
CVE-2026-23624	Session Fixation ausgelöst, wenn Remote-Authentifizierung SSO-Variablen nutzt; Angreifer kann Sitzung stehlen, die zuvor von einem anderen Benutzer auf demselben Rechner geöffnet wurde	Ausstehend	GLPI (≥ 0.71 < 10.0.23; ≥ 11.0.0-alpha < 11.0.5)	2026
CVE-2025-55266	Session Fixation (CWE-384) ermöglicht Angreifer die Übernahme der Benutzersitzung und Durchführung unautorisierter Transaktionen im Namen des Opfers	MITTEL (6.5)	HCL Technologies: Aftermarket DPC (Aftermarket Cloud 1.0.0)	2025
CVE-2025-1723	Fehlerhafte Sitzungsbehandlung (CWE-287) in ManageEngine ADSelfService Plus; authentifizierter Benutzer mit niedrigen Rechten nutzt fehlerhaftes Sitzungsmanagement zur Übernahme anderer Benutzerkonten	HOCH (9.3)	Zohocorp ManageEngine ADSelfService Plus (≤ Build 6510)	2025
CVE-2024-38513	Session Fixation (CWE-384) im GoFiber-Session-Middleware; akzeptiert vom Benutzer übermittelte session_id-Werte, wodurch der Angreifer den Schlüssel der authentifizierten Sitzung kontrollieren kann	KRITISCH (9.8)	GoFiber: Fiber (< 2.52.5)	2024
CVE-2024-22250	Session Hijacking (CWE-384) im veralteten VMware Enhanced Authentication Plug-in; lokaler, nicht privilegierter Angreifer kapert authentifizierte EAP-Sitzung eines privilegierten Domain-Benutzers	HOCH (7.8)	VMware: Enhanced Authentication Plug-in (veraltet)	2024
CVE-2024-22245	Authentifizierungs-Relay und Session Hijacking im veralteten VMware EAP; Angreifer verleitet Domain-Benutzer dazu, Kerberos-Service-Tickets für beliebige Active Directory SPNs weiterzuleiten	KRITISCH (9.6)	VMware: Enhanced Authentication Plug-in (veraltet)	2024
CVE-2023-27524	Standard-SECRET_KEY in Apache Superset wird zur Signierung von Session-Cookies verwendet; Angreifer mit Kenntnis des Standardwerts kann gültige Session-Cookies fälschen und sich als beliebiger Benutzer, einschließlich Admins, authentifizieren; CISA KEV	KRITISCH (9.8)	Apache Superset (≤ 2.0.1)	2023
CVE-2021-34428	Sitzungs-ID bleibt im Session-ID-Manager gültig, wenn eine Ausnahme von SessionListener#sessionDestroyed() ausgelöst wird (CWE-613); Sitzung des vorherigen Benutzers nach Logout auf gemeinsam genutzten Rechnern zugänglich	NIEDRIG (3.5)	Eclipse Jetty (< 9.4.41, < 10.0.3, < 11.0.3)	2021
CVE-2020-17526	Sitzungstoken, die mit dem Standard-Secret-Key signiert sind, werden über verschiedene Airflow-Deployments akzeptiert; authentifizierter Benutzer auf einer Instanz kann auf eine andere zugreifen, ohne sich erneut zu authentifizieren	HOCH (8.8)	Apache Airflow Webserver (< 1.10.14)	2020

Fazit

Session Fixation nutzt einen einzigen, gut verstandenen Fehler aus: Ihre Anwendung regeneriert die Sitzungs-ID nach der Authentifizierung nicht. Formal als CWE-384 klassifiziert und der OWASP Top 10 2025 A07 zugeordnet, tritt sie weiterhin auf CMS-Plattformen, Java-Frameworks, PHP-Anwendungen und ICS/SCADA-Systemen auf. 

Sie reduzieren das Risiko, indem Sie Sitzungs-IDs bei jeder Privilegienänderung rotieren, strikte Sitzungsannahme erzwingen, den Cookie-Scope härten und die Aktivitäten nach der Authentifizierung auf Missbrauch überprüfen.

FAQs

Was ist die Session Fixation-Schwachstelle?

Session Fixation tritt auf, wenn eine Anwendung dieselbe Sitzungs-ID vor und nach dem Login beibehält. Ein Angreifer bringt das Opfer zunächst dazu, eine bekannte Sitzungs-ID zu verwenden, und wartet dann, bis sich das Opfer authentifiziert. 

Wenn die Anwendung keine neue ID ausstellt, kann der Angreifer diese authentifizierte Sitzung nutzen. Die wichtigste Abwehrmaßnahme ist einfach: Die alte Sitzung ungültig machen und nach dem Login sowie bei anderen Privilegienänderungen eine neue erstellen.

Ist Session Fixation Teil der OWASP Top 10?

Ja. CWE-384 ist unter OWASP Top 10 2025 A07: Authentication Failures enthalten. Für Verteidiger ist das weniger als Label, sondern als Priorisierungssignal relevant: Session Fixation wird als Authentifizierungsfehler behandelt, nicht nur als Cookie-Fehlkonfiguration. 

Sie gehört in Überprüfungen von Login-Flows, Tests des Sitzungsmanagements und Maßnahmen zur Härtung der Authentifizierung.

Kann Session Fixation aus der Ferne ausgenutzt werden?

Ja. Die Fernzustellung ist üblich, da der Angreifer meist nur einen Weg benötigt, das Opfer zur Nutzung einer gewählten Sitzungs-ID zu bringen. Das kann über eine manipulierte URL, ein Browser-Skript, eine bösartige Antwort oder eine schwächere Anwendung auf derselben übergeordneten Domain geschehen. 

Physischer Zugriff ist nur in Szenarien wie gemeinsam genutzten oder öffentlichen Terminals erforderlich.

Welche Arten von Anwendungen sind am anfälligsten für Session Fixation?

Die Anwendungen mit dem höchsten Risiko sind diejenigen, die vom Benutzer bereitgestellte Sitzungs-IDs akzeptieren oder diese nach der Authentifizierung nicht rotieren. Zu den im Artikel genannten Beispielen gehören URL-basierte Sitzungsmechanismen, CMS-Authentifizierungsmodule, Java-Anwendungs-Stacks, Umgebungen mit gemeinsam genutzten Domains, Workflow-Plattformen und ICS/SCADA-Webschnittstellen. 

Das gemeinsame Muster ist eine schwache Verwaltung des Sitzungs-Lebenszyklus, nicht eine bestimmte Programmiersprache oder Branche.

Wie entdecken Angreifer typischerweise Session Fixation?

Sie testen, ob eine Sitzung den Login unverändert übersteht. Eine einfache Methode ist, eine Sitzungs-ID vor der Authentifizierung zu erfassen, sich damit zu authentifizieren und den Wert danach zu vergleichen. 

Wenn die gleiche ID weiterhin gültig ist, liegt die Schwachstelle vor. Scanning-Tools können helfen, aber manuelles Testen ist oft für Randfälle wie teilweise Regeneration oder Cookie-Verhalten über Subdomains hinweg erforderlich.

Was sind die ersten Anzeichen einer Session Fixation-Ausnutzung?

Achten Sie auf eine Sitzung, die sich verhält, als ob sie zwei Benutzern gehört. Praktische Warnzeichen sind dieselbe Sitzung von unterschiedlichen IP-Adressen, plötzliche Geräte- oder Standortwechsel oder Zugriffsmuster, die sich unmittelbar nach dem Login ändern. 

Anfragen, die Sitzungskennungen in URLs zu Authentifizierungs-Endpunkten übertragen, können ebenfalls auf einen Fixierungsversuch statt normales Browsen hinweisen.

Wie schwerwiegend ist Session Fixation im Vergleich zu anderen Schwachstellen?

Die Schwere hängt davon ab, was das kompromittierte Konto tun kann. In wenig kritischen Kontexten kann sie als mittel eingestuft werden. In hochkritischen Systemen kann derselbe Fehler eine vollständige Kontoübernahme und administrativen Missbrauch ermöglichen. 

Die CVE-Beispiele im Artikel reichen von 4.6 bis 9.8, was zeigt, dass Session Fixation nicht grundsätzlich geringfügig ist; die Auswirkung wird durch Privilegien, Exponierung und umgebende Kontrollen bestimmt.

Kann Session Fixation zu einer vollständigen Systemkompromittierung führen?

Sie kann direkt zur vollständigen Kompromittierung des Zielkontos führen, was bei administrativen Opfern zu einer noch umfassenderen Kompromittierung werden kann. Sobald der Angreifer erhöhte Privilegien übernimmt, kann er Einstellungen ändern, auf sensible Daten zugreifen oder Aktionen durchführen, die die gesamte Umgebung betreffen. 

Die Schwachstelle selbst zielt auf Sitzungen ab, aber die geschäftlichen Auswirkungen können weit über einen einzelnen Login hinausgehen.

Ist Session Fixation mit Sicherheitstools leicht zu finden?

Die einfachste Form ist relativ leicht zu erkennen, da Tools Sitzungs-IDs vor und nach der Authentifizierung vergleichen können. Schwieriger sind Fälle mit teilweiser Regeneration, vererbten Cookies über Subdomains oder Bedingungen, die an Transport und Browser-Verhalten gebunden sind. 

In der Praxis ist Scanning für die Abdeckung nützlich, aber gezieltes manuelles Testen bleibt wichtig, um die tatsächliche Ausnutzbarkeit zu bestätigen.

Welche Branchen sind am stärksten von Session Fixation bedroht?

Jede Branche, die authentifizierte Webanwendungen betreibt, ist gefährdet, insbesondere wenn Benutzer mit sensiblen Daten oder Transaktionen arbeiten. Der Artikel hebt E-Commerce, Unternehmensplattformen, Shared-Domain-Umgebungen, regulierte Systeme wie im Gesundheitswesen und ICS/SCADA-Implementierungen hervor. 

Das Risiko steigt, wenn Organisationen auf Plugins, veraltetes Sitzungsmanagement oder mehrere Anwendungen mit gemeinsamer übergeordneter Domain setzen.