Header Injection
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 JWT attacks 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 matchingkidparameter.
Via JWK
The below example is based on PortSwigger's JWT authentication bypass via jwk header injection 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
kidparameters; they need to also be matching. The above extension does this automatically.
Via JKU
The below example is based on PortSwigger's JWT authentication bypass via jku header injection lab.
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.



Via KID
The below example is based on PortSwigger's JWT authentication bypass via kid header path traversal lab.
Servers may use several keys for signing different kinds of data, no just JWTs.
The
kidparameter identifies which key to use when verifying the signature.The
kidparameter is just an arbitraty string of the developer's choosing.If
kidis 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,
kidmight be vulnerable to SQLi.

Other interesting JWT header parameters
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 actyheader to change the content type totext/xmlorapplication/x-java-serialized-object, which can potentially enable new vectors for XXE and deserialization attacks.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 thejwkheader injection attacks discussed above. Due to the complexity of the X.509 format and its extensions, parsing these certificates can also introduce vulnerabilities.
Last updated
Was this helpful?