Merge pull request #532 from bugcrowd/June-2024-VRT-Update

June 2024 VRT update

.gitignore

@@ -1,3 +1,5 @@
 .DS_Store
 # https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
 Gemfile.lock
+submissions/description/broken_access_control/privilege_escalation/.gitkeep
+submissions/description/sensitive_data_exposure/password_reset_token/.gitkeep

submissions/description/broken_access_control/privilege_escalation/guidance.md

@@ -0,0 +1,5 @@
+# Guidance
+
+For access control vulnerabilities, include instructions on how to access the vulnerable authentication mechanism and steps to bypass it in order to perform a function or access data not intended for that user. Provide screenshots to show the functionality accessed without valid authentication.
+
+Explain how this broken access control is a risk and how it can be used as an attack vector. If safe, perform a function that is shown to require authentication.

submissions/description/broken_access_control/privilege_escalation/recommendations.md

@@ -0,0 +1,13 @@
+# Recommendation(s)
+
+There are a number of best practices involved with implementing strong access controls, including the following:
+
+- Declare the type of access allowed for each resource and deny access by default, unless these specific access conditions are met by a user attempting to access the resource. To enforce these access controls, it’s important to use a single application wide mechanism.
+- It is recommended that all critical information is stored server-side, with only a session ID being passed back and forth between the server and client.
+- Similarly, the data being sent to the client should be encrypted to ensure that data cannot be viewed in transit, and it should be digitally signed to ensure the data's integrity.
+- Thoroughly test and audit the access controls during the development and deployment lifecycle to ensure the security and integrity of the controls.
+
+For further information, please see the following resources:
+
+- <https://owasp.org/Top10/A01_2021-Broken_Access_Control/>
+- <https://owasp.org/www-community/Access_Control>

submissions/description/broken_access_control/privilege_escalation/template.md

@@ -0,0 +1,51 @@
+# Privilege Escalation via Broken Access Control
+
+## Overview of the Vulnerability
+
+Access controls can be bypassed through a variety of ways including, calling an internal post authentication page, modifying the given URL parameters, by manipulating the form, or by counterfeiting sessions. The access controls for this application can be bypassed by an attacker who can gain access to a privileged user’s account and functionality. As a result, the attacker has access to more resources or functionality within the application. This could include viewing or editing sensitive customer data, and viewing or editing other user permissions.
+
+## Business Impact
+
+The impact of this vulnerability can vary in severity depending on the degree of access to resources or functionality the attacker is able to gain. An attacker with the ability to access, delete, or modify data from within the application could result in reputational damage for the business through the impact to customers’ trust. This can also result in indirect financial cost to the business through fines and regulatory bodies if sensitive data is accessed. The severity of the impact to the business is dependent on the sensitivity of the data being stored in, and transmitted by the application.
+
+## 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. Login to User Account A
+1. Using the HTTP interception proxy, forward the following request to the endpoint:
+
+```HTTP
+{{request}}
+```
+
+1. Forward the requests until there is a POST request visible with the following parameters:
+
+{{parameter}}
+
+1. Modify the parameter to the following payload:
+
+{{payload}}
+
+1. Forward the request then turn off interception in the proxy
+1. Observe that User Account A now has additional Administrator privileges and user functionality it was previously not authorized to access
+
+## Proof of Concept (PoC)
+
+The screenshots below demonstrate the access controls being bypassed.
+
+Unauthenticated view:
+
+{{screenshot}}
+
+Bypassing the access controls:
+
+{{screenshot}}
+
+Privileged user view:
+
+{{screenshot}}
+
+An attacker could escalate this further by abusing the privileged users permissions to perform specific actions. This is demonstrated in the screenshot below:
+
+{{screenshot}}

submissions/description/sensitive_data_exposure/password_reset_token/recommendations.md

@@ -0,0 +1,14 @@
+# Recommendation(s)
+
+The application should transmit sensitive tokens via a HTTPS connection using HTTP cookies, or via hidden field forms which are submitted by using the HTTP Post method.
+
+If using the `Referer` header, set a `Referrer-Policy` header and set the directives as appropriate to the information displayed. For example, on sensitive pages such as the password reset page the `Referrer-Policy` header can be set as follows:
+
+`Referrer-Policy: no-referrer`
+
+For more information, please see the following resources:
+
+- <https://infosec.mozilla.org/guidelines/web_security.html#referrer-policy>
+- <https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere>
+- <https://developer.mozilla.org/en-US/docs/Web/Security/Referer_header:_privacy_and_security_concerns>
+- <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer>

