Ethical Hacking

🛡️ Ethical Hacking — Day 22

Authentication Testing & Session Security Lab

⚠️ LEARNING PURPOSE ONLY: This tutorial is strictly for educational and defensive cybersecurity learning. Perform all practical exercises only against your local OWASP Juice Shop lab, applications you own, or systems for which you have explicit authorization. Never test credentials, sessions, or authentication mechanisms on public websites or accounts without permission.

Welcome to Day 22.

Yesterday we learned the fundamentals of authentication, password hashing, cookies, sessions, MFA, rate limiting, and password-reset security.

Today we'll turn that knowledge into a structured authentication-security assessment.

🎯 Today's Objectives

By the end of Day 22, you should understand how to:

Analyze a login request
Identify authentication parameters
Inspect authentication responses
Analyze session cookies
Understand session lifecycle
Test logout behavior safely
Understand session fixation
Identify authentication errors
Observe rate limiting without attacking accounts
Analyze password-reset design
Understand MFA security
Review authentication code
Use Burp Suite
Perform the same practical work on Linux, Windows and macOS
Write an authentication-security finding

1. Authentication Testing Methodology

Use this workflow:

Permission
    ↓
Scope
    ↓
Login Page
    ↓
Capture Request
    ↓
Analyze Response
    ↓
Session Creation
    ↓
Authenticated Request
    ↓
Logout
    ↓
Session Invalidation
    ↓
Security Review
    ↓
Report

The objective is not to break into an account.

The objective is to determine whether the authentication system is implemented securely.

2. Start Your Lab

Linux

docker ps

Windows PowerShell

docker ps

macOS

docker ps

If Juice Shop isn't running:

docker start <container-id>

Verify:

Linux/macOS

curl -I http://127.0.0.1:3000

Windows

curl.exe -I http://127.0.0.1:3000

3. Start Burp Suite

Open:

Burp Suite
   ↓
Proxy
   ↓
Open Browser

Navigate to:

http://127.0.0.1:3000

Set the Burp target scope to:

127.0.0.1:3000

This prevents accidentally mixing your lab traffic with unrelated websites.

4. Create a Test Account

If your local Juice Shop setup allows registration, create a dedicated lab account.

Use something like:

Email:
day22-test@example.test

Password:
Lab-Only-Password-2026!

Do not use your real password.

Keep the credentials only inside your local lab.

5. Capture the Login Request

Then open:

Proxy
 ↓
HTTP history

Find the login request.

It may look conceptually like:

POST /rest/user/login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json

with a body containing authentication information.

Your application may use a different endpoint, so always analyze the request generated by your installation.

6. Record the Login Request

Create this table:

Property	Value
Method	___
Endpoint	___
Content-Type	___
Authentication fields	___
HTTPS	Yes/No
Response status	___

Never put a real password into a public report.

Use:

<REDACTED>

7. Analyze the Response

After successful authentication, inspect:

HTTP response

Look for:

Set-Cookie
Authorization
Token
Session
Redirect

For example:

HTTP/1.1 200 OK
Set-Cookie: ...

or:

{
    "authentication": {
        "token": "..."
    }
}

Do not copy actual tokens into your notes.

8. Why Tokens Matter

A session token is effectively a temporary credential.

Think:

Password
   ↓
Authentication
   ↓
Session Token
   ↓
Authenticated Requests

Therefore:

A session token should be treated as sensitive as a password.

9. Session Cookie Inspection

Open browser Developer Tools.

For Chromium-based browsers:

Developer Tools
   ↓
Application
   ↓
Storage
   ↓
Cookies

Inspect your local application's cookies.

Record only:

Cookie name:
Secure:
HttpOnly:
SameSite:
Path:
Domain:
Expiration:

Do not record the cookie value.

10. Cookie Security

A sensitive session cookie should generally use:

Secure
HttpOnly
SameSite

Secure

Cookie
  ↓
HTTPS only

HttpOnly

Cookie
  ↓
Not directly readable by normal JavaScript

SameSite

Cookie
  ↓
Controls certain cross-site request behavior

These protections are complementary.

11. Capture an Authenticated Request

After login, visit a page that requires authentication.

For example:

Profile
Account
Orders

Capture the request in Burp.

You might see:

GET /some/protected/resource HTTP/1.1
Host: 127.0.0.1:3000
Cookie: ...

