JWT authentication bypass via jku header injection
Since Host server is using the JKU field of the JWT without validating, attacker can tamper with the payload of JWT and access protected resources.
Broken User Authentication (BUA)
How this template works
The template uses API selection filters to specify the criteria for selecting the requests to be executed. In this case, the template filters requests based on the response code, ensuring that it is greater than or equal to 200 and less than 300. It also filters requests based on the presence of a JWT in the request headers.
The template uses the "single" type of execution, which means that only one request will be executed. The request is specified under the "requests" section. In this case, the template replaces the authentication header with the value of the "jku_added_token" from the authentication context.
After executing the request, the template validates the response code to ensure it is within the expected range of 200 to 300. This is done using the "response_code" validation rule, which checks that the response code is greater than or equal to 200 and less than 300.
Frequently asked questions
What is the purpose of the "JKU" header in a JSON Web Token (JWT)
How does the vulnerability in the "ADD_JKU_TO_JWT" category impact the application
Can you explain how an attacker can exploit the vulnerability by tampering with the JWT payload
What are the potential consequences of a successful exploitation of this vulnerability
Are there any specific security measures recommended to mitigate this vulnerability
Are there any known real-world examples or references related to this vulnerability