What is a session in web development? In web development, a session is a token that is used to tie web requests to user identity.

The session lifecycle are on four phases

Creation phase A session is created when a user logins to the web application, this marks the beginning of the user interaction with the application. The process involved

The trigger: when a user logs in to the application it triggers the creation phase of session management Token generation: A unique cryptographic string is generated by the server to serve as the session ID for user Storage: session are stored in memory, a database or cache Transmission: sessions are transmitted through cookies. Use HTTP-only to avoid the use of XSS to steal cookies. Validation phase The browser automatically attaches the session cookie to each request. The server extracts the ID and compares it against its internal storage.

The following are criteria for the session ID to be validated:

The session must exist in the record The session hasn't expired ye Rotation phase Rotation is the practice of replacing an existing Session ID with a new one while maintaining the same session data. It is a vital defense against an attacker tricking a user into using a known ID

Moment for rotation

Post login: immediately after the user logins the user should be given a new session ID Periodic: in order to reduce the risk of stoked ID session cookies have an X time to be replaced with a new session but the data must be retained during replacement. Invalidation

The session must be terminated, which means all associated data with the session ID is removed from the server.

Invalidation occurs

Explicitly: when the user logs out the server must revoke the session from it storage rather than relying on the client side Implicitly: when there is no request for an X amount of time or the expiration time is up. Stateful Cookies Vs JWT In a stateful Cookie architecture the servers hold the user data which is referred to as the source of truth while the client holds the session ID of the user also known as the reference ID. When a request is made the client side sends the session ID along with the request and with the session ID the server accesses that user data.

The session ID is generated and stored alongside user data either in the cache memory or database, while the reference ID is seen in the set-cookie HTTP header.

Characteristics of stateful Cookie

Application can intercept, modify or invalidate session with client cooperation Server can easily revoke session ID by simply deleting it from its storage Every web server must access the same storage space tis makes it harder to scale the application In JSON Web Token(JWT)

Modern day web consists of many features that may or may not have restrictions, JWT is a way of keeping track of which feature users are authorised to access.

A typical JWT consist of:

Header: this contains metadata information about the token l, such as the algorithm used, type of token Payload: this is the main part of the token it contains the claims of the token, such as Issuer (iss) Subject(sub) Audience (aud) Expiry (exp) Issued at(iat) Sample payload

{

"sub": "1bfee8d8-98b6-4314-a9ae-fb55c4c48845",

"email": "divine@divosec.org",

"name": "Devine",

"role": "ADMIN",

"iat": 3621684279,

"exp": 3621747384

}

Signature: Although the payload is the main part of the JWT, the security of JWT relies on the signature by preventing token tampering and ensuring data integrity. The signature is created from the encoded header, encoded payload, a secret and a cryptographic algorithm. Because JWT payload can be easily decided you should never store sensitive information in the token.

Session management Failure Logout doesn't invalidate JWT Assumption: Logging out invalidates the JWT, ending the session.

Reality: JWT remains valid until expiration, allowing unauthorized access.

Attack: Attacker steals JWT, logs out user, and uses the token to access protected routes.

Root cause: JWT is stateless; server doesn't track valid tokens.

Fix:

Implement token revocation (e.g., blacklist) on logout.

Use short-lived tokens with a refresh mechanism.

Store JWT in HttpOnly cookies for added security.

2. Session persists after password reset

Assumption: Password reset invalidates all active sessions.

Reality: Session remains active, allowing unauthorized access.

Attack: Attacker compromises account, changes password, but still accesses account via old session.

Root cause: Session not tied to password hash or updated on password change.

Fix:

Invalidate all sessions on password reset.

Update session identifiers and re-authenticate users.

Notify users of password change via email or SMS.

3. Refresh token replay

Assumption: Refresh tokens are secure and can't be reused.

Reality: Stolen refresh tokens can be replayed, generating new access tokens.

Attack: Attacker steals refresh token, uses it to obtain new access tokens.

Root cause: Lack of refresh token rotation or one-time use enforcement.

Fix:

Implement refresh token rotation

Invalidate previous token on reuse.

Use secure storage for refresh tokens.

4. Multiple active sessions abuse

Assumption: Users have a single active session.

Reality: Multiple sessions allow attackers to exploit concurrent access.

Attack: Attacker uses stolen credentials to open multiple sessions, bypassing security checks.

Root cause: Lack of session limit or monitoring.

Fix:

Limit concurrent sessions per user.

Implement session monitoring and termination.

Use device fingerprinting to track sessions.

5. Session fixation

Assumption: Session IDs are secure and can't be manipulated.

Reality: Attacker fixes session ID, hijacking user's session.

Attack: Attacker sets victim's session ID, accesses account after login.

Root cause: Session ID not regenerated on login or privilege change.

Fix:

Regenerate session ID on login, privilege change, or periodically.

Use secure session management practices (e.g., HttpOnly, Secure flags).

Implement session timeouts and idle timeouts.

Real world Case study CVS Health (2021)

Cause: Misconfigured cloud-hosted databases allowed attackers to access log files containing sensitive search metadata and session IDs.

Attacker Mindset: Exploit a lack of encryption in logging systems to harvest session tokens passively without interacting with the primary application.

Mitigation:

Implement strict access controls on cloud-hosted logs.

Ensure all logs containing sensitive session data are encrypted and isolated from public-facing environments.

GitLab (2019)

Cause: A session management vulnerability exposed user session tokens through improper handling of session state.

Attacker Mindset: Target high-value developer accounts to gain access to sensitive private code repositories.

Mitigation:

Use robust web frameworks for session management rather than custom implementations.

Perform regular security audits to ensure tokens are not leaked in headers or URLs.

Slack (2019)

Cause: A vulnerability allowed attackers to force users into fake session redirects, effectively stealing session cookies.

Attacker Mindset: Use social engineering and phishing to trick authenticated users into clicking links that exfiltrate their active session data.

Mitigation:

Implement Session ID Regeneration immediately after any sensitive action or redirect.

Apply HttpOnly and Secure cookie attributes to prevent client-side script access

Pegasus Airlines (2022)

Cause: A misconfiguration of an AWS S3 bucket exposed 6.5 terabytes of data, including sensitive flight charts and crew credentials that could be used for session impersonation.

Attacker Mindset: Scan for "low-hanging fruit" like open storage buckets to find credentials or session tokens that grant wide-scale access to internal systems.

Mitigation:

Enforce Multi-Factor Authentication (MFA) for all internal and administrative access to mitigate the impact of stolen session data.

Continuously monitor cloud configurations for public exposure.

Cisco (2022)

Cause: An attacker used voice phishing (vishing) to compromise an employee's credentials, which were then synchronized in a browser, allowing the attacker to bypass MFA by stealing the session cookies.

Attacker Mindset: Bypass MFA by targeting session tokens directly rather than passwords, as servers often treat a valid token as absolute proof of identity.

Mitigation:

Bind session tokens to specific user attributes like IP address or device fingerprints to block replay attempts.

Shorten session lifetimes and set aggressive inactivity timeouts.