How to test JWT NONE Algorithm vulnerability?

JWT stands for JSON Web Token. It is a standardized format for representing claims securely between two parties. It is commonly used for authentication and authorization in web applications, and it allows for the transfer of information such as user identities and session data in a compact and secure way. JWTs consist of three parts: a header, a payload, and a signature. The header typically includes information about the algorithm used to sign the token, while the payload contains the claims or information about the user, such as their name or email address. The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message hasn't been tampered with.

What is JWT NONE algorithm attack?

The JWT None algorithm attack is a type of vulnerability that arises when a JWT (JSON Web Token) is signed using the "None" algorithm. This algorithm is a reserved name in the JWT specification that signifies that no algorithm is being used to sign the JWT.

In other words, the JWT is not digitally signed, which means that an attacker can modify it without detection. This can be a serious security issue, as the JWT may be used to authenticate a user for access to a protected resource, and an attacker could potentially modify the JWT to grant themselves access to that resource.

Severity: Medium to Critical

OWASP Category: API2:2019 Broken User Authentication

Example:

1. A user named Alice logs into a website that uses JWTs for authentication.

2. The website issues Alice a JWT that looks like this:

After decoding the JWT token:

The JWT consists of three base64-encoded strings separated by dots.

- The first part (eyJhbG...) is the header, which specifies the algorithm used to sign the JWT. In this case, the algorithm is "None", which means the JWT is not signed.

- The second part (eyJzY29wZSI6...) is the payload, which contains claims about the user, such as their scope of access and the time the JWT was issued.

- The third part (an empty string) is the signature, which is supposed to be a hashed version of the header and payload using a secret key. However, since the algorithm is "None", there is no signature.

1. Alice presents the JWT to the website to authenticate herself and gain access to protected resources. The website verifies the JWT by checking that it is correctly formatted and has not expired, but it does not check the signature since the algorithm is "None".

2. An attacker named Bob intercepts the JWT as it is being transmitted between Alice and the website.

3. Bob modifies the payload of the JWT to grant himself access to additional resources, such as the ability to delete messages. The modified JWT looks like this:

The modified JWT token after decoding:

1. Bob presents the modified JWT to the website, pretending to be Alice. The website accepts the JWT as valid and grants Bob access to the protected resources, including the ability to delete messages.

How to test this?

We used Portswigger lab to test this. Navigate screens below to understand the test:

What's the impact of this vulnerability?

In general, the use of the "NONE" algorithm in a JWT can have significant consequences, as it allows anyone who has access to the JWT to tamper with its content without detection. This can lead to several types of security vulnerabilities and risks, including:

1. Unauthorized access to protected resources: An attacker could modify the JWT to include different claims or permissions, allowing them to gain unauthorized access to protected resources.

2. Impersonation of another user: An attacker could modify the JWT to impersonate another user, allowing them to perform actions on behalf of that user.

3. Tampering with sensitive information: An attacker could modify the JWT to tamper with sensitive information, such as financial transactions or personal data.

How to remediate?

To prevent this type of attack:

1. It is important to use a strong signing algorithm, such as HMACSHA256 or RSA, to sign JWTs. This ensures that any tampering with the JWT can be detected, as the signature will no longer be valid if the JWT has been modified.

2. Validate the algorithm on every JWT token. It should exactly match what server uses to generate the token

We also recently wrote about a CVE found in JWT here. Read more here. In the next blog, we will look at how attackers can exploit this vulnerability using Expired Auth Token. Stay Tuned!