Session Fixation hält sich vor allem dort, wo das Framework die Rotation der Session-ID der Entwicklerin überlässt

Hypothese

Bei einem Session-Fixation-Angriff setzt die Angreiferin eine Session-Kennung im Browser des Opfers, bevor dieses sich anmeldet (über einen Link, ein Cookie auf einer Nachbardomain oder eine Injection), wartet, bis das Opfer sich unter dieser Kennung authentifiziert, und verwendet danach dieselbe Kennung. Das (zitierte) OWASP-Session-Management-Cheatsheet hält fest, dass die Regenerierung der Session-ID nach jedem Wechsel des Privilegienlevels, vor allem bei der Authentifizierung, zwingend ist, um den Angriff zu verhindern, und nennt die Framework-Aufrufe, die dies tun. Frameworks unterscheiden sich darin, ob dieser Aufruf automatisch geschieht. Die (zitierte) Spring-Security-Referenz sagt, sie schütze automatisch vor Fixation, indem sie beim Login einer Nutzerin eine neue Session erzeuge oder die Session-ID ändere, wobei changeSessionId auf Servlet 3.1 und neueren Containern der Standard sei. In PHP dokumentiert das (zitierte) Handbuch session_regenerate_id(), das die aktuelle ID ersetzt und die Daten behält, aber die Session-Extension weiss nichts von "Login"; die Anwendung muss die Funktion im richtigen Moment aufrufen, und die eigenen Beispiele des Handbuchs zeigen, dass dies robust zu tun (verzögertes Zerstören der alten ID, Wettlaufsituationen bei instabilen Netzwerken) nicht trivial ist. Die Hypothese: Die Verbreitung von Session Fixation wird durch diesen Standardwert bestimmt, nicht durch das Bewusstsein der Entwicklerinnen, und handgeschriebener Login-Code auf Stacks ohne automatische Rotation wird den Befund weiterhin produzieren.

Vorhersage

Über eine mit derselben Methode getestete Stichprobe von Anwendungen (Login mit vorab gesetztem Session-Cookie, Prüfung, ob sich die Kennung ändert) ist der Anteil mit Fixation-Befunden bei Anwendungen, deren Login auf einer Session-API ohne automatische Rotation aufbaut, um ein Mehrfaches höher als bei solchen auf Frameworks, die standardmässig rotieren; innerhalb der zweiten Gruppe stammen die verbleibenden Befunde aus eigenen Login-Pfaden, die den Authentifizierungs-Handler des Frameworks umgehen (SSO-Callbacks, API-Token-Austausch, "Angemeldet bleiben").

Vorgeschlagener Test

1. Open-Source-Webanwendungen über verschiedene Stacks hinweg auswählen; jede danach klassifizieren, ob der Login-Helfer ihres Frameworks die Session-ID standardmässig rotiert (laut Framework-Dokumentation) oder ob die Rotation ein separater Aufruf ist.
2. Für jede dieselbe Fixation-Prüfung gegen eine lokale Bereitstellung durchführen; festhalten, ob sich die Kennung beim Login, beim Privilegienwechsel und beim Logout ändert.
3. Die Befundraten zwischen den Gruppen vergleichen; die verbleibenden Befunde in der automatisch rotierenden Gruppe auf umgangene Login-Pfade untersuchen.
4. Optional mit Korpora von Penetrationstestberichten wiederholen, die den Stack benennen.

Status

Kein Ergebnis wird behauptet. Störgrössen: Stacks unterscheiden sich in Alter, Ökosystemreife und der Art der darauf gebauten Anwendungen; Anwendungen mit tokenbasierten, zustandslosen Sessions haben keine serverseitige ID, die fixiert werden könnte, und müssen ausgeschlossen werden; der Standardwert eines Frameworks kann sich zwischen Versionen geändert haben, weshalb die verwendete Version festgehalten werden muss.