submissions/description/sensitive_data_exposure/password_reset_token/template.md

@@ -0,0 +1,23 @@
+# Password Reset Token Leakage via Referer Header
+
+## Overview of the Vulnerability
+
+The `Referer` HTTP request header is used to show the URL of the page a user requested the resource from. This application’s `Referer` headers leak valid user password reset tokens over an untrusted third-party link. This token can be intercepted by a local attacker performing a Person-in-The-Middle (PiTM) attack, or by an attacker exploiting third-party vendors. With access to the exposed password reset token in the `Referer` HTTP header, the attacker could escalate privileges and execute API calls on behalf of a user in the application.
+
+## Business Impact
+
+Token Leakage via `Referer` header can lead to indirect financial loss through an attacker accessing, deleting, or modifying data from within the application, providing that they can capture the password reset token and use it to escalate privileges and execute API calls. This could also result in reputational damage for the business through the impact to customers’ trust. The severity of the impact is dependent on the sensitivity of the data being stored in, and transmitted by the application, as well as the privileges of the account the attacker gains access to.
+
+## Steps to Reproduce
+
+1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
+1. Use a browser to login and navigate to: {{URL}}
+1. Click on the link to the third-party website
+1. Capture the request using the HTTP interception proxy
+1. Observe the password token in the `Referer` header
+
+## Proof of Concept (PoC)
+
+The following screenshot(s) demonstrate(s) this vulnerability:
+
+{{screenshot}}

submissions/description/server_security_misconfiguration/email_verification_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 triage time and result in faster rewards. Your submission must include evidence of the vulnerability and not be theoretical in nature.
+
+For a server security misconfiguration vulnerability, please include a screenshot or video to easily demonstrate and reproduce the issue. Attempt to escalate the server security misconfiguration to perform additional actions (such as an account takeover or CSRF bypass to perform a sensitive action). If this is possible, provide a full Proof of Concept (PoC).

submissions/description/server_security_misconfiguration/email_verification_bypass/recommendations.md

@@ -0,0 +1,7 @@
+# Recommendation(s)
+
+There are a number of best practices involved with implementing email validation, including the following:
+
+- Implement server-side validation for email verification tokens.
+- Ensure effective rate limiting controls are in place to prevent automated account creation, potential verification bypass attempts, and email inboxes from being bombarded with emails.
+- Ensure that email verification tokens have a suitable expiring time and cannot be reused.

submissions/description/server_security_misconfiguration/email_verification_bypass/template.md

@@ -0,0 +1,33 @@
+# Email Verification Bypass
+
+## Overview of the Vulnerability
+
+Email verification bypass is where an attacker is able to gain access to the application or system without confirming the email address used to create the account. As a result,  an attacker is able to sign up to the application using email addresses that they don't own. This can lead to multiple fake accounts being created, or accounts being created on behalf of other users. While not a vulnerability within itself, bypassing email verification can lead to social engineering attacks on legitimate users.
+
+## Business Impact
+
+The impact of this vulnerability can lead to an attacker creating multiple fake accounts, performing fraudulent activities, or exploiting other vulnerabilities on behalf of other users. This could result in reputational damage for the business through the impact to customers’ trust. The severity of the impact to the business is dependent on the sensitivity of the data being stored in, and transmitted by the application.
+
+## 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. Register User Account A
+1. Using the HTTP interception proxy, intercept the following request:
+
+```HTTP
+{{request}}
+```
+
+1. Modify the following parameters:
+
+{{payload}}
+
+1. Forward the request then turn off interception in the proxy
+1. Observe that User Account A is activated without email verification.
+
+## Proof of Concept (PoC)
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+
+{{screenshot}}

