Lab 11 Web Authentication & Session Security Assessment

Mission Overview

Welcome to Lab 11 — Web Authentication & Session Security Assessment.

In Lab 10, you mapped the authorized training web application and identified its pages, endpoints, forms, parameters, authentication boundaries, cookies, APIs, and trust relationships.

Now you will examine one of the most important web security controls:

How does the application establish, maintain, and terminate an authenticated user session?

Authentication answers:

“Who are you?”

Session management answers:

“How does the application remember that you successfully proved who you are?”

A secure login page alone is not enough. Weak session handling can undermine otherwise strong authentication.

Mission Goal: Assess authentication and session-management controls within an authorized training application, identify weaknesses, collect evidence, evaluate business impact, and recommend appropriate remediation.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	90–120 minutes
Primary Skill	Web Authentication Assessment
Secondary Skill	Session Security Analysis
Environment	Kali + Authorized Training Web Application
Primary Tools	Browser, Developer Tools, Burp Suite Community, curl
Testing Type	Controlled Authentication & Session Assessment
Primary Outcome	Authentication & Session Security Findings Register
Accounts	Lab-provided accounts only
Evidence Required	Requests, responses, screenshots, observations
Safety Level	Authorized Lab Only

Learning Objectives

By completing this lab, you will be able to:

• understand authentication vs authorization

• map authentication workflows

• assess login behavior

• evaluate authentication error handling

• review password-policy controls

• safely assess rate limiting and account lockout

• analyze password-reset functionality

• understand MFA controls

• identify session establishment

• inspect session cookies

• assess Secure, HttpOnly, and SameSite attributes

• evaluate session identifiers without exposing them

• assess logout behavior

• review session expiration

• understand idle and absolute timeouts

• evaluate sensitive-action reauthentication

• review concurrent-session behavior

• identify session-management weaknesses

• document authentication findings professionally

• recommend defensive improvements

Authentication & Session Methodology

Use:

Identity → Login → Verification → Session Creation → Session Protection → Session Lifecycle → Logout → Evidence

Conceptually:

User
 │
 ▼
Login
 │
 ▼
Credential Verification
 │
 ├──── Failure ────► Controlled Error
 │
 ▼
Success
 │
 ▼
Session Created
 │
 ▼
Session Protected
 │
 ▼
Authenticated Activity
 │
 ▼
Timeout / Logout
 │
 ▼
Session Invalidated

A useful assessment question is:

Can the application reliably distinguish an authenticated user from everyone else throughout the complete session lifecycle?

Lab Architecture

Example:

                 GHC Ethical Hacking Lab
                    192.168.56.0/24
                           │
                      Kali Linux
                           │
                Browser + Burp Proxy
                           │
                           ▼
                 Training Web Application
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
           Login         Session       Account
             │             │             │
        Credentials      Cookie       Protected
             │             │           Actions
             └─────────────┼─────────────┘
                           ▼
                      User Identity

Use only intentionally vulnerable applications or dedicated systems for which you have explicit authorization.

Part 1 — Confirm Scope

Record:

Application:

Target URL:

Target IP:

Authentication Endpoint:

Authorized Username:

Account Role:

Password Reset Testing:
Allowed / Not Allowed

MFA Testing:
Allowed / Not Applicable

Session Testing:
Allowed

Account Lockout Testing:
Allowed / Restricted

Excluded Functions:

Assessment Start:

Do not test authentication against public or unrelated services.

Part 2 — Establish Rules of Engagement

Permitted

• use of lab-provided accounts

• normal login attempts

• controlled invalid-password tests

• observing HTTP requests/responses

• inspecting your own cookies

• testing logout

• observing session expiration

• using multiple browser sessions for your own account

• reviewing password-reset behavior

• documenting security controls

Not Required

• credential stuffing

• password spraying

• large-scale brute forcing

• attacking real accounts

• stealing another user’s session

• phishing

• bypassing MFA

• session fixation exploitation against another user

• destructive account manipulation

The mission is security validation, not uncontrolled credential attacks.

Part 3 — Create the Workspace

Create:

Ethical-Hacking-Labs/
└── Lab-11/
    ├── Notes/
    ├── Evidence/
    │   ├── Login/
    │   ├── Password/
    │   ├── Recovery/
    │   ├── MFA/
    │   ├── Cookies/
    │   ├── Sessions/
    │   └── Logout/
    ├── Requests/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-11-Investigation-Journal.md

Suggested structure:

# Lab 11 — Web Authentication & Session Security Assessment

## Mission Objective

## Scope

## Authentication Workflow

## Login Behavior

## Error Handling

## Password Controls

## Rate Limiting

## Account Lockout

## Password Recovery

## MFA

## Session Creation

## Session Cookies

## Session Expiration

## Logout

## Sensitive Actions

## Concurrent Sessions

## Positive Controls

## Findings

## Evidence

## Recommendations

## Lessons Learned

Part 4 — Establish the Authentication Baseline

From Lab 10, retrieve:

Login Endpoint:

Login Method:

Username Field:

Password Field:

Registration Endpoint:

Password Reset Endpoint:

Logout Endpoint:

Session Cookie:

Protected Pages:

Account Roles:

Do not rediscover everything from scratch.

A professional workflow carries evidence forward between assessment phases.

Part 5 — Map the Authentication Workflow

Using your authorized training account, map:

Unauthenticated
      │
      ▼
   /login
      │
      ▼
Credentials Submitted
      │
      ▼
Application Validation
      │
   ┌──┴──┐
   │     │
Failure Success
   │     │
   ▼     ▼
Error   Session
         │
         ▼
    Protected Area

Record every endpoint involved.

Part 6 — Capture the Login Page

Before authenticating, document:

Login URL:

Protocol:

Username Field:

Password Field:

Remember Me:

Forgot Password:

Registration:

MFA Prompt:

CAPTCHA:

Other Controls:

Capture a screenshot.

Never include real reusable credentials in screenshots.

Part 7 — Verify HTTPS Protection

Authentication credentials should normally be transmitted over encrypted transport.

Determine:

Login Uses HTTPS:
Yes / No

HTTP Login Available:
Yes / No

HTTP Redirects to HTTPS:
Yes / No

Authenticated Pages Use HTTPS:
Yes / No

Conceptually:

Credentials
    │
    ▼
   HTTPS
    │
    ▼
Application

Sensitive authentication over plaintext HTTP can expose credentials to network interception.

Part 8 — Observe a Successful Login

Configure your browser through Burp Suite as established in Lab 10.

Submit the supplied training credentials once.

Observe the request.

Conceptually:

POST /login
Content-Type: application/x-www-form-urlencoded

username=<REDACTED>&password=<REDACTED>

Do not save the real password in course evidence.

Record:

Method:

Endpoint:

Content-Type:

Username Parameter:

Password Parameter:

Response Status:

Redirect:

Session Created:

Part 9 — Observe Authentication Success

A successful login may result in:

200 OK

or:

302 Found
Location: /dashboard

The application may also issue a cookie.

Example:

Set-Cookie: session=<REDACTED>

Record the behavior without exposing the session value.

Part 10 — Identify Session Establishment

Determine when the application creates the authenticated session.

Ask:

Was a cookie created before login?

Was it replaced after login?

Was a new session created after authentication?

Was authentication state stored elsewhere?

Create:

Stage	Session Present	Identifier Changed
Before Login
After Login

This helps assess session lifecycle behavior.

Part 11 — Understand Session Identifiers

A session identifier effectively tells the server:

“This request belongs to this authenticated session.”

Conceptually:

User Authenticates
      │
      ▼
Server Creates Session
      │
      ▼
Browser Receives Identifier
      │
      ▼
Future Requests Carry Identifier
      │
      ▼
Server Associates Request with User

Therefore, session identifiers should be treated like sensitive authentication material.

Part 12 — Protect Session Evidence

Never place active values such as:

session=abc123...

into screenshots or reports.

Use:

session=<REDACTED>

Likewise redact:

• passwords

• reset tokens

• access tokens

• API tokens

• authorization headers

• CSRF tokens where appropriate

• personal information

Evidence must be useful without creating another security problem.

Part 13 — Inspect Session Cookies

Use Browser Developer Tools:

Application / Storage
        ↓
Cookies
        ↓
Training Application

Record:

Attribute	Observation
Cookie Name
Domain
Path
Secure
HttpOnly
SameSite
Expiration
Session/Persistent

Redact the cookie value.

Part 14 — Assess the Secure Attribute

Look for:

Secure

A Secure cookie is intended to be sent over HTTPS rather than ordinary HTTP.

Record:

Session Cookie Secure:
Yes / No

If the application handles authenticated sessions over HTTPS but its session cookie lacks appropriate transport protection, document the observation for further analysis.

Part 15 — Assess HttpOnly

Look for:

HttpOnly

HttpOnly helps prevent client-side JavaScript from directly accessing the cookie.

Conceptually:

Session Cookie
     │
 HttpOnly
     │
     ▼
Reduced Direct JavaScript Access

It is an important defense-in-depth control.

Part 16 — Assess SameSite

Look for:

SameSite=Strict

SameSite=Lax

or:

SameSite=None

SameSite influences when browsers send cookies in cross-site contexts.

Do not automatically rate one value as vulnerable.

Evaluate the application’s workflow and other CSRF protections.

Part 17 — Build the Cookie Security Matrix

Create:

Cookie	Secure	HttpOnly	SameSite	Sensitive	Review
Session				Yes
Preference				No

Not every cookie requires exactly the same protection.

Session cookies deserve particular attention.

Part 18 — Check Cookie Scope

Review:

Domain

Path

Ask:

Is the session cookie available to more of the application or domain structure than necessary?

Apply the principle of least privilege to session scope as well.

Part 19 — Determine Whether the Session Is Persistent

Close the browser according to the lab procedure and determine whether the authenticated state persists.

Document:

Session Cookie:
Session / Persistent

Expiration:

Authentication Persists After Browser Restart:
Yes / No

Do not assume persistence is automatically insecure.

Business requirements matter.

Part 20 — Test an Invalid Password Safely

For the authorized training account only:

1. Log out.

2. Enter the correct lab username.

3. Enter one intentionally incorrect password.

4. Submit.

5. Record the response.

Example:

Username:
lab-user

Password:
<INTENTIONALLY INCORRECT>

Do not perform repeated automated guessing.

Part 21 — Review Authentication Error Handling

Observe whether the application says:

Invalid username or password.

versus more specific messages such as:

User exists, but password is incorrect.

Overly specific authentication errors can sometimes assist account enumeration.

Record:

Condition	Response
Valid user + invalid password
Invalid lab username
Empty fields

Keep tests minimal.

Part 22 — Evaluate Username Enumeration

The question is:

Does the application reveal whether a particular account exists?

Potential signals can include:

• different error text

• significantly different workflows

• different status codes

• password-reset responses

Do not enumerate lists of users.

Use only the small number of identities supplied for the lab.

Part 23 — Review Generic Error Handling

A stronger public-facing response often avoids unnecessarily confirming account existence.

Example:

Invalid username or password.

However, assess the complete behavior rather than only visible text.

Part 24 — Review Password Policy

If the training application permits account creation or password changes, inspect its password requirements.

Record:

Minimum Length:

Maximum Length:

Complexity Requirements:

Common Password Protection:

Password History:

Password Reuse:

Compromised Password Detection:

Other Requirements:

Do not change a shared lab account password unless instructed.

Part 25 — Evaluate Password Policy Professionally

Avoid reducing password security to:

Must contain:
Uppercase
Lowercase
Number
Symbol

A stronger assessment considers:

• adequate length

• support for long passphrases

• compromised-password blocking

• rate limiting

• MFA

• secure storage

• password-reset security

• protection against automated guessing

Authentication security is a system, not one regex.

Part 26 — Review Password Input Handling

Observe whether the login form appropriately uses a password field.

Check whether the application accidentally exposes the password through:

URL parameters

Browser-visible application logs

Error messages

Page content

A password should not appear in a URL such as:

/login?password=<REDACTED>

because URLs may be stored in histories and logs.

Part 27 — Assess Rate Limiting Carefully

Rate limiting helps control automated authentication attempts.

