06 Session Management Security Assessment

Mission Overview

Welcome to Lab 06 — Session Management Security Assessment.

In Lab 05, you assessed how the application authenticates a user.

Now you will assess what happens after authentication succeeds.

A web application may correctly verify a username, password, and MFA challenge, yet still expose serious risk if the authenticated session is weakly created, insufficiently protected, not rotated, not expired, or not invalidated correctly.

Session management answers a critical question:

“Once the application knows who you are, how securely does it maintain that identity?”

Mission Goal: Assess the complete lifecycle of authenticated session state in an authorized training application, including session creation, cookie protections, session rotation, logout invalidation, timeouts, concurrent sessions, credential changes, recovery events, and remember-me behavior.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Session Management Security
Secondary Skill	Authenticated State Analysis
Environment	GoHackersCloud Web Pentesting Lab
Testing Mode	Controlled Session Lifecycle Assessment
Primary Outcome	Session Management Security Report
Safety Level	Authorized Training Accounts Only

Learning Objectives

By completing this lab, you will be able to:

identify session-related cookies and tokens
distinguish pre-authentication and authenticated sessions
observe session creation
assess session identifier rotation
review cookie security attributes
assess logout invalidation
distinguish browser state from server-side state
assess idle-session timeout
assess absolute-session lifetime
evaluate concurrent sessions
observe password-change effects on sessions
observe password-reset effects on sessions
assess remember-me behavior
document MFA-related session transitions
identify session-management weaknesses
separate observations from validated findings
assign severity and confidence
create reproducible session evidence
produce a professional assessment report

Core Methodology

Use:

Create → Observe → Compare → Transition → Expire → Invalidate → Validate → Report

Expanded:

Anonymous Session
      │
      ▼
Observe Pre-Auth State
      │
      ▼
Authenticate
      │
      ▼
Observe Post-Auth State
      │
      ▼
Compare Session Identifiers
      │
      ▼
Review Cookie Controls
      │
      ▼
Test Session Lifecycle
      │
      ├── Logout
      ├── Idle Timeout
      ├── Absolute Timeout
      ├── Concurrent Sessions
      ├── Password Change
      ├── Password Reset
      └── Remember Me
      │
      ▼
Validate Server-Side State
      │
      ▼
Assess Impact
      │
      ▼
Evidence & Report

The core principle is:

A session is secure only when the server correctly creates, protects, rotates, expires, and invalidates authenticated state.

Part 1 — Confirm Scope

Record:

ASSESSMENT ID:
GHC-WEB-LAB06-001

APPLICATION:

BASE URL:

AUTHORIZED:
Yes

TEST ACCOUNTS:

ACCOUNT ROLES:

TEST WINDOW:

EXCLUDED SYSTEMS:

Use only lab accounts and lab sessions.

Part 2 — Create the Lab Workspace

Create:

Web-Pentesting-Labs/
└── Lab-06/
    ├── 01-Scope/
    ├── 02-Pre-Auth-Session/
    ├── 03-Post-Auth-Session/
    ├── 04-Cookies/
    ├── 05-Rotation/
    ├── 06-Logout/
    ├── 07-Idle-Timeout/
    ├── 08-Absolute-Timeout/
    ├── 09-Concurrent-Sessions/
    ├── 10-Password-Change/
    ├── 11-Password-Reset/
    ├── 12-MFA/
    ├── 13-Remember-Me/
    ├── 14-Evidence/
    ├── 15-Findings/
    └── 16-Report/

Part 3 — Identify Session Mechanisms

Review normal application traffic and identify values that appear to maintain state.

Examples may include:

session
sessionid
sid
auth
token
access_token
refresh_token
jwt
remember_me

Create:

SESSION MECHANISM PROFILE

Cookie / Token Name:

Location:
Cookie / Header / Client Storage / Other

Present Before Login:
Yes / No

Present After Login:
Yes / No

Changes During Login:
Yes / No / Unknown

Purpose:
Known / Suspected / Unknown

Part 4 — Distinguish Session Types

An application may maintain several kinds of state.

Anonymous Session

Used before login for preferences, shopping carts, or workflow state.

Authenticated Session

Represents an authenticated identity.

Pre-MFA Session

Represents partially authenticated state before MFA completion.

Remember-Me Session

Longer-lived state intended to reduce repeated authentication.

Do not assume every token has the same security significance.

Part 5 — Establish the Pre-Authentication Baseline

Open a new clean browser session.

Before logging in, record:

PRE-AUTH SESSION

Cookies:

Tokens:

Client Storage:

Session Identifier:

Protected Content Accessible:
No / Unexpected

Evidence ID:

Preserve the actual value only in restricted lab evidence if necessary.

In reports, redact reusable session secrets.

Part 6 — Authenticate Normally

Record:

AUTHENTICATION EVENT

User:

Role:

Login Time:

Login Endpoint:

Session Before Authentication:

Session After Authentication:

Redirect:

MFA:
Yes / No

Part 7 — Compare Pre-Auth and Post-Auth Sessions

Create:

Attribute	Pre-Auth	Post-Auth
Session ID
Cookie Name
Cookie Count
Authorization Token
Accessible State	Anonymous	Authenticated

This comparison is critical.

Ask:

Did the application replace or regenerate the session identifier when authentication succeeded?

Record:

SESSION ROTATION

Pre-Login Identifier:
Redacted fingerprint/value

Post-Login Identifier:
Redacted fingerprint/value

Changed:
Yes / No / Unknown

Authenticated State Established:
Yes

A session identifier that remains unchanged across an important authentication transition may require further assessment.

Do not immediately call it session fixation without validating the security impact.

Part 9 — Understand Session Fixation Conceptually

A session fixation weakness may exist when an attacker-controlled or predictable pre-authentication session can remain valid after a victim authenticates.

Conceptually:

Pre-Auth Session
      │
      ▼
Authentication
      │
      ▼
Same Session Identifier
      │
      ▼
Authenticated State

A safer design usually establishes a new authenticated session identifier at privilege-changing transitions.

In this lab, focus on the authorized lifecycle behavior rather than involving another real user.

Part 10 — Create the Rotation Register

Transition	Before	After	Rotated
Anonymous → Login
Login → MFA Complete
User → Higher Privilege	If applicable
Password Change

For session cookies, inspect:

Secure
HttpOnly
SameSite
Domain
Path
Expires
Max-Age

Create:

Cookie	Secure	HttpOnly	SameSite	Persistent
session

Part 12 — Understand Secure

Conceptually:

Secure

instructs the browser to send the cookie only over secure transport such as HTTPS.

Its absence may matter when the application can be accessed over insecure transport.

Context matters.

Part 13 — Understand HttpOnly

Conceptually:

HttpOnly

restricts normal browser-side script access to the cookie.

It can reduce certain session-theft paths involving client-side script execution.

It does not make the entire session secure automatically.

Part 14 — Understand SameSite

Common values include:

Strict
Lax
None

SameSite affects cross-site cookie sending behavior.

Its security value depends on the workflow.

Detailed CSRF-related assessment may be handled separately, but record the attribute here.

Record:

COOKIE SCOPE

Domain:

Path:

Subdomain Reach:

Purpose:

Scope Broader Than Necessary:
Observed / Not Observed / Unknown

Do not assume broad scope automatically produces exploitable impact.

Part 16 — Identify Persistent vs Session Cookies

A session cookie may expire when the browser closes.

A persistent cookie may use:

Expires

or:

Max-Age

Record:

COOKIE LIFETIME

Cookie:

Persistent:
Yes / No

Expiration:

Security Purpose:
Session / Remember Me / Other

COOKIE SECURITY PROFILE

Cookie:

Purpose:

Secure:

HttpOnly:

SameSite:

Domain:

Path:

Expires:

Max-Age:

Observed Risk:

Evidence:

Part 18 — Validate Authenticated Access

While logged in, open a clearly authenticated page such as:

/account

Record:

AUTHENTICATED BASELINE

Endpoint:

Response:

User:

Session:

Sensitive Content:
Training data only

Evidence:

This becomes the baseline for later invalidation tests.

Part 19 — Test Normal Logout

Use the application’s normal logout function.

Record:

LOGOUT EVENT

Logout Endpoint:

Method:

Response:

Redirect:

Cookie Updated:
Yes / No

Cookie Removed:
Yes / No

Session Invalidated:
To be validated

Part 20 — Validate Logout Server-Side

Do not rely solely on:

