Vulnerable claims
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 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 |
- 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 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 |
- 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.