or a token-based authorization header.

12. Compare Before and After Login

This is a useful authentication test.

Before authentication

GET /protected-resource
        ↓
401 / 403 / redirect

After authentication

GET /protected-resource
        ↓
200 OK

This demonstrates:

Authentication State
        ↓
Access Decision

13. Send the Authenticated Request to Repeater

Right-click:

Send to Repeater

Then send the request.

Record:

Status:
Response length:
Authentication mechanism:

Don't modify the token yet.

This is your baseline.

14. Logout Testing

Now log out normally.

Then repeat the previously captured authenticated request.

Observe:

Before logout:
200 OK

After logout:
?

A secure application should invalidate the session appropriately.

If the same authenticated session continues to work after logout, investigate further.

15. Logout Security Flow

Secure design:

LOGIN
  ↓
SESSION CREATED
  ↓
AUTHENTICATED REQUESTS
  ↓
LOGOUT
  ↓
SESSION INVALIDATED
  ↓
OLD SESSION
  ↓
REJECTED

The exact behavior depends on the application's session architecture.

16. Session Invalidation

A common mistake is:

Logout
 ↓
Delete cookie in browser

while the server-side session remains valid.

A stronger design is:

Logout
 ↓
Invalidate server session
 ↓
Expire/remove client cookie

This reduces the chance that an old session remains usable.

17. Session Fixation

Session fixation is a session-management problem.

Conceptually:

Attacker
   ↓
Known/controlled session identifier
   ↓
Victim authenticates
   ↓
Same session remains authenticated

The important defense is:

Before authentication
      ↓
Session ID A

After authentication
      ↓
Session ID B

The identifier should be regenerated when the user's authentication state changes.

18. Testing Session Regeneration

In your local lab, record the session identifier only as a redacted fingerprint, not the actual value.

For example:

Before login:
Session = [REDACTED-A]

After login:
Session = [REDACTED-B]

If the application uses a session cookie and you can safely inspect it:

Before:
A

After:
B

A change after authentication is generally desirable.

Don't expose actual session tokens.

19. Authentication Errors

Try an invalid login using your local test account.

For example:

Email:
day22-test@example.test

Password:
Definitely-Wrong-Lab-Password

Observe the response.

Does it reveal:

User exists

versus:

User doesn't exist

20. Account Enumeration

Consider:

Existing account:
"Incorrect password"

Non-existing account:
"User not found"

This can allow someone to determine which accounts exist.

A more consistent response might be:

"Invalid email or password."

The exact implementation should balance security, usability, and operational needs.

21. Timing Differences

Applications should also consider whether authentication failures produce substantially different processing behavior depending on whether an account exists.

For example:

Existing user:
200 ms

Non-existing user:
20 ms

A consistent error message alone doesn't necessarily eliminate all enumeration channels.

However, timing measurements can be noisy and should be interpreted carefully.

For your lab:

Focus on understanding the concept rather than trying to build a large-scale enumeration tool.

22. Rate Limiting

Authentication endpoints should resist excessive automated attempts.

A secure system may implement:

Attempt
   ↓
Attempt
   ↓
Attempt
   ↓
Too many attempts
   ↓
Slow down / temporary restriction

You don't need to perform hundreds of attempts.

23. Safe Rate-Limit Test

Use your own local test account.

Make only a small number of intentionally incorrect attempts manually.

For example:

Attempt 1 → wrong password
Attempt 2 → wrong password
Attempt 3 → wrong password

Observe whether the application:

Returns an error
Slows down
Temporarily restricts attempts
Shows a CAPTCHA
Provides another security response

Stop there.

The objective is to understand the control, not to brute-force the account.

24. Why Rate Limiting Matters

Without rate limiting:

Login
 ↓
Password guess
 ↓
Password guess
 ↓
Password guess
 ↓
Thousands of guesses

With protection:

Login
 ↓
Few attempts
 ↓
Rate limit
 ↓
Attack becomes expensive

25. Password Reset Testing

Find the application's:

Forgot Password

feature.

Use only your own local test account.

Capture the request.

Record:

Method:
Endpoint:
Response:
Token mechanism:
Expiration:

Don't send the reset token anywhere outside your local lab.

26. Secure Password Reset

A secure reset token should be:

Random
Unpredictable
Short-lived
Single-use
Bound to the reset request

Conceptually:

Forgot Password
       ↓
