Sitzungsfixierung

Was ist Sitzungsfixierung?

Fixierung und Hijacking unterscheiden sich darin, wann der Angreifer die Sitzungs-ID erhält. Ein Hijacker stiehlt es, nachdem Sie sich authentifiziert haben. Durch die Fixierung wird ein bekannter Wert vorher angelegt und Ihr eigener Login kann ihn aktualisieren. Sie pinnen eine anonyme Live-ID an einen Link an, beobachten, wie sich das Opfer anmeldet, und laden ihr Dashboard mit derselben Zeichenfolge. Der Handler liest const sid = req.cookies.sid || crypto.randomUUID() . Der Fix prägt bei jedem Authentifizierungs- und Privilegienübergang bedingungslos eine neue ID, weshalb Entropy und HttpOnly diese ID nicht schließen.

Was Sie lernen in Sitzungsfixierung

• Session Fixation von Session Hijacking anhand des Zeitpunkts unterscheiden, zu dem der Angreifer die ID besitzt (vor oder nach der Anmeldung)
• Erkennen, dass jede Möglichkeit zum Schreiben eines Cookies (Subdomain-XSS, MITM, Response Splitting) Session Fixation ermöglichen kann
• Bei jeder erfolgreichen Authentifizierung (und jedem Rechteübergang) eine bedingungslose Rotation der Session-ID anwenden
• Die Rotation mit dem expliziten Löschen der Session-ID vor der Anmeldung kombinieren, damit die alte Bindung serverseitig nicht fortbesteht
• Jeden Übergang des Authentifizierungsstatus auf denselben Rotations-Hook prüfen (Anmeldung, nach MFA, Erhöhung von Rollenrechten, Passwortänderung)

Sitzungsfixierung — Trainingsschritte

1. Bobs Plan

   Bob kann Alices Passwort nicht stehlen und muss es auch nicht. Sein Plan ist, ihr eine ihm bekannte Session-ID zu geben und sie dann darauf anmelden zu lassen, sodass die Sitzung, in der sie letztlich authentifiziert ist, von ihm kontrolliert wird. Zunächst benötigt er eine Session-ID zum Platzieren. Er öffnet selbst das Portal von Sundermark Logistics. Dieses Legacy-Portal gibt seinem Browser eine anonyme Session-ID und schreibt sie als ?sid -Wert direkt in die Adressleiste, genau wie bei jedem Besucher.

2. Eine gültige Session-ID zum Platzieren

   Bob öffnet den Cookie-Inspektor des Browsers. Das Portal hat ihm bereits eine Session-ID gegeben, bevor er sich angemeldet oder etwas getan hat. Sie ist anonym, aber ein echter vom Server ausgestellter und akzeptierter Wert. Genau diese ID wird er bei Alice platzieren.

3. Die ID in einen Link einbauen

   Bob muss nichts erstellen. Die Session-ID, die der Server ihm gab, steht bereits als ?sid=SID-9F3A2B1C7D in der Adresse, und das Portal hat eine Legacy-Eigenheit: Es kopiert diese sid direkt aus der URL in das Cookie des Besuchers. Damit ist genau dieser Link die Falle. Bei jedem, dem Bob ihn sendet, wird seine Session-ID beim Öffnen im Cookie platziert.

4. Die Falle an Alice senden

   Bob nimmt Alice ins Visier, eine Mitarbeiterin, deren Portalkonto er will. Er öffnet seine E-Mail und schreibt ihr eine als routinemäßige IT-Zugriffsbenachrichtigung getarnte Nachricht mit demselben Session-ID-Link im Text. Er muss nur erreichen, dass sie ihn öffnet und sich anmeldet.

5. Eine routinemäßige Zugriffsbenachrichtigung

   Außerhalb der Arbeitszeit erhält Alice eine E-Mail, die wie eine IT-Routinemeldung klingt: Bestätigen Sie Ihren Portalzugang vor Ende des Tages. Der Link verweist auf das echte Portal, daher fällt nichts auf.

6. Ein Klick übergibt das Cookie

   Alice klickt auf den Link. Er öffnet wie erwartet die echte Anmeldeseite des Portals. Was sie nicht sehen kann: Das Portal hat die sid aus dem Link gerade in ihren Cookie-Speicher kopiert. Ihr Browser enthält nun Bobs Session-ID.

7. Alice meldet sich an

   Alice meldet sich mit ihren Sundermark-Zugangsdaten an, wie in der Benachrichtigung verlangt. Das Portal begrüßt sie und zeigt ihr Dashboard. Nichts wirkt falsch. Ihr Konto, ihre Daten, ihre Sitzung.

8. Die ID, die sich hätte ändern müssen

   Hier wird der Fehler sichtbar. Eine sichere Anmeldung erstellt im Moment der Anmeldung eine völlig neue Session-ID, sodass die eingetroffene ID verworfen wird. Alices ID hat sich nicht geändert. Das Cookie auf ihrem authentifizierten Dashboard entspricht Byte für Byte dem Wert aus dem per E-Mail gesendeten Link – dem von Bob platzierten Wert.

9. Bob aktualisiert die Seite und gelangt in ihr Konto

   Bob hat die Anmeldeseite, die er mit seiner platzierten Session-ID geladen hat, noch in seinem Browser geöffnet. Eine Minute nach Alices Anmeldung aktualisiert er sie einfach. Seine platzierte ID ist nun an ihre authentifizierte Sitzung gebunden. Das Portal behandelt seine Anfrage daher als ihre und leitet ihn direkt zu ihrem Dashboard weiter. Kein Passwort, kein Diebstahl, keine Malware.

10. Den Vorfall benennen

    Bevor Alice von der Betroffenen zur Ingenieurin wechselt, benennen Sie den Angriff präzise.