JSON Web Tokens (JWTs)
What are JWTs?
JSON Web Tokens (JWTs) are a standardized format for sending cryptographically signed JSON data between systems. They are most commonly used to send information (called “claims”) about users for authentication, session handling, and access control.
Unlike traditional session tokens, JWTs store all session-related data on the client-side, allowing servers to remain stateless. This makes them especially useful in distributed systems.
Note: Some labs may require the Burp Suite JWT Editor extension, which is available only in Burp Suite Community or Pro editions. If you’re using Linux and cannot access the extension due to an outdated cracked version, you can use the online JWT editor instead: token.dev
JWT Format
A JWT consists of three parts:
<Header>.<Payload>.<Signature>
Each part is Base64URL-encoded.
1. Header
Contains metadata about the type of token and the algorithm used for signing.
{
"alg": "HS256",
"typ": "JWT"
}
2. Payload
Contains the claims or actual data about the user or subject.
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
3. Signature
Generated by hashing the base64url-encoded header and payload with a secret key:
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret)
Any change to the header or payload invalidates the signature unless the attacker also possesses the secret key.
JWT vs JWS vs JWE
- JWT – General term for the JSON-based token.
- JWS (JSON Web Signature) – A signed JWT (most common).
- JWE (JSON Web Encryption) – An encrypted JWT (rare).
Most JWTs you see in the wild are actually JWS – signed but not encrypted. JWS ensures the message hasn’t been tampered with. JWE ensures message confidentiality.
What Are JWT Attacks?
JWT attacks involve modifying JWTs to bypass authentication or access controls. Attackers exploit flaws in how JWTs are created, verified, or handled by the server.
Examples of JWT Attack Goals:
- Impersonate another user
- Gain admin privileges
- Bypass login or access restrictions
Why JWT Attacks Happen
The JWT specification is flexible. This means developers can misconfigure implementations or make incorrect assumptions about how JWTs should be verified, often leading to vulnerabilities.
Exploiting Flawed JWT Signature Verification
If a server fails to verify the JWT signature properly, an attacker can manipulate the header and payload and forge tokens. Since the server doesn’t store JWT state, it can’t verify the original token content.
For Example:
{
"username": "admin",
"isAdmin": true
}
If the application trusts this token without verifying its signature, an attacker can escalate privileges or impersonate other users.
JWT Resources
Recommendations
- Always verify JWT signatures.
- Avoid using “none” as the algorithm in production.
- Rotate and protect signing keys.
- Use short expiration times and consider token revocation mechanisms.
Tip: If your version of Burp Suite doesn’t support JWT Editor, use token.dev to decode, edit, and re-sign JWTs during testing.