search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.76k stars 671 forks source link

Abstract requirement for "tokens can be used only for the intended usage" (move or duplicate 51.1.1) #2379

Closed elarlang closed 2 days ago

elarlang commented 6 days ago

We added requirement 51.1.1 via #2005:

# Description L1 L2 L3
51.1.1 [ADDED] Verify that tokens (such as ID tokens, access tokens and refresh tokens) can only be used for their intended purpose. For example, ID tokens can only be used to prove user authentication for the client. ✓ ✓ ✓

The problem is general and we need a general requirement, but wording for the current requirement is OAuth / OIDC specific by wording.

Options are:

elarlang commented 5 days ago

Maybe we should change the point of view for this requirement, as it is in current wording - how do you verify that the token can not be used for anything else?

The actual point we want to achieve is that "the token received is meant for that usage".

TobiasAhnoff commented 5 days ago

Make one extra requirement to V3.5 about that, but make V51.1.1 more detailed to give more value for OAuth and OIDC scenarios, and not be a clear duplicate. By more specific I mean to list also, why access tokens are made and why refresh tokens are made.

I think that is a good approach and then V51 could also include e g that aud for ID Tokens should be client id.

The actual point we want to achieve is that "the token received is meant for that usage".

Yes, it is good if the wording is positive, like "the token received is meant for that usage".

TobiasAhnoff commented 5 days ago

Maybe add an abstract one to "V3" (together with token requirements)

Verify the token received is meant for the intended usage. For JWTs e g the 'typ' claim can be used to verify what kind of token it is.

And then "modify" 51.1.1 to include more details or maybe, to avoid overlap within V51, it is better to include the details for tokens in the section Resource Server, OAuth Client and OIDC client? Maybe like this:

If this sounds good, then we probably need to split this into different issues

elarlang commented 5 days ago

I opened this issue to have one-topic-per-issue discussion. Please let's keep focus in this issue to solve the "intended usage" problem only.

elarlang commented 5 days ago

An attempt to make the requirement with positive wording. At the moment it seems that this proposal is abstract enough to use as a general requirement (outside of V51), although using access token and ID token as an example:

Verify that the received token is of the correct type and is meant for the intended purpose. For example, only access tokens can be accepted for authorization decisions and ID tokens for proving user authentication.

randomstuff commented 5 days ago

Same as https://github.com/OWASP/ASVS/issues/2363#issuecomment-2481528143, we need not verify that token is of the correct type but we need to verify that the receiver checks that the token is of the correct type.

elarlang commented 4 days ago

Updated proposal:

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. For example, only access tokens can be accepted for authorization decisions and only ID tokens can be used for proving user authentication.

With this wording I propose to add a general requirement into current V3.5 and remove "specific" requirement 51.1.1.

elarlang commented 4 days ago

If no further comments and feedback, I'll PR it tomorrow.