Vapt Auth

Authentication & Session Testing

When Invoked

The user runs /vapt auth <url> or this skill is triggered as part of Wave 3 during /vapt audit.

Prerequisites

Check for existing context:

• If VAPT-SCAN.md exists → use discovered login pages and auth endpoints
• If VAPT-WAVE2-CONTEXT.md exists → use discovered services requiring auth
• If no context → look for /login, /signin, /auth, /api/auth, /wp-login.php

Phase 1: Authentication Mechanism Analysis

1.1 Identify Auth Type

# Check for login forms
curl -sL <url>/login | grep -i '<form\|<input\|password\|username\|email'

# Check for HTTP auth
curl -sI <url>/admin | grep -i www-authenticate

# Check for API auth
curl -sI <url>/api | grep -i authorization
curl -sI <url>/api | grep -i x-api-key

Classify the authentication mechanism:

• Form-based (username/password)
• HTTP Basic/Digest Auth
• OAuth 2.0 / OpenID Connect
• JWT (Bearer tokens)
• API Key
• SAML/SSO
• Multi-factor authentication

1.2 Password Policy Analysis

If a registration form exists:

1. Attempt to register with weak passwords to discover the policy
2. Check minimum length, complexity requirements
3. Check for password strength meter
4. Check if common passwords are blocked

Phase 2: Brute Force Resistance

2.1 Rate Limiting

Send 10 rapid login attempts with wrong credentials:

for i in $(seq 1 10); do
    curl -s -o /dev/null -w "%{http_code}" -X POST <url>/login -d "username=test&password=wrong$i"
done

Check:

• Does the server rate-limit after N failures?
• Is there an account lockout mechanism?
• Are CAPTCHA/challenge mechanisms triggered?
• Does the error message change (indicating lockout)?

2.2 Username Enumeration

Test if the application reveals valid usernames:

# Compare responses for valid vs invalid usernames
curl -s -X POST <url>/login -d "username=admin&password=wrong"
curl -s -X POST <url>/login -d "username=nonexistent12345&password=wrong"

Compare: response body, status code, response time, headers. Differences indicate username enumeration.

Also check:

• Registration endpoint (does it say "email already exists"?)
• Password reset (does it say "user not found"?)
• API responses with different error messages

2.3 Default Credentials

Only test a small set of well-known defaults (not brute force):

• admin/admin, admin/password, admin/123456
• root/root, root/password
• test/test, user/user, guest/guest
• CMS-specific defaults based on detected CMS

Phase 3: Session Management

3.1 Session Token Analysis

After successful login (or by examining Set-Cookie headers):

curl -sI <url>/login -X POST -d "username=test&password=test" | grep -i set-cookie

Analyze tokens for:

• Length: Should be >= 128 bits (16+ characters)
• Entropy: Should appear random (no sequential patterns)
• Predictability: Collect 10+ tokens and check for patterns
• Cookie flags: HttpOnly, Secure, SameSite (checked in vapt-headers)

3.2 Session Fixation

1. Get a session token before authentication
2. Authenticate with that token
3. Check if the token changes after login

If the token remains the same → Session fixation vulnerability.

3.3 Session Expiration

• Does the session expire after a reasonable period of inactivity?
• Is the session invalidated server-side after logout?
• Can the old session token be reused after logout?

# Login, get token, logout, try to use old token
TOKEN=$(curl -s -c - <url>/login -X POST -d "..." | grep session)
curl -s <url>/logout -b "session=$TOKEN"
curl -s <url>/dashboard -b "session=$TOKEN"  # Should fail

Phase 4: JWT Analysis

4.1 JWT Detection

If the application uses JWTs (in Authorization header or cookies):

# Decode JWT (header and payload are base64)
echo "<token>" | cut -d. -f1 | base64 -d 2>/dev/null
echo "<token>" | cut -d. -f2 | base64 -d 2>/dev/null

4.2 JWT Vulnerability Checks

4.3 JWT none Algorithm

# Craft a JWT with algorithm "none"
# Header: {"alg":"none","typ":"JWT"}
# Payload: modify claims (e.g., change user role)
# Signature: empty

Try to access protected endpoints with the forged token.

Phase 5: OAuth Testing

5.1 OAuth Flow Analysis

If OAuth is detected:

5.2 Redirect URI Testing

# Test redirect_uri manipulation
curl -sI "<oauth_url>?client_id=<id>&redirect_uri=https://evil.com&response_type=code"
curl -sI "<oauth_url>?client_id=<id>&redirect_uri=https://legit.com.evil.com&response_type=code"
curl -sI "<oauth_url>?client_id=<id>&redirect_uri=https://legit.com%40evil.com&response_type=code"

Phase 6: MFA Analysis

If MFA is detected:

Phase 7: Password Reset

7.1 Reset Flow Analysis

Phase 8: Output

Terminal Output

Dev mode: Explain each auth vulnerability, how it can be exploited, and best practices for secure authentication.

Pro mode: Findings table only.

VAPT-AUTH.md

# VAPT Authentication & Session Report

## Target: <url>
## Date: <timestamp>

## Authentication Mechanism
| Type | Details |
|------|---------|
| Method | ... |
| MFA | ... |
| Password Policy | ... |

## Brute Force Resistance
| Check | Status |
|-------|--------|
| Rate limiting | ... |
| Account lockout | ... |
| CAPTCHA | ... |
| Username enumeration | ... |

## Session Management
| Check | Status |
|-------|--------|
| Token entropy | ... |
| Session fixation | ... |
| Logout invalidation | ... |
| Cookie flags | ... |

## JWT Analysis (if applicable)
<findings>

## OAuth Analysis (if applicable)
<findings>

## Findings
<scored findings table>

## Suggested Next Steps
- /vapt authz <url> — test authorization controls
- /vapt inject <url> — test for injection via auth parameters

Cross-Skill Integration

• Auth findings weight 15% in Security Posture Score
• Weak auth informs vapt-authz (easier to test access control with authenticated sessions)
• JWT findings inform vapt-api testing