Session Fixation

Wie Session Fixation funktioniert

Session Fixation, auf Deutsch Sitzungsfixierung, nutzt einen Fehler beim Übergang von einer anonymen zu einer angemeldeten Sitzung. Die Anwendung akzeptiert eine bereits vorhandene Session-ID und behält sie nach dem Login bei. Der Angreifer muss die Kennung daher nicht erraten oder stehlen. Er sorgt dafür, dass das Opfer genau die Sitzung authentifiziert, deren Kennung bereits bekannt ist.

Ein typischer Angriff besteht aus drei Schritten:

• Der Angreifer ruft die Anwendung auf und erhält eine gültige, noch nicht authentifizierte Session-ID.
• Der Angreifer bringt das Opfer dazu, dieselbe Session-ID zu verwenden, etwa über einen präparierten Link oder eine manipulierbare Sitzungsvariable.
• Das Opfer meldet sich an. Wenn der Server die Session-ID nicht ersetzt, kann der Angreifer die nun authentifizierte Sitzung erneut aufrufen.

Der zentrale Prüfpunkt liegt deshalb direkt nach der Anmeldung: Die Session-ID vor dem Login muss sich von der Session-ID nach dem Login unterscheiden. Bleibt beispielsweise die Kennung A1B2C3 während des gesamten Vorgangs unverändert, wurde die anonyme Sitzung lediglich um Benutzerrechte erweitert. Eine sichere Anwendung erzeugt nach der Authentifizierung eine neue, nicht vorhersehbare Kennung und entwertet die alte Sitzung.

Voraussetzungen für den Angriff

Session Fixation funktioniert nur, wenn die Anwendung eine vom Client vorgegebene oder bereits bekannte Session-ID akzeptiert und diese nach einer Änderung des Berechtigungsstatus weiterverwendet. Eine lange, zufällige Session-ID allein verhindert den Angriff nicht. Selbst eine praktisch nicht erratbare Kennung bleibt angreifbar, wenn der Angreifer sie selbst erzeugen oder vorab erhalten und anschließend beim Opfer festsetzen kann.

Die Session-ID kann je nach Anwendung auf mehreren Wegen zum Opfer gelangen:

• Die Anwendung übernimmt eine Sitzungskennung aus einem URL-Parameter.
• Eine unsicher konfigurierte Subdomain kann ein Cookie für die übergeordnete Domain setzen.
• Ein Skript oder eine andere Schwachstelle verändert den Session-Cookie im Browser.
• Die Anwendung erlaubt frei vorgegebene Kennungen, statt ausschließlich serverseitig erzeugte Werte anzunehmen.

Session Fixation sicher verhindern

Die wirksamste Schutzmaßnahme gegen Session Fixation ist die vollständige Erneuerung der Session-ID nach jeder sicherheitsrelevanten Statusänderung. Dazu zählen die Anmeldung, ein Wechsel der Benutzerrolle, eine erneute Bestätigung für sensible Funktionen und gegebenenfalls ein Passwortwechsel. Die alte Kennung muss serverseitig ungültig werden, damit ein paralleler Zugriff darüber nicht mehr möglich ist.

Eine belastbare Sitzungsverwaltung verbindet mehrere Maßnahmen:

• Session-ID regenerieren: Nach dem Login wird eine neue Kennung erzeugt und der authentifizierten Sitzung zugeordnet.
• Alte Sitzung entwerten: Die vorherige Kennung darf keine Berechtigungen behalten und nicht erneut aktiviert werden.
• URL-Sessions vermeiden: Session-IDs gehören nicht in URLs, weil sie in Browserverläufen, Protokollen, Referrer-Daten oder geteilten Links auftauchen können.
• Cookies absichern: Secure beschränkt die Übertragung auf HTTPS, HttpOnly erschwert den Zugriff durch clientseitige Skripte und SameSite begrenzt bestimmte websiteübergreifende Cookie-Übertragungen.
• Sitzungen begrenzen: Leerlaufzeit und maximale Sitzungsdauer sollten zum Schutzbedarf des Kontos passen.

