search

OWASP / ASVS

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

proposal/discussion: JWT - 3.5.6 add "type", and rephrase it to describe the goal #1967

Open elarlang opened 4 months ago

elarlang commented 4 months ago

spin-off from https://github.com/OWASP/ASVS/issues/1925 "proposal 4"

From @TobiasAhnoff

4 Verify that only access-tokens are used for authorization by the RS (not id-tokens or other kinds of tokens)

Proposal from me:

I think we should add typ (RFC7519) to this requirement:

# Description L1 L2 L3 CWE NIST §
3.5.6 [ADDED] Verify that other, security-sensitive attributes of a stateless token are being verified. For example, in a JWT this may include issuer, subject, and audience. ✓ ✓ ✓ 287

Response from @TobiasAhnoff

I agree, this could be part of 3.5.6

Proposal/Goal 1: add typ (Type) to the requirement to have special spotlight for it in OAuth context.

The question: should the requirement list issuer, subject, audience, and type - or iss, sub, aud, and typ?

Proposal/Goal 2: get rid of "that other" part and describe why this requirement exists defining the goal to ask those parameters to be verified.

The CWE-287 is "Improper Authentication", which I would say is not correct. Additionally, it points to CWE "Class" or "Category" and should not be used for mapping.

elarlang commented 4 months ago

Note, I labeled it as V51, although it is not OAuth-specific. Also, at the moment it belongs to V3 Session management, but it is not related to sessions. It should belong to V13 - for that discussion, there is a separate issue:https://github.com/OWASP/ASVS/issues/1917

jmanico commented 4 months ago

A few notes:

1) Even though it's covered elsewhere, it's a bit weird to talk about security-centric attributes that do not include the signature - the most essential security-centric attribute.

2) Here is a list of other security-centric attributes to consider for the requirement text:

And of course:

elarlang commented 4 months ago

Jim, you should take a look at section V3.5 first, and see, which one of them is already covered by other requirements. But this is precisely the reason for proposal 2 - that we should define the clear goal, why you need to verify aud, iss, sub, typ and keep the focus only on those. Also note, that even the current requirement lists them as "For example".

jmanico commented 4 months ago

Sounds good, Elar. I just wanted to provide the complete list here for consideration. I did read the entire thread before I commented. Here is what I see for the main list of token claims:

elarlang commented 4 months ago

In my opinion, this requirement/issue focuses only on "Verify that the token is generated by an expected party" and "Verify that the token is meant for this usage". As it is not clearly defined (yet), it can cause confusion.

If something needs to be improved, please open separate issues for those - let's keep the issue here clear and focused on solving this one and precise problem, not covering the entire section or paragraph.

elarlang commented 4 months ago

Scopes/Permissions - Not converted in 3.5.x

I think the scope and permission is not general JWT topic, but it comes from OAuth 2.0 Token Exchange. For that discussion we have https://github.com/OWASP/ASVS/issues/1964

TobiasAhnoff commented 2 months ago

Given level of detail for other 3.5 verifications a suggestion is to merge 3.5.4 into 3.5.6 (and remove 3.5.4), like this:

3.5.6 - "Verify that any security-sensitive attributes of a stateless token are being verified before processing it further. For example, issuer, expiration and intended usage. Note that the exact list of attributes depends on token format, for JWT see chapter 13.??".

The new 13.?? section could be JWT specific and have a list claims to verify details like alg, iss, aud, exp, nfb, typ etc, maybe also add a reference to a JWT cheat sheet (or JWT RFC on token validation)

elarlang commented 2 months ago

The requirement should be independent without references to other requirements or sections.

TobiasAhnoff commented 2 months ago

The requirement should be independent without references to other requirements or sections.

Should 3.5 be independent of token format (without e g JWT or SAML detalails)? If so, then 3.5.6 could be

3.5.6 - "Verify that security-sensitive attributes of a stateless token are being verified before processing it further. Regardless of token format, the following must be verified by the service protecting resources (e g an API):

And then have specific token verification details in chapter 13, for e g JWT and SAML, without reference in 3.5.6.

But, perhaps also add a note in chapter 3 text to make it clear for the reader that specific token format details are found in chapter 13 (as 3.5 is independent of token format)?

elarlang commented 3 weeks ago

Original reason to open the issue:

4 Verify that only access-tokens are used for authorization by the RS (not id-tokens or other kinds of tokens)

it is / will be covered by https://github.com/OWASP/ASVS/issues/2005#issuecomment-2350139666

Verify that tokens (such as ID tokens, access tokens and refresh tokens) can only be used according to their intended purpose without allowing cross-usage between them.

(the final wording can be changed/updated)

In the requirement 3.5.6 is not defined, why it exists:

... in a JWT this may include issuer, subject, and audience.

By checking: