Sean Lee

Posted on Mar 12

TryHackMe: Session Management

#cybersecurity #learning #productivity #tutorial

Session Management

Why is Session Management Important?

HTTP is a stateless protocol, meaning it does not inherently track users between requests. Instead of sending a username and password with every request, sessions are used to maintain user authentication. Proper session management ensures that sessions remain secure throughout their lifecycle.

Session Management Lifecycle

1. Session Creation

A session can be created before authentication (to track user actions) or after login (for authenticated sessions).
Upon successful authentication, a session value (often a session ID) is generated.
Security Considerations:
- Ensure session values are random and unpredictable to prevent attacks like session fixation.
- Secure session storage mechanisms.

2. Session Tracking

The session value is submitted with each request.
The server retrieves the session value, identifies the user, and grants appropriate permissions.
Security Risks:
- Improper session tracking can lead to session hijacking or session impersonation.

3. Session Expiry

Because HTTP is stateless, web applications can't detect when a user stops using the application (e.g., closing a tab).
To prevent old session reuse, sessions should have a lifetime.
If an expired session is used, the server should reject it and require re-authentication.
Security Risks:
- Long session lifetimes increase the risk of session hijacking.
- Lack of expiration policies can lead to persistent unauthorized access.

4. Session Termination

Unlike expiry, session termination happens when a user actively logs out.
The session should be immediately invalidated to prevent unauthorized reuse.
Security Risks:
- If termination is not properly handled, attackers could maintain persistent access.

Cookie-Based vs. Token-Based Session Management

Cookie-Based Session Management

Traditional method of handling sessions.
The Set-Cookie header is sent from the server, and the browser automatically stores the session ID.
Example: Set-Cookie: session=12345;
The browser automatically sends the cookie in subsequent requests.

Key Cookie Attributes

Secure – Ensures the cookie is only sent over HTTPS.
HttpOnly – Prevents JavaScript from accessing the cookie, reducing XSS risks.
Expire – Defines the lifespan of the cookie.
SameSite – Helps mitigate CSRF attacks by controlling cross-site cookie transmission.

Pros & Cons of Cookie-Based Authentication

Pros	Cons
Automatically sent with requests, requiring no extra JavaScript	Vulnerable to CSRF attacks if SameSite is not properly configured
Built-in browser security features (e.g., Secure, HttpOnly)	Limited flexibility in decentralized applications
Easy to manage session expiration & termination	May be susceptible to cookie theft via XSS if HttpOnly is not set

Token-Based Session Management

A modern approach where tokens (e.g., JWTs) are stored in LocalStorage or SessionStorage instead of cookies.
Tokens must be manually added to requests, typically in an Authorization: Bearer header.

How It Works

The user logs in, and the server returns a token.
The token is stored in LocalStorage using JavaScript.
On each request, JavaScript retrieves the token and attaches it to the header.
Authorization: Bearer <JWT_TOKEN>

Pros & Cons of Token-Based Authentication

Pros	Cons
More secure against CSRF attacks (tokens are not sent automatically)	Requires manual implementation using JavaScript
Suitable for decentralized applications (e.g., microservices, APIs)	XSS attacks can steal tokens if LocalStorage is compromised
Tokens can contain user info, reducing the need for database lookups	No built-in expiration/termination handling like cookies

Choosing Between Cookies & Tokens

Use cookies for traditional web applications where browser security features (e.g., SameSite, Secure, HttpOnly) help protect against attacks.
Use tokens for API-based and decentralized applications, especially where multiple domains are involved.

Both methods have trade-offs, and the best choice depends on security needs and application architecture.

Securing the Session lifecycle

Weak Session Values

try decoding using base64

Controllable Session Values

In certain tokens, such as JWTs, all the relevant information to both create and verify the JWT's validity is provided. If security measures are not enforced, such as verifying the token's signature or ensuring that the signature itself was created securely, a threat actor would be able to generate their own token.

Session Fixation

Websites that creates a session before authentication are vulnerable to session fixation
If your session value is not adequately rotated once you authenticate, a suitably positioned threat actor could record it when you are still unauthenticated and wait for you to authenticate to gain access to your session

Insecure Session Transmission

Modern systems often use separate authentication servers and application servers, like in Single Sign-On (SSO).
After logging in, session data is transferred via the browser to the application server, but this process can be vulnerable.
If an attacker manipulates the redirect URL after authentication, they could intercept and hijack your session.

A real testimony can be read here.

Authentication Bypass

Authorisation bypasses occur when there aren't sufficient checks being performed on whether a user is allowed to perform the action they requested.
In essence, this fails to track the user's session and its associated rights correctly
There are 2 types of authentication bypass:
- Vertical bypass - You can perform an action that is reserved for a more privileged user
- Horizontal bypass - You can perform an action you are allowed to perform, but on a dataset that you should not be allowed to perform the action on

Enumerate Insecure Session Management

Step 1: Initial Observation

Visiting the application reveals no cookies or tokens for unauthenticated users.
Sign-up options:
- Student (open registration)
- Lecturer (requires verification code)

Step 2: Creating an Account

Registering as a student successfully creates an account.
Redirects back to login.

Step 3: Logging In & Tracking Sessions

Cookies used for session tracking.
HTTPOnly flag is set.
Issue: Expiry time is immediately reset upon each request.

After login, dashboard features become available.

Step 4: Testing Session Expiry

Removing the session cookie should invalidate access.
Issue: Requests still work partially without a cookie.

Some functionality remains, but sensitive data is hidden.

Step 5: Testing Logout & Termination

Clicking logout removes the session client-side.
Issue: Old session still works but causes 500 Internal Server Error.

Step 6: Testing Role Escalation via LocalStorage

User roles are stored in LocalStorage and editable.
Modifying userRole: "student" → "lecturer" does not give full access.
Changing user: 2 → 3 also fails.

Some UI elements appear, but no extra privileges.

Final Observations & Vulnerabilities

Lifecycle Phase	Observation
Session Creation	Uses both cookies & tokens for tracking.
	Each login generates a new session ID.
	Session ID appears sufficiently random.
Session Tracking	Cookies are sent with each request.
	Some API calls work without a session.
	Token values in LocalStorage affect UI visibility.
Session Expiry	Client-side & server-side expiry mismatch.
	Sessions last excessively long.
Session Termination	Logout removes session locally but not server-side.
	Reusing an old session causes server errors.

Reported Vulnerabilities

✅ Confirmed Issues:

Excessive session lifetime → Risk of session hijacking.
Inconsistent session termination → Old sessions may remain active.

🔍 Requires Further Testing:

API access controls → Are restricted endpoints properly protected?
Logging mechanisms → Are unauthorized actions tracked?

Next Steps

API Testing → Attempt unauthorized API requests via Burp Suite/Postman.
Session Fixation Test → Can we reuse or set another user’s session?
Cross-Site Scripting (XSS) & Token Hijacking → Are tokens stealable?

DEV Community