Change the text for cards belonging to VE, AT & SM to align them with modern authentication and session management practices

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/authentication/AT3/explanation.md

@@ -1,6 +1,6 @@
 ## Scenario: Muhammad’s Secret Acquisition
 
-Imagine a scenario where Muhammad, a skilled eavesdropper, obtains a user's password or other confidential information like security questions. He exploits various vulnerabilities:
+Imagine a scenario where Muhammad, a skilled eavesdropper, obtains a user's password or other confidential information like MFA codes (stored in your password manager without password protection) or your fingerprint. He exploits various vulnerabilities:
 
 1. **Observation During Entry:** Muhammad watches as a user enters their password.
 

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/authentication/AT6/explanation.md

@@ -10,7 +10,7 @@ Envision a scenario where Sven capitalizes on the shortcomings in temporary pass
 
 ### Example
 
-Sven discovers that a company’s system issues temporary passwords to users which do not expire quickly and do not require a change upon first use. He intercepts or guesses these temporary passwords and gains access to user accounts, exploiting the extended period these passwords remain valid and the lack of a mandatory password reset on initial login.
+Sven discovers that a company’s system issues temporary passwords and/or MFA codes to users which do not expire quickly and do not require a change upon first use. He intercepts or guesses these temporary passwords/codes and gains access to user accounts, exploiting the extended period these remain valid and the lack of a mandatory password reset on initial login.
 
 ## Threat Modeling
 

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/authentication/AT7/explanation.md

@@ -10,7 +10,7 @@ Imagine a situation where Cecilia, employing brute force and dictionary attack t
 
 ### Example
 
-Cecilia targets an online platform that lacks account lockout policies and has weak password requirements. She uses automated tools to repeatedly attempt logins on various accounts, trying combinations from commonly used passwords and dictionary words. Due to the absence of complexity and length requirements for passwords, and no system to detect or block repeated failed attempts, she eventually succeeds in guessing the correct credentials for several accounts.
+Cecilia targets an online platform that lacks account lockout policies and has weak authentication requirements. She uses automated tools to repeatedly attempt logins on various accounts, trying combinations from commonly used passwords and dictionary words. Due to the absence of complexity and length requirements for passwords, and no system to detect or block repeated failed attempts, she eventually succeeds in guessing the correct credentials for several accounts.
 
 ## Threat Modeling
 

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/authentication/AT9/explanation.md

@@ -2,7 +2,7 @@
 
 Imagine a situation where Claudia, exploiting insufficient authentication protocols, gains access to critical functions within a system. This occurs due to:
 
-1. **Weak Authentication Standards:** The system lacks robust authentication methods, such as two-factor authentication (2FA), relying only on basic password entry.
+1. **Weak Authentication Standards:** The system lacks robust authentication methods, such as passkeys or two-factor authentication (2FA), relying only on basic password entry or on low-assurance methods such as email one-time passcodes (email-based “MFA”).
 
 2. **Absence of Re-authentication:** There's no requirement for users to re-authenticate or confirm their identity for accessing or performing sensitive or critical operations.
 

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/data-validation-&-encoding/VEQ/technical-note.md

@@ -1 +1 @@
-This relates to actual exploitation of an injection vulnerability on the client-side. See [Data Validation & Encoding K (VEK)](/cards/VEK#card 'Data Validation & Encoding K [internal]') for the same attack server-side, and other cards in this suit for individual data validation and encoding issues (e.g. missing/by-passable/badly-implemented input/output validation, encoding or sanitization).
+This relates to actual exploitation of an injection vulnerability on the client-side (e.g., XSS). See [Data Validation & Encoding K (VEK)](/cards/VEK#card 'Data Validation & Encoding K [internal]') for the same attack server-side, and other cards in this suit for individual data validation and encoding issues (e.g. missing/by-passable/badly-implemented input/output validation, encoding or sanitization).

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/data-validation-&-encoding/VEX/explanation.md

@@ -6,7 +6,7 @@ Imagine a scenario where Darío takes advantage of the application's trust in it
 
 2. **Tampering with Client-Side Data:** The application fails to validate data altered on a client device.
 
-3. **Altering State Data on Client Devices:** The application doesn't verify the integrity of state data, like session tokens, stored on client devices.
+3. **Altering State Data on Client Devices:** The application doesn't verify the integrity of state data, like session tokens or JWTs stored on client devices.
 
 4. **Lack of Identity Verification:** The system inadequately verifies the identity of a user during data validation.
 

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/session-management/SM2/explanation.md

@@ -1,14 +1,15 @@
 ## Scenario: William's Control Over Session Identifier Generation
 
-Envision a scenario where William, exploiting a critical aspect of session management, gains control over the generation of session identifiers. He leverages this control to:
+Envision a scenario where William, exploiting a critical aspect of session management, gains control over the generation of session identifiers or authorization tokens. He leverages this control to:
 
 1. **Predictability in Session IDs:** By influencing session ID generation, William makes these identifiers predictable, allowing him to guess valid session IDs.
 
-2. **Creation of Weak Session Identifiers:** He generates session identifiers that are not sufficiently random or complex, making them easier to compromise.
+2. **Creation of Weak Session Identifiers or Tokens:** He generates session identifiers or tokens that are not sufficiently protected, random, or complex, making them easier to compromise.
 
 ### Example
 
-William infiltrates a web application's session management system. He manipulates the session ID generation algorithm to produce predictable IDs. For instance, he sets the IDs to increment sequentially. With this knowledge, William easily predicts and hijacks active sessions by guessing the next valid session ID, gaining unauthorized access to user accounts and sensitive data.
+William infiltrates a web application's session management system. He manipulates the session ID generation algorithm to produce predictable IDs. For instance, he sets the IDs to increment sequentially. With this knowledge, William easily predicts and hijacks active sessions by guessing the next valid session ID, gaining unauthorized access to user accounts and sensitive data. 
+Or he finds an unprotected endpoint (e.g., a cache) containing JWT tokens and can exchange them for new tokens with a payload of his choosing, allowing him to impersonate other users or escalate privileges.
 
 ## Threat Modeling
 
@@ -29,7 +30,7 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 
 ### What are we going to do about it?
 
-In general use the server or framework’s own session management controls, rather than creating custom code. The application should only recognize these session identifiers as valid, and the session identifier creation must always be done on a trusted system (e.g. server-side).
+In general, use the server or framework’s own session management controls, rather than creating custom code. The application should only recognize these session identifiers as valid, and the session identifier creation must always be done on a trusted system (e.g., server-side).
 
 1. Ensure that session identifiers are generated using strong, cryptographically secure algorithms that produce random and complex IDs.
 2. Regularly review and test the session ID generation process to ensure it remains robust against prediction and manipulation.

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/session-management/SM3/explanation.md

@@ -1,12 +1,15 @@
-## Scenario: Ryan’s Exploitation of Concurrent Sessions
+## Scenario: Ryan’s Exploitation of a Poorly Implemented Session Management System
 
-Imagine a scenario where Ryan takes advantage of a system's leniency in allowing multiple concurrent sessions for a single account. This occurs because:
+Imagine a scenario where Ryan takes advantage of a system that doesn't sufficiently give the user an overview of their active sessions and allows multiple sessions without proper controls. He exploits the following vulnerabilities:
 
-1. **Allowance of Multiple Active Sessions:** The system permits one user account to be logged in from multiple devices or locations at the same time.
+1. **Allowance of Multiple Active Sessions:** The system does not give the user an overview of which devices are logged in. This allows Ryan to log in on a device while the legitimate user is also active, without the user being aware of it.
+2. **Lack of Controls on Concurrent Sessions:** The system fails to restrict or monitor active sessions, enabling Ryan to access the account without detection.
+3. **No Alerts for Unusual Concurrent Access:** The system does not alert users or administrators about unusual patterns of access, such as logins from other countries or old devices.
+4. **Inadequate Session Management Policies:** The system does not have robust session management policies to handle scenarios like authorization code theft or session fixation. If a session gets compromised, Ryan can continue to use it without the system detecting the breach or being able to empower administrators and users to take appropriate actions.
 
 ### Example
 
-Ryan discovers that a corporate network does not restrict the number of active sessions per user account. He obtains the login credentials of an employee and logs into the account while the legitimate user is also active. The system fails to detect or alert the concurrent usage, allowing Ryan to access sensitive information and perform unauthorized actions unnoticed.
+Ryan discovers that someone at the airport has left their mobile device unattended. He steals the device and takes it home. He then finds out that the user still has an active session on the device and uses it to access the account. The user is unaware of this access, and the system does not have any controls or alerts in place to detect or prevent it. Ryan can then access sensitive information and perform unauthorized actions without being detected.
 
 ## Threat Modeling
 
@@ -15,21 +18,24 @@ Ryan discovers that a corporate network does not restrict the number of active s
 This scenario falls under STRIDE: **Spoofing**.
 
 **Spoofing** is about impersonating a legitimate user or system.
-Ryan uses valid credentials to simultaneously access the account while the legitimate user is active, effectively impersonating the user in parallel.
-The system’s failure to restrict or monitor concurrent sessions enables him to bypass control over who is acting as that user.
+Ryan exploits a poorly implemented session management system that allows him to access active sessions without the user's knowledge or being able to prevent it.
 
 ### What can go wrong?
 
-Allowing concurrent sessions without proper controls can lead to unauthorized access and exploitation of user accounts, potentially compromising data security and privacy.
+Poorly implemented session management can lead to unauthorized access and exploitation of user accounts, potentially compromising data security and privacy.
 
 For more things that can go wrong, see the [Common Attack Patterns related to this card](#mapping 'Common Attack Patterns related to this card [internal]') in the table below.
 
 ### What are we going to do about it?
 
-In some ecommerce applications it may be desirable to allow customers to be logged in using multiple browsers/devices. However that would be unusual for administrative users, or users of more sensitive data. Even if concurrent sessions are allowed. consider what should occur in other sessions when a user changes their password, or changes their delivery address, or logs out, or times out, or authentication failure occurs.
+For many applications, it may be desirable to allow customers to be logged in using multiple browsers/devices. Consider implementing a policy to restrict or carefully monitor active sessions. Options include implementing impossible travel detection, alerting in case of logins from geographically distant locations within a short timeframe, or even from old devices. Require the use of MFA in these cases. Also consider that users should be informed about active sessions and be able to manage them, including terminating sessions that they do not recognize. This can help mitigate the risk of unauthorized access and provide users with greater control over their accounts. Additionally, implementing robust session management policies can help detect and prevent session fixation and authorization code theft, further enhancing the security of the application.
 
-1. Implement a policy to restrict or carefully monitor concurrent sessions. Options include limiting the number of simultaneous sessions per user or requiring additional verification for new sessions.
-2. Set up alerts for unusual patterns of concurrent access, such as logins from geographically distant locations within a short timeframe.
-3. Regularly audit session management policies to ensure they effectively protect against unauthorized concurrent access. 
+1. Implement a policy to restrict or carefully monitor active sessions.
+2. Require the use of MFA for logins from new devices or locations.
+3. Provide users with an overview of their active sessions and the ability to manage them, including terminating sessions that they do not recognize.
+4. Implement robust session management policies to detect and prevent session fixation and authorization code theft.
+5. Regularly review and update session management policies to ensure they effectively protect against unauthorized access and account compromise.
+6. Educate users about the importance of monitoring their active sessions and recognizing signs of unauthorized access.
+7. Implement alerts for unusual access patterns, such as logins from other countries or old devices, to enhance security and enable timely responses to potential breaches.
 
 For detailed advice on how to mitigate threats related to the card, see the [ASVS and OWASP Developer Guide requirements ](#mapping 'ASVS and OWASP Developer Guide requirements [internal]') in the table below.

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/session-management/SM4/explanation.md

@@ -1,8 +1,12 @@
-## Scenario: Alison’s Cookie Manipulation Across Domains
+## Scenario: Alison’s Manipulation Across Domains
 
-Visualize a situation where Alison, exploiting weaknesses in cookie management, sets session identification cookies on a different web application. This happens due to:
+Visualize a situation where Alison, exploiting weaknesses in cookie or token management, sets session identification cookies on a different web application or manipulates the audience claims in tokens. This happens due to:
 
 1. **Insufficient Domain and Path Restrictions:** The web application does not adequately restrict the domain and path for which its cookies are valid.
+2. **Lack of Secure Cookie Attributes:** The application fails to use secure attributes (e.g., Secure, HttpOnly, SameSite) for its cookies, making them vulnerable to manipulation and cross-site attacks.
+3. **Inadequate Token Audience Validation:** The application does not properly validate the audience claims in tokens, allowing them to be used across different applications or contexts.
+4. **Absence of strong secret management:** The client is incapable of securely storing refresh tokens or cookies, making them vulnerable to theft and misuse.
+5. **Absence of strong client authentication resistant to replay attacks:** The application does not implement strong client authentication methods, making it easier for attackers to impersonate legitimate users and misuse tokens or cookies.
 
 ### Example
 
@@ -15,14 +19,14 @@ Alison targets a web application that has loosely defined domain attributes for
 This scenario maps primarily to STRIDE: **Spoofing**.
 
 **Spoofing** is about impersonating a legitimate user or entity.
-Alison sets cookies for another web application due to insufficient domain/path restrictions, which lets her impersonate users or hijack their sessions on that application.
+Alison sets cookies for another web application due to insufficient domain/path restrictions, allowing her to impersonate users or hijack their sessions on that application.
 The root issue is unauthorized impersonation via session manipulation, making Spoofing the correct primary category.
 
 ### What can go wrong?
 
 Such vulnerabilities can lead to cross-domain attacks, unauthorized session tracking, and potentially session hijacking, compromising user security on multiple applications.
 
-There may be reasons to share sessions across multiple applications, but if one of those applications is less secure one application might be used to compromise another.
+There may be reasons to share sessions across multiple applications, but if one of those applications is less secure, one application might be used to compromise another.
 
 For more things that can go wrong, see the [Common Attack Patterns related to this card](#mapping 'Common Attack Patterns related to this card [internal]') in the table below.
 
@@ -33,5 +37,7 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 3. Use SameSite Cookie Attribute: Configure the SameSite attribute on cookies to prevent them from being sent with cross-site requests, which helps mitigate the risk of cross-site request forgery (CSRF).
 4. Regularly change session IDs after authentication to minimize the impact of a compromised ID.
 5. Regularly review and update cookie policies to align with best practices in web security.
+6. Implement strong client authentication methods that are resistant to replay attacks, and ensure that authorization servers implement refresh token rotation (issuing a new refresh token on each use, revoking the previous one, and detecting any reuse of revoked tokens) to limit the impact of token theft.
+7. Ensure that tokens are properly validated for their intended audience to prevent misuse across different applications.
 
 For detailed advice on how to mitigate threats related to the card, see the [ASVS and OWASP Developer Guide requirements ](#mapping 'ASVS and OWASP Developer Guide requirements [internal]') in the table below.

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/session-management/SM7/explanation.md

@@ -8,6 +8,8 @@ Imagine a situation where Graham takes advantage of a system’s flawed session
 
 3. **Complex Log Out Process:** The log out function is not easily accessible or user-friendly, leading to users inadvertently leaving sessions active.
 
+4. **No Session Logout when Authentication Credentials are Changed:** The system does not automatically log out users from all sessions when they change their authentication credentials, such as passwords or MFA methods.
+
 ### Example
 
 Graham targets a web application where users find it difficult to locate the log out button due to its obscure placement. Adam, a user of the application, believes he has exited the session, but in reality, the session remains active. Graham, seizing this opportunity, accesses the still-active session from Adam's device or a public computer Adam used, gaining unauthorized access to Adam’s account and sensitive information.
@@ -35,5 +37,6 @@ Users should be able to log out from any pages protected by access control (auth
 1. Ensure the log out function is clearly visible and easily accessible on all interfaces of the application.
 2. Design the log out process to completely terminate the session on the server side, not just on the client device.
 3. Conduct user experience testing to ensure the log out process is intuitive and effective.
+4. Implement automatic session termination when users change their authentication credentials to stop ongoing abuse from already stolen sessions.
 
 For detailed advice on how to mitigate threats related to the card, see the [ASVS and OWASP Developer Guide requirements ](#mapping 'ASVS and OWASP Developer Guide requirements [internal]') in the table below.