Add changes to CR and C to align better with ASVS 5.0

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

@@ -32,6 +32,6 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 2. Enforce the use of signature verification for the distribution of executable code and packages.
 3. Consider using anti reverse-engineering techniques. Implement code obfuscation techniques to prevent easy decompilation and understanding of business logic in distributed binaries.
 4. Avoid embedding secrets in the source code. Instead, use secure methods for managing and accessing credentials and keys.
-5. Conduct regular security reviews and audits of source code management practices
+5. Conduct regular security reviews and audits of source code management practices.
 
 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/cornucopia/C4/explanation.md

@@ -33,5 +33,6 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 1. Implement comprehensive logging of all user activities within the application, capturing details such as timestamps, user IDs, and the nature of the actions.
 2. Ensure that all actions are attributable to individual users by maintaining secure and unique user identification mechanisms.
 3. Develop robust audit trails that provide a clear and detailed history of user actions for accountability and forensic analysis.
+4. Ensure that logs are securely transmitted to a logically separate system for analysis, detection, alerting, and escalation, and that they are protected from unauthorized access and modification.
 
 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/cornucopia/C5/explanation.md

@@ -18,9 +18,10 @@ The primary STRIDE category is **Spoofing**.
 
 This scenario is about exploiting trust for malicious gain, typically referred to in STRIDE as **Spoofing**, because Larry pretends to be the trusted application or uses its trusted identity to deceive others.
 
+
 ### What can go wrong?
 
-Such manipulation can lead to significant breaches of user trust, unauthorized access to sensitive information, and exploitation of interconnected systems. Abuse of trust attacks include: Clickjacking, Phishing, Pharming, SSL downgrade/misconfiguration.
+Such manipulation can lead to significant breaches of user trust, unauthorized access to sensitive information, and exploitation of interconnected systems. Abuse of trust attacks include: Clickjacking, Phishing, Pharming, SSL downgrade/misconfiguration, auth code interception attacks, mix-up attacks, and session replay and token replay attacks.
 
 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.
 
@@ -30,5 +31,6 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 2. Educate users about the risks of phishing and other trust exploitation tactics. 
 3. Monitor and control how the application’s APIs and services interact with other systems, ensuring secure and verified connections.
 4. Establish strict guidelines and security protocols for third-party applications or services that integrate with the application.
+5. Implement and properly configure identity management to ensure authentication and authorization tokens are properly secured to mitigate unauthorized access and exploitation of interconnected systems.
 
 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/cornucopia/C7/explanation.md

@@ -24,7 +24,7 @@ The STRIDE category applicable here is **Repudiation**.
 
 ### What can go wrong?
 
-Inadequate logging and auditing can lead to significant gaps in security oversight, hindering the ability to detect, investigate, and respond to unauthorized activities.
+Inadequate logging and auditing can lead to significant gaps in security oversight, hindering the ability to detect, investigate, and respond to unauthorized activities. It increases the risk of identity theft, insider threats, advanced persistent threats, and replay attacks going unnoticed.
 
 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.
 

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

@@ -34,7 +34,7 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 
 ### What are we going to do about it?
 
-1. Regularly update all frameworks, libraries, and components to their latest, secure versions.
+1. Regularly update all frameworks, libraries, and components to their latest, secure versions and ensure their versions are pinned.
 2. Conduct thorough security reviews and vulnerability assessments of all in-house, outsourced, and open-source code used within the application.
 3. Monitor security advisories for any components used within the application and respond swiftly to vulnerability disclosures.
 4. Establish a robust security protocol for integrating and maintaining external software components.

cornucopia.owasp.org/data/cards/webapp-cards-3.0-en/cryptography/CR6/explanation.md

@@ -6,6 +6,8 @@ Picture a scenario where Romain accesses and modifies unencrypted data, either i
 
 2. **Data Exposed in Communication:** Personal and commercially-sensitive data is transmitted without encryption, either within the application or in interactions with external systems.
 
+3. **Data lacks authenticated integrity protection:** Personal and commercially-sensitive data is not protected using an HMAC (or another message authentication code), a digital signature with an asymmetric key, or both, meaning that an attacker can modify the data in transit without detection.
+
 ### Example
 
 Romain targets an application that handles sensitive user data but fails to encrypt this data while in use or during internal processing. He exploits this by accessing the application’s memory, where he finds unencrypted credentials and session identifiers. Additionally, Romain intercepts data being transmitted between the application and external systems, such as payment gateways, as it is sent without proper encryption, allowing him to read and modify sensitive information during transit.
@@ -27,8 +29,8 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 
 ### What are we going to do about it?
 
-1. Implement encryption for sensitive data while it is in memory and during processing within the application.
-2. Ensure that all data communications, both internal and external, are secured with robust encryption methods.
+1. Implement proper encryption for sensitive data while it is in memory, in transit, and during processing within the application according to the latest recommendations for cryptographic operations.
+2. Ensure that all data communications, both internal and external, are secured with robust and recommended encryption methods using only approved and recommended cryptographic algorithms and modes of operation.
 3. Regularly review and update encryption practices to cover data in use, in transit, and during communications with external systems.
 
 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/cryptography/CR7/explanation.md

@@ -36,5 +36,9 @@ Configuration best practice guidance needs to be reviewed periodically, vulnerab
 2. Use valid and trusted certificates for encrypted communications to prevent man-in-the-middle attacks.
 3. Prevent the possibility of downgrading encrypted connections to weaker or unencrypted states.
 4. Regularly review and update the cryptographic setup to address new vulnerabilities and maintain strong security.
+5. Ensure digital signatures use collision-resistant hash functions with appropriate output lengths (for example, SHA-256 or stronger), and ensure HMACs use approved hash functions with sufficiently long tags and strong, unpredictable keys for data authentication and integrity.
+6. All random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy.
+7. Only allow modern, recommended versions of TLS (for example, TLS 1.2 and TLS 1.3), and require TLS for all communication, both within the application and with external services.
+8. Log and monitor security events such as backend TLS and encryption failures.
 
 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/cryptography/CR8/explanation.md

@@ -30,5 +30,9 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 1. Implement robust encryption for sensitive data storage, ensuring that even if data is accessed, it remains unintelligible and secure.
 2. Use secure hashing algorithms, particularly for storing passwords, to prevent them from being reverted to their original form.
 3. Regularly review and update encryption and hashing methods to adhere to current best practices and standards.
+4. For digital signatures, use collision-resistant hash functions with appropriate output lengths (for example, SHA-256 or stronger) and key sizes that meet current recommendations; for HMACs, use approved hash functions (for example, HMAC-SHA-256 or stronger) and ensure the MAC/tag length provides sufficient security (typically at least 128 bits of effective strength, avoiding excessive truncation).
+5. All random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy.
+6. Only allow modern, recommended versions of TLS (for example, TLS 1.2 and TLS 1.3), and enforce TLS for all internal and external application communications.
+7. Log and monitor security events such as backend TLS and encryption failures.
 
 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.