Session Fixation
Vulnerability Overview
Session Fixation (CWE-384) is an attack that permits an attacker to hijack a valid user session. Authenticating a user, or establishing a new user session without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
The flaw occurs when the HTTP Session ID remains the same before and after a user logs-in. This permits an attacker to “fix” a specific Session ID and hijack a valid user session. In other words, the Session ID can be controlled by the attacker.
Recommended Security Controls
According to the OWASP and MITRE recommendations, to be protected against Session Fixation, applications must:
-
Invalidate any existing session identifiers prior to authorizing a new user session
-
Regenerate the session ID after any privilege level change within the associated user session
The most common scenario where the Session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state.
How Waratek’s Protection Works
Waratek offers protection against Session Fixation attacks via the ARMR http rule using the following declarations
request()
authenticate(user)
protect(http-session: regenerate-id)
This rule hooks into the session authentication mechanism of the Servlet API and monitors user authentication processes. When a user successfully authenticates then the Waratek agent regenerates the Session ID of the user’s HTTP Session. This proactive security control remediates the vulnerability and eliminates the attack surface for Session Fixation attacks. Because no Session Fixation attacks are possible, this rule does not log any security events for attacks.
Following is a high-level description of the Session ID regeneration workflow that Waratek performs:
-
User enters correct credentials.
-
System successfully authenticates the user.
-
Existing HTTP session content is moved to temporary cache.
-
Existing HTTP session is invalidated (HttpSession.invalidate()).
-
A new HTTP session is created for the user.
-
The previously cached session data is restored into the newly created HTTP session.
-
The user goes to a successful login landing page using a new Session ID.
Protective Action
The Session Fixation rule is a proactive rule. It is triggered proactively before a potential attack and eliminates the attack vector for Session Fixation.
Rule Applicability
The Session Fixation rule is applicable and can be safely enabled in web applications:
-
That use the Servlet API to handle HTTP requests, responses and session management.
-
Whose authentication management system sets authentication and identity information on every HTTP request.
-
Whose authentication mechanism sets the HttpServletRequest user Principal after authentication.
Users should not enable the Session Fixation rule in the following cases as it could either provide no protection or break the normal application functionality:
-
In the very rare case where the target web application depends on having the same HTTP Session ID before and after the user authentication.
-
If there is another security control in place that also regenerates the HTTP Session ID as it might cause conflicts.
Best Practices
Waratek recommends to also enable the XSS security rule in blocking mode to be protected against XSS attacks. Applications vulnerable to XSS attacks are still vulnerable to Session Fixation or Session Hijacking attacks even if the Session Fixation rule is enabled.