Redirected to /login

After logout, make a fresh request to the previously authenticated endpoint.

Record:

POST-LOGOUT VALIDATION

Endpoint:

Old Session Presented:
Yes / No

Authenticated Content Returned:
Yes / No

Redirect:
Yes / No

Status:

Assessment:

This determines whether the server accepted the old session.

Suppose logout causes the browser to delete the cookie.

That is useful.

But if the old identifier still works when presented to the server, server-side invalidation may be incomplete.

Always distinguish:

Browser Removed Cookie
        ≠
Server Invalidated Session Automatically

Part 22 — Build the Logout Register

Test	Expected	Result
Logout	Session ends
Old request reused	Denied
Protected page refreshed	Authentication required

Part 23 — Distinguish Browser Cache from Session Validity

After logout, using the Back button may display a cached page.

This does not prove active authenticated access.

Use a new request.

Cached Sensitive Page ≠ Active Server Session Automatically

However, sensitive cache behavior may still deserve separate evaluation.

Part 24 — Assess Idle Timeout

If the training application supports an intentionally short test timeout, authenticate and remain inactive for the defined period.

Then request a protected page.

Record:

IDLE TIMEOUT

Documented Timeout:

Observed Timeout:

Session Valid Before Timeout:

Session Valid After Timeout:

Reauthentication Required:
Yes / No

Do not waste time testing hours-long production-style values unless the lab is designed for it.

Part 25 — Understand Idle vs Absolute Timeout

Idle Timeout

Expires after a period without activity.

Absolute Timeout

Expires after a maximum session age regardless of activity.

These are different controls.

Part 26 — Build the Timeout Register

Control	Configured/Observed	Result
Idle Timeout
Absolute Timeout
Warning
Reauthentication

Part 27 — Assess Absolute Lifetime Where Supported

If the training environment explicitly exposes a short absolute lifetime, validate it.

Otherwise record:

Absolute Session Lifetime:
Documented / Unknown / Not Practically Tested

Do not infer “no absolute timeout” merely because your 15-minute lab session remained active.

Part 28 — Assess Concurrent Sessions

Using the same authorized account in two isolated browser profiles:

Session A
Session B

Perform two legitimate logins.

Record:

CONCURRENT SESSION TEST

Account:

Session A:
Valid / Invalid

Session B:
Valid / Invalid

Second Login Invalidated First:
Yes / No

Both Allowed:
Yes / No

Application Policy:
Known / Unknown

Multiple concurrent sessions are not automatically a vulnerability.

Their security relevance depends on the application’s risk model.

Part 29 — Test Logout Impact on Concurrent Sessions

Where authorized:

authenticate Session A
authenticate Session B
log out Session A
verify Session B normally

Record whether logout is:

Current Session Only

or:

All Sessions

Neither behavior is inherently wrong; policy and context matter.

Part 30 — Create the Concurrent Session Register

Event	Session A	Session B
Initial login	Valid	—
Second login		Valid
Logout A	Invalid
Validate B

Part 31 — Assess Password Change Session Behavior

Using your authorized account:

establish Session A
establish Session B where supported
change the test password in one session
verify the other session

Record:

PASSWORD CHANGE IMPACT

Password Changed:
Yes

Current Session:
Valid / Invalid

Other Session:
Valid / Invalid

Reauthentication Required:

Old Password Accepted:
No / Unexpected

Security Policy:
Known / Unknown

Part 32 — Evaluate Session Revocation After Password Change

For higher-risk applications, organizations may expect password changes to revoke some or all existing sessions.

But application requirements differ.

Report the actual behavior first.

Then assess whether it matches the intended security model.

Part 33 — Assess Password Reset Session Behavior

Repeat the concept using the authorized password-recovery workflow.

Record:

PASSWORD RESET IMPACT

Existing Session Before Reset:
Valid

Reset Completed:
Yes

Existing Session After Reset:
Valid / Invalid

Other Session:
Valid / Invalid

Recovery Session:
Created / Not Created

Evidence:

Password reset can represent a stronger account-recovery event than an ordinary password change.

Part 34 — Assess Logout-All / Session Management Features

If the application exposes:

Log Out All Devices

Active Sessions

Trusted Devices

Session Management

document:

sessions listed
device information
revocation behavior
expected ownership
reauthentication requirement