Random Reset Token
       ↓
Email / Recovery Channel
       ↓
Reset Password
       ↓
Token Invalidated

27. Password Reset Enumeration

Be careful with responses such as:

"Email sent because this account exists."

versus:

"No account exists."

A more privacy-preserving response can be:

"If an account exists, reset instructions will be sent."

This reduces account enumeration.

28. MFA Security

If your lab application supports MFA, understand:

Password
   +
Second Factor
   ↓
Authenticated

The second factor could be:

Authenticator app
Security key
OTP
Biometric

MFA makes stolen passwords less useful by requiring another authentication factor.

29. MFA Verification Should Also Be Protected

Don't protect only:

Password login

while leaving:

OTP verification

unprotected.

MFA endpoints should also have appropriate:

Rate limiting
Attempt limits
Expiration
Replay protection
Secure recovery

30. Authentication Architecture

A secure high-level design:

                 USER
                   │
                   ▼
              HTTPS LOGIN
                   │
                   ▼
          ┌──────────────────┐
          │ Authentication   │
          │ Service          │
          └────────┬─────────┘
                   │
            Password Verifier
                   │
                   ▼
             User Database
                   │
                   ▼
              MFA / Risk
                   │
                   ▼
             New Session
                   │
                   ▼
             Secure Cookie
                   │
                   ▼
           Authorization Layer
                   │
             ┌─────┴─────┐
             ▼           ▼
           ALLOW        DENY

31. Linux Practical Session

Check Docker

docker ps

Check the application

curl -I http://127.0.0.1:3000

Verbose headers

curl -v http://127.0.0.1:3000/

Through Burp

curl -x http://127.0.0.1:8080 \
http://127.0.0.1:3000/

32. Linux — Inspect Response Cookies

For your local application:

curl -i http://127.0.0.1:3000/

Look for:

Set-Cookie

Don't copy session values into your report.

You can redact them:

Set-Cookie: session=[REDACTED]

33. Windows Practical Session

Docker

docker ps

Headers

curl.exe -I http://127.0.0.1:3000

Verbose

curl.exe -v http://127.0.0.1:3000/

Through Burp

curl.exe -x http://127.0.0.1:8080 `
http://127.0.0.1:3000/

34. Windows — Cookie Header

curl.exe -i http://127.0.0.1:3000/

Look for:

Set-Cookie

Record only attributes.

Never publish:

session=actual-secret-value

35. macOS Practical Session

docker ps

Check headers:

curl -I http://127.0.0.1:3000

Verbose:

curl -v http://127.0.0.1:3000/

Through Burp:

curl -x http://127.0.0.1:8080 \
http://127.0.0.1:3000/

36. macOS — Cookie Analysis

curl -i http://127.0.0.1:3000/

Look for:

Set-Cookie

Document:

Secure:
HttpOnly:
SameSite:
Path:

Keep the actual value redacted.

37. Burp Repeater Workflow

Your authentication-testing workflow should be:

Login
  ↓
Capture
  ↓
Send to Repeater
  ↓
Record baseline
  ↓
Logout
  ↓
Replay
  ↓
Compare

This is much safer than automated attack tooling.

38. Burp HTTP History

Review:

Proxy
 ↓
HTTP history

Look for:

Login
Logout
Profile
Account
Password reset
MFA
Protected API

Create a small map:

/login
   ↓
/profile
   ↓
/account
   ↓
/logout

This helps you understand the authentication lifecycle.

39. Authentication Request Map

Create:

┌─────────────┐
│ Login       │
└──────┬──────┘
       ↓
┌─────────────┐
│ Session     │
└──────┬──────┘
       ↓
┌─────────────┐
│ Protected   │
│ Resource    │
└──────┬──────┘
       ↓
┌─────────────┐
│ Logout      │
└──────┬──────┘
       ↓
┌─────────────┐
│ Session     │
│ Invalidated │
└─────────────┘

40. Authentication Code Review

When reviewing your own application, search for:

login
authenticate
password
session
cookie
logout
reset
token
MFA

Then ask:

Is the password hashed?
Is the session regenerated?
Are cookies protected?
Is rate limiting present?
Does logout invalidate the session?
Are reset tokens random?
Are reset tokens single-use?
Is MFA protected?

41. Laravel Review

Laravel's authentication ecosystem provides mature mechanisms.

For passwords:

Hash::make($password);

