New Template Additions

submissions/description/insufficient_security_configurability/business_logic_bypass/guidance.md

@@ -0,0 +1,5 @@
+**Guidance**
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed up triage time and result in faster rewards. Please include specific details on where you identified the vulnerability, how you identified it, and what actions you were able to perform as a result.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/insufficient_security_configurability/business_logic_bypass/recommendations.md

@@ -0,0 +1,11 @@
+**Recommendation**
+
+Remediate the identified flaws within the applications design and implementation, to ensure that the intended application logic cannot be bypassed or manipulated to elicit unintended behaviours.
+
+Furthermore, the following key points should be taken into consideration: 
+
+* Ensure developers and Quality Assurance testers understand the application and its intended functionality.
+* Avoid making implicit assumptions about user behaviour or other parts of the application.
+* Maintain clear design documents and data flows for all transactions and workflows, noting any assumptions that are made at each stage.
+* Write code as clearly as possible. If it's difficult to understand what is supposed to happen, it will be difficult to spot any logic flaws. Ensure that developers and testers know what assumptions are being made and exactly what the expected behaviour is.
+* Note any references to other code that uses each component. Consider any side-effects of these dependencies if a malicious party were to manipulate them in an unintended manner.

submissions/description/insufficient_security_configurability/business_logic_bypass/template.md

@@ -0,0 +1,20 @@
+Business logic vulnerabilities occur due to logic flaws in an applications workflow, often stemming from mistaken expectations regarding user behaviour. This can lead to a condition where failure to anticipate unexpected states during the design and implementation of the application results in a malicious user being able to trigger unintended behaviour.
+
+An attacker may exploit this vulnerability to manipulate workflows, abuse legitimate features and functionality, or bypass traditional security controls.
+
+{{Describe the application logic bypass identified in the in-scope application}}
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company through the impact to customers’ trust.
+
+**Steps to Reproduce**
+
+1. Step 1
+1. Step 2, with context:
+    ```http
+    POST /example HTTP/2
+    Host: example.com
+
+    {"param":"value"}
+    ```

submissions/description/insufficient_security_configurability/no_account_lockout/guidance.md

@@ -0,0 +1,5 @@
+**Guidance**
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed up triage time and result in faster rewards. Please include specific details on where you identified the vulnerability, how you identified it, and what actions you were able to perform as a result.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/insufficient_security_configurability/no_account_lockout/recommendations.md

@@ -0,0 +1,5 @@
+**Recommendation**
+
+An account lockout should be enforced to provide an extra layer of defence against brute force attacks, in addition to a strong password policy. A reasonable account lockout policy would be to lockout an account for fifteen minutes if five invalid login attempts were made within a ten-minute period, however this can be adapted depending on business requirements or the sensitivity of the application. 
+
+It is important to ensure that the lockout is not permanent, otherwise this can be used to perform denial of service attacks against the system by purposely locking valid accounts out.

submissions/description/insufficient_security_configurability/no_account_lockout/template.md

@@ -0,0 +1,15 @@
+The application was found to have no account lockout enforced, thereby potentially allowing an attacker to brute force accounts for an indefinite period. 
+
+An account lockout is a countermeasure whereby a user account is prevented from logging in temporarily after an incorrect password is supplied a fixed number of times. The lack of account lockout makes the application particularly vulnerable to brute force attacks, which could lead to the direct compromise of users’ accounts. 
+
+It is normally trivial to determine the difference between a successful and failed login attempt automatically. Therefore, it is possible for an attacker to write a script to continuously attempt to login with many different passwords and report on any that were successful. Without a strong password policy in place, this technique is likely to succeed.
+
+**Business Impact**
+
+Having no account lockout can result in reputational damage for the business through the impact to customers’ trust as they could believe that the business doesn’t take their account security seriously or trust that their data within will remain secure.
+
+**Proof of Concept (PoC)**
+
+The following screenshot shows the use of a tool to automate the numerous login requests to the application. As visible from the response statuses, it was possible to successfully login to the application after submitting 25 consecutive invalid login requests:
+
+{{screnshot}}

submissions/description/server_security_misconfiguration/fingerprinting_banner_disclosure/software_versions_disclosed_in_response_headers/guidance.md

@@ -0,0 +1,5 @@
+**Guidance**
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed up triage time and result in faster rewards. Please include specific details on where you identified the vulnerability, how you identified it, and what actions you were able to perform as a result.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/server_security_misconfiguration/fingerprinting_banner_disclosure/software_versions_disclosed_in_response_headers/recommendations.md

@@ -0,0 +1,3 @@
+**Recommendation**
+
+Remove the version number disclosure in the HTTP response headers, either by removing the headers entirely, or having them return a generic response. Vendor documentation should provide specific details on how to adjust the configuration to remove version numbers.

submissions/description/server_security_misconfiguration/fingerprinting_banner_disclosure/software_versions_disclosed_in_response_headers/template.md

