Is your JWT Secure ?

Listing out common misconfigurations in JWT

What is JWT ?

A JWT (JSON Web Token) is a string that contains a signed data structure, typically used to authenticate users. The JWT contains a cryptographic signature, for example a HMAC over the data. Because of this, only the server can create and modify tokens. This means the server can safely put userid=123 in the token and hand the token to the client, without having to worry that the client changes his user identifier. This way, authentication can be stateless: the server does not have to remember anything about the tokens or the users because all information is contained within the token.

The header

The header section of a JSON web token identifies the algorithm used to generate the signature. It is a base64url encoded string of a JSON blob like this:

{
 "alg" : "HS256",
 "typ" : "JWT"
}base64url encoded string: eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K

(Base64url encoding is a modified version of base64 for the URL format. It is similar to base64, but uses different non-alphanumeric characters and omits padding. )

The most common algorithms used are HMAC and RSA algorithms.The header almost contain data about the type of algorithm used, Key Identifier(KID) and other algorithmic specifications

The payload

The payload section contains the information that is actually used for identifying the user technical details. This section, too, is base64url encoded before being used in the token.The payload mostly contains data about the PII of the user and might leak some sensitive details too(which is dangerous).Other than this , there are also some JWT Payloads which are there for authenticity of the token( discussing later on)

{
 "user_name" : "admin",
}base64url encoded string: eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg

The signature

The signature is the part that is used to validate that the token has not been tampered with. It is calculated by concatenating the header with the payload, then signing with the algorithm specified in the header.

signature = HMAC-SHA256(base64urlEncode(header) + '.' + base64urlEncode(payload), secret_key)// Let's just say the value of secret_key is "key".-> signature function returns 4Hb/6ibbViPOzq9SJflsNGPWSk6B8F6EqVrkNjpXh7M

For this specific token, the string “eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K.eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg” is signed with the HS256 algorithm with the secret key “key”. The resulting string is 4Hb/6ibbViPOzq9SJflsNGPWSk6B8F6EqVrkNjpXh7M.

The complete token

You get the complete token by concatenating each section (header, payload, and signature) with a “.” in between each section.

eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K.eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg.4Hb/6ibbViPOzq9SJflsNGPWSk6B8F6EqVrkNjpXh7M

Common Misconfigurations and Vulnerabilities

Sensitive Data in JWT

JWTs may look like garbage to the naked eye, but actually they are just base64-encoded data. They are easily decoded, for example by using the website JWT.io. There may be sensitive information stored in the JWT, that is easily discovered this way

Modification with Signing Algorithm

Changing the algorithm to none :

If an application fails to verify the value of “alg” header, then we can change its value to “none” and this way it omits the need of a valid Signature for verification. For example:

// Modified Header of JWT after changing the "alg" parameter{
  "alg": "none",
  "typ": "JWT"
}

Changing the algorithm from RS256 to HS256 :

The two most common types of algorithms used for JWTs are HMAC and RSA. With HMAC, the token would be signed with a key, then later verified with the same key. As for RSA, the token would first be created with a private key, then verified with the corresponding public key.

As I have explained above RS256 algorithm needs a private key in order to tamper the data and a corresponding public key to verify the authenticity of the Signature. But if we able to change the signing algorithm from RS256 to HS256, we would force the Application to use only one key to do the both tasks which is the normal behaviour of the HMAC algorithm.

Hence, this way the workflow would convert from Asymmetric to Symmetric encryption and now we can sign the new tokens with the same public key.

Lab to try :

Go to this RS256 demo page. You get a RS256 signed token. Create a new token, set the algorithm to HS256 and sign it with the public key. Verify that the key is accepted.

Improper Signature Verification

It is also possible that the signature of the token is never verified after it arrives at the application. This way an attacker could simply bypass the security mechanism by providing an invalid signature.

Security Misconfiguration in Payload Claims

aud -This header defines the audience(application) for which the token is authorised for, if this header is missing from JWT Token, and there application for which you have implemented JWT, any attacker can use the same token in multiple applications.This can lead to Cross Service Relay Attack

exp -This header defines the expiration time of the token, after which the token will not be valid.So if JWT is missing exp token, then it could lead to session management vulnerabilities

nbf -This header defines the time after which the token will be valid, if this is not properly configured any attacker can leverage the token for greater amount of time again leading to session management vulnerabilities

jti -This header is used to uniquely identify the JWT token, which prevents the token from replaying, if this is missing any attacker can replay the token (specifically in case of financial applications) can lead to Token Replay Attack

KID Misconfigurations

KID stands for “Key ID”. It is an optional header field in JWTs, and it allows developers to specify the key to be used for verifying the token. The proper usage of a KID parameter looks like this:

{
 "alg" : "HS256",
 "typ" : "JWT",
 "kid" : "1"       // use key number 1 to verify the token 
}

Since this field is controlled by the user, it can be manipulated by attackers and lead to dangerous consequences.

1. Directory traversal

Since the KID is often used to retrieve a key file from the file system, if it is not sanitized before use, it can lead to a directory traversal attack. When this is the case, the attacker would be able to specify any file in the file system as the key to be used to verify the token.

“kid”: “../../public/css/main.css” // use the publicly available file main.css to verify the token

For example, the attacker can force the application into using a publicly available file as the key, and sign an HMAC token using that file.

2. SQL injection

The KID could also be used to retrieve the key from a database. In this case, it might be possible to utilize SQL injection to bypass JWT signing.

If SQL injection is possible on the KID parameter, the attacker can use this injection to return any value she wants.

“kid”: "aaaaaaa' UNION SELECT 'key';--"// use the string "key" to verify the token

For example, this above injection will cause the application to return the string “key” (since the key named “aaaaaaa” doesn’t exist in the database). The token will then be verified with the string “key” as the secret key.

Header parameter manipulation

In addition to a key ID, JSON web token standards also provide developers with the ability to specify keys via a URL.

JKU header parameter

JKU stands for “JWK Set URL”. It is an optional header field used to specify a URL that points to a set of keys that are used to verify the token. If this field is allowed and not properly restricted, an attacker could host their own key file and specify that the application uses it to verify tokens.

jku URL -> file containing JWK set -> JWK used to verify the token

JWK header parameter

The optional JWK (JSON Web Key) header parameter allows attackers to embed the key used to verify the token directly in the token.

X5U, X5C URL manipulation

Similar to the jku and jwk headers, the x5u and x5c header parameters allow attackers to specify the public key certificate or certificate chain used to verify the token. x5u specifies the information in the URI form while x5c allows the certificate values to be embedded in the token.

Other Security Issues

Attackers can brute force the secret key ( if the key used is guessable) and can create forged tokens.It is always advisable to make the secret key as hard as possible.Sometimes the authorisation token is secure, but the refresh token is very much vulnerable which may allow attacker to create forged tokens.So security must not only be kept for authorisation token , but also other parameters has to be taken in consideration