Understanding session fixation Session fixation is a security vulnerability that occurs when an attacker forces a legitimate user to utilize a predetermined session identifier (session ID). This allows the attacker to hijack the session and impersonate the victim once they authenticate with the web application.

The vulnerability arises when an application fails to properly regenerate a new session ID upon user authentication, thereby continuing to use the preexisting session ID provided by the attacker. Common attack vectors include injecting the session ID through URL parameters, cookies, or hidden form fields.

Such a misconfiguration was identified during one of the previous penetration tests conducted. Additionally, it was noted that after logging out - just as during login - the value of the session cookie did not change. As a result, in the event of a session cookie compromise, the user remains permanently exposed to account takeover when using the same browser. If the attacker possesses the compromised session cookie, they need only wait for the victim to log in again and authenticate the already compromised session identifier. Exploiting improper file validation An attacker can upload a malicious JSP file to the server due to weak file validation. This ZIP file contains a web page structure that is converted into a JSP file. The attacker places harmful code in the file, such as in index.html. After the ZIP file is uploaded and extracted, the attacker can access the path to the JSP file and execute any system commands on the server using the permissions of the application user (e.g., Tomcat).
Attack vectors Several techniques can be used to execute a session fixation attack, depending on how the web application manages session tokens. Below are some of the most common methods:

1. Session token in the URL parameter
The attacker sends the session ID to the victim via a malicious URL, and the victim accesses the site by clicking on the link containing the session ID.

2. Session token in a hidden form field
In this approach, the victim is deceived into authenticating on a target web server through a login form crafted by the attacker. This form could be hosted on a malicious web server or embedded in an HTML-formatted email.

3. Session ID in a cookie
The attacker can manipulate the session ID stored in the victim's browser cookies.

4. Client-Side scripting
Many browsers support client-side scripting, which allows attackers to exploit code injection vulnerabilities like Cross-Site Scripting (XSS). Through this attack, the attacker can insert malicious code into a hyperlink sent to the victim. This code can then manipulate the browser to fix the session ID within the victim's cookies using the document.cookie function, which allows the attacker to control the session token.

5. META tag
While this method is also a form of code injection, it differs from XSS because it cannot easily be disabled in modern browsers. The attack works by using the META tag to instruct the browser to execute specific actions, including setting the session ID, without being blocked by script execution filters.

6. HTTP response header

This technique exploits the server’s response by inserting the session ID into the Set-Cookie HTTP header. The attacker can manipulate the response to set the session ID in the victim’s browser cookie, allowing them to hijack the session.
Exploitation during real pentest Below is an example of a login request sent to the application with the modified cookie value:
In response, the application neither validates nor changes the cookie set in the request and redirects to the 'My Account' page:
The following request retrieves user data from the 'My Account' section:
The server response confirms the ability to retrieve content that is only available to authenticated users:
RECCOMENDATIONSDo not accept user-generated cookie values The application should never accept or rely on cookie values generated by users, as they can be tampered with or manipulated by attackers. Instead, cookies should be generated and managed securely by the server, ensuring that their integrity is maintained. User-controlled session cookies should not be trusted for session management or authentication. Regenerate session IDs after login and logout The application should always regenerate the session ID upon successful login and logout. This helps prevent session fixation attacks, where an attacker could exploit a pre-existing session ID to hijack a user's session. By regenerating the session ID after each authentication event, the application ensures that each session is unique and cannot be reused maliciously. Invalidate previous session identifiers When a new session ID is generated (e.g., after login or logout), the old session ID should be invalidated immediately. This prevents session hijacking or fixation by attackers who might attempt to use an old session ID to authenticate themselves. Ensuring that old session IDs are invalidated upon login or logout enhances the security of session management.


#Cybersecurity #WebSecurity #SessionFixation #PenTesting #SecureApplications