Verification:

Hash::check($password, $hash);

Don't manually implement:

md5()
sha1()
sha256()

for password storage.

42. Laravel Session

After authentication, use Laravel's built-in authentication/session mechanisms rather than creating your own session-token system.

For sensitive authentication changes, ensure session regeneration is handled appropriately.

Example:

$request->session()->regenerate();

The exact implementation should follow the authentication flow and current Laravel guidance.

43. Spring Security

For Spring Boot applications, prefer Spring Security rather than manually building:

Login
Password verification
Session handling
CSRF
Authentication filters

Spring Security provides established security components.

Use:

PasswordEncoder

for password verification/storage.

44. Secure Authentication Code Principle

Avoid:

Custom crypto
Custom session IDs
Custom password hashing
Custom authentication protocol

Prefer:

Framework
   ↓
Mature security library
   ↓
Secure defaults
   ↓
Configuration

45. Common Authentication Vulnerabilities

During a security review, watch for:

☐ Plaintext passwords
☐ Weak password hashing
☐ No rate limiting
☐ Account enumeration
☐ Weak session IDs
☐ Session fixation
☐ Session not invalidated on logout
☐ Missing Secure flag
☐ Missing HttpOnly
☐ Weak SameSite configuration
☐ Session IDs in URLs
☐ Weak password reset
☐ Missing MFA for sensitive accounts
☐ Poor authorization checks

46. Authentication Testing vs Credential Attacking

These are not the same.

Authentication testing

Inspect
Analyze
Review
Capture
Compare
Document

Credential attack

Thousands of guesses
Password spraying
Credential stuffing
Automated login attempts

Today's training focuses on the first category.

47. Day 22 Main Practical Challenge

Perform a complete authentication review of your local Juice Shop account.

Step 1

Step 2

Capture the login request.

Step 3

Record:

Method
Endpoint
Content-Type
Response

Step 4

Inspect the authentication response.

Step 5

Inspect the session cookie/token.

Step 6

Access a protected page.

Step 7

Capture the authenticated request.

Step 8

Logout.

Step 9

Replay the old authenticated request.

Step 10

Observe whether the session remains valid.

Step 11

Perform a small number of invalid login attempts.

Step 12

Observe the application's rate-limit behavior.

Step 13

Inspect the password-reset workflow if available.

📊 Day 22 Lab Report

╔══════════════════════════════════════╗
║   DAY 22 — AUTHENTICATION REVIEW     ║
╚══════════════════════════════════════╝

Target:
127.0.0.1:3000

Login Endpoint:
________________________

HTTP Method:
________________________

Content-Type:
________________________

Successful Status:
________________________

Session Mechanism:
Cookie / Token / Other

Cookie Name:
________________________

Secure:
Yes / No / Unknown

HttpOnly:
Yes / No / Unknown

SameSite:
________________________

Protected Resource:
________________________

Before Login:
________________________

After Login:
________________________

Session Regenerated:
Yes / No / Unknown

Logout Performed:
Yes / No

Old Session After Logout:
Valid / Invalid / Unknown

Rate Limiting:
Observed / Not Observed / Unknown

Password Reset:
________________________

MFA:
________________________

Potential Finding:
________________________

Risk:
Low / Medium / High / Critical / Informational

Recommendation:
________________________

📝 Day 22 Assignment

Answer these:

What is authentication testing?
Why should authentication requests be captured?
What information should you record from a login request?
Why are session tokens sensitive?
What are Secure, HttpOnly, and SameSite?
What is session fixation?
Why should sessions be regenerated after authentication?
Why should logout invalidate the server-side session?
What is account enumeration?
Why should authentication responses be carefully designed?
What is rate limiting?
Why should MFA verification also be protected?
What makes a password-reset token secure?
Why shouldn't session IDs appear in URLs?
Why should you avoid custom authentication implementations?
Why shouldn't you perform large numbers of password guesses during a normal security review?
What is the difference between authentication and authorization?
Why should authenticated requests be tested after logout?
Why should session values be redacted from security reports?
What should a professional authentication-security report contain?

🏆 Day 22 Challenge

Create this complete security diagram:

                   USER
                     │
                     ▼
              ┌─────────────┐
              │ LOGIN       │
              └──────┬──────┘
                     │
                     ▼
             PASSWORD HASHING
                     │
                     ▼
                MFA / RISK
                     │
                     ▼
             SESSION CREATED
                     │
                     ▼
              SECURE COOKIE
                     │
                     ▼
          ┌──────────────────┐
          │ AUTHENTICATED    │
          │ REQUEST           │
          └────────┬─────────┘
                   │
                   ▼
             AUTHORIZATION
                   │
             ┌─────┴─────┐
             ▼           ▼
           ALLOW        DENY
             │
             ▼
          RESOURCE
             │
             ▼
           LOGOUT
             │
             ▼
       SESSION INVALIDATED

Add:

Rate Limiting
Password Reset
Audit Logging
Session Timeout

🔐 Day 22 Golden Rules

Rule 1

Treat session tokens as credentials.

Rule 2

Authentication is only one part of application security.

Rule 3

A secure logout must invalidate the authenticated state.

Rule 4

Use established authentication frameworks instead of inventing your own.

Rule 5

Test safely with your own local account. Don't turn a security review into a credential attack.

📚 Day 22 Summary

Today you practiced:

Login request analysis
Authentication response analysis
Session cookies
Cookie security attributes
Authenticated requests
Logout testing
Session invalidation
Session fixation
Account enumeration
Rate limiting
Password reset
MFA
Burp Suite
Browser Developer Tools
Laravel authentication concepts
Spring Security concepts
Linux commands
Windows PowerShell commands
macOS commands
Authentication reporting

🔑 Most Important Lesson

LOGIN
  ↓
AUTHENTICATE
  ↓
CREATE SECURE SESSION
  ↓
AUTHORIZE EVERY REQUEST
  ↓
LOGOUT
  ↓
INVALIDATE SESSION

Authentication security is not just about protecting the password.

It is about protecting the entire identity and session lifecycle.

🔐 LEARN → PRACTICE IN YOUR LAB → ANALYZE → DOCUMENT → SECURE

🔜 Day 23 — Broken Access Control & IDOR

Tomorrow we'll move to another critical web-security category:

Authentication vs authorization
Access-control models
Horizontal privilege escalation
Vertical privilege escalation
IDOR / BOLA
Object-level authorization
API authorization
Safe Burp Repeater testing
Laravel authorization
Spring Security authorization
Linux, Windows & macOS practical exercises
Writing an access-control security report

⚠️ LEARNING PURPOSE ONLY: All practical exercises will remain inside your local/authorized lab environment.

Author Description

Author Social Links

Post Page Advertisement [Top]

Ethical Hacking — Authentication Testing & Session Security Lab | Day 22

🛡️ Ethical Hacking — Day 22

Authentication Testing & Session Security Lab

🎯 Today's Objectives

1. Authentication Testing Methodology

2. Start Your Lab

Linux

Windows PowerShell

macOS

Linux/macOS

Windows

3. Start Burp Suite

4. Create a Test Account

5. Capture the Login Request

6. Record the Login Request

7. Analyze the Response

8. Why Tokens Matter

9. Session Cookie Inspection

10. Cookie Security

Secure

HttpOnly

SameSite

11. Capture an Authenticated Request

12. Compare Before and After Login

Before authentication

After authentication

13. Send the Authenticated Request to Repeater

14. Logout Testing

15. Logout Security Flow

16. Session Invalidation

17. Session Fixation

18. Testing Session Regeneration

19. Authentication Errors

20. Account Enumeration

21. Timing Differences

22. Rate Limiting

23. Safe Rate-Limit Test

24. Why Rate Limiting Matters

25. Password Reset Testing

26. Secure Password Reset

27. Password Reset Enumeration

28. MFA Security

29. MFA Verification Should Also Be Protected

30. Authentication Architecture

31. Linux Practical Session

Check Docker

Check the application

Verbose headers

Through Burp

32. Linux — Inspect Response Cookies

33. Windows Practical Session

Docker

Headers

Verbose

Through Burp

34. Windows — Cookie Header

35. macOS Practical Session

36. macOS — Cookie Analysis

37. Burp Repeater Workflow

38. Burp HTTP History

39. Authentication Request Map

40. Authentication Code Review

41. Laravel Review

42. Laravel Session

43. Spring Security

44. Secure Authentication Code Principle

45. Common Authentication Vulnerabilities

46. Authentication Testing vs Credential Attacking

Authentication testing

Credential attack

47. Day 22 Main Practical Challenge

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6