3.5.3 update (stateless token signature or mac)

[elarlang]

Spin-off from #1917

#	Description	L1	L2	L3	CWE
3.5.3	[MODIFIED, LEVEL L2 > L1] Verify that stateless session tokens make use of a digital signature to protect against tampering and this is checked before processing it further.	✓	✓	✓	345

• 3.5.3 should not be limited with "stateless session tokens", just "stateless tokens".

Discussion between @jmanico and @randomstuff started here #1917 (comment)

and ended with proposal:

Verify that stateless tokens use a digital signature or MAC to protect against tampering, ensuring it is checked before performing any other actions based on the token's contents.

I think that last sentence should be updated:

Verify that stateless tokens use a digital signature or MAC to protect against tampering, ensuring it is checked before accepting the token's contents.

Option to discuss - should requirement 3.5.5 be merged into this one:

V3.5.5 Verify that only signing algorithms on an allowlist are allowed for a stateless token.

[jmanico]

This looks good.

Verify that stateless tokens use a digital signature or MAC to protect against tampering, ensuring it is checked before accepting the token's contents.

I personally would like to see 3.5.5 as separate, since it's addressing a different issue that signature verification. It's addressing signature type abuse. However, most of those problems (like changing the signature to NONE to bypass verification) have been fixed in verification libraries. I can see 3.5.5. getting merged if you really want to.

[randomstuff]

V3.5.5 Verify that only signing algorithms on an allowlist are allowed for a stateless token.

Should we verify as well that in a given context either MAC or public-key signature are used but not both interchangeably (notably as a way to prevent JWT key confusion type attacks)?

I think this is what @jmanico is referring to when talking about "signature type abuse" but if that's the case, the requirement should be more explicit about this (i.e. don't mix MAC and signatures).

[elarlang]

requirement 3.5.3 got updated and merged. Is there need to update 3.5.5 as well? Or we should discuss it in a separate issue?

[jmanico]

Another type of historical signature type abuse is when you forcibly set the JWT signature type to "none" and bypass signature validation. This is less of an issue when you set up an allow list of legal signatures and use modern JWT libraries.

[elarlang]

#2184 (comment)

requirement 3.5.3 got updated and merged. Is there need to update 3.5.5 as well? Or we should discuss it in a separate issue?

ping @randomstuff

[randomstuff]

Yes, it would probably be good to open an issue about 3.5.3 specifically.

[elarlang]

Yes, it would probably be good to open an issue about 3.5.3 specifically.

assuming it was about 3.5.5, opened #2204

[ryarmst]

Reopening to suggest an update (following discussion):

#	Description	L1	L2	L3	CWE	NIST §
3.5.3	[MODIFIED, LEVEL L2 > L1] Verify that if cryptographically secured tokens are used to represent user sessions, that they use a digital signature or MAC to protect against tampering, which is checked before accepting the token's contents.	✓	✓	✓	345

I would also like to propose moving to V3.1 due to divergence from surrounding requirements.

[TobiasAhnoff]

A suggestion is to update 3.5.3 and move it to a new "Access token" section (where examples are given for JWTs).
This is part of "cleaning up 3.5" see #1917 (comment)

Verify that access tokens are cryptographically secure, either by using a digital signature or MAC to protect against tampering, or being a secure random string (hard to guess and with low collision risk). If validation fails, the token must be rejected.

[elarlang]

Current requirement:

Verify that stateless tokens use a digital signature or MAC to protect against tampering, which is checked before accepting the token's contents.

Proposed requirement #2184 (comment):

Verify that if cryptographically secured tokens are used to represent user sessions, that they use a digital signature or MAC to protect against tampering, which is checked before accepting the token's contents.

Why do we need to make this requirement specific for user-sessions (if cryptographically secured tokens are used to represent user sessions)? I think it is a general requirement.

Proposed requirement #2184 (comment):

Verify that access tokens are cryptographically secure, either by using a digital signature or MAC to protect against tampering, or being a secure random string (hard to guess and with low collision risk). If validation fails, the token must be rejected.

I'm also not on the board with the access topic direction and I think this requirement is not limited to the access tokens.

Let's fix the requirement text if it requires update as general stateless token requirement. Where it will be located and grouped, we can decide if we have other related requirements in place.

At the moment I would say I like the current requirement as it is.

[ryarmst]

The requirement can be generalized beyond sessions. Consider 3.1.3:

Verify that the application uses either cryptographically secured or random session tokens for session management. Static API secrets and keys should be avoided.

As long as the terminology is consistent, the requirements for cryptographically secured tokens can be independent. Consider:

Verify that cryptographically secured tokens use a digital signature or MAC to protect against tampering, which is checked before accepting the token's contents.

[ryarmst]

Thoughts on my current proposal restated below? @TobiasAhnoff @randomstuff

Verify that cryptographically secured tokens use a digital signature or MAC to protect against tampering, which is checked before accepting the token's contents.

It can be generalized to sessions, access tokens, or anything else.

[randomstuff]

@ryarmst, this looks good but the first half is somewhat tautological,

Verify that cryptographically secured tokens use a digital signature or MAC […]

where,

Cryptographically Secured Token - These tokens will generally contain claims or assertions encoded within the token structure, with cryptographic techniques such as signatures or message authentication codes (MAC) used to verify the authenticity and integrity of this data. The most common examples are SAML assertions and JWTs.

[elarlang]

Maybe a general glossary thingy - did not find immediately, why do we use the term "Cryptographically Secured Token"?

My concern is, is it intuitive and understandable for wide-audience and community from the requirement text that it applies to stateless tokens and JWTs?

[ryarmst]

@randomstuff Good point. The wording could be changed to focus not on use but to ensure validation occurs, which may also fit better with V5 (a discussed possible location for token validation type requirements). How about:

Verify that cryptographically secured tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents.

@elarlang I understand your point, but issues exist with other candidate terms that have been used:

• "Stateless" - may not always be the case
• "Self-encoded" - basically the OAuth equivalent to "Stateless"
• "Token" - too broad
• "JWT" - technology-specific
• And so on...

The glossary does mention JWTs and could include "stateless" as well. I have not seen a better alternative yet and I think it is a good opportunity for the ASVS to set precedent if terminology is lacking.

EDIT: this is the term in the Glossary:

Cryptographically Secured Token - These tokens will generally contain claims or assertions encoded within the token structure, with cryptographic techniques such as signatures or message authentication codes (MAC) used to verify the authenticity and integrity of this data. The most common examples are SAML assertions and JWTs.

[elarlang]

Discussion over the term "Cryptographically Secured Token" is offtopic from this issue and I'll open a separate issue if there is need for that. My feeling is, that this term is not clear and intuitive and makes requirements only using this term not understandable. Linking the glossary here just proves it in a way.

I think there is agreement on the latest proposed requirement text and this can be updated as it is now:

Verify that cryptographically secured tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents.

[ryarmst]

@elarlang PR at #2372

[elarlang]

@elarlang PR at #2372

handled via PR #2373