ASVS
ASVS copied to clipboard
OWASP
v3.3.1 - Clarification as to meaning,
This requirement is currently as follows. (My emphasis). I had a question come up on this during a training course.
Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.
(The earliest version of the requirement I can find was added here as 3.3.4.)
My understanding of this requirement includes a few things. For the purposes of this point let's assume AzureAD is the identity provider (IdP) and Salesforce and ServiceNow are relying parties (RPs) where they use the user's AzureAD identity rather than managing authentication separately.
Understanding of the requirement:
- Logout from AzureAD invalidates the session identifier with AzureAD and the user will not be able to use AzureAD until they authenticate again.
- Pressing the back button will not result in seeing sensitive data from AzureAD or being able to resurrect the session with AzureAD.
- Browsing to Salesforce or ServiceNow should not resurrect the session with AzureAD.
- In fact, the last 4 words of the requirement ("including across relying parties") indicate that the user's session with Salesforce or ServiceNow should also be invalidated when the IdP session has been invalidated. After logging out in the IdP, the user should not be able to access these RPs without first reauthenticating to the IdP.
- However, if the user logs out from their specific session with one of the RPs (e.g. Salesforce), this requirement does not expect or require that this will also log the user out of other RPs or the IdP.
@vanderaj (or anyone else), do you understand this requirement differently to me?
Good analysis Josh. I suggest we simplify this to drop the last phrase since we already mention "Downstream relying party"
So perhaps:
Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session.
That makes sense although do you think saying "cannot" instead of "does not" is clearer @jmanico ?
Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party cannot resume an authenticated session.
Yes, that makes more sense. I encounter this in applications most often that the cookie is cleared at the client, but not invalidated on the server. The back button won't work in that case, but anyone with posession of the session token can still resume the session. We want that person to be unable to do that, so "cannot" makes more sense. However, is that person an "downstream relying party"?
