CWICP: Authentication and Session Management Testing

This domain tests whether you can break or validate the full identity lifecycle: enrollment, login, MFA, session issuance, session lifetime, and logout. Expect questions on token formats, cookie flags, and the specific logic flaws that survive otherwise strong cryptography.

What to test

• Enumeration. Differential responses, status codes, or timing on valid vs invalid usernames; registration and password-reset forms are the usual leaks.
• Credential defenses. Rate limiting per account and per IP, lockout thresholds (and lockout as a denial-of-service vector), password policy realism, breached-password checks.
• MFA. Response manipulation (flipping success:false), OTP brute force when there is no per-session attempt cap, backup codes, "remember this device" cookies, and MFA enrollment that can be skipped or reset via email only.
• Session fixation and lifecycle. Does the session identifier rotate at login? Is the pre-auth token accepted post-auth? Does logout invalidate server-side state, or only delete the cookie? Does a password change kill other sessions?
• JWT. Test alg:none, RS256-to-HS256 confusion using the public key as an HMAC secret, kid path traversal or SQL injection, jku/x5u pointing at attacker-controlled keys, missing exp validation, and trusted role claims.
• OAuth/OIDC. redirect_uri validation (prefix, subdomain, path traversal, open redirect), missing or unbound state, implicit-flow token leakage in fragments and Referer, PKCE downgrade.
• Password reset. Host-header poisoning of the reset link, predictable or reusable tokens, tokens not bound to the user, reset invalidating nothing.

Worked example

A login returns a JWT with header {"alg":"HS256"} and body {"sub":"1042","role":"user","exp":1893456000}. The server publishes /jwks.json with an RSA public key and accepts tokens from multiple clients. Reasoning: if the library selects the verification algorithm from the token header, signing an HS256 token with the RSA public key bytes as the HMAC secret will validate. That is a full authentication bypass; confirm by changing role to admin and calling an admin endpoint. Note the exp value is years out - a second, lower-severity finding about token lifetime.

Traps that cost marks

• Assuming the session dies at logout because the cookie disappeared in the browser.
• Treating Base64 as protection - decode, edit, re-encode.
• Testing account lockout against one account and declaring no lockout exists.
• Reporting alg:none as exploitable without confirming the library still honors it.