JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. A JSON web token comprises of three key components: a header, a payload, and a signature.
Ways to bypass JWT Controls
If JWT is not implemented properly, there are ways that an attacker can bypass the security mechanism and forge arbitrary tokens.
Changing up the Algorithm Type
None algorithm
JWT supports “none” algorithm. Any token would be considered valid if the alg field is set to “none” and signature section is set to empty. This feature was originally used for debugging purposes and if not turned off in a production environment, it would allow attackers to forge any token by setting the alg field to “none”.
2. HMAC algorithm
The most commonly used algorithms for JWTs are HMAC and RSA. In RSA algorithm implementation of JWTs, private keys are used by the server to sign the payload, and clients can verify the JWT using the public key. Similarly, the server will use the public key to confirm the integrity of JWT upon receiving it from a client. The vulnerability occurs if a server’s code is expecting a token with “alg” set to RSA but receives a token with “alg” set to HMAC. It might use the public key as HMAC symmetric key while verifying the signature. As the public key would be revealed, the attacker could modify payloads, sign using obtained public key, change “alg” to HMAC, and then be able to forge JWTs.
Secret Key Brute Force
If the “HS256” algorithm is used, the payload is signed with an HMAC using SHA-256 with a symmetric key. A valid JWT has both a payload and a valid signature for that payload. Various symmetric keys could be brute forced by using tools like hashcat, and the signature result is compared to the known-valid signature in order to discover the symmetric key.
Sensitive Information Leak
It is possible for sensitive data like SSN number, credit card number, etc., to be contained in a JWT’s payload and go unnoticed because of Base64 encoding.
Open Redirection
Many Single Sign-On solutions use JWTs to track user’s authentication status. In a typical setup, a user authenticates on the authentication server and is redirected to the end application, along with a JWT to prove their authenticity. The end application then verifies the user’s authenticity by validating the JWT against authentication server. It is possible to manipulate where users were redirected after authentication, allowing attackers to redirect users and their JWT to a server controlled by the attacker, thus stealing their JWT and session.
Key ID Manipulation
Key ID (KID) is an optional header field that specifies the key to be used for verifying the token. As the header parameter is user controlled, it can be manipulated and can lead to serious consequences.
Directory traversal Key ID is used to retrieve a key file from the file system. If the parameter is not sanitized, it can lead to directory traversal attack. It is possible for the attacker to specify any file in the file system as the key to verify the token.
“kid”: “../../public/css/main.css”
SQL injection The KID parameter is also used to retrieve the key from a database. Using the retrieved key, JWT signing could also be bypassed.
“kid”: "aaa' UNION SELECT 'key';--"
Command injection It is possible to inject commands into the code flow when the KID parameter is passed directly into an insecure file read operation. Command injection occurs whenever an application passes any of the header parameters unsanitized into any function like system(), exec(), etc.
“key_file” | whoami;
Header Parameter Manipulation
JKU (JWK set URL) Parameter JKU is an optional header field which is used to specify a URL that points to a set of keys used to verify the token. If this field is not properly restricted or allowed to use, an attacker could host their own key file and specify that the application uses it to verify tokens.
X5U, X5C URL Manipulation The x5u and x5c header parameters allows attackers to specify the public key certificate or certificate chain used to verify the token. Where x5u specifies the information in the URI form, while x5c allows the certificate values to be embedded in the token.
JWK parameter The JWK (JSON Web Key) header parameter is an optional field which allows attackers to embed the key used to verify the token.
Mitigation and Best Practices
Always perform Algorithm Verification.
Use appropriate algorithms.
In the case of nested tokens, perform all validation steps as declared in the headers of each token.
Validate the inputs for all the parameters in JWT.
Do not store sensitive information in JWT token.
Different validation rules must be applied for each token.
Divya Shankari is a security specialist and is part of the DevSecOps vertical at GAVS’ Security Center of Excellence, supporting critical customer engagements. Her core interest is in applications and API security.
