Merge pull request #542 from mike-holbrook-bc/new-template-additions

New Template Additions

Author: RRudder

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,18 @@
+The application does not enforce account lockout on the login endpoint after repeated failed authentication attempts. An attacker can perform brute force or credential stuffing attacks on users' accounts for an indefinite period without restriction. Without a strong password policy in place, this technique is likely to succeed. This could allow an attacker to gain access to users' accounts if successful.
+
+**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.
+
+**Steps to Reproduce**
+
+1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
+1. Use a browser to navigate to: {{URL}}
+1. Submit multiple incorrect password attempts in rapid succession
+1. Confirm that no account lockout, CAPTCHA, or rate limiting is triggered
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/server_security_misconfiguration/fingerprinting_banner_disclosure/software_version_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_version_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_version_in_response_headers/template.md

@@ -0,0 +1,20 @@
+The application server discloses the software name and version number of the web server, application framework, or other server-side components 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`
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/server_security_misconfiguration/misconfigured_security_headers/insecure_csp/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_csp/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_csp/template.md

@@ -0,0 +1,20 @@
+The application implements a Content Security Policy (CSP) header, but the policy is configured insecurely. 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. An attacker can 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.
+
+**Steps to Reproduce**
+
+1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
+1. Use a browser to navigate to: {{URL}}
+1. Inspect the HTTP response headers and locate the `Content-Security-Policy` header
+1. Review the policy and note the usage of the following explicitly unsafe source expressions:
+
+- 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()
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

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).