I've just finished a PortSwigger lab about exploiting JWT with jku header injection, but there's a problem I couldn't understand.

My issue relates specifically to the signature in JWT, so I won't go too deep into the lab's details. Basically, the lab involves bypassing JWT validation by injecting the jku header to make the server fetch a malicious key from a controlled URL.

I will describe some contexts:

Client-side:

• JWT sent: client_jwt
• jku header sent: client_jku (e.g., pointing to url_A or url_B)
• Signature sent: client_sign
• Key data fetched from jku URL: key_data

Server-side:

• After receiving the JWT, the server extracts header, payload, signature; calculates the signature server_sign, and checks if it matches the client_sign.

My Observations:

1. I using JWT edition extension in BurpSuite for signing. For example intial jku header look like this

"jku" : "url_A": Change this to "jku" : "url_B" -> client_sign changes. change key_data -> client_sign doesn't change.

2. Sent client_jwt to server

• Initial correct key_data -> server response 200 OK.
• Change initial correct key_data -> server response 401 Unauthorized.

My confusion:

• I initially thought the client-side signature (client_sign) would be calculated after fetching key_data from the jku URL (bacause the data contains key). But in reality: client_sign depends only on the raw header/payload (including jku value), not on the fetched key_data.
• The server, however, uses key_data (because follwing 2. if I change key_data, server return 401) from the URL to verify the signature.

Question: How does the server verify client_jwt if the signature is based only on the jku URL string, while the server relies on the actual key_data from that URL?

I've just finished a PortSwigger lab about exploiting JWT with jku header injection, but there's a problem I couldn't understand.

My issue relates specifically to the signature in JWT, so I won't go too deep into the lab's details. Basically, the lab involves bypassing JWT validation by injecting the jku header to make the server fetch a malicious key from a controlled URL.

I will describe some contexts:

Client-side:

• JWT sent: client_jwt
• jku header sent: client_jku (e.g., pointing to url_A or url_B)
• Signature sent: client_sign
• Key data fetched from jku URL: key_data

Server-side:

• After receiving the JWT, the server extracts header, payload, signature; calculates the signature server_sign, and checks if it matches the client_sign.

My Observations:

1. I using JWT edition extension in BurpSuite for signing. For example intial jku header look like this

"jku" : "url_A": Change this to "jku" : "url_B" -> client_sign changes. change key_data -> client_sign doesn't change.

2. Sent client_jwt to server

• Initial correct key_data -> server response 200 OK.
• Change initial correct key_data -> server response 401 Unauthorized.

My confusion:

• I initially thought the client-side signature (client_sign) would be calculated after fetching key_data from the jku URL (bacause the data contains key). But in reality: client_sign depends only on the raw header/payload (including jku value), not on the fetched key_data.
• The server, however, uses key_data (because follwing 2. if I change key_data, server return 401) from the URL to verify the signature.

Question: How does the server verify client_jwt if the signature is based only on the jku URL string, while the server relies on the actual key_data from that URL?

• authentication
• oauth-2.0
• oauth
• jwt

Share Improve this question Follow edited Mar 28 at 3:50 David Adonis asked Mar 28 at 3:48 David AdonisDavid Adonis 311 bronze badge

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

A client assertion (JWT) is a strong way to authenticate a client to a server. The JWT can also contain claims with extra information - the JWT's digital signature protects the integrity and authenticity of that data. Therefore the server can trust those claims if it trusts the JWT issuer and digital signature verification is successful.

The client performs these steps:

• Generates an asymmetric key pair

• Creates an assertion and signs it with the private key

• Provides a JSON Web Key Set that contains the public key, hosted at a JWKS URI

The server performs these steps:

• Configures a trusted JWKS URI for a client

• Reads a kid from the JWT header

• Gets the correspoding public key from the JWKS URI and verifies the JWT signature

There are some technical variations on how a client can deliver the public key to the server, which you can read about in the RFC 7515 document.

Adding a jku parameter to the JWT header is not the most mainstream option so avoid it unless you have a good reason. If used, it needs to be accompanied by extra validation. For example, the server might configure a set of whitelisted base URLs and reject any received URL not in the whitelist.