Best Practices – Sitzungsfixierung

Sitzungsfixierung

Erklärung der Sicherheitslücke

Session Fixation (CWE-384) ist ein Angriff, der es einem Angreifer ermöglicht, eine gültige Benutzersitzung zu kapern. Das Authentifizieren eines Benutzers oder das Einrichten einer neuen Benutzersitzung, ohne eine vorhandene Sitzungskennung ungültig zu machen, bietet einem Angreifer die Möglichkeit, authentifizierte Sitzungen zu stehlen.

Der Fehler tritt auf, wenn die HTTP-Sitzungs-ID vor und nach der Anmeldung eines Benutzers gleich bleibt. Dadurch kann ein Angreifer eine bestimmte Sitzungs-ID „reparieren“ und eine gültige Benutzersitzung kapern. Mit anderen Worten: Die Sitzungs-ID kann vom Angreifer kontrolliert werden.

Empfohlene Sicherheitskontrollen

Gemäß den OWASP- und MITRE-Empfehlungen müssen Anwendungen zum Schutz vor Sitzungsfixierung Folgendes tun:

  1. Machen Sie alle vorhandenen Sitzungskennungen ungültig, bevor Sie eine neue Benutzersitzung autorisieren
  2. Generieren Sie die Sitzungs-ID nach jeder Änderung der Berechtigungsebene innerhalb der zugehörigen Benutzersitzung neu

Das häufigste Szenario, in dem die Neugenerierung der Sitzungs-ID obligatorisch ist, ist während des Authentifizierungsprozesses, wenn sich die Berechtigungsebene des Benutzers vom nicht authentifizierten (oder anonymen) Zustand in den authentifizierten Zustand ändert.

So funktioniert der Schutz von Waratek

Waratek bietet Schutz vor Session-Fixation-Angriffen über die ARMR-HTTP-Regel unter Verwendung der folgenden Deklarationen

 http("Enable Session Fixation protection"):
request()
authenticate(user)
protect(http-session: regenerate-id)
endhttp
 
Diese Regel bindet sich an den Sitzungsauthentifizierungsmechanismus der Servlet-API an und überwacht Benutzerauthentifizierungsprozesse. Wenn sich ein Benutzer erfolgreich authentifiziert, generiert der Waratek-Agent die Sitzungs-ID der HTTP-Sitzung des Benutzers neu. Diese proaktive Sicherheitskontrolle behebt die Schwachstelle und eliminiert die Angriffsfläche für Sitzungsfixierungsangriffe. Da keine Sitzungsfixierungsangriffe möglich sind, protokolliert diese Regel keine Sicherheitsereignisse für Angriffe.

Im Folgenden finden Sie eine allgemeine Beschreibung des Arbeitsablaufs zur Sitzungs-ID-Regeneration, den Waratek durchführt:

  1. Der Benutzer gibt die korrekten Anmeldeinformationen ein.
  2. Das System authentifiziert den Benutzer erfolgreich.
  3. Vorhandener HTTP-Sitzungsinhalt wird in den temporären Cache verschoben.
  4. Vorhandene HTTP-Sitzung wird ungültig gemacht (HttpSession.invalidate()​).
  5. Für den Benutzer wird eine neue HTTP-Sitzung erstellt.
  6. Die zuvor zwischengespeicherten Sitzungsdaten werden in der neu erstellten HTTP-Sitzung wiederhergestellt.
  7. Der Benutzer gelangt mit einer neuen Sitzungs-ID zu einer Zielseite für die erfolgreiche Anmeldung.

Schutzmaßnahme

Die Sitzungsfixierungsregel ist eine proaktive Regel. Es wird proaktiv vor einem potenziellen Angriff ausgelöst und eliminiert den Angriffsvektor für die Sitzungsfixierung.

Anwendbarkeit der Regel

Die Sitzungsfixierungsregel ist anwendbar und kann in Webanwendungen sicher aktiviert werden falls:

  • es wird die Servlet-API zur Verarbeitung von HTTP-Anfragen, -Antworten und zur Sitzungsverwaltung verwendet
  • Dessen Authentifizierungsverwaltungssystem legt bei jeder HTTP-Anfrage Authentifizierungs- und Identitätsinformationen fest.
  • Dessen Authentifizierungsmechanismus legt den HttpServletRequest-Benutzerprinzipal nach der Authentifizierung fest.


Benutzer sollten die Sitzungsfixierungsregel in den folgenden Fällen nicht aktivieren, da sie entweder keinen Schutz bieten oder die normale Anwendungsfunktionalität beeinträchtigen könnte:

  • In dem sehr seltenen Fall, dass die Ziel-Webanwendung darauf angewiesen ist, vor und nach der Benutzerauthentifizierung dieselbe HTTP-Sitzungs-ID zu haben.
  • Wenn eine andere Sicherheitskontrolle vorhanden ist, die auch die HTTP-Sitzungs-ID neu generiert, kann dies zu Konflikten führen.

Empfohlene Vorgehensweise

Waratek empfiehlt, die XSS-Sicherheitsregel auch im Blockierungsmodus zu aktivieren, um vor XSS-Angriffen geschützt zu sein. Anwendungen, die für XSS-Angriffe anfällig sind, sind auch dann anfällig für Sitzungsfixierungs- oder Sitzungs-Hijacking-Angriffe, wenn die Sitzungsfixierungsregel aktiviert ist.

Weiterführende Verweise

https://owasp.org/www-community/attacks/Session_fixation

https://cwe.mitre.org/data/definitions/384.html