V3 chapter and section texts

[elarlang]

V3 chapter texts

Control Objective

As previously noted, these requirements have been adapted to be a compliant subset of selected NIST SP 800-63B controls, focused on common threats and commonly exploited authentication weaknesses.

Maybe "Many of these requirements..." to avoid "As previously noted".

Previous verification requirements have been retired, de-duped, or in most cases adapted to be strongly aligned with the intent of mandatory NIST SP 800-63B requirements.

I don't think we need this one. It is outdated really fast (what was previously is not relevant).

---

V1.3 Session Management Documentation

When this section text was made, the section was part of the "security decision documentation" chapter and before the session management chapter. By content it is "the topic opener" and I think that 1st paragraph should be merged into "Control Objective" 1st paragraph.

---

V3.7 Defenses Against Session Abuse

This section provides requirements to mitigate the risk posed by active sessions that are either hijacked or abused through vectors such as cross-site attacks.

"cross-site attacks"? such as "cross-site scripting, cross-site request forgery, and user interface redress attacks"?

---

V3.8 Session Termination

If self-contained tokens are being used, a way to revoke these tokens will be needed.

Maybe:
If self-contained tokens are being used, a way to revoke or block these tokens will be needed.

[tghosth]

@ryarmst will you be doing these updates? :)

[ryarmst]

@tghosth I am on it. I have had some stuff half written and will be following up shortly when I have some free time today.

[ryarmst]

Here is my proposal in full:

---

Control Objective

Session management mechanisms give applications the ability to correlate user and device interactions over time, even when using otherwise stateless communication protocols. Modern applications may utilize multiple session identifiers or tokens with distinct characteristics and purposes. A secure session management system is one that optimally 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 satisfied:

• Sessions are unique to each individual and cannot be guessed or shared.
• Sessions are invalidated when no longer required and timed out during periods of inactivity.

Many of the requirements in this chapter have been adapted to be a compliant subset of selected NIST SP 800-63 Digital Identity Guidelines controls, focused on common threats and commonly exploited authentication weaknesses.

Requirements governing some concepts related to implementation details of session management mechanisms can be found elsewhere:

• HTTP Cookies are a common mechanism for securing session identifiers and 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.

---

V1.3 Session Management Documentation

There is no single pattern that suits all applications. Therefore, it is infeasible 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.

---

V3.1 Fundamental Session Management Security

This section satisfies the essential requirements of secure sessions by verifying that session tokens are securely generated, managed, and validated.

---

V3.2

See #2449

---

V3.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 requirements.

---

V3.6 Federated Re-authentication

This section relates to those writing Relying Party (RP) or Credential Service Provider (CSP) code. These requirements are derived from the NIST SP 800-63C for Federation & Assertions.

---

V3.7 Defenses Against Session Abuse

This section provides requirements to mitigate the risk posed by active sessions that are either hijacked or abused through vectors such as cross-site request forgery (CSRF) and other cross-site attacks, which rely on the existence and capabilities of active user sessions.

---

V3.8 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.

[elarlang]

Requirements governing some concepts related to implementation details of session management mechanisms can be found elsewhere:

• HTTP Cookies are a common mechanism for securing session identifiers and 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.

Should we add here already terms like reference tokens and stateful mechanism (for cookies)?

(This is nice-to-have topic to discuss, in general I think we can PR it in and finetune the pieces later if needed)

[jmanico]

We are trending to make this text a lot more brief than what we see above. Can we consider reducing it so it's more inline with out reduced sections like:

https://github.com/OWASP/ASVS/blob/master/5.0/en/0x12-V4-Access-Control.md

[elarlang]

Jim, I agree with the direction, but just in case - note that proposal contains basically all chapter and sections texts.

For each sentence we can ask "why it exists and what message / point it sends", if there no clear answer, then probably it can be removed.

[jmanico]

For starters, I suggest this section be removed. We often deviate from NIST. The remaining part above this section is more inline with the size of the other new sections.

** Suggested section to remove **

Many of the requirements in this chapter have been adapted to be a compliant subset of selected NIST SP 800-63 Digital Identity Guidelines controls, focused on common threats and commonly exploited authentication weaknesses.

Requirements governing some concepts related to implementation details of session management mechanisms can be found elsewhere:

HTTP Cookies are a common mechanism for securing session identifiers and 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.

[ryarmst]

Many of the requirements in this chapter have been adapted to be a compliant subset of selected NIST SP 800-63 Digital Identity Guidelines controls, focused on common threats and commonly exploited authentication weaknesses.

While many requirements deviate from NIST, I do think it is a particularly relevant reference for this chapter. That said, I do recognize that it is not a goal to provide comprehensive references.

While there is an effort to make the ASVS short/concise, I think there is value in providing chapter and section text that helps contextualize the requirements.

Requirements governing some concepts related to implementation details of session management mechanisms can be found elsewhere: ...

On its own, this does seem like unnecessary bloat, but the intent behind this text was to provide direction for implementation details previously within this chapter (V3) that ASVS consumers may expect to find here, but have been moved elsewhere for better logical organization. Consider HTTP Cookies: this mechanism has pretty much universally been grouped with session management concerns. I lean towards its inclusion, but it could be shortened.

[jmanico]

I think the NIST stuff is mostly irrelevant, and defining cookies and tokens should go in the glossary.

I still respectfully think we can shorten this section up a lot if we have not done already.

Thank you kindly for this effort, Ryan!

[elarlang]

Glossary is just for "we have it defined somewhere", but it does not help with readability.

We have at the moment quite a different direction for OAuth chapter text - we can duplicate the terms to a glossary, but it loses the readability and overview.

Probably I'm the first one to vote for shorter texts, but at the same time I always say - every line must have a point and message to carry and the whole thing must be usable. In short - at the moment I'm in favor of having a bit longer text for chapters and sections to have a clear(er) overview of related terms because this is really important and fundamental to understanding the requirements. Those are so discussed and opinionated terms, that it must be clear what we mean by those without leaving readers with their assumptions.

[tghosth]

Let's get it into a PR and see what it looks like.

In general I'd prefer shorter text and I understand why @jmanico is pushing for that.

On the other hand, I can be persuaded with longer text if it is adding value to the requirements. Given how much discussion we had around V3 this might be a good candidate for more explanations and even term definitions here rather than the glossary :)

[ryarmst]

I put the latest proposal in #2459