Skip to content

Vulnerable claims

ticarpi edited this page Nov 14, 2019 · 2 revisions

The following are 'official' or required claims according to the relevant RFCs. Their functions are identified here, as well as any observed or theoretical vulnerabilities they may expose.

Header claims

Header claims are the 'metadata' of the token, telling the application what type of token it is, how the token is signed, where the signing key or secret is stored, and other details.

They are necessarily processed before the token is validated, which is why most of the JWT library vulnerabilities have been found in Header claims.

Some 'standard' claims:

Token Description Format
typ Type of token (JWT/JWE/JWS etc.) string
alg Algorithm used for signing or encryption string
kid Key ID - used as a lookup string
x5u URL for x509 certificate URL
x5c x509 certificate for signing (as a nested JSON object) JSON object
jku URL for JWKS format keys URL
jwk JWK format key for signing (as a nested JSON object) JSON object

Vulnerabilities in Header claims

  • Claims that reference an algorithm or signing method can be adjusted to force the service the attempt to verify the provided token with the amended process.
  • Claims which reference a URL can be used to redirect the service to query a URL under the attacker's control.
  • Claims which include signing certificates can be injected to prompt the service to verify the token with the provided key.
  • The kid claim may be amended to adjust/attack the location or method used to find/access a signing key.

Payload claims

Payload claims are the application-specific data of the token. They pass to the application the customised list of data it has been programmed to include.

They are usually processed after the token is validated, which restricts their usefulness in bypass attacks. However some applications may use some of the provided data without proper validation checks occurring.

If you can find a way to get a token signed then it is the contents of the Payload claims that will give you the path to impersonation, privilege escalation, code execution or other attack paths

The 'standard' claims:

Token Description Format
iss Issuer of the token string/URL
aud Audience of the token: the user or service that is the intended recipient of the token string/URL
sub Subject: the recipient of the token string
jti A unique identifier for the token string/integer
nbf NotBefore - a UNIX timestamp of the time before which the token should not be considered valid integer
iat IssueddAt - a UNIX timestamp of the time when the token was created/became valid integer
exp Expires - a UNIX timestamp of the time when the token should cease to be valid integer

Vulnerabilities in Payload claims

  • Claims with a URL may be tweaked to redirect traffic to an external service under the attacker's control.
  • Claims with timestamps might be processed before validation, and may tweaked to affect the validity of a token.
  • Supplementary claims may be accessed in unexpected ways by application code, and may introduce a wide range of attack paths through injection into, or addition of these fields.
You can’t perform that action at this time.