Skip to main content
CWECWE-287, CWE-306
WSTGWSTG-ATHN-01, WSTG-ATHN-02, WSTG-ATHN-03, WSTG-ATHN-04, WSTG-ATHN-05, WSTG-ATHN-06, WSTG-ATHN-07, WSTG-ATHN-08, WSTG-ATHN-09, WSTG-ATHN-10
MITRE ATT&CKT1078
CVSS Range6.5-9.8
Toolsburp, jwt_tool
Difficulty🔴 advanced

Authentication Bypass

Systematically test all authentication mechanisms — JWT, sessions, MFA, password reset, OAuth — for bypass opportunities. Escalate from indicators to demonstrated access with full evidence chains.

Quick Reference​

Attack Checklist​

JWT Attacks:

  • Algorithm confusion (RS256 -> HS256)
  • None algorithm variants (none, None, NONE, nOnE)
  • Weak secret brute force (hashcat, jwt_tool)
  • Claim manipulation (user, role, admin, exp)
  • JWK/JKU injection
  • Kid parameter injection (path traversal, SQLi)
  • Signature stripping
  • Token replay
  • Sensitive data exposed in claims

Session Attacks:

  • Session fixation (pre-auth token survives login)
  • Session prediction / low entropy
  • Session persistence after logout
  • Session persistence after password change
  • Concurrent session handling
  • Session token in URL (Referer leakage)
  • Cookie attributes: missing HttpOnly, Secure, SameSite
  • Session timeout (idle and absolute)

Credential Attacks:

  • Username/account enumeration (response diffs, timing)
  • Brute force with rate limit testing
  • Rate limit bypass (IP headers, case variations, null bytes)
  • Account lockout policy and bypass
  • Password complexity enforcement during registration
  • Credential stuffing with breached credentials
  • Data breach correlation (Have I Been Pwned)

MFA Attacks:

  • MFA step skip (access post-MFA endpoints directly)
  • MFA code brute force
  • MFA rate limit bypass
  • Backup code abuse (single-use? predictable?)
  • MFA disable without re-authentication
  • MFA scope gaps (API vs web vs mobile vs OAuth)

Password Reset:

  • Token prediction (sequential, timestamp-based)
  • Token leakage (Referer header, logs)
  • Host header poisoning
  • Parameter tampering (email substitution)
  • Token reuse after reset
  • Race conditions

Remember Me:

  • Token analysis and prediction
  • Token validity after password change
  • Long-lived tokens without encryption
  • Easily guessable tokens
  • Token expiration enforcement

OAuth/SSO:

  • Open redirect in redirect_uri
  • Missing or unvalidated state parameter
  • Authorization code injection across clients
  • Scope escalation
  • Token leakage via redirect manipulation

Test Credential Stuffing Defenses​

Correlate Data Breaches​

Check whether the target organization has credentials exposed in known data breaches. Use Have I Been Pwned or similar services to check for compromised corporate email addresses.

# Check if a domain has breached accounts (HIBP API)
curl -s "https://haveibeenpwned.com/api/v3/breachedaccount/user@TARGET" \
    -H "hibp-api-key: YOUR_KEY" \
    -H "User-Agent: PenTest"

If breached credentials are found for the target domain, test whether password reuse allows access. This is especially effective when combined with missing account lockout or rate limiting.

Detect Missing Defenses​

Test whether the application has defenses against automated credential stuffing:

  • Rate limiting on login endpoints
  • Account lockout after N failures
  • CAPTCHA or bot detection
  • Breach detection / credential screening during login

Enumerate Accounts​

Different error messages for "user not found" vs "incorrect password" reveal valid usernames.

# Compare responses for known-valid vs definitely-invalid usernames
valid_response=$(curl -s -X POST "https://TARGET/login" \
    -d "username=known_valid_user&password=wrong")
invalid_response=$(curl -s -X POST "https://TARGET/login" \
    -d "username=definitely_not_a_user_xyz&password=wrong")

# Compare: response body content, response length, response time, Set-Cookie headers

Use Timing Differences​

# Valid usernames may take longer (password hash comparison happens)
time curl -X POST "https://TARGET/login" -d "username=valid&password=wrong"
time curl -X POST "https://TARGET/login" -d "username=invalid&password=wrong"

Enumerate via Other Endpoints​

Also test for enumeration on:

  • Registration: "Email already in use"
  • Password reset: "No account with that email" vs "Reset link sent"
  • API: different status codes for existing vs non-existing users

Bypass Brute Force Protections​

Test Rate Limits​

for i in {1..100}; do
    response=$(curl -s -o /dev/null -w "%{http_code}" \
        -X POST "https://TARGET/login" \
        -d "username=admin&password=wrong${i}")
    echo "Attempt $i: $response"
    # Watch for: 429 Too Many Requests, lockout messages, CAPTCHA, increasing delays
done

Test Lockout Policy​

Determine whether the application locks accounts after failed attempts, and if so:

  • How many attempts trigger lockout?
  • How long does lockout last?
  • Does lockout apply per-IP or per-account?
  • Can lockout be used for denial-of-service against legitimate users?

Circumvent Rate Limits​

# IP rotation via headers
curl -H "X-Forwarded-For: 1.2.3.$((RANDOM % 255))" ...
curl -H "X-Real-IP: 1.2.3.$((RANDOM % 255))" ...
curl -H "X-Originating-IP: 1.2.3.$((RANDOM % 255))" ...
curl -H "True-Client-IP: 1.2.3.$((RANDOM % 255))" ...

# Username case variations
curl -d "username=Admin&password=test" ...
curl -d "username=ADMIN&password=test" ...
curl -d "username=admin &password=test" ...  # Trailing space

# Parameter pollution
curl -d "username=admin&username=attacker&password=test" ...

# Null byte injection
curl -d "username=admin%00&password=test" ...

Test Password Complexity​

During registration, test whether the application enforces password complexity:

# Try registering with weak passwords
curl -X POST "https://TARGET/register" -d "username=test&password=123456"
curl -X POST "https://TARGET/register" -d "username=test&password=password"
curl -X POST "https://TARGET/register" -d "username=test&password=a"

Weak password policies during registration mean users can set easily-guessable credentials, making brute force and credential stuffing far more effective.

Exploit Remember Me Functionality​

# Analyze remember-me cookie
echo "remember_token_value" | base64 -d

# Check for:
# - User ID embedded in token (change to impersonate)
# - Predictable token generation
# - No server-side validation
# - Long-lived without encryption
# - Easily guessable values
# - Token doesn't expire on password change

Test token validity after password change:

  1. Login with remember-me enabled
  2. Note the remember-me token
  3. Change password via settings
  4. Use the original remember-me token -- it should be invalidated but often is not

Assess Impact​

Verification Levels​

Level 1 -- Indicator (not reportable alone): Weak algorithm in JWT, missing cookie flags, timing differences, predictable token patterns. Requires further investigation.

Level 2 -- Confirmed Mechanism: JWT signature bypass accepted by server, MFA step skippable, password reset token predictable, rate limiting bypassable. Sufficient for informational report.

Level 3 -- Demonstrated Access: Access to another user's data, access to authenticated endpoints without credentials, persistent access through forged tokens. Medium-High severity.

Level 4 -- Full Compromise: Takeover of any arbitrary account, admin access without authorization, ability to create or modify credentials, persistent backdoor access. Critical severity. Submit with full evidence chain.

Write the PoC​

Evidence Requirements​

For every finding, provide:

  1. Request/response pairs showing the exact HTTP traffic
  2. Before and after -- show normal behavior, then the bypass
  3. Reproducible steps -- numbered list another tester can follow
  4. Impact demonstration -- what unauthorized data or functionality was accessed
  5. Affected scope -- which users or roles are affected

What NOT to Do​

  • Do not report JWT payload decoding as a vulnerability (payloads are not encrypted by design)
  • Do not assume algorithm confusion works without testing it against the server
  • Do not report missing cookie flags without demonstrating an exploit path
  • Do not brute force passwords against production accounts you do not own
  • Do not spam password reset emails to real users
  • Do not create multiple accounts to bypass rate limits (ToS violation)
  • Do not use automated tools without understanding what they report

False Positives to Avoid​

JWT non-issues: Readable payload (by design), using token before expiry, weak algorithm when server validates signatures correctly, cosmetic claims that do not affect authorization.

Session non-issues: Long session timeout (design decision), sessions persisting across browser close (often intentional), multiple concurrent sessions allowed (often intentional).

Rate limiting non-issues: Rate limits that add delays but still work, account lockout functioning correctly, CAPTCHA that blocks automated attempts.

Tools​

ToolPurpose
jwt_toolJWT analysis, algorithm confusion, claim tampering, brute force
hashcat -m 16500Offline JWT secret cracking
Burp SuiteRequest interception, session analysis, response manipulation
curlManual HTTP requests for all auth testing
ffuf / hydraCredential brute force (use within scope only)
Have I Been Pwned APIData breach correlation for target domain
nucleiAutomated auth vulnerability scanning templates

jwt_tool Quick Reference​

# Decode and analyze
python3 jwt_tool.py "$TOKEN"

# Test all known attacks
python3 jwt_tool.py "$TOKEN" -M at

# Brute force secret
python3 jwt_tool.py "$TOKEN" -C -d wordlist.txt

# Tamper claims
python3 jwt_tool.py "$TOKEN" -T -S hs256 -p "secret"

Prioritization​

Test these first (highest real-world exploitability)​

  1. JWT algorithm confusion and none attacks -- EPSS >0.8 for JWT bypass CVEs. These are trivial to exploit with jwt_tool and yield immediate full authentication bypass. Check algorithm handling first.
  2. MFA step skip (accessing post-MFA endpoints directly) -- Extremely common implementation flaw. Simply navigate to protected endpoints after password auth without completing MFA. High impact, zero complexity.
  3. Password reset token prediction and host header poisoning -- Password reset flows are frequently vulnerable. Host header poisoning and weak token generation are the most exploited patterns.

Test these if time permits (lower exploitability)​

  1. Session fixation and persistence after logout -- Requires specific conditions (session token in URL, no regeneration on login). Lower probability in modern frameworks but still worth testing.
  2. OAuth redirect_uri manipulation and state parameter abuse -- Requires OAuth/SSO integration. Complex exploitation chain but high impact when successful.
  3. Brute force with rate limit bypass -- Time-intensive, may trigger account lockouts. Test rate limit headers first; only attempt bypass if limits exist but seem bypassable.

Skip if​

  • No JWT, session, or token-based authentication is used (e.g., mutual TLS only)
  • Authentication is out of scope per engagement rules

Note: Even when using a managed identity provider (Auth0, Okta, Firebase Auth), still test application-layer auth decisions -- role mapping, token enrichment, session handling, and post-authentication authorization are where vulnerabilities hide.

Asset criticality​

Prioritize by access level: admin authentication > privileged user authentication > standard user authentication > public API authentication. Authentication bypass on admin endpoints is always Critical. Focus on endpoints that gate access to PII, financial data, or system configuration.