Cookie-Attribute ergänzen den Schutz, ersetzen die Regeneration der Session-ID aber nicht. HttpOnly hilft beispielsweise gegen das Auslesen eines Cookies durch JavaScript, verhindert jedoch nicht, dass eine bereits bekannte Kennung nach dem Login gültig bleibt. Prüfe daher zuerst den serverseitigen Sitzungswechsel und danach die Cookie-Konfiguration.

Session Fixation richtig testen

Messbar ist Session Fixation durch einen Vorher-nachher-Vergleich: Öffne die Anwendung ohne Anmeldung, notiere die vom Server vergebene Session-ID und melde dich mit einem Testkonto an. Vergleiche anschließend den Cookie oder die serverseitige Sitzungskennung. Eine unveränderte ID weist auf eine Schwachstelle hin, sofern dieselbe Kennung nun Zugriff auf authentifizierte Inhalte ermöglicht.

Ein vollständiger Test kontrolliert zusätzlich, ob die alte Session-ID nach dem Login tatsächlich unbrauchbar ist. Nur eine neue Kennung auszugeben reicht nicht, wenn der Server die alte Sitzung weiterhin akzeptiert. Wiederhole die Prüfung außerdem bei Rollenwechseln und besonders geschützten Aktionen, weil ein System den Login korrekt behandeln, spätere Berechtigungsänderungen aber mit derselben Kennung fortführen kann.

Unterschied zum Session Hijacking

Der Unterschied zwischen Session Fixation und Session Hijacking liegt im Zeitpunkt und in der Herkunft der Kennung. Bei Session Fixation kennt der Angreifer die Session-ID bereits vor der Anmeldung und lässt das Opfer diese Sitzung authentifizieren. Beim Session Hijacking übernimmt der Angreifer dagegen eine bereits authentifizierte Sitzung, beispielsweise durch den Diebstahl eines Cookies oder durch eine unsichere Übertragung.

Auch Cross-Site Scripting und Cross-Site Request Forgery sind getrennt zu betrachten. Cross-Site Scripting kann als technischer Weg dienen, Sitzungsdaten zu lesen oder zu verändern. Cross-Site Request Forgery veranlasst einen bereits angemeldeten Browser zu einer unerwünschten Aktion. Session Fixation zielt hingegen darauf, eine bekannte Sitzungskennung durch die Anmeldung des Opfers mit Rechten aufzuladen.

Auswirkungen auf SEO, SEA und GEO

Session Fixation ist kein direkter Ranking-Faktor. Eine ausgenutzte Schwachstelle kann jedoch Benutzerkonten, Kundenbereiche oder Redaktionszugänge gefährden. Werden darüber Inhalte, Weiterleitungen oder Seiteneinstellungen verändert, entstehen mögliche Folgen für Crawling, Indexierung, Conversions und die Qualität öffentlich erreichbarer Informationen.

Bei SEA kann ein kompromittierter Shop oder Kundenbereich bezahlten Traffic auf fehlerhafte beziehungsweise manipulierte Prozesse führen. Für GEO, also Generative Engine Optimization, betrifft das Risiko vor allem öffentlich erreichbare Inhalte: Werden Produktinformationen oder Unternehmensangaben verändert, können Suchmaschinen und KI-Systeme falsche Versionen erfassen. Geschützte Sitzungsinhalte werden dagegen üblicherweise weder organisch indexiert noch als öffentliche Quelle verwendet.

Ein technisches SEO-Audit kann auffällige Weiterleitungen, Statuscodes oder Veränderungen an öffentlich erreichbaren Seiten erkennen, ersetzt aber keinen Sicherheitstest der Authentifizierung. Bei einem Relaunch sollte die Sitzungsverwaltung deshalb zusätzlich zur technischen Relaunch-Prüfung durch Entwickler oder einen spezialisierten Sicherheitstester kontrolliert werden.

Häufige Fragen zu Session Fixation

Wenn ein Relaunch, ein Login-Bereich oder ein Checkout technisch geprüft werden soll, kannst du die Anforderungen im unverbindlichen Erstgespräch einordnen lassen.

Kostenlosen Potenzialcheck anfragen