asvs/v9-self-contained-tokens

8 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

V9 Self-contained Tokens - Chapter objective

V9 covers self-contained tokens such as JSON Web Tokens (JWTs) and SAML assertions that contain data or claims on which a receiving service relies for security decisions. The chapter ensures tokens are produced by trusted parties, have not been tampered with, and are validated within their validity period and intended context to prevent insecure cross-usage between different services.

V9.1.1 - Self-contained token validation requirement

Requirement 9.1.1 at Level 1: Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents.

V9.1.2 - Algorithm allowlist requirement

Requirement 9.1.2 at Level 1: Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens for a given context. The allowlist must include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and must not include the 'None' algorithm. If both symmetric and asymmetric algorithms must be supported, additional controls are needed to prevent key confusion.

V9.1.3 - Key material validation requirement

Requirement 9.1.3 at Level 1: Verify that key material used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources.

V9.2.1 - Token validity time span requirement

Requirement 9.2.1 at Level 1: Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For JWTs, the claims 'nbf' (not before) and 'exp' (expiration) must be verified.

V9.2.2 - Token type validation requirement

Requirement 9.2.2 at Level 2: Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. Only access tokens can be accepted for authorization decisions and only ID Tokens can be used for proving user authentication.

V9.2.3 - Token audience validation requirement

Requirement 9.2.3 at Level 2: Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service.

V9.2.4 - Token audience restriction requirement

Requirement 9.2.4 at Level 2: Verify that, if a token issuer uses the same private key for issuing tokens to different audiences, the issued tokens contain an audience restriction that uniquely identifies the intended audiences. This prevents a token from being reused with an unintended audience. If the audience identifier is dynamically provisioned, the token issuer must validate these audiences to ensure they do not result in audience impersonation.

Give your agent this brain