Header Injection
Last updated
Was this helpful?
Last updated
Was this helpful?
JWT header parameter injection occurs when an attacker manipulates or injects malicious data into the JWT's header section. This vulnerability arises from inadequate validation and handling of JWT header parameters, allowing attackers to exploit or manipulate the token's integrity and authentication.
The below content is based on PortSwigger's module.
Only the alg
header parameter is mandatory, but often there are other parameters as well.
jwk
(JSON Web Key) - Provides an embedded JSON object representing the key.
jku
(JSON Web Key Set URL) - Provides a URL from which servers can fetch a set of keys containing the correct key.
kid
(Key ID) - Provides an ID that servers can use to identify the correct key in cases where there are multiple keys to choose from. Depending on the format of the key, this may have a matching kid
parameter.
The below example is based on PortSwigger's lab.
jwk
is an optional parameter for JWS which servers use to embed their public key directly within the token itself in JWK
format, i.e., a standardized format for representing keys as a JSON object. Typically, servers use a limited whitelist of public keys for JWT signature verification, but they can be misconfigured and use any key that's embedded within the jwt
parameter.
This can be also done manually, but make sure to also change the
kid
parameters; they need to also be matching. The above extension does this automatically.
Some servers let you use the jku
(JWK Set URL) header parameter to reference a JWK set, i.e., a JSON object containing an array of JWKs representing different keys. When verifying the signature, the server fetches the relevant key from this URL. JWK Sets are sometimes exposed publicly via a standard endpoint, such as /.well-known/jwks.json
. More secure websites will only fetch keys from trusted domains, but you can sometimes take advantage of URL parsing discrepancies to bypass this kind of filtering.
Servers may use several keys for signing different kinds of data, no just JWTs.
The kid
parameter identifies which key to use when verifying the signature.
The kid
parameter is just an arbitraty string of the developer's choosing.
If kid
is vulnerable to directory traversal, an attacker could force the server to use an arbitraty file from their filesystem as the verification key.
If the server stores its verification keys in a database, kid
might be vulnerable to SQLi.
x5c
(X.509 Certificate Chain) - Sometimes used to pass the X.509 public key certificate or certificate chain of the key used to digitally sign the JWT. This header parameter can be used to inject self-signed certificates, similar to the jwk
header injection attacks discussed above. Due to the complexity of the X.509 format and its extensions, parsing these certificates can also introduce vulnerabilities.
The below example is based on PortSwigger's lab.
The below example is based on PortSwigger's lab.
cty
(Content Type) - Sometimes used to declare a media type for the content in the JWT payload. This is usually omitted from the header, but the underlying parsing library may support it anyway. If you have found a way to bypass signature verification, you can try injecting a cty
header to change the content type to text/xml
or application/x-java-serialized-object
, which can potentially enable new vectors for and attacks.