During software development or testing, the eyes are usually in the authentication functions as these provide the gate going inside the application. Password policies (complexity, length, history, min/max password age, and lockout) are defined. A not-so-new cybersecurity movement promotes passwordless authentication and a single-sign-on (SSO) or federated authentication shift.

But complex authentication mechanisms don’t automatically provide consistent security if the other security functionalities are not fully observed. One of the significant security concerns that are often not focused on is session management. Various cybersecurity literature explains that exploits on security management may not be as apparent as exploits on authentication due to logs and threshold policies. Maintaining access or establishing a dwell time is more manageable in session management exploits as well. These reasons make session management attacks more dangerous due to the severity and (sometimes, lack of) priority.

Session Management = Confusion + Diffusion

Similar to encryption concepts, the strength of the session IDs relies on confusion and diffusion. It means that the more random, dispersed, and more prolonged the length of a session ID, the more secure it is. One of the tools you can use to check the quality of the session ID is the Sequencer from Burp Suite.  It will provide you with the Character-level or Bit-level analysis details of the web application’s session ID.

Example: Extremely Poor vs. Excellent Result 

We have used the DVWA Weak Session ID example to demonstrate how it determines that the session ID is weak or strong to test the Sequencer functionality. Usually, we wait for at least a thousand sample tokens to analyze, and we can copy and save the tokens so that the developers have a reference if they are required to remediate it.

In the example, the session ID with a poor result only increments the following session ID by one, while the session ID with an excellent product shows no traces of patterns.

• 

• 

• 

• 

• 

So, what does this tell us? If the session ID is predictable, we can analyze its patterns and determine which ones are used for authentication or authorization purposes.

Proof-of-Concept: Getting Authenticated by Exploiting Weak Session ID’s

A proof-of-concept (POC) example comes from a login function in WebGoat. We didn’t log in using valid credentials. Instead, we forced the server to generate a cookie for the client and sent it to the sequencer. The session IDs were analyzed and found to be poor. When we copied it to a text editor, we found out that the increment of the session ID is just 1. There are some gaps, however, on some session IDs, by 2. We can use the gaps as possible “reserved” session IDs for legitimate users. So we test if it is possible.

• 

• 

Based on the analysis, we found out that it is true. We arranged the results based on length, and the one that differs is the legitimate one.

• 

• 

• 

• 

What to do now?

One of the things that security teams do in the early stages of the secure SDLC is determining the attack surface and identity ways to lessen it. To reiterate the point in the introduction, the bulk of planning and implementation of controls focus on initial login/authentication. However, attackers concede that with the stringent rules and policies on login pages, they opt to look for other places to enter. In analogy, if you cannot enter through the door, try the window.

Proper planning and enforcing security best practices on session management will lessen the inherent risk by a significant value. The OWASP Session Management Cheat Sheet provides all the necessary information to baseline and hardens any application’s session management functionality.