Use only your own authorized sessions.

Part 35 — Review Active Session Metadata

Possible metadata includes:

Device
Browser
IP
Login Time
Last Activity
Location

Record whether sensitive metadata is exposed appropriately to the account owner.

Do not test other users’ session metadata in this lab.

Part 36 — Assess MFA Session Transition

If MFA exists, compare:

Before password

Password accepted / MFA pending

MFA completed

Record session identifiers at each state.

Part 37 — Create the MFA Transition Register

State	Session	Access
Anonymous	S1	Public
Password accepted	S2	Pre-MFA
MFA complete	S3	Full user

Ask:

Does the application create full authenticated state only after all required authentication factors are complete?

Part 38 — Assess Pre-MFA Access

Using only normal authorized navigation, determine what is accessible before MFA completion.

Expected:

Limited authentication workflow only

Unexpected sensitive functionality should be documented for follow-up.

Do not attempt destructive actions.

Part 39 — Assess Remember-Me Functionality

If present, establish:

Session A:
Remember Me disabled

Session B:
Remember Me enabled

Compare:

cookie names
persistence
expiration
session lifecycle
logout impact

Part 40 — Create the Remember-Me Profile

REMEMBER-ME PROFILE

Token / Cookie:

Persistent:
Yes / No

Expiry:

Secure:

HttpOnly:

SameSite:

Removed on Logout:

Invalidated on Password Change:

Invalidated on Password Reset:

Notes:

Part 41 — Understand Remember-Me Risk

Remember-me tokens may persist beyond a normal browser session.

Therefore they often deserve stronger lifecycle controls.

But:

Persistent Cookie ≠ Vulnerability Automatically

You must evaluate protection and invalidation.

Part 42 — Assess Session Identifier Exposure

Review whether session values appear in:

Cookie

Authorization header

URL query

URL path

Page content

Browser storage

Session identifiers in URLs can create additional exposure through logs, history, analytics, or referrer behavior.

Document any such observation carefully.

Part 43 — Create the Session Exposure Register

Location	Session Value Present	Risk Context
Cookie	Yes	Normal
URL
HTML
Client Storage
Logs	Unknown

Part 44 — Review Client-Side Storage

Applications may use:

localStorage

sessionStorage

IndexedDB

Record security-relevant authentication artifacts.

Do not automatically classify browser storage as vulnerable.

Assess:

what is stored
purpose
sensitivity
lifecycle

Part 45 — Understand Token-Based Sessions

Some applications may use bearer tokens rather than classic session cookies.

Conceptually:

Authorization: Bearer <token>

For this lab, assess:

when issued
where stored
when replaced
when expired
whether logout/revocation affects it

Do not attempt cryptographic attacks or token forgery.

Part 46 — Identify Access and Refresh Tokens

Where applicable:

ACCESS TOKEN:
Shorter-lived authorization token

REFRESH TOKEN:
Used to obtain new access state

Record:

TOKEN PROFILE

Access Token Lifetime:

Refresh Token Present:

Storage:

Rotation:
Observed / Unknown

Logout Revocation:
Observed / Unknown

Part 47 — Do Not Assume Token Format Equals Vulnerability

For example:

JWT

by itself is not a finding.

JWT Used ≠ JWT Vulnerability

The actual implementation must be assessed.

Part 48 — Assess Session State Across Privilege Changes

If the lab contains an authorized workflow that changes privilege, such as switching into an elevated administrative role, observe whether session state changes.

Example:

Standard User
      ↓
Approved Privilege Transition
      ↓
Administrative State

Record whether a new session or stronger reauthentication is used.

Do not attempt to grant yourself unauthorized privileges.

Part 49 — Create the Session Transition Map

Example:

Anonymous
   │
   ▼
Pre-Auth Session
   │
   ▼
Password Accepted
   │
   ▼
MFA Pending
   │
   ▼
Authenticated Session
   │
   ├── Password Change
   │
   ├── Remember Me
   │
   └── Logout
   │
   ▼
Invalid Session

Part 50 — Identify Positive Session Controls

Examples include:

Session identifier rotated after login

Session rotated after MFA

Secure cookie enabled

HttpOnly enabled

Appropriate SameSite behavior

Old session invalidated after logout

Idle timeout implemented

Password reset revokes sessions

Remember-me token invalidated after logout

Active-session revocation available

Document them.

Part 51 — Create the Positive Controls Register

Control	Result	Evidence
Login rotation	Effective
Logout invalidation	Effective
Secure cookie	Present
Idle timeout	Effective

Part 52 — Identify Potential Findings

Possible finding categories include:

Session Identifier Not Rotated After Authentication

Session Remains Valid After Logout

Insufficient Session Timeout

Password Reset Does Not Revoke Existing Sessions

Sensitive Session Token Exposed in URL

Weak Session Cookie Attributes

Remember-Me Token Not Invalidated

Do not create a finding merely because the application behaves differently from your personal preference.

Validate risk.

Part 53 — Finding Example: Session Not Invalidated After Logout

FINDING ID:
SESSION-001

TITLE:
Authenticated Session Remains Valid After Logout

SEVERITY:
High
Depending on application context

CONFIDENCE:
High

ENDPOINT:
/logout

OBSERVATION:
The application removed the session cookie from the browser,
but a previously captured authorized session identifier remained
accepted by the server after logout.

VALIDATION:
A fresh request to an authenticated lab endpoint using the
pre-logout session state returned authenticated content.

SECURITY IMPACT:
A previously obtained session identifier could remain usable
even after the user believes the session has ended.

RECOMMENDATION:
Invalidate the server-side session on logout and reject further
requests using that identifier.

FINDING ID:
SESSION-002

TITLE:
Session Identifier Is Not Regenerated After Authentication

SEVERITY:
Context Dependent

CONFIDENCE:
High

OBSERVATION:
The same session identifier was observed before and after
successful authentication of the authorized test account.

SECURITY RELEVANCE:
Failure to rotate authentication state may increase exposure
to session fixation where an attacker can establish or predict
a victim's pre-authentication session.

LIMITATION:
This lab validated the lifecycle behavior only; exploitability
depends on whether an attacker can influence or obtain the
pre-authentication identifier.

RECOMMENDATION:
Regenerate the session identifier when authentication succeeds
and at other significant privilege changes.

The limitation matters.

Part 55 — Finding Example: Session Survives Password Reset

FINDING ID:
SESSION-003

TITLE:
Existing Authenticated Sessions Remain Valid After Password Reset

CONFIDENCE:
High

OBSERVATION:
A second authenticated test session remained usable after the
account password was reset through the authorized recovery flow.

SECURITY IMPACT:
If password recovery is being used to regain control of an
account after suspected compromise, an existing unauthorized
session could potentially remain active.

RECOMMENDATION:
Consider revoking existing authenticated sessions after
successful account recovery according to application risk and
business requirements.

Part 56 — Build the Findings Register

Finding	Status	Severity	Confidence
Login session rotation
Cookie protections
Logout invalidation
Timeout behavior
Password-change revocation
Password-reset revocation
Remember-me lifecycle

Part 57 — Build the Session Coverage Matrix

Area	Tested	Result
Pre-auth session	Yes
Post-auth session	Yes
Login rotation	Yes
Cookie attributes	Yes
Logout invalidation	Yes
Idle timeout	Yes/Documented
Absolute timeout	Yes/Unknown
Concurrent sessions	Yes
Password change	Yes
Password reset	Yes
MFA transition	Yes/NA
Remember Me	Yes/NA
Token storage	Yes/NA

Part 58 — Create the Evidence Register

Example:

Evidence ID	Description
EV-SES-001	Pre-auth session
EV-SES-002	Post-auth session
EV-SES-003	Login rotation comparison
EV-SES-004	Cookie attributes
EV-SES-005	Logout request
EV-SES-006	Post-logout validation
EV-SES-007	Idle-timeout behavior
EV-SES-008	Concurrent session test
EV-SES-009	Password-change session behavior
EV-SES-010	Password-reset session behavior
EV-SES-011	Remember-me lifecycle

Always redact reusable session material from normal report copies.

Part 59 — Mission Challenge

Complete:

SESSION MANAGEMENT SECURITY ASSESSMENT

Assessment ID:

Analyst:

Date:


SCOPE

Application:

Base URL:

Authorized:
Yes / No

Test Accounts:


SESSION MECHANISM

Session Cookie:

Authorization Token:

Client-Side Storage:

Remember-Me Token:

Other:


PRE-AUTH STATE

Session Present:
Yes / No

Identifier:

Protected Access:
Yes / No


POST-AUTH STATE

Session Identifier:

Changed After Login:
Yes / No

Authenticated Access:
Yes / No


SESSION ROTATION

Anonymous → Authenticated:

Password → MFA:

Privilege Transition:

Password Change:


COOKIE SECURITY

Cookie:

Secure:

HttpOnly:

SameSite:

Domain:

Path:

Persistent:

Expiry:


LOGOUT

Endpoint:

Cookie Removed:

Server Session Invalidated:

Old Session Rejected:

Authenticated Access After Logout:


IDLE TIMEOUT

Documented:

Observed:

Reauthentication Required:


ABSOLUTE TIMEOUT

Documented:

Observed:

Result:


CONCURRENT SESSIONS

Session A:

Session B:

Both Active:

Second Login Invalidates First:

Logout A Invalidates B:


PASSWORD CHANGE

Other Sessions Invalidated:

Reauthentication:

Result:


PASSWORD RESET

Existing Sessions Invalidated:

Recovery Session:

Result:


MFA

Pre-MFA Session:

Post-MFA Session:

Session Rotated:

Pre-MFA Access:


REMEMBER ME

Token:

Persistent:

Expiry:

Logout Invalidates:

Password Change Invalidates:

Password Reset Invalidates:


TOKEN STORAGE

Cookie:

Authorization Header:

Local Storage:

Session Storage:

URL:

Other:


POSITIVE CONTROLS

Control 01:

Control 02:

Control 03:


FINDINGS

Finding 01:

Severity:

Confidence:

Evidence:


Finding 02:

Severity:

Confidence:

Evidence:


LIMITATIONS

Limitation 01:

Limitation 02:


FINAL ASSESSMENT

Session Rotation:
Effective / Weak / Inconclusive

Cookie Protection:
Effective / Weak / Inconclusive

Logout Invalidation:

Timeout Controls:

Concurrent Session Controls:

Credential-Change Revocation:

Recovery Revocation:

Remember-Me Controls:

Overall Session Risk:

Ready for Authorization Assessment:
Yes / No

What Not to Do

Do not:

Use another person's real session

Capture or reuse production session tokens

Share reusable session identifiers in reports

Attempt session hijacking outside the lab

Attempt cross-user session theft

Guess session identifiers at scale

Perform token forgery

Attempt cryptographic attacks against tokens

Grant yourself unauthorized privileges

Assume a cookie is weak because it exists

Assume multiple concurrent sessions are automatically vulnerable

Assume browser Back-button content means active session

Assume logout succeeded because the login page appeared

Assume JWT means insecurity

Assume persistent cookies are automatically vulnerable

Keep testing a session after unexpected application instability

The professional rule is:

Validate session lifecycle controls using your own authorized sessions and the minimum interaction required to establish the behavior.

Professional Distinctions

Always distinguish:

Authentication Success
      ≠
Secure Session Management

Cookie Removed
      ≠
Server Session Invalidated

Login Redirect
      ≠
Session Rotation

Cached Page
      ≠
Valid Session

Persistent Cookie
      ≠
Vulnerability

Concurrent Sessions
      ≠
Account Compromise

Session ID Unchanged
      ≠
Confirmed Session Fixation Exploit

JWT
      ≠
JWT Vulnerability

MFA Completed
      ≠
Every Session Transition Is Secure

Password Changed
      ≠
All Existing Sessions Revoked Automatically

Password Reset
      ≠
Account Recovery Complete Until Session Risk Is Considered

HttpOnly
      ≠
Session Cannot Be Stolen

Secure Cookie
      ≠
Secure Application

Evidence Requirements

Capture:

authorization and scope
session mechanism profile
pre-authentication session baseline
authenticated session baseline
pre/post-login comparison
session rotation register
cookie security attributes
cookie scope
cookie lifetime
authenticated page baseline
logout request
post-logout fresh request
server-side invalidation result
idle-timeout assessment
absolute-timeout assessment/documentation
concurrent session behavior
concurrent-session logout impact
password-change session behavior
password-reset session behavior
active-session functionality where applicable
MFA transition map where applicable
pre-MFA access assessment
remember-me profile
session exposure register
client-storage observations
token profile where applicable
positive controls
findings register
coverage matrix
evidence register

Mission Deliverables

Complete:

scope confirmed
session mechanisms identified
pre-authentication state documented
authenticated state documented
session identifiers compared
login rotation assessed
MFA rotation assessed where applicable
cookie attributes reviewed
cookie scope reviewed
persistence/lifetime documented
authenticated baseline preserved
logout performed
server-side logout invalidation validated
cache behavior distinguished from session validity
idle timeout assessed
absolute timeout assessed or documented as unknown
concurrent sessions evaluated
logout impact across sessions evaluated
password-change session impact evaluated
password-reset session impact evaluated
active-session controls reviewed where available
MFA session states reviewed where applicable
remember-me lifecycle assessed where available
session identifier exposure locations reviewed
client storage reviewed
token lifecycle reviewed where applicable
positive controls documented
potential findings validated
limitations documented
final Session Management Assessment completed

Lab Report Template

# Lab 06 — Session Management Security Assessment

## Executive Summary

## Mission Objective

## Authorization & Scope

## Session Architecture

## Session Mechanisms

## Pre-Authentication State

## Post-Authentication State

## Session Rotation

## Cookie Security Attributes

## Cookie Scope & Lifetime

## Authenticated Access Baseline

## Logout Assessment

## Post-Logout Validation

## Idle Timeout

## Absolute Timeout

## Concurrent Sessions

## Password Change Session Impact

## Password Reset Session Impact

## Active Session Management

## MFA Session Transition

## Remember-Me Functionality

## Session Identifier Exposure

## Client-Side Token Storage

## Token Lifecycle

## Positive Security Controls

## Findings

## Severity & Confidence

## Evidence Register

## Limitations

## Recommendations

## Conclusion

Knowledge Check

Question 1 — What is session management?

The mechanisms used by an application to maintain authenticated state across multiple requests after a user successfully authenticates.

Question 2 — Why should session identifiers often change after authentication?

Because authentication represents a major trust transition, and regenerating session state helps prevent an unauthenticated session from simply becoming the authenticated session.

No.

The server must reject the previous authenticated session state.

Question 4 — What is the difference between idle and absolute timeout?

Idle timeout expires after inactivity. Absolute timeout limits the total lifetime regardless of continued activity.

Question 5 — Are multiple concurrent sessions automatically insecure?

No.

Their acceptability depends on the application’s risk model and required controls.

Question 6 — Why assess password-reset effects on existing sessions?

Because account recovery may be performed after suspected compromise, and old authenticated sessions may need to be revoked.

Question 7 — Does HttpOnly make a session fully secure?

No.

It protects against certain browser-script access scenarios but does not solve every session-security risk.

No.

It is an important security observation, but exploitability depends on whether an attacker can influence or obtain the relevant pre-authentication session.

Question 9 — Why should session secrets be redacted in reports?

Because a valid session token can function like a temporary credential.

Question 10 — What is the central question?

“Once a user is authenticated, does the application maintain, rotate, expire, and invalidate session state in a way that prevents unauthorized reuse of that identity?”

Skills Achieved

After completing this lab, you should understand:

session architecture
session identifier discovery
pre/post-auth state comparison
session rotation
cookie security attributes
cookie scope
cookie lifetime
logout invalidation
idle timeout
absolute timeout
concurrent sessions
password-change session behavior
password-reset session behavior
MFA session transitions
remember-me lifecycle
session exposure analysis
client-side token storage
bearer-token lifecycle concepts
session-control validation
evidence-safe reporting

Professional Takeaway

A weak assessment looks like:

Cookie Exists
     ↓
Inspect Flags
     ↓
Secure + HttpOnly
     ↓
Session Secure

A professional assessment looks like:

Identify Session Mechanism
        ↓
Capture Pre-Auth State
        ↓
Authenticate
        ↓
Compare Session State
        ↓
Validate Rotation
        ↓
Review Cookie Protection
        ↓
Validate Logout
        ↓
Validate Timeout
        ↓
Assess Concurrent Sessions
        ↓
Assess Credential-Change Revocation
        ↓
Assess Recovery Revocation
        ↓
Assess MFA Transition
        ↓
