Broken Authentication & Session Management 101 – OWASP10

Hi there and welcome to another OWASP top 10 related blog post. This week we will have a look at how web application sessions are handled and what might happen if these sessions are incorrectly configured and managed.

Whenever you log in at your favourite web application, you identify yourself and by doing so, you establish a new session. The session saves you from entering your credentials every time you have to perform a restricted action. Sessions are identifiable by unique identifiers and this unique identifier is a long, one-time used and difficult to reproduce value that is only transmitted over encrypted channels and is not displayed in the URL of the application. After you log out, the session closes. The unique value of the session identifier is discarded and this randomly generated string will not be used again.

Unfortunately, the high-level situation described above is not common practice within a staggering amount of web applications, which could leave sensitive customer information up for malicious actors to grab. There is a reason why broken authentication and session management can be found at the second place in the OWASP top 10.

Session fixation is one of the most common attack vectors in regards to broken authentication and session management. It means that an attacker is able to control your session. When an attacker gets a hold of your valid session ID, it is possible for the attacker to hijack the victim’s identity. For this attack to be successful, the attacker is in a situation to determine the used session ID by the victim before it is actually used to establish a session with the victim. One of the most dangerous mistakes that could be made by a developer in regards to authentication and session management is to get the value of the Session ID through the URL. This insecure property will aid attackers in setting up successful session fixation attacks, as can be seen below.

Let´s take a look at the following URL:

https://www.examplesite.com/login.php?JSESSIONID=CCFD79AD0A79536E7F7F90D2E20E0326

As can be seen above, examplesite.com displays a JSESSIONID value in the URL. In certain cases the displayed value will be the value used for the session after successfully logging in. An attacker is able to verify this by specifying an arbitrary value for JSESSIONID before logging in. The web application is vulnerable for session fixation attacks when the used JSESSIONID value is the same as the attacker-supplied value after logging in.

Session hijacking can be done through conventional cross-site scripting attacks in combination with insecure cookie settings, but this not an inherent flaw present within the way the application manages sessions. Session fixation however, is based on the fact that the attacker is able to determine the session ID before the victim uses said session ID. By forcing the victim to use the predetermined session ID, a session is established that will be identified by a session ID that is known by the attacker.

Session fixation can be achieved by:

The attacker creating a new session ID by establishing a connection with the targeted web application

1. The attacker ‘forces’ the victim to use this session ID by sending the victim the URL containing the attacker-supplied Session ID value.
2. The victim logs in while using the attacker-supplied session ID
3. The attacker has now access to the victim’s authenticated session due to the valid credentials that were supplied by the victim within session the attacker set up beforehand.

The attacker is now able to gain access to the victim’s session and personal information, since authentication took place during the log in attempt from the victim. This successful login attempt is registered within the session, thus making it unnecessary for the attacker to log in twice. The attacker can now copy the supplied JSESSIONID value into the used session-cookie to gain access to the victim’s session.

What countermeasures could examplesite.com take to prevent the attack vector described above from happening again? Well, for starters it is highly recommended to remove all JSESSIONID values from used URLs within the application. Another way that this attack could have been prevented is to not simultaneously allow two different IP addresses to use the same JSESSIONID value. And what about properly validating JSESSIONID’s by confirming whether they have already been used to establish previous sessions or destroying and recreating a new session after sensitive operations such as processing login credentials?

In order to detect issues with the authentication and session management processes within your application, we recommend performing annual in-dept penetration testing, a process that Outpost24 is gladly to support with. Please contact your local Outpost24 office for more information about our penetration testing services and continuous web application monitoring SWAT or request a consultation.