submissions/description/server_security_misconfiguration/missing_subresource_integrity/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 triage time and result in faster rewards. Your submission must include evidence of the vulnerability and not be theoretical in nature.
+
+For a server security misconfiguration vulnerability, please include a screenshot or video to easily demonstrate and reproduce the issue. Attempt to escalate the server security misconfiguration to perform additional actions (such as an account takeover or CSRF bypass to perform a sensitive action). If this is possible, provide a full Proof of Concept (PoC).

submissions/description/server_security_misconfiguration/missing_subresource_integrity/recommendations.md

@@ -0,0 +1,3 @@
+# Recommendation(s)
+
+It is recommended to implement SRI attributes for all external resources to ensure their integrity and prevent tampering. It is also recommended to ensure that Content Security Policy (CSP) headers  are in place to restrict the sources from which resources can be loaded.

submissions/description/server_security_misconfiguration/missing_subresource_integrity/template.md

@@ -0,0 +1,24 @@
+# Missing Subresource Integrity (SRI)
+
+## Overview of the Vulnerability
+
+Subresource Integrity (SRI) is a security feature that helps ensure the integrity and authenticity of externally loaded resources that are included in a web application, such as scripts, stylesheets, or images. While not a vulnerability within itself, missing SRI in a web application can allow an attacker to modify or replace external resources that can lead to the execution of malicious code. An attacker could achieve this by compromising the server hosting the resource, intercepting network traffic, or by leveraging weaknesses in the supply chain.
+
+## Business Impact
+
+Missing SRI could result in reputational damage for the business through the impact to customers’ trust. The severity of the impact to the business is dependent on the sensitivity of the data being stored in, and transmitted by the application.
+
+## Steps to Reproduce
+
+1. Use a browser to navigate to: {{URL}}
+2. Open Developer Tools and navigate to the Elements tab.
+3. Search for `<script>` and `<link>` tags that load external resources.
+4. Observe that the following tags are missing an `integrity` attribute:
+
+{{List of tags missing an 'integrity' attribute}}
+
+## Proof of Concept (PoC)
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+
+{{screenshot}}

submissions/description/server_security_misconfiguration/software_package_takeover/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 triage time and result in faster rewards. Your submission must include evidence of the vulnerability and not be theoretical in nature.
+
+For a server security misconfiguration vulnerability, please include a screenshot or video to easily demonstrate and reproduce the issue. Attempt to escalate the server security misconfiguration to perform additional actions (such as an account takeover or CSRF bypass to perform a sensitive action). If this is possible, provide a full Proof of Concept (PoC).

submissions/description/server_security_misconfiguration/software_package_takeover/recommendations.md

@@ -0,0 +1,7 @@
+# Recommendation(s)
+
+There are a number of best practices recommended to prevent software package takeover, including the following:
+
+- Implement dependency management tools and practices to manage and update software dependencies on a regular basis.
+- Implement that package verification mechanisms that ensure the authenticity and integrity of software packages, such as cryptographic signatures used is Subresource integrity checks.
+- Ensure that package repositories are monitored regularly for changes to ownership, unusual activities, and security alerts for dependencies.

submissions/description/server_security_misconfiguration/software_package_takeover/template.md

@@ -0,0 +1,25 @@
+# Software Package Takeover
+
+## Overview of the Vulnerability
+
+Software package takeover is where an attacker is able to gain control of software packages or dependencies used by an application by hijacking ownership or exploiting weak security controls in package repositories. This control allows the attacker to modify the package, potentially injecting malicious code or making other unauthorized changes. This can in turn have downstream affects on the web application.
+
+## Business Impact
+
+This vulnerability can lead to the injection of malicious code, unauthorized access, or compromise of the application and its data. It can also result in reputational damage, financial losses, and legal liabilities. The severity of the impact to the business is dependent on the nature of the compromised package, its use within the application, and the attacker's ability to modify or inject code.
+
+## Steps to Reproduce
+
+1. Use a browser to navigate to: {{URL}}
+2. Identify the software packages or dependencies used by the application.
+3. Observe that the software package has outdated dependencies or unmaintained packages.
+4. Demonstrate the ability to inject malicious code or take over the package.
+5. Observe the following downstream affects on the target application:
+
+{{screenshot}}
+
+## Proof of Concept (PoC)
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+
+{{screenshot}}