Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V3 updates #2373

Merged
merged 4 commits into from
Nov 14, 2024
Merged

V3 updates #2373

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0cc92a6
#2185 - update token time-window validation
Nov 13, 2024
37898a4
#2368 - move and update requirement for user-consent-for-a-session
Nov 13, 2024
924aa26
#2184 - update token integrity check
Nov 13, 2024
4a455d4
rm '
elarlang Nov 14, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions 5.0/en/0x12-V3-Session-management.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,6 @@ Some of the requirements in this section relate to section [7.1](https://pages.n
| **3.2.2** | [MOVED TO 3.1.4] | | | | |
| **3.2.3** | [DELETED, MERGED TO 8.2.2] | | | | |
| **3.2.4** | [DELETED, MERGED TO 3.1.4] | | | | |
| **3.2.5** | [ADDED] Verify that creating a session for the application requires the user's consent and that the application is protected against a CSRF-style attack where a new application session for the user is created via SSO without user interaction. | | ✓ | ✓ | |

TLS or another secure transport channel is mandatory for session management. This is covered in the Communications Security chapter.

Expand Down Expand Up @@ -80,8 +79,8 @@ Token-based session management includes JWT, OAuth, SAML, and API keys. Of these
| :---: | :--- | :---: | :---: | :---: | :---: |
| **3.5.1** | [GRAMMAR] Verify that the application allows users to revoke OAuth tokens that form trust relationships with linked applications. | | ✓ | ✓ | 290 |
| **3.5.2** | [MOVED TO 3.1.3] | | | | |
| **3.5.3** | [MODIFIED, LEVEL L2 > L1] Verify that stateless tokens use a digital signature or MAC to protect against tampering, which is checked before accepting the token's contents. | ✓ | ✓ | ✓ | 345 |
| **3.5.4** | [ADDED] Verify that stateless tokens are checked for expiration before processing them further. | ✓ | ✓ | ✓ | 613 |
| **3.5.3** | [MODIFIED, LEVEL L2 > L1] Verify that cryptographically secured tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | ✓ | ✓ | ✓ | 345 |
| **3.5.4** | [ADDED] Verify that, if a validity time span is present in the token data, the token and it's content are accepted only if the verification time is within this validity time span. For example, for JWTs the claims 'nbf' and 'exp' must be verified. | ✓ | ✓ | ✓ | 613 |
elarlang marked this conversation as resolved.
Show resolved Hide resolved
| **3.5.5** | [ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion. | ✓ | ✓ | ✓ | 757 |
| **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 |

Expand All @@ -95,6 +94,7 @@ Some of the requirements in this section relate to section [7.2.1](https://pages
| :---: | :--- | :---: | :---: | :---: | :---: |
| **3.6.1** | [MODIFIED, MERGED FROM 3.6.2] Verify that session lifetime and termination between Relying Parties (RPs) and Credential Service Providers (CSPs) behave as documented, requiring re-authentication as necessary such as when the maximum time between CSP authentication events is reached. | | | ✓ | 613 |
| **3.6.2** | [DELETED, MERGED TO 3.6.1] | | | | |
| **3.6.3** | [ADDED] Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user interaction. | | ✓ | ✓ | |

## V3.7 Defenses Against Session Abuse

Expand Down
Loading