Session Fixation vulnerability CWE-384 needs to be addressed
Description
Acceptance / Success Criteria
Activity
Christian Pape October 15, 2024 at 12:56 PM
Yes and it is tested, that the session ids are different. Otherwise the builds would fail.
Veena Kannan October 15, 2024 at 12:54 PM
I am making this security-NA since we already do the mitigation.
Christian Pape October 15, 2024 at 6:46 AM
We had this issue before with NMS-15310 The session id will be regenerated on login. The behavior is also tested in the smoke test IndexPageIT.testSessionFixation_NMS15310(). So I think we have nothing more to do here.
Nishtha Kaura October 8, 2024 at 1:51 PM
Information Security Review
Since this is not a CVSS but a CWE (software weakness with no score assigned) the customer has identified, it is important that we validate or check if there is a mitigation in place for this CWE.
I would generally rate this as High severity considering the session takeover possibility with this CWE.
Session fixation vulnerability may allow a remote, unauthenticated attacker the opportunity to steal authenticated sessions or infer the session identifier of other users and possibly usurp their session. Such a scenario is commonly observed when:
A web application authenticates a user without first invalidating the existing session, thereby continuing to use the session already associated with the user.
An attacker is able to force a known session identifier on a user so that, once the user authenticates, the attacker has access to the authenticated session.
The application or container uses predictable session identifiers.
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to associate, and possibly authenticate, against the server using that session identifier, giving the attacker access to the user's account through the active session.
Common Consequences
Scope | Impact | Likelihood |
|---|---|---|
Access Control | Technical Impact: Gain Privileges or Assume Identity | 0.8 |
Potential Mitigations
Invalidate any existing session identifiers prior to authorizing a new user session. |
For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again. |
Details
Assignee
Christian PapeChristian PapeReporter
Veena KannanVeena KannanLabels
HB Grooming Date
Sep 26, 2024HB Backlog Status
Refined BacklogSprint
NonePriority
High
Details
Details
Assignee
Christian PapeReporter
Veena KannanLabels
HB Grooming Date
HB Backlog Status
Sprint
Priority
High
PagerDuty
PagerDuty Incident
PagerDuty
PagerDuty Incident
PagerDuty
Web Inspect tool run by poweredby customer has identified CWE-384 session fixation vulnerablitiy on PoweredBy-2024. This needs to be addressed.
Details from the customer:
WebInspect has found a session fixation vulnerability on the site. Session fixation allows an attacker to impersonate a user by abusing an authenticated session ID (SID). This attack can occur when a web application: Fails to supply a new, unique SID to a user following a successful authenticationAllows a user to provide the SID to be used after authenticating In a session fixation attack, the attacker creates or obtains a valid session identifier and causes the user to provide authentication credentials to the application along with the session identifier. If the application fails to renew this SID after the user logs in, the attacker can use the previously obtained/created value of this SID to clone the authenticated session. The attacker can continue to impersonate the victim user until the SID expires. The need to brute-force or intercept the SID is eliminated. An example of this situation is a login page that includes the SID as a URL parameter. An attacker could execute a session fixation attack by crafting a URL to the vulnerable login page and sending it to a user. Contained in the attack URL is a SID known to the attacker. Once the user logs in, the attacker can use this SID, which is now associated with an authenticated session, to impersonate the victim user.
The best way to prevent session fixation attacks is to renew the session ID when a user logs in. This fix can be done at the code level or framework level, depending on where the session management functionality is implemented. Example 1: the following PHP code changes the session ID after users log in successfully: If ($authenication_successful) { $_session[“authenticated”] = true; Session_regenerate_id(); } Example 2: When deploying web applications to Apache Tomcat, care must be taken to set the “changeSessionIdOnAuthentication” attribute in context.xml to true. Additionally, session IDs should be sufficiently random and should be invalidated at logout.