🔐 JWT Tampering: From Token to Admin Takeover (with PinewoodStore Demo)

👋 Welcome back to the blog!
Today we’re diving into the world of JWT Tampering. You’ll see how an attacker can go from a basic user to full-blown admin by exploiting insecure JWT implementations. We’ll walk through how JWTs work, common vulnerabilities, and top it off with a real-world demo using our intentionally vulnerable app — PinewoodStore.

Ready to hack some tokens? Let’s go. 😈

🧠 What is JWT Authentication?

JWT (JSON Web Token) is a compact, self-contained way to transmit information between parties securely. It’s often used for authentication in modern web applications and APIs.

Here’s what happens when a user logs in:

Server verifies credentials ✅
Server generates a JWT signed with a secret/private key 🧾🔑
Server sends this JWT back to the client
Client sends the JWT in every subsequent request using the Authorization header

🧱 Structure of a JWT

..

Each part is Base64URL-encoded and has a specific purpose:

1. Header

Purpose: Describes the token type and signing algorithm.
Format: Base64URL-encoded JSON.
Example Decoded:

{
  "alg": "HS256",  // Signing algorithm (e.g., HMAC-SHA256)
  "typ": "JWT"     // Token type
}

Key Fields:

alg: Algorithm used for the signature (HS256, RS256, ES256, etc.)
typ: Always "JWT" for standard tokens
kid (optional): Key ID – used for key rotation in systems with multiple signing keys

🔐 Security Note:

Header is not encrypted, only Base64URL-encoded.
Never accept tokens with alg: "none" — that means no signature at all!

2. Payload (Claims)

Purpose: Contains user data and metadata (claims).
Format: Base64URL-encoded JSON.
Example Decoded:

{
  "sub": "user123",       // Subject (user ID)
  "iat": 1516239022,      // Issued-at timestamp
  "exp": 1516242622,      // Expiration timestamp
  "roles": ["admin"],     // Custom claim
  "name": "John Doe"      // Custom claim
}

🔖 Standard Claims (from RFC 7519):

Claim	Purpose	Example
`sub`	Subject (user ID)	`"sub": "user123"`
`iat`	Issued at	Unix timestamp
`exp`	Expiration	Unix timestamp
`aud`	Audience	`"aud": ["api.example.com"]`
`iss`	Issuer	`"iss": "auth-server"`

✨ Custom Claims:

Used to store app-specific data, like roles, permissions, name, email, etc.
Do not store sensitive info (e.g., passwords) — payload is not encrypted!

3. Signature

Purpose: Verifies the token’s integrity and authenticity.

How It’s Created:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secretKey
)

Key Fields/Concepts:

Signing Algorithm: Depends on alg in the header (HS256, RS256, etc.)
Secret Key / Private Key: Used to sign the token
Signature: Final output of the algorithm; prevents tampering

✅ If the header or payload is modified, the signature becomes invalid unless the attacker has the signing key.

🔑 Bearer Token Usage

JWTs are typically included in the Authorization header when calling APIs:

GET /protected HTTP/1.1  
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

🛑 Common JWT Vulnerabilities

Let’s break down where things go wrong — and how attackers take over accounts like a boss. 🧠💥

1. 🚫 `alg: none` Vulnerability

If the server doesn’t enforce signature checks, an attacker can send an unsigned token:

{
  "alg": "none",
  "typ": "JWT"
}

💥 Exploit:

curl -H "Authorization: Bearer " http://target.com/api

✅ Fix: Always verify the signature and reject alg: none.

2. 🔄 Algorithm Confusion

If the server supports both RS256 (asymmetric) and HS256 (symmetric) without validation…

An attacker can forge an HS256 token using the public key as a secret.

jwt.encode({"sub": "admin"}, key=public_key, algorithm="HS256")

🔥 Boom! You’re admin.

✅ Fix: Lock down supported algorithms and enforce strict verification.

3. 🕒 Ignored Expiration

If the exp field isn’t checked, a token can be reused forever.

{
  "exp": 1600000000
}

🧪 Test:

curl -H "Authorization: Bearer " http://target.com/api

✅ Fix: Always validate exp.

4. 🔓 No Signature Verification

This is what we exploited in PinewoodStore 👇

Vulnerable Code:

private Map extractAllClaims(String token) {
    String[] parts = token.split("\\.");
    String payloadJson = new String(Base64.getUrlDecoder().decode(parts[1]));
    return objectMapper.readValue(payloadJson, Map.class);
}

😱 It just decodes the token without verifying the signature.

👿 Modify the payload to:

{
  "sub": "admin",
  "roles": ["admin"]
}

Then Base64 encode it and send it with the original header and signature. The server doesn’t care — you’re now admin.

🧪 Real-World Demo: PinewoodStore

Here’s how we take over an account using JWT tampering in PinewoodStore:

🧩 Steps:

Log in as a normal user → get a valid JWT
Decode the payload: { "sub": "user", "roles": ["user"] }
Modify to: { "sub": "admin", "roles": ["admin"] }
Base64 encode and rebuild the token
Send request with: Authorization: Bearer

💥 You’re now in the admin panel!

📊 JWT Testing Matrix

Test Case	Should Be Rejected?
1. `alg: none`	✅ Yes
2. Expired token	✅ Yes
3. Tampered payload	✅ Yes
4. Algorithm switch	✅ Yes
5. Missing signature	✅ Yes

🧪 Tools to Help You Hack JWTs

🔧 jwt_tool – Modify, sign, test tokens
🔍 Burp Suite JWT Scanner Extension
🧪 Postman for quick token tests
🔐 jwt.io debugger

✅ JWT Security Best Practices

🔒 Always verify the signature
❌ Never accept alg: none
📉 Enforce token expiration
⛔ Don’t put sensitive info in the payload
🔐 Use strong secrets (for HS256)
🧾 Prefer short-lived access tokens and refresh tokens
✅ Implement role-based access control on the server

🧠 Summary

JWTs are powerful, but power without control is dangerous.
As shown in PinewoodStore, skipping a simple signature check can lead to full account takeover.

So next time you build or audit a JWT-based app, ask:

🤔 “What happens if someone tampers with this token?”

If the answer is “Nothing”, then you’re doing it right. 🙌