Structure of JWT#

• Header: Contains metadata about the token, such as the algorithm used (HS256, RS256).
• Payload: Contains the claims or data (user information, roles). This part is base64-encoded and not encrypted.
• Signature: A hash of the header and payload signed with a secret key or private key.

  • Symmetric vs. Asymmetric Signing

    Symmetric (HS256): Uses the same secret key to sign and verify must be kept secure. Asymmetric (RS256): Uses a private key to sign (kept secret by the server) and a public key to verify (can be shared). More secure for distributed systems.

The Authentication Flow using JWT#

1. User submits credentials ( username and password) to the server.
2. Server verifies credentials against a database or identity provider.
3. If credentials are valid, server generates a JWT:
   • Header: Specifies algorithm ( {"alg": "HS256", "typ": "JWT"}).
   • Payload: Contains claims ( sub, iat, exp, role).
   • Signature: Signs header and payload using a secret key (for HMAC) or private key (for RSA).
   • Encodes header, payload, and signature in Base64, joining them with dots (.).
4. Server sends JWT to client ( in HTTP response, often as a cookie or in Authorization header).
5. Client stores JWT (in local storage, session storage, or cookie).
6. Client includes JWT in subsequent requests (in Authorization: Bearer <JWT> header).
7. Server Validates JWT
   • Server verifies:
     • Signature using secret key (HMAC) or public key (RSA).
     • Payload claims ( exp for expiration, iss for issuer).
   • If valid, grants access to requested resources.

What are JWT attacks?#

involve a user sending modified JWTs to the server in order to achieve a malicious goal. Typically, this goal is to bypass authentication and access controls by impersonating another user who has already been authenticated

Exploiting flawed JWT signature verification#

The server doesn’t actually know anything about the original contents of the token, or even what the original signature was. Therefore, if the server doesn’t verify the signature properly, there’s nothing to stop an attacker from making arbitrary changes to the rest of the token.

1. Accepting arbitrary signatures

   JWT libraries typically provide one method for verifying tokens and another that just decodes them.

   For example, the Node.js library jsonwebtoken has verify() and decode().

   Occasionally, developers confuse these two methods and only pass incoming tokens to the decode() method. This effectively means that the application doesn’t verify the signature at all.

   Mitigation: Never trust the payload until the signature is successfully validated

2. Accepting tokens with no signature

   his tells the server which algorithm was used to sign the token and, therefore, which algorithm it needs to use when verifying the signature.

   JWTs can be signed using a range of different algorithms, but can also be left unsigned. In this case, the alg parameter is set to none, which indicates a so-called “unsecured JWT”. Due to the obvious dangers of this, servers usually reject tokens with no signature. However, as this kind of filtering relies on string parsing, you can sometimes bypass these filters using classic obfuscation techniques, such as mixed capitalization and unexpected encodings.

   • Exploiting the “none” algorithm

     1. Decode the JWT
     2. Modify the Algorithm to “none” delete signature
        • none None NONE nOnE
     3. Send the Modified JWT: try to add = end of jwt

   • Mitigations

     1. Explicitly disable the “none” algorithm in your JWT library configuration
     2. Do not rely on defaults, enforce algorithm allowlists like RS256 or HS256

Brute-forcing weak secret keys#

Brute-forcing secret keys using hashcat

hashcat -a 0 -m 16500 <jwt> <wordlist>

forge JWTs

JWT header parameter injections#

1. Injecting self-signed JWTs via the jwk parameter

   jwk (JSON Web Key) - Provides an embedded JSON object representing the key.

   • Exploit this vulnerability explain

     1. Generates their own RSA key pair.
     2. Creates a JWT with a forged payload ( "user": "admin").
     3. Includes their public key in the header under the jwk field:
     4. Signs the token using their private key.
     5. Sends the token to the vulnerable service.

   • Exploit In Burp

     load the JWT Editor extension from the BApp store.

     1. In Burp Repeater, change edit jwt.
     2. Go to the JWT Editor Keys tab in Burp’s main tab bar.
     3. Click New RSA Key.
     4. In the dialog, click Generate to automatically generate a new key pair, then click OK to save the key. Note that you don’t need to select a key size as this will automatically be updated later.
     5. Burp Repeater and switch to the extension-generated JSON Web Token tab.
     6. At the bottom of the JSON Web Token tab, click Attack, then select Embedded JWK. When prompted, select your newly generated RSA key and click OK.
     7. In the header of the JWT, observe that a jwk parameter has been added containing your public key.
     8. Send the request to test how the server responds.

   Mitigation: Never accept keys from the token itself

2. Injecting self-signed JWTs via the jku parameter

   • jku (JSON Web Key Set URL) - Provides a URL from which servers can fetch a set of keys containing the correct key.
   • To exploit this vulnerability
     1. Generate their own RSA key pair.
     2. Host the public key on a server they control, either:
        • As a JWK set (for jku)
        • As an X.509 certificate (for x5u)
     3. Create a JWT with:
        • "alg": "RS256"
        • "jku": "https://attacker.com/jwks.json" or "x5u": "https://attacker.com/cert.pem"
     4. Sign the token using their private key.
     5. Send the forged token to the target application.
   • Mitigations
     1. Do not trust keys from arbitrary jku or x5u URLs.
     2. Implement an explicit allowlist of trusted domains for JWK and cert loading.

3. Injecting self-signed JWTs via the kid parameter

   the kid header parameter tells the server which public key to use to verify the JWT’s signature. Regardless of the location of the public key, the server generally looks for one that has the same kid as the one present in the JWT. However, depending on how the server manages the value of the kid, classic vulnerabilities such as SQL injection or path traversal can occur.

   • Exploiting IT
     1. Verify kid in Header: Check if the JWT header contains a kid parameter ({"alg": "HS256", "kid": "key-id"}).
     2. Test Path Traversal: Modify the kid to a path traversal sequence like ../../../../../../../dev/null.
     3. Modify Payload: Update the JWT payload to escalate privileges or bypass authentication.
     4. Create Null Signing Key:
        • In Burp Suite’s JWT Editor Keys, generate a new symmetric key for HS256.
        • Set the key to a Base64-encoded null byte (AA==) in the JWK.
     5. Sign Modified JWT:
        • In Burp Repeater’s JSON Web Token tab, update the header’s kid to the path traversal value.
        • Update the payload as needed.
        • Sign the token with the null key, ensuring Don’t modify header is selected.
     6. Send Request: Submit the modified JWT request to the server.
   • Mitigation
     1. Validate kid strictly — never allow user-controlled paths or queries
     2. Use allowlists of valid kid values with fixed file or key mappings