OWASP / ASVS

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

3.5.4 - token time-window validation #2185

Open elarlang opened 1 week ago

elarlang commented 1 week ago

Spin-off from #1917

Current requirement: # Description L1 L2 L3 CWE
3.5.4 [ADDED] Verify that stateless tokens are checked for expiration before processing them further. 613

It should be more abstract and cover "time window" when the token is valid.

To check the expiration, we need to require exp to be present and set. It is not set for example for refresh tokens when offline_access is used.

Technically it should also cover to check nbf (Not Before).

Related RFC https://datatracker.ietf.org/doc/html/rfc7519

So the requirement need to validate the "time-window", and it can be validated, if nbf and/or exp claims are provided in the token (both are optional).

elarlang commented 1 week ago

Something like that?

Verify that stateless token is allowed to be used at the time of checking, using not-before ('nbf' claim in JWT) and expires ('exp' claim in JWT) values, if those are provided in the token.

randomstuff commented 1 week ago

For reference some wording about "iat" and "nbf" (but not "exp") from FAPI 2.0:

to accommodate clock offsets, shall accept JWTs with an iat or nbf timestamp between 0 and 10 seconds in the future but shall reject JWTs with an iat or nbf timestamp greater than 60 seconds in the future.

elarlang commented 1 week ago

I would not put iat here that quickly. From this you can assume are the clocks synced, but it is not meant for time-window validation.

randomstuff commented 3 days ago

I would not put iat here that quickly. From this you can assume are the clocks synced, but it is not meant for time-window validation.

Note that for DPoP, "iat" is the value used to check the validity of the DPoP proof.

Verify that stateless token is allowed to be used at the time of checking, using not-before ('nbf' claim in JWT) and expires ('exp' claim in JWT) values, if those are provided in the token.

I'm wondering if there is something missing here (?):

So this should be something like:

Verify the the consumer of a stateless token verifies that stateless token is allowed to be used at the time of checking, using not-before ('nbf' claim in JWT) and expires ('exp' claim in JWT) values, if those are provided in the token.

randomstuff commented 3 days ago

What about something like:

Verify that the consumer of a stateless token accepts the token only if the verification time is within this validity time span in the token (if present). For example, for JWTs, this is typically conveyed using the 'nbf' and 'exp' claims.

or

Verify that the consumer of a stateless tokens honors the validity time span associated with the token (if present). For example, for JWTs, this is typically conveyed using the 'nbf' and 'exp' claims.

elarlang commented 3 days ago

From last 2 proposals I prefer the first one. This "honors" feels a bit out of context, we need to use a strong and clear term such as "must" from https://datatracker.ietf.org/doc/html/rfc2119.

(if present) feels like it is written for the token "if token is present", I think it should be repositioned to be clearly apply to time-window claims.

consumer - it can be there, but I think it is not necessary. If something is going to use the content from the token, is is consuming the content and is consumer by nature. Is there any other interpretation that we need to clarify this?

elarlang commented 3 days ago

Rechecking it again, I think this one good enough:

Verify the the consumer of a stateless token verifies that stateless token is allowed to be used at the time of checking, using not-before ('nbf' claim in JWT) and expires ('exp' claim in JWT) values, if those are provided in the token.

@randomstuff - any changes or improvement to apply from your last proposal comment taking into account my last comment?

elarlang commented 3 days ago

Some more versions:

randomstuff commented 2 days ago

I'd like your second version better. The two other looks somewhat ambiguous to me.

Analysis of the third proposition For example, > Verify that the stateless token is allowed to be used at the time of checking if the stateless token has information about the time of being valid, such as 'nbf' and 'exp' claims in JWT. I think this is ambiguous about the scope of the condition. This might be understood as: > Verify that the (stateless token is allowed to be used at the time of checking if the stateless token has information about the time of being valid), such as 'nbf' and 'exp' claims in JWT. whereas we mean: > (Verify that the stateless token is allowed to be used at the time of checking) if the stateless token has information about the time of being valid, such as 'nbf' and 'exp' claims in JWT. This would be clearer: > Verify, if the stateless token has information about the time of being valid (such as 'nbf' and 'exp' claims in JWT), the stateless token is allowed to be used at the time of checking. But actually, something seems to be missing to me and we mean: > Verify, if the stateless token has information about the time of being valid (such as 'nbf' and 'exp' claims in JWT), the application verifies the token is currently valid according to this information before taking any actions based on this token.

What about:

Verify that application accepts an stateless token only if the verification time is within this validity time span in the token, if such a validity time span is present. For JWTs and OAuth Token Introspection, this is currently represented by the 'nbf' and 'exp' claims and properties respectively.

or

Verify, if a stateless token is associated with some validity time span, the application verifies the token is currently valid according to this information before taking any action based on this token. For JWTs and OAuth Token Introspection, this is currently represented by the 'nbf' and 'exp' claims and properties respectively.

I removed "stateless" here because this can apply to stateful tokens as well (i.e. when using OAuth token introspection), right?

ryarmst commented 2 days ago

May I suggest wording that favours rejection over acceptance? For example, rather than "accepts a token only if.." what about "rejects the token if..."?

elarlang commented 1 day ago

I'm a bit lost now what is the latest proposal here :)

@randomstuff - just in case, it is a V3 issue. If we want to have OAuth mentioned, it sounds like a specific requirement for V51. By content at the moment I see it as general requirement.

Is OAuth Introspection defines nbf and exp or it uses the definitions from JWT?

randomstuff commented 21 hours ago

@elarlang, the token introspection part can be skipped if needed.

The definitions of nbf and exp from token introspection reference the definition from JWT (but use them in a separate context):

exp OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token will expire, as defined in JWT [RFC7519].

[...]

nbf OPTIONAL. Integer timestamp, measured in the number of seconds since January 1 1970 UTC, indicating when this token is not to be used before, as defined in JWT [RFC7519].