If explicitly allowed by the lab, perform only a small controlled sequence of invalid attempts against the supplied training account.

For example, record the response after each attempt without using automated password lists.

Look for:

Delay

Temporary block

429 response

CAPTCHA

Lockout

Security notification

Stop if the account locks.

Part 28 — Understand HTTP 429

You may observe:

429 Too Many Requests

This can indicate rate limiting.

Record:

Attempts Performed:

Rate Limiting Observed:

Response:

Recovery Behavior:

Do not attempt to circumvent the control.

Part 29 — Assess Account Lockout

If the training environment specifically permits lockout testing, determine:

Lockout Exists:

Threshold:
Observed / Unknown

Duration:
Observed / Unknown

Automatic Unlock:
Yes / Unknown

Administrator Required:
Unknown / Yes

Use the minimum testing necessary.

Part 30 — Understand Lockout Trade-Offs

Account lockout can reduce password guessing but overly aggressive lockout policies can create denial-of-service problems.

Therefore:

Authentication Defense
        =
Rate Limiting
+
Risk-Based Controls
+
MFA
+
Monitoring
+
Appropriate Lockout

No single mechanism solves every authentication problem.

Part 31 — Review “Remember Me”

If the application provides:

Remember Me

test it only with your authorized account.

Determine:

Does authentication persist?

How long?

Is a persistent cookie created?

Does logout invalidate it?

Do not expose the token value.

Part 32 — Locate Password Recovery

From Lab 10, identify:

Forgot Password

or:

/reset-password

Record:

Recovery Endpoint:

Identifier Required:

Email/Username:

Verification Mechanism:

Token Used:

Expiration:
Observed / Unknown

Part 33 — Assess Password-Recovery Responses

Submit only an approved lab account or designated training address.

Observe whether the application reveals account existence.

Compare conceptually:

Account exists:
Email sent.

versus:

If an account exists, recovery instructions will be sent.

The latter reveals less information.

Part 34 — Protect Reset Tokens

If the training application generates a password-reset link, treat its token like a credential.

Do not place the full token in evidence.

Use:

/reset-password?token=<REDACTED>

Part 35 — Assess Reset Token Properties

Without attempting to predict or attack the token, determine where possible:

Single Use:

Expiration:

Invalidated After Use:

Bound to Account:

Transported Over HTTPS:

Exposed in URL:

The objective is to assess lifecycle controls.

Part 36 — Review Password Reset Completion

If the lab specifically permits changing a disposable training account password:

Request Reset
      ↓
Receive Authorized Token
      ↓
Set New Training Password
      ↓
Token Invalidated
      ↓
Old Authentication State Reviewed

Do not modify a shared course account.

Part 37 — Understand MFA

Multi-factor authentication requires factors from different categories.

Examples:

Something You Know
Password

Something You Have
Authenticator / Security Key

Something You Are
Biometric

Two passwords are not two factors.

Part 38 — Review MFA Availability

If the training application implements MFA, document:

MFA Available:

MFA Mandatory:

Protected Roles:

Factor Type:

Recovery Mechanism:

Remember Device:

Sensitive Actions Require MFA:

Do not attempt to bypass MFA.

Part 39 — Review MFA Recovery

MFA can be weakened by insecure recovery.

Ask:

How is MFA reset?

Does recovery require strong verification?

Are backup codes protected?

Does password recovery disable MFA?

Are administrators involved?

The weakest recovery path can undermine stronger authentication.

Part 40 — Test Session Rotation

Using only your own session:

1. Record a redacted fingerprint of the pre-login session state.

2. Authenticate normally.

3. observe whether the session identifier changes.

Do not publish either value.

Record:

Pre-Authentication Session:
Present / Not Present

Post-Authentication Session:
Present

Identifier Rotated:
Yes / No / Unable to Determine

Session rotation after authentication is an important defense against session-fixation scenarios.

Part 41 — Understand Session Fixation Conceptually

The security concern is:

Session Exists Before Login
        ↓
User Authenticates
        ↓
Same Identifier Continues
        ↓
Potential Session-Fixation Risk

A stronger pattern is:

Pre-Login Session
        ↓
Authentication
        ↓
New Session Identifier