@@ -0,0 +1,17 @@
+Software version numbers were disclosed within the HTTP response headers. 
+
+An attacker could use this information to enumerate the underlying technologies and plan further attacks based on the versions disclosed. 
+
+**Business Impact**
+
+Software version disclosures can lead to reputational damage for the business due to a loss in confidence from users who can see that the web server is running on older software. If an attacker is successful in identifying and exploiting a known vulnerability for the identified version of software on this host, this can lead to indirect financial losses and data loss.
+
+
+**Steps to Reproduce**
+
+1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
+1. In a browser, navigate to the homepage of the application 
+1. Use the Web Proxy to intercept the response
+1. Observe the `{{header name}}` response header, noting the the version number disclosed for the software `{{disclosed software}}`, e.g:
+
+>`Server: nginx/1.17.10`

submissions/description/server_security_misconfiguration/misconfigured_security_headers/insecure_content_security_policy/guidance.md

@@ -0,0 +1,5 @@
+**Guidance**
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed up triage time and result in faster rewards. Please include specific details on where you identified the vulnerability, how you identified it, and what actions you were able to perform as a result.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/server_security_misconfiguration/misconfigured_security_headers/insecure_content_security_policy/recommendations.md

@@ -0,0 +1,10 @@
+**Recommendation**
+
+The `Content-Security-Policy` header should be configured in a way that reduces the attack surface of the application. The CSP header is not set as a default catch-all, due to its permissive design. Therefore, It is important to ensure that the CSP header is not too permissive for the application's needs, and has directives appropriately set.
+
+For example, the `script-src` directive should have a value applied to block all inline scripts at a minimum. This will prevent the execution of JavaScript that has been injected into the page through cross-site scripting attacks. Furthermore, an allow list of external sources can be specified to prevent injection of Javascript from sources that lie outside of the page.
+
+For more information, please see:
+
+- <https://owasp.org/www-community/controls/Content_Security_Policy/>
+- <https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP/>

submissions/description/server_security_misconfiguration/misconfigured_security_headers/insecure_content_security_policy/template.md

@@ -0,0 +1,21 @@
+The configured `Content Security Policy` (CSP) was insecure.
+
+A CSP is a mechanism designed to add an additional layer of protection against injection attacks such as Cross-Site Scripting (XSS) and clickjacking. The CSP achieves this by specifying the limitations on which resources may be loaded and from where.
+
+A CSP can inherit weakness if configured by attributes that reduce the security benefits of having a CSP. The in-scope application's CSP was found to be insecure due to the usage of the following explicitly unsafe source expressions:
+
+{{replace following with relevant insecure directives}}
+- unsafe-inline: allows the execution of untrusted inline page scripts and event handlers
+- unsafe-eval: allows the execution of code injected into DOM APIs such as eval()
+
+An attacker may leverage an insecure CSP to attempt attacks with the aim of executing malicious code in a user’s browser.
+
+**Business Impact**
+An insecure `Content-Security-Policy` header can lead to reputational damage and indirect financial loss to the business due to an advanced attacker’s ability to access data through a XSS attack. The degree of impact is dependent on the sensitivity of data being transmitted over the wire and the sophistication of the attacker’s abilities.
+
+
+**Proof of Concept (PoC)**
+
+The following code snippet contains the Content-Security-Policy header returned by the application:
+
+`Content-Security-Policy:<contents>`

submissions/description/using_components_with_known_vulnerabilities/unpatched_javascript_libraries/guidance.md

@@ -0,0 +1,5 @@
+**Guidance**
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed up triage time and result in faster rewards. Please include specific details on where you identified the vulnerability, how you identified it, and what actions you were able to perform as a result.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/using_components_with_known_vulnerabilities/unpatched_javascript_libraries/recommendations.md

@@ -0,0 +1,4 @@
+ **Recommendation**
+
+Ensure that all JavaScript libraries and their associated components are routinely updated to the latest secure version.
+Deprecated libraries should be reviewed for replacement by actively maintained alternatives.

submissions/description/using_components_with_known_vulnerabilities/unpatched_javascript_libraries/template.md

@@ -0,0 +1,30 @@
+The application was found to be using outdated and unpatched JavaScript libraries. Without security updates, these libaries are vulnerable to a number of publicly disclosed vulnerabilities. 
+
+Given their close integration with the Document Object Model (DOM), JavaScript libraries are a prime target for Cross Site Scripting (XSS) attacks. 
+
+{{Delete if not applicable}} Additionally, further JavaScript libraries were identified that are no longer maintained. Consequently, these libraries will no longer be able to receive security updates and patches for known vulnerabilities.
+
+The affected software versions and related vulnerabilities have been listed below:
+
+{{example formatting below}}
+
+>**[Bootstrap v3.4.1](https://getbootstrap.com/)**
+>- Bootstrap before 4.0.0 is end-of-life and no longer maintained
+>- [CVE-2024-6485](https://nvd.nist.gov/vuln/detail/CVE-2024-6485): XSS in bootstrap button component
+>- [CVE-2024-6484](https://nvd.nist.gov/vuln/detail/CVE-2024-6485): XSS in carousel component
+
+**Business Impact**
+
+Outdated JavaScript libraries can lead to reputational damage for the business due to a loss in confidence and trust by users.
+
+**Proof Of Concept (PoC)**
+
+Navigate to the following JavaScript library files and view the version numbers disclosed at the top of the files:
+
+{{direct link to source file}}
+```
+* Bootstrap v3.4.1 (https://getbootstrap.com/)
+ * Copyright 2011-2019 Twitter, Inc.
+ * Licensed under the MIT license
+ */
+```