Session Fixation is a web attack technique. An attacker tricked a user into using a special session ID. After a user logs in to the web application with the given session ID, the attacker uses this valid session ID to gain access to the user’s account.
1. Session Identifiers: Pros and cons
Session identifiers (session IDs) are used to authenticate users within web applications. This technology has both advantages and disadvantages.
Pros: Without session IDs, users will have to log in to web applications more often than once per session.
Defect:
- Session ID has the same weaknesses as passwords: If it is available it is possible to gain access to the account, which is the platform to conduct further attacks, favoring privilege escalation .
- Attackers attempting to obtain session IDs of whatever form they may execute may use social engineering, phishing, and other means. There are several methods of sessions related to sessions. With session hijacking is getting the session ID from the logged in user (Example: using man-in-the-middle ). But with session fixation, things are reversed: The victim gets the session ID and is tricked into logging in with this session ID, which allows the attacker to take over the user’s session.
2. How Session Fixation attack works
A typical session fixation attack looks like this:
- The attacker visits the login page and receives the session ID generated by the web application. This step can be omitted if the application accepts any session ID.
- The attacker uses a technique like CRLF Injection , man-in-the-middle attack , social engineering … and causes the victim to use the session ID provided. This depends on how the web application handles session IDs. It can be as simple as submitting a malicious URL or more complicated than creating a fake website.
- The victim visits the login page and logs into the app. After authenticating, the web application identifies the user via session ID.
- The attacker uses the session ID code to access the web application, capture the session, and impersonate the victim. Subsequent actions depend on the attacker and the web application functionality.
The exact phases of an attack and its difficulty depend on a few factors. Much of it is how the developer handles session IDs. If we accept the session ID from the URL (Via a GET request) then the attack is very simple. If accepting the session ID from the POST request, an attacker could have created a fake website. It is more complicated (but not impossible) if session IDs are only accepted from cookies. In that case, the attacker has to use some intermediate techniques (Example: Cross-site Scripting (XSS) ).
3. Measures against Session Fixation
The main cause of session fixation is the lack of security of the web application and poor programming methods related to session management:
- Worst case scenario, developer doesn’t validate session ID. Hence, any string (or just matching a certain format) can be supplied as the session ID. This makes session fixation attacks too easy.
- Usually, developers only create session ID before a user logs in and never change it. This is a typical cause of session fixation attacks.
- If the developer accepts the session ID from the GET or POST request, they make it easier for the attacker to force a session ID for the user.
There are several measures to avoid session fixation:
- The most effective method is to change the session ID as soon as the user logs on. This eliminates most of the session fixation vulnerabilities.
- An additional countermeasure is to change the session ID if there is a suspicion of potential misconduct. Example: Can check if the IP address or
user-agentof the client has changed and if so, provide a new session ID. - It is recommended to disable session ID after the timeout expires. This leaves an attacker with no chance of taking advantage of the fixed session ID. Example: After 10 minutes of inactivity will automatically log out.
- Session ID can be changed with every user action. This is a strong measure, however, not necessary and has the potential to affect the user experience and website performance (It may not be possible when using an applet). To minimize the impact, it is possible to change session ID before every important user action on the website.
- Remember to use session cookie for session management and do not accept session ID from HTTP request and HTTP header.
- HTTPS ( HSTS ), anti-CSRF tokens and matching cookie flags (
Secure, SameSite) can also be helpful in avoiding session fixation. - Another countermeasure is to store user-specific attributes in the session, verify them every time there is a request, and deny access if the information doesn’t match. Those attributes can be the IP address or the user agent.
Web vulnerability scanner can be used to check if your website or web application has any session fixation vulnerability, but session fixation is similar to logical vulnerability and is difficult to detect automatically.
Source: