+V7 Session Management
---+V7.1 Session Management Documentation
------+V7.1.1 Verify that the user's session inactivity timeout and absolute maximum session lifetime are …
------+V7.1.2 Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one …
------+V7.1.3 Verify that all systems that create and manage user sessions as part of a federated identity …
---+V7.2 Fundamental Session Management Security
------+V7.2.1 Verify that the application performs all session token verification using a trusted, backend …
------+V7.2.2 Verify that the application uses either self-contained or reference tokens that are dynamically …
------+V7.2.3 Verify that if reference tokens are used to represent user sessions, they are unique and generated …
------+V7.2.4 Verify that the application generates a new session token on user authentication, including …
---+V7.3 Session Timeout
------+V7.3.1 Verify that there is an inactivity timeout such that re-authentication is enforced according to …
------+V7.3.2 Verify that there is an absolute maximum session lifetime such that re-authentication is enforced …
---+V7.4 Session Termination
------+V7.4.1 Verify that when session termination is triggered (such as logout or expiration), the application …
------+V7.4.2 Verify that the application terminates all active sessions when a user account is disabled or …
------+V7.4.3 Verify that the application gives the option to terminate all other active sessions after a …
------+V7.4.4 Verify that all pages that require authentication have easy and visible access to logout …
------+V7.4.5 Verify that application administrators are able to terminate active sessions for an individual user …
---+V7.5 Defenses Against Session Abuse
------+V7.5.1 Verify that the application requires full re-authentication before allowing modifications to …
------+V7.5.2 Verify that users are able to view and (having authenticated again with at least one factor) …
------+V7.5.3 Verify that the application requires further authentication with at least one factor or secondary …
---+V7.6 Federated Re-authentication
------+V7.6.1 Verify that session lifetime and termination between Relying Parties (RPs) and Identity Providers …
------+V7.6.2 Verify that creation of a session requires either the user's consent or an explicit action …
|
V7 Session Management
Control ObjectiveSession management mechanisms allow applications to correlate user and device interactions over time, even when using stateless communication protocols (such as HTTP). Modern applications may use multiple session tokens with distinct characteristics and purposes. A secure session management system is one that prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session. Applications maintaining sessions must ensure that the following high-level session management requirements are met: - Sessions are unique to each individual and cannot be guessed or shared.
- Sessions are invalidated when no longer required and are timed out during periods of inactivity.
Many of the requirements in this chapter relate to selected NIST SP 800-63 Digital Identity Guidelines controls, focusing on common threats and commonly exploited authentication weaknesses. Note that requirements for specific implementation details of certain session management mechanisms can be found elsewhere: - HTTP Cookies are a common mechanism for securing session tokens. Specific security requirements for cookies can be found in the "Web Frontend Security" chapter.
- Self-contained tokens are frequently used as a way of maintaining sessions. Specific security requirements can be found in the "Self-contained Tokens" chapter.
ReferencesFor more information, see also:
1. Prezentare generală
| Titlu |
Standard |
|
V7.1 Session Management Documentation
|
There is no single pattern that suits all applications. Therefore, it is not feasible to define universal boundaries and limits that suit all cases. A risk analysis with documented security decisions related to session handling must be conducted as a prerequisite to implementation and testing. This ensures that the session management system is tailored to the specific requirements of the application. Regardless of whether a stateful or "stateless" session mechanism is chosen, the analysis must be complete and documented to demonstrate that the selected solution is capable of satisfying all relevant security requirements. Interaction with any Single Sign-on (SSO) mechanisms in use should also be considered.
|
|
V7.2 Fundamental Session Management Security
|
This section satisfies the essential requirements of secure sessions by verifying that session tokens are securely generated and validated.
|
|
V7.3 Session Timeout
|
Session timeout mechanisms serve to minimize the window of opportunity for session hijacking and other forms of session abuse. Timeouts must satisfy documented security decisions.
|
|
V7.4 Session Termination
|
Session termination may be handled either by the application itself or by the SSO provider if the SSO provider is handling session management instead of the application. It may be necessary to decide whether the SSO provider is in scope when considering the requirements in this section as some may be controlled by the provider. Session termination should result in requiring re-authentication and be effective across the application, federated login (if present), and any relying parties. For stateful session mechanisms, termination typically involves invalidating the session on the backend. In the case of self-contained tokens, additional measures are required to revoke or block these tokens, as they may otherwise remain valid until expiration.
|
|
V7.5 Defenses Against Session Abuse
|
This section provides requirements to mitigate the risk posed by active sessions that are either hijacked or abused through vectors that rely on the existence and capabilities of active user sessions. For example, using malicious content execution to force an authenticated victim browser to perform an action using the victim's session. Note that the level-specific guidance in the "Authentication" chapter should be taken into account when considering requirements in this section.
|
|
V7.6 Federated Re-authentication
|
This section relates to those writing Relying Party (RP) or Identity Provider (IdP) code. These requirements are derived from the NIST SP 800-63C for Federation & Assertions.
|
1.1 Referințe
1.2 Cerințe identificate
1.3 Reglementări asociate
2. Cerințe identificate
3. Reglementări asociate
Reglementări
| Sursă |
Reglementare |
- OWASP -
EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative. - OWASP Application Security Verification Standard (ASVS) 5.0.0, May 2025, from OWASP/ASVS: © 2008-2025 The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: divided into sections and converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0, January 2024, from OWASP/masvs: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0, August 2026, from OWASP/maswe: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged, linked to the MASVS controls they map to. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0, June 2026, from OWASP/mastg: © The OWASP Foundation, licensed under CC BY-SA 4.0. The tests and best practices only, without code samples, images, tools or apps. Changes: converted into the GRCA format, the wording unchanged; references to other pages of the MASTG as links to mas.owasp.org; the weakness of each test in the numbering of MASWE v1 and linked to it. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Software Assurance Maturity Model (SAMM) v2.2.0, July 2026, from owaspsamm/core: © The OWASP Foundation, licensed under CC BY-SA 4.0. Changes: converted into the GRCA format, the wording unchanged; short codes (G-SM-1-A) built from the model, the assessment questions as assessment procedures of their activities. These adaptations are shared under CC BY-SA 4.0 as well.
- OWASP Top 10:2025, from OWASP/Top10: © 2003-2025 The OWASP® Foundation, Inc., licensed under CC BY-SA 4.0. The ten categories, without the icons. Changes: converted into the GRCA format, the wording unchanged. These adaptations are shared under CC BY-SA 4.0 as well. The names of the mapped CWEs (Common Weakness Enumeration): © 2006–2026 The MITRE Corporation. License: The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. See the CWE Terms of Use. CWE™ is a trademark of The MITRE Corporation.
DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen. - OWASP Application Security Verification Standard (ASVS) 5.0.0, Mai 2025, aus OWASP/ASVS: © 2008-2025 The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in Abschnitte aufgeteilt und in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Verification Standard (MASVS) v2.1.0, Januar 2024, aus OWASP/masvs: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Weakness Enumeration (MASWE) v1.0.0, August 2026, aus OWASP/maswe: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert, mit den MASVS-Controls verknüpft, denen sie zugeordnet sind. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Mobile Application Security Testing Guide (MASTG) v2.0.0, Juni 2026, aus OWASP/mastg: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Nur die Tests und Best Practices, ohne Codebeispiele, Bilder, Werkzeuge und Apps. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert; Verweise auf andere Seiten des MASTG als Links zu mas.owasp.org; die Schwachstelle jedes Tests in der Nummerierung der MASWE v1 und mit ihr verknüpft. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Software Assurance Maturity Model (SAMM) v2.2.0, Juli 2026, aus owaspsamm/core: © The OWASP Foundation, lizenziert unter CC BY-SA 4.0. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert; Kürzel (G-SM-1-A) aus dem Modell gebildet, die Assessment-Fragen als Prüfverfahren ihrer Aktivitäten. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0.
- OWASP Top 10:2025, aus OWASP/Top10: © 2003-2025 The OWASP® Foundation, Inc., lizenziert unter CC BY-SA 4.0. Die zehn Kategorien, ohne die Symbole. Änderungen: in das GRCA-Format umgewandelt, der Wortlaut unverändert. Diese Bearbeitungen stehen ebenfalls unter CC BY-SA 4.0. Die Namen der zugeordneten CWEs (Common Weakness Enumeration): © 2006–2026 The MITRE Corporation. MITRE erlaubt die Nutzung für Forschung, Entwicklung und kommerzielle Zwecke, wenn jede Kopie den Urheberrechtsvermerk und die Lizenz enthält; maßgeblich ist der englische Wortlaut der Lizenz oben und die CWE Terms of Use. CWE™ ist eine Marke der MITRE Corporation.
|