Assess Remember-Me Lifecycle
        ↓
Validate Server-Side Behavior
        ↓
Document Evidence

What’s Next?

➡️ Lab 07 — Authorization & Access Control Assessment

In the next lab, you will move from maintaining identity to determining whether the application correctly enforces what each identity is allowed to access or perform.

You will assess:

anonymous vs authenticated access
user-to-user object access
role boundaries
administrative functionality
object identifiers
horizontal access control
vertical access control
API authorization
function-level access
state-changing operations
ownership validation
direct endpoint access
authorization consistency
impact and evidence

The methodology becomes:

Baseline → Compare Identities → Change Object Context → Change Role Context → Validate Server Enforcement → Assess Impact → Report

The central question will be:

“Does the server enforce access based on the authenticated user’s identity, role, and object ownership—or does it rely on values the client can control?”

06 Session Management Security Assessment

Mission Overview

Mission Information

Learning Objectives

Core Methodology

Part 1 — Confirm Scope

Part 2 — Create the Lab Workspace

Part 3 — Identify Session Mechanisms

Part 4 — Distinguish Session Types

Anonymous Session

Authenticated Session

Pre-MFA Session

Remember-Me Session

Part 5 — Establish the Pre-Authentication Baseline

Part 6 — Authenticate Normally

Part 7 — Compare Pre-Auth and Post-Auth Sessions

Part 8 — Assess Session Rotation at Login

Part 9 — Understand Session Fixation Conceptually

Part 10 — Create the Rotation Register

Part 11 — Review Cookie Security Attributes

Part 12 — Understand Secure

Part 13 — Understand HttpOnly

Part 14 — Understand SameSite

Part 15 — Assess Cookie Scope

Part 16 — Identify Persistent vs Session Cookies

Part 17 — Create the Cookie Security Register

Part 18 — Validate Authenticated Access

Part 19 — Test Normal Logout

Part 20 — Validate Logout Server-Side

Part 21 — Distinguish Client-Side Cookie Removal from Server-Side Invalidation

Part 22 — Build the Logout Register

Part 23 — Distinguish Browser Cache from Session Validity

Part 24 — Assess Idle Timeout

Part 25 — Understand Idle vs Absolute Timeout

Idle Timeout

Absolute Timeout

Part 26 — Build the Timeout Register

Part 27 — Assess Absolute Lifetime Where Supported

Part 28 — Assess Concurrent Sessions

Part 29 — Test Logout Impact on Concurrent Sessions

Part 30 — Create the Concurrent Session Register

Part 31 — Assess Password Change Session Behavior

Part 32 — Evaluate Session Revocation After Password Change

Part 33 — Assess Password Reset Session Behavior

Part 34 — Assess Logout-All / Session Management Features

Part 35 — Review Active Session Metadata

Part 36 — Assess MFA Session Transition

Part 37 — Create the MFA Transition Register

Part 38 — Assess Pre-MFA Access

Part 39 — Assess Remember-Me Functionality

Part 40 — Create the Remember-Me Profile

Part 41 — Understand Remember-Me Risk

Part 42 — Assess Session Identifier Exposure

Part 43 — Create the Session Exposure Register

Part 44 — Review Client-Side Storage

Part 45 — Understand Token-Based Sessions

Part 46 — Identify Access and Refresh Tokens

Part 47 — Do Not Assume Token Format Equals Vulnerability

Part 48 — Assess Session State Across Privilege Changes

Part 49 — Create the Session Transition Map

Part 50 — Identify Positive Session Controls

Part 51 — Create the Positive Controls Register

Part 52 — Identify Potential Findings

Part 53 — Finding Example: Session Not Invalidated After Logout

Part 54 — Finding Example: Session Not Rotated on Login

Part 55 — Finding Example: Session Survives Password Reset

Part 56 — Build the Findings Register

Part 57 — Build the Session Coverage Matrix

Part 58 — Create the Evidence Register

Part 59 — Mission Challenge

What Not to Do

Professional Distinctions

Evidence Requirements

Mission Deliverables

Lab Report Template

Knowledge Check

Question 1 — What is session management?

Question 2 — Why should session identifiers often change after authentication?

Question 3 — Does removing a session cookie from the browser prove logout invalidated the session?

Question 4 — What is the difference between idle and absolute timeout?