See for yourself – run a scan on your code right now

At a basic level, understanding session management is straightforward. When a user authenticates to a server, it creates and sends a token to the browser so that the browser can share the authentication information, making future access easier. However, managing session expiration and ensuring that the session token is valid for the requestor becomes challenging. Further, as users increasingly adopt the application, horizontal scaling impacts the load balancer’s ability to appropriately route traffic and maintain service speed. 

For developers, understanding secure session management’s impact on security and steps to mitigate risks arising from improper session management is critical to the application’s security. 

​​Understanding session management security

Session management refers to the process of destroying session tokens for the following events:

  • User manual log out: user interface controls that allow people to log out
  • Direct session termination: administrator-forced logout 
  • Session timeout: automatic logout after a period of inactivity

A simple session management flow looks like this:

  • User authenticates to the application using credentials
  • Server receives the request, creating a session
  • Server responds to request by sending the application an access token
  • Application uses the access token for subsequent requests to the server
  • Server checks and validates the access token when it receives the request so the user can perform authorized actions
  • Process repeats until the user logs out or the session expires. 
  • Access tokens are deleted.

Since a session token uniquely identifies a user’s session, each request and response associated with one allows the application to connect a specific user with the client using it. Without correct session management, attackers can exploit an authenticated user session to undermine the applications security. 

Attacks Arising from Broken Authentication and Session Management Vulnerabilities

Identification and Authentication Failures, formerly Broken Authentication, is one of the OWASP Top 10 application vulnerability categories. Within this vulnerability category, attackers can exploit a session management vulnerability during the following attack types.

Session ID Hijacking

Attackers can steal or predict a valid session token by performing a standard request to observe a session token that is unencrypted, easily decrypted, or guessable. For example, some implementations include easily guessable information in their session ID, like:

  • Username
  • Timestamps
  • Client IP address

Attackers that understand the session ID’s structure can implement a brute force technique to generate and test various session ID values until they gain unauthorized access to the application. 

Cross-Site Scripting (XSS)

Applications may use cookies to store the session ID. By identifying a vulnerable input in the web application, they can inject a malicious cookie stealer script, pointing to a web-server hosted file that can be resolved outside the local network.  With access to the session token, they can hijack the session ID to compromise the application’s sensitive data. 

Session Fixation Attacks

A web application server is often a “stateful server,” meaning that it retains persistent information about the user’s session. In a session fixation attack, the threat actors use social engineering to trick the user into authenticating into the application. Unlike Session Hijacking, the attackers steal the valid session ID during the victim’s login rather than after. The techniques used to execute the attack depend on the application’s implementation of session tokens, including:

  • Token in URL: The malicious actor sends a hyperlink containing a Session ID to the victim who then accesses the site through the malicious link. 
  • Hidden in a form field: The attackers trick the victim into authenticating into the application using a login form that they developed.
  • Cookie: Using the function document.cookie, the victim’s browser executes a command that fixes values inside the cookie to maintain an open session between the client and application. 

Secure Coding Session Management Checklist

When building your application, you should work to make sure that:

  • The application only recognizes the server’s or framework’s session management identifiers as valid. 
  • A trusted server-side system always creates session identifiers.
  • Session management controls create random identifiers using vetted algorithms. 
  • Cookies containing authenticated session identifiers have a restricted value for their domain and path. 
  • For sensitive server-side operations, the application supplements standard session management with per-session strong random tokens.
  • The logout function fully terminates the associated session/connection. 
  • Logout function is available from all authorization-protected pages. 
  • Session timeout period is appropriately short based on risk and business function requirements.
  • The application disallows persistent logins and periodically terminates sessions. 
  • The application closes sessions established before login and establishes a new session after a successful login. 
  • The application does not explode session identifiers in URLs, error messages, or logs. 
  • The application periodically deactivates the session identifiers and generates a new one. 
  • The application generates a new session identifier on an re-authentication. 
  • The application generates a new session identifier if connection changes from HTTP to HTTPS.
  • The application consistently uses HTTPS rather than changing between secure and insecure communications.
  • The cookies’ “secure” attribute is set for those transmitted over TLS connections. 
  • Use HttpOnly cookie attribute, unless the application specifically requires client-side scripts to read or set a cookie’s value. 

Qwiet AI: Visibility into Source Code Security

With Qwiet AI, you can scan millions of lines of code in minutes for visibility into all components, dependencies, and reachable vulnerabilities. Our platform quickly returns accurate and detailed findings while significantly reducing false positives. With our Code Property Graph (CPG), you gain a holistic view of your code, including data flows across the application, to quickly determine reachability and risk impact.

We also deliver a fully managed application security service tailored specifically to your organization’s unique needs. Our deep expertise in application security combined with seamless CI/CD integration ensures you’re not just deploying a solution but establishing a robust partnership. We delve deep into the unique business logic that drives your application. Our specialized focus on these flaws ensures that every facet of your application’s logic is meticulously tested and secured. 

Take our platform for a free spin to see how Qwiet AI can help you secure your application today. 

 

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit: www.shiftleft.io.

Share

See for yourself – run a scan on your code right now