This lab does not require exploiting fixation.

Part 42 — Review Session Identifier Exposure

Inspect your own requests.

Determine whether the session identifier appears in:

Cookie
Authorization Header
URL
Page Source
Local Storage
Session Storage

Sensitive session identifiers should generally avoid unnecessary exposure.

Part 43 — Review Browser Storage

Use Developer Tools to inspect:

Cookies

Local Storage

Session Storage

Record authentication-related data types.

Do not copy live token values.

Create:

Storage	Authentication Data	Observation
Cookie	Session	Review
Local Storage	Token	Review
Session Storage	None	Observed

Part 44 — Review Logout Behavior

While authenticated:

1. Visit a protected page.

2. Log out normally.

3. Attempt to revisit the protected page through normal browser navigation.

4. Record the result.

Expected secure behavior normally requires the application to recognize that the session is no longer authenticated.

Part 45 — Verify Server-Side Logout

A UI redirect alone does not prove session invalidation.

Observe:

Logout Request
      ↓
Server Processing
      ↓
Session Invalidated
      ↓
Protected Request
      ↓
Authentication Required

Record:

Logout Endpoint:

Method:

Session Cookie Removed/Changed:

Protected Page After Logout:

Reauthentication Required:

Part 46 — Review Browser Back-Button Behavior

After logout, use the browser Back button.

You may see cached content.

Distinguish:

Cached Page Display

from:

Server Still Accepts Session

A cached page does not automatically prove the session remains valid.

Refresh or make a legitimate protected request to confirm server behavior.

Part 47 — Assess Idle Session Timeout

If feasible within the lab duration:

1. Authenticate.

2. Leave the session inactive.

3. Wait for the configured or practical observation period.

4. Request a protected page.

5. Record whether reauthentication is required.

Record:

Idle Timeout Observed:

Approximate Duration:

Reauthentication Required:

Do not claim there is no timeout simply because your short observation window did not reach it.

Use:

Not observed within 20-minute test window.

rather than:

No timeout exists.

Part 48 — Understand Idle vs Absolute Timeout

Idle Timeout

Ends a session after a period of inactivity.

Absolute Timeout

Ends a session after a maximum lifetime regardless of activity.

Conceptually:

Session Created
      │
      ├── Inactivity ──► Idle Timeout
      │
      └── Maximum Age ─► Absolute Timeout

Both can be appropriate depending on application risk.

Part 49 — Assess Sensitive-Action Reauthentication

Identify sensitive actions such as:

Change Password

Change Email

Change MFA

Payment Changes

Security Settings

Account Deletion

Do not perform destructive actions.

If a harmless training action exists, observe whether the application requires recent authentication.

Part 50 — Understand Reauthentication

An already authenticated browser should not always be sufficient for the most sensitive account operations.

Conceptually:

Authenticated Session
       │
       ▼
Sensitive Action
       │
       ▼
Reauthentication
       │
       ▼
Action Allowed

This reduces risk from unattended or compromised sessions.

Part 51 — Review Password Change Behavior

If the lab provides a disposable account and explicitly permits password changes, assess:

Current Password Required:

New Password Policy:

MFA Required:

Existing Sessions Invalidated:

Security Notification:

Otherwise, inspect the workflow without submitting changes.

Part 52 — Review Concurrent Sessions

Using your own lab account:

Browser A
   │
   └── Login

Browser B / Private Window
   │
   └── Login

Observe:

Are both sessions allowed?

Does the first session terminate?

Can sessions be viewed?

Can the user terminate other sessions?

Concurrent sessions are not automatically insecure.

The appropriate behavior depends on application risk and business requirements.

Part 53 — Build the Session Lifecycle Map

Create:

                 Session Lifecycle
                       │
                       ▼
                 Unauthenticated
                       │
                     Login
                       │
                       ▼
                Session Created
                       │
                       ▼
                 Authenticated
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
        Active       Idle       Sensitive
        Usage        Period       Action
          │            │            │
          │            ▼            ▼
          │         Timeout      Reauth?
          │
          ▼
        Logout
          │
          ▼
    Session Invalidated

Part 54 — Build the Authentication Control Matrix

Create:

Control	Status	Evidence	Priority
HTTPS Login			High
Generic Errors			Medium
Password Policy			High
Rate Limiting			High
Lockout			Medium
MFA			High
Secure Cookie			High
HttpOnly			High
SameSite			Medium
Session Rotation			High
Idle Timeout			Medium
Logout Invalidation			High
Sensitive Reauth			High

Part 55 — Correlate Controls

Do not evaluate authentication controls in isolation.

For example:

Strong Password
      +
No Rate Limiting
      +
No MFA
      =
Authentication Still Needs Improvement

Another:

HTTPS
  +
Secure Cookie
  +
HttpOnly
  +
Session Rotation
  +
Effective Logout
      =
Strong Session-Control Combination

Security posture comes from layers.

Part 56 — Record Positive Controls

Examples:

Authentication is protected with HTTPS.

Invalid authentication responses do not reveal account existence.

Rate limiting is enforced.

MFA is enabled for sensitive accounts.

Session cookie uses Secure.

Session cookie uses HttpOnly.

Session identifier changes after authentication.

Logout invalidates the server-side session.

Sensitive account changes require reauthentication.

Authentication events are logged.

Do not create findings only for weaknesses.

Part 57 — Finding Example: Account Enumeration

Finding:
Authentication responses disclose account existence.

Observation:
The application returns materially different responses for an
existing training username and a nonexistent username.

Impact:
An attacker may be able to determine valid account identifiers,
which could support subsequent credential attacks.

Recommendation:
Use consistent public authentication responses and monitor
repeated account-discovery attempts.

Part 58 — Finding Example: Missing Rate Limiting

Finding:
Authentication endpoint lacks observable rate limiting.

Observation:
Within the approved controlled test window, repeated invalid
authentication requests received equivalent responses without
delay or throttling.

Impact:
Insufficient rate limiting can increase exposure to automated
password-guessing attacks.

Recommendation:
Implement appropriate authentication throttling, risk-based
controls, monitoring, and MFA.

Be precise about the number and duration of tests.

Do not claim unlimited guessing unless you actually have evidence.

Part 59 — Finding Example: Missing Secure Attribute

Finding:
Session cookie lacks the Secure attribute.

Observation:
The authenticated session cookie was issued without the Secure
attribute.

Impact:
Where insecure HTTP transport is possible, the cookie may be
exposed to unnecessary transport risk.

Recommendation:
Use HTTPS throughout the authenticated application and mark
sensitive session cookies Secure.

Part 60 — Finding Example: Missing HttpOnly

Finding:
Session cookie lacks HttpOnly protection.

Observation:
The primary authenticated session cookie does not include the
HttpOnly attribute.

Impact:
If client-side script execution were compromised through another
application weakness, direct access to the session cookie could
increase session exposure.

Recommendation:
Apply HttpOnly to session cookies where client-side access is not
required.

Notice the wording.

Missing HttpOnly does not itself prove session theft.

Part 61 — Finding Example: Logout Does Not Invalidate Session

Finding:
Logout does not fully invalidate authenticated session state.

Observation:
After using the application's logout function, the same
authorized test session remained accepted when accessing a
protected training endpoint.

Impact:
A session believed to be terminated could potentially continue
to provide authenticated access.

Recommendation:
Invalidate the session server-side during logout and require
fresh authentication for subsequent protected requests.

Part 62 — Finding Example: Missing Reauthentication

Finding:
Sensitive account changes do not require recent authentication.

Observation:
The training application permits a security-sensitive account
operation using only the existing authenticated session.

Impact:
An unattended or compromised session could potentially be used
to alter important account-security settings.

Recommendation:
Require recent authentication and, where appropriate, MFA for
high-risk account operations.

Part 63 — Assign Severity Carefully

High

Could materially undermine authentication or authenticated session security.

Medium

Meaningful weakness requiring additional conditions or with mitigating controls.

Low

Limited security impact or defense-in-depth issue.

Informational

Observation useful for understanding posture.

Do not rate:

Missing SameSite

as automatically Critical.

Severity depends on exploitability, application behavior, compensating controls, and impact.

Part 64 — Build the Findings Register

Example:

ID	Area	Observation	Severity	Confidence	Recommendation
AUTH-01	Login	Generic errors	Positive	Confirmed	Maintain
AUTH-02	Rate Limit	Not observed in approved test	Medium	High	Implement throttling
SES-01	Cookie	Secure enabled	Positive	Confirmed	Maintain
SES-02	Cookie	HttpOnly missing	Medium	Confirmed	Enable HttpOnly
SES-03	Logout	Session invalidated	Positive	Confirmed	Maintain

Part 65 — Create the Authentication Attack-Surface Map

Example:

                     User Identity
                          │
         ┌────────────────┼────────────────┐
         ▼                ▼                ▼
       Login          Recovery            MFA
         │                │                │
         └────────────────┼────────────────┘
                          ▼
                    Authentication
                          │
                          ▼
                     Session
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
       Cookie          Timeout          Logout
          │               │               │
          └───────────────┼───────────────┘
                          ▼
                   Protected Actions
                          │
                          ▼
                    Reauthentication

Part 66 — Evidence Requirements

Capture:

Evidence 01

Authentication scope.

Evidence 02

Login page.

Evidence 03

HTTPS behavior.

Evidence 04

Redacted successful login request.

Evidence 05

Successful authentication response.

Evidence 06

Redacted session-cookie attributes.

Evidence 07

Controlled invalid-login response.

Evidence 08

Authentication error comparison.

Evidence 09

Password-policy observations.

Evidence 10

Rate-limit/lockout observations.

Evidence 11

Password-recovery workflow.

Evidence 12

MFA observations if applicable.

Evidence 13

Session rotation result.

Evidence 14

Session storage observations.

Evidence 15

Logout behavior.

Evidence 16

Session expiration observation.

Evidence 17

Sensitive-action reauthentication observation.

Evidence 18

Concurrent-session behavior.

Evidence 19

Final Authentication & Session Findings Register.

Part 67 — Mission Challenge

Complete:

Application:

Login Endpoint:

Login Method:

HTTPS Enforced:

Generic Authentication Errors:

Username Enumeration Observed:

Password Policy:

Rate Limiting:

Account Lockout:

Password Recovery:

MFA Available:

MFA Required:

Session Cookie:

Secure:

HttpOnly:

SameSite:

Session Identifier Rotated After Login:

Persistent Session:

Idle Timeout:

Absolute Timeout:

Logout Invalidates Session:

Sensitive Actions Require Reauthentication:

Concurrent Sessions Allowed:

Session Management Interface:

Strongest Authentication Control:

Highest Authentication Risk:

Strongest Session Control:

Highest Session Risk:

Top Remediation Priority:

Every conclusion should reference evidence.

Part 68 — What Not to Do

This lab does not require:

Credential stuffing

Password spraying

Large password lists

Brute-force automation

MFA bypass

Phishing

Session theft

Cookie theft

Session replay against other users

Password-reset token prediction

Account takeover

Authentication bypass exploitation

Destructive account changes

Your objective is:

Evaluate the controls, not defeat users.

Part 69 — Troubleshooting

Burp Does Not Capture Login

Verify:

Browser proxy configuration

Burp listener

Correct target

HTTPS proxy configuration

Intercept status

Login Stops Working

Check whether your controlled failed attempts triggered a temporary lockout.

Do not continue attempting passwords.

Document the control.

Cookie Is Not Visible

The application may use:

• another cookie

• Authorization headers

• local storage

• session storage

• another token mechanism

Review your own authenticated request.

Session Appears Valid After Logout

Do not rely only on browser Back.

Request a protected endpoint from the server.

Differentiate cached content from active server-side authentication.

Timeout Was Not Observed

Record:

No timeout observed during the 20-minute assessment window.

Do not report:

Session never expires.

unless you have evidence supporting that conclusion.

Mission Deliverables

Complete:

• scope confirmed

• authentication workflow mapped

• login transport assessed

• successful login captured safely

• authentication errors reviewed

• username-enumeration behavior assessed

• password controls reviewed

• rate limiting assessed within scope

• lockout behavior documented

• password recovery reviewed

• MFA reviewed where applicable

• session creation identified

• session rotation assessed

• session cookies reviewed

• Secure attribute reviewed

• HttpOnly reviewed

• SameSite reviewed

• storage mechanisms reviewed

• session persistence assessed

• logout tested

• timeout behavior documented

• sensitive-action reauthentication reviewed

• concurrent-session behavior assessed

• positive controls documented

• findings prioritized

• evidence redacted

• final report completed

Lab Report Template

# Lab 11 — Web Authentication & Session Security Assessment

## Executive Summary

## Mission Objective

## Scope

## Authentication Architecture

## Authentication Workflow

## Login Security

## Transport Security

## Authentication Error Handling

## Password Policy

## Rate Limiting

## Account Lockout

## Password Recovery

## Multi-Factor Authentication

## Session Creation

## Session Identifier Management

## Cookie Security

## Session Storage

## Session Rotation

## Session Expiration

## Logout Security

## Sensitive-Action Reauthentication

## Concurrent Sessions

## Positive Security Controls

## Security Findings

## Risk Prioritization

## Recommendations

## Evidence

## Limitations

## Lessons Learned

## Conclusion

Knowledge Check

Question 1 — What is the difference between authentication and session management?

Authentication verifies identity. Session management maintains that authenticated state across subsequent requests.

Question 2 — Why should login use HTTPS?

Because authentication credentials and session information require protection while travelling between the client and server.

Question 3 — Why use generic authentication errors?

They can reduce unnecessary disclosure about whether a particular account exists.

Question 4 — What does the Secure cookie attribute do?

It instructs the browser to send the cookie only over secure HTTPS connections.

Question 5 — What does HttpOnly do?

It prevents ordinary client-side JavaScript from directly accessing the cookie.

Question 6 — Is missing HttpOnly proof of session compromise?

No.

It removes a defense-in-depth control but does not itself demonstrate session theft.

Question 7 — Why should session identifiers change after authentication?

Rotation helps prevent a pre-authentication session identifier from continuing unchanged into an authenticated context.

Question 8 — Why must logout invalidate the server-side session?

Because removing a browser cookie or redirecting the user does not necessarily terminate the authenticated session maintained by the server.

Question 9 — What is an idle timeout?

A mechanism that terminates a session after a defined period without activity.

Question 10 — Why might sensitive actions require reauthentication?

Because an existing session may belong to an unattended or compromised browser, and high-impact changes warrant stronger confirmation of the user’s identity.

Skills Achieved

After completing this lab, you should understand:

• authentication architecture

• login workflow analysis

• HTTPS authentication protection

• authentication error handling

• username-enumeration concepts

• password-policy assessment

• rate-limiting concepts

• account-lockout analysis

• password-recovery security

• MFA fundamentals

• session creation

• session identifiers

• Secure cookies

• HttpOnly cookies

• SameSite

• session rotation

• browser storage

• idle and absolute timeout

• logout validation

• sensitive-action reauthentication

• concurrent sessions

• authentication evidence handling

• security finding development

• remediation planning

Professional Takeaway

Authentication testing is not:

“Try passwords until something works.”

A professional assessment asks:

“How does the application verify identity, resist automated abuse, recover accounts, establish authenticated state, protect session credentials, handle sensitive operations, and reliably terminate that state?”

The complete chain matters:

Credential → Authentication → Session → Authorization → Sensitive Action → Logout

A weakness anywhere in that chain can undermine otherwise strong controls.

What’s Next?

➡️ Lab 12 — Web Input Validation Security Assessment

You have now mapped the web application and evaluated how it authenticates users and protects their sessions.

The next step is to examine how the application handles user-controlled input.

You will assess authorized training inputs such as:

• search fields

• form fields

• query parameters

• JSON properties

• path parameters

• numeric values

• application-generated identifiers

• file names

• structured input

The focus will be on understanding:

Input → Validation → Processing → Output → Security Impact

You will learn how to distinguish:

Unexpected Input
       ↓
Interesting Behavior

from:

Validated Security Finding
       ↓
Evidence
       ↓
Business Impact

By the end of Lab 12, you should be able to answer:

“Does the application safely validate, process, and return user-controlled data across its identified input surfaces?”