Adding ASVS to CAPEC mapping for the Cornucopia suit. Adding logging …

cornucopia.owasp.org/data/cards/webapp-cards-2.2-en/cornucopia/C5/explanation.md

@@ -20,15 +20,22 @@ This scenario is about exploiting trust for malicious gain, typically referred t
 
 ### 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, Session Hijacking, Cross-Site Request Forgery (CSRF) and Session Credential Falsification through Forging.
 
 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?
 
 1. Implement robust verification and authentication measures to prevent misuse of the application’s trusted status.
-2. Educate users about the risks of phishing and other trust exploitation tactics. 
+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 Content Security Policy (CSP) to mitigate clickjacking and other injection attacks.
+6. Use secure cookies and implement anti-CSRF tokens to protect against session hijacking and CSRF attacks.
+7. Implement session management best practices, including secure session identifiers and proper session expiration.
+8. Enforce digital signatures and integrity checks for tokens and limit the scope and audience of their use.
+9. Harden token exchange flows, limit the lifetime of tokens and enforce cryptographic proof of possession.
+10. Regularly audit and update SSL/TLS configurations to prevent downgrade attacks.
+11. Employ multi-factor authentication (MFA) to enhance user account security.
 
 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-2.2-en/cornucopia/C6/explanation.md

@@ -8,9 +8,13 @@ Imagine a situation where Aaron exploits weaknesses in an application’s error
 
 3. **Dependence on External Error Handling:** The application relies on other services or systems for its error management, creating gaps in control.
 
+4. **Information Leakage through Errors:** Error messages reveal sensitive information that can be exploited.
+
+5. **Fallback to Insecure States:** In the event of an error, the application reverts to a less secure state, like unencrypted communication or default credentials, allowing Aaron to bypass normal controls.
+
 ### Example
 
-Aaron targets a web application that has incomplete error handling routines. He induces errors in the application which, due to inadequate or inconsistent handling, expose sensitive information or system functionalities. Additionally, since errors do not default to denying access or terminating execution, Aaron uses these error states to bypass normal application controls. In some cases, the application relies on external systems to handle errors, and Aaron exploits the delay or miscommunication between these systems to gain unauthorized access.
+Aaron targets a web application that has incomplete error handling routines. He induces errors in the application which, due to inadequate or inconsistent handling, expose sensitive information or system functionalities. Additionally, since errors do not default to denying access or terminating execution, Aaron uses these error states to bypass normal application controls. In some cases, the application relies on external systems to handle errors, and Aaron exploits the delay or miscommunication between these systems to gain unauthorized access or to revert the application to a less secure state.
 
 ## Threat Modeling
 
@@ -38,5 +42,6 @@ Ensure all forms of error are handled robustly and consistently (e.g. web server
 4. Avoid relying solely on external systems for error handling; ensure that the application has robust internal mechanisms to deal with errors securely. The application should handle application errors and not rely on the server configuration.
 5. Regularly review and test error handling routines to identify and address any weaknesses or inconsistencies.
 6. Properly free allocated memory when error conditions occur.
+7. Avoid fallback to insecure states in the event of an error, such as unencrypted communication or default credentials.
 
 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-2.2-en/cornucopia/C9/explanation.md

@@ -6,6 +6,8 @@ Consider a situation where Michael bypasses standard application protocols to ga
 
 2. **Inadequate Access Controls for Administrative Interfaces:** The interfaces used for administrative purposes are easily accessible and lack stringent access restrictions.
 
+3. **Weak Authentication Mechanisms:** The authentication processes for accessing administrative tools are missing or not strong enough, allowing unauthorized users to gain entry.
+
 ### Example
 
 Michael discovers that a web application’s administrative interface is accessible through a common URL and is only protected by a weak password. Leveraging this, he gains access to the administrative panel where he can view, modify, and delete sensitive data. This unauthorized access is facilitated by the lack of multi-factor authentication, inadequate password policies, and the absence of monitoring mechanisms on the administrative interface.
@@ -32,5 +34,6 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 2. Enforce robust password policies and regular credential updates for system administrators.
 3. Restrict access to administrative interfaces to a limited set of authorized IP addresses or networks.
 4. Regularly audit and monitor activities performed through administrative tools to detect and respond to unauthorized access.
+5. Ensure that administrative tools are not exposed to the public internet unless absolutely necessary, and if they are, implement additional security layers such as VPNs or bastion hosts.
 
 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-2.2-en/cornucopia/CJ/explanation.md

@@ -1,3 +1,5 @@
+Roman can exploit the application because dangourous or risky compononents haven't been securely compiled or deployed, or its configuration is not secure by default, or security information was not documented, or passed on to operational teams, or the user is not warned or access blocked when the expected security features are not supported or enabled
+
 ## Scenario: Roman’s Exploitation of Outdated Compilation and Configuration Lapses
 
 Envision a scenario where Roman takes advantage of vulnerabilities in an application caused by using outdated compilation tools, insecure default configurations, or a lack of documented security information for operational teams. These issues arise from:
@@ -6,6 +8,8 @@ Envision a scenario where Roman takes advantage of vulnerabilities in an applica
 
 2. **Insecure Default Configuration:** The application’s default configuration settings are not aligned with best security practices.
 
+3. **Use of Dangerous or Risky Components:** The application includes components that are considered dangerous or risky, which have not been securely deployed and configured.
+
 3. **Lack of Security Documentation:** Essential security information and configurations are not properly documented or communicated to the operational teams responsible for maintaining the application.
 
 ### Example
@@ -34,5 +38,6 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 2. Configure the application with secure settings by default and regularly review these settings to align with evolving security standards. 
 3. Create comprehensive security documentation and ensure it is effectively communicated and accessible to all operational teams. 
 4. Conduct regular security audits and provide ongoing training to operational teams to keep them informed about security best practices and application-specific requirements.
+5. Avoid using dangerous or risky components, and if their use is necessary, ensure they are securely deployed and configured.
 
 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.

source/webapp-cards-3.0-en.yaml

@@ -408,7 +408,7 @@ suits:
     id: "CJ"
     value: "J"
     url: "https://cornucopia.owasp.org/cards/CJ"
-    desc: "Roman can exploit the application because it was compiled using out-of-date tools, or its configuration is not secure by default, or security information was not documented, or passed on to operational teams, or the user is not warned or access blocked when the expected security features are not supported or enabled"
+    desc: "Roman can exploit the application because it was insecurely compiled or deployed, or its configuration is not secure by default, or because security information was not documented, or passed on to operational teams, or the user is not warned and access blocked when the expected security features are unsupported or disabled"
   -
     id: "CQ"
     value: "Q"

source/webapp-mappings-2.2.yaml

@@ -1137,15 +1137,15 @@ suits:
     id: "C5"
     value: "5"
     url: "https://cornucopia.owasp.org/cards/C5"
-    stride: [ R ]
+    stride: [ S ]
     owasp_scp: [ "-" ]
-    stride_print: [ Repudiation ]
+    stride_print: [ Spoofing ]
     owasp_dev_guide: [ ]
     owasp_dev_guide_print: [ "-" ]
     owasp_asvs: [ 1.9.2, 5.1.5, 9.1.1, 9.2.1, 9.2.4 ]
     owasp_asvs_print: [ 1.9.2, 5.1.5, 9.1.1, 9.2.1, 9.2.4 ]
     owasp_appsensor: [ "-" ]
-    capec: [ 21, 22, 57, 89, 103, 181, 459 ]
+    capec: [ 21, 22, 57, 89, 103, 181, 473 ]
     safecode: [ "-" ]
     owasp_cre:
       owasp_asvs: [ 530-671, 232-217, 745-045, 430-636, 537-367 ]
@@ -1162,7 +1162,7 @@ suits:
     owasp_asvs: [ 4.1.5, 7.1.4 ]
     owasp_asvs_print: [ 4.1.5, 7.1.4 ]
     owasp_appsensor: [ "-" ]
-    capec: [ 54, 98, 164, 172, 554 ]
+    capec: [ 54, 114, 217 ]
     safecode: [ 4, 11, 23 ]
     owasp_cre:
       owasp_asvs: [ 166-15, 555-048 ]
@@ -1196,7 +1196,7 @@ suits:
     owasp_asvs: [ 1.4.5, 10.3.1, 10.3.2, 14.1.4, 14.1.5, 14.2.1, 14.2.2 ]
     owasp_asvs_print: [ 1.4.5, 10.3.1-2, 14.1.4-5, 14.2.1-2 ]
     owasp_appsensor: [ RE1, RE2 ]
-    capec: [ 37, 161, 169, 176, 220, 310, 536 ]
+    capec: [ 37, 121, 159, 169, 217, 220, 310, 446 ]
     safecode: [ "-" ]
     owasp_cre:
       owasp_asvs: [ 801-310, 154-031, 418-525, 208-355, 347-352, 715-334, 462-245 ]
@@ -1213,7 +1213,7 @@ suits:
     owasp_asvs: [ 1.4.5, 4.3.1 ]
     owasp_asvs_print: [ 1.4.5, 4.3.1 ]
     owasp_appsensor: [ "-" ]
-    capec: [ 122, 169, 233 ]
+    capec: [ 1, 36, 49, 87, 121, 127, 169 ]
     safecode: [ "-" ]
     owasp_cre:
       owasp_asvs: [ 801-310, 201-246 ]
@@ -1229,7 +1229,7 @@ suits:
     owasp_asvs: [ 1.14.3, 10.1.1, 10.2.3, 10.2.4, 10.2.5, 10.2.6, 14.2.1 ]
     owasp_asvs_print: [ 1.14.3, 10.1.1, 10.2.3-6, 14.2.1 ]
     owasp_appsensor: [ "-" ]
-    capec: [ 68, 310, 438, 439, 442, 443, 523, 524, 446, 538 ]
+    capec: [ 68, 159, 206, 442, 446, 523, 538, 673, 691 ]
     safecode: [ 15 ]
     owasp_cre:
       owasp_asvs: [ 053-751, 611-158, 838-636, 838-636, 418-525, 265-800, 715-334 ]
@@ -1246,7 +1246,7 @@ suits:
     owasp_asvs: [ 1.14.3, 14.1.1, 14.1.2, 14.1.3, 14.1.4, 14.1.5, 14.2.1 ]
     owasp_asvs_print: [ 1.14.3, 14.1.1-5, 14.2.1 ]
     owasp_appsensor: [ "-" ]
-    capec: [ 445, 447 ]
+    capec: [ 70, 121, 127, 133, 176, 180, 191, 207 ]
     safecode: [ 4 ]
     owasp_cre:
       owasp_asvs: [ 053-751, 253-452, 314-131, 180-488, 208-355, 347-352, 715-334 ]
@@ -1262,7 +1262,7 @@ suits:
     owasp_asvs: [ 8.1.4, 11.1.1-4 ]
     owasp_asvs_print: [ 8.1.4, 11.1.1-4 ]
     owasp_appsensor: [ (All) ]
-    capec: [ 212 ]
+    capec: [ 156, 268 ]
     safecode: [ 1, 27 ]
     owasp_cre:
       owasp_asvs: [ 176-154, 534-605, 456-535, 746-705, 630-573 ]
@@ -1279,7 +1279,7 @@ suits:
     owasp_asvs_print: [ 2.2.1, 11.1.3-4 ]
     owasp_appsensor: [ UT1, UT2, UT3, UT4, STE3 ]
     owasp_appsensor_print: [ UT1-4, STE3 ]
-    capec: [ 2, 25, 125, 130, 212, 227, 469, 607 ]
+    capec: [ 2, 25, 100, 125, 130, 227, 469, 572, 607 ]
     safecode: [ 1 ]
     owasp_cre:
       owasp_asvs: [ 802-056, 746-705, 630-573 ]