From c347634c7b8ba4313812bbbea0e523d80582c6f3 Mon Sep 17 00:00:00 2001 From: Ryan Rudder <96507400+RRudder@users.noreply.github.com> Date: Thu, 13 Jun 2024 18:01:48 +1000 Subject: [PATCH 1/3] Removal of category * Privilege Escalation via Broken Authentication --- .../privilege_escalation/.gitkeep | 0 .../privilege_escalation/guidance.md | 5 -- .../privilege_escalation/recommendations.md | 7 --- .../privilege_escalation/template.md | 51 ------------------- 4 files changed, 63 deletions(-) delete mode 100644 submissions/description/broken_authentication_and_session_management/privilege_escalation/.gitkeep delete mode 100644 submissions/description/broken_authentication_and_session_management/privilege_escalation/guidance.md delete mode 100644 submissions/description/broken_authentication_and_session_management/privilege_escalation/recommendations.md delete mode 100644 submissions/description/broken_authentication_and_session_management/privilege_escalation/template.md diff --git a/submissions/description/broken_authentication_and_session_management/privilege_escalation/.gitkeep b/submissions/description/broken_authentication_and_session_management/privilege_escalation/.gitkeep deleted file mode 100644 index e69de29b..00000000 diff --git a/submissions/description/broken_authentication_and_session_management/privilege_escalation/guidance.md b/submissions/description/broken_authentication_and_session_management/privilege_escalation/guidance.md deleted file mode 100644 index fc5963fb..00000000 --- a/submissions/description/broken_authentication_and_session_management/privilege_escalation/guidance.md +++ /dev/null @@ -1,5 +0,0 @@ -# Guidance - -For authentication bypass 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 why this bypass is a risk and how it can be used as an attack vector. If safe, perform a function that is shown to require authentication. diff --git a/submissions/description/broken_authentication_and_session_management/privilege_escalation/recommendations.md b/submissions/description/broken_authentication_and_session_management/privilege_escalation/recommendations.md deleted file mode 100644 index f1044ebd..00000000 --- a/submissions/description/broken_authentication_and_session_management/privilege_escalation/recommendations.md +++ /dev/null @@ -1,7 +0,0 @@ -# Recommendation(s) - -There are a number of best practices involved with implementing authentication methods and session management. 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. diff --git a/submissions/description/broken_authentication_and_session_management/privilege_escalation/template.md b/submissions/description/broken_authentication_and_session_management/privilege_escalation/template.md deleted file mode 100644 index 63ce6df1..00000000 --- a/submissions/description/broken_authentication_and_session_management/privilege_escalation/template.md +++ /dev/null @@ -1,51 +0,0 @@ -# Privilege Escalation via Broken Authentication - -## Overview of the Vulnerability - -Authentication and session management 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 authentication method for this application can be bypassed by an attacker which enables them to access a privileged user’s account and functionality, giving them 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 privilege escalation through broken authentication controls can vary in severity depending on the degree of access to resources or functionality the malicious 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 prox -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 authentication method being bypassed. - -Unauthenticated view: - -{{screenshot}} - -Bypassing authentication and escalating privileges: - -{{screenshot}} - -Privileged user view: - -{{screenshot}} - -A malicious attacker could abuse this authentication bypass further by abusing the privileged users permissions. This is demonstrated in the screenshot below: - -{{screenshot}} From 11de2baef2627058bc2e282284411e68ca261872 Mon Sep 17 00:00:00 2001 From: Ryan Rudder <96507400+RRudder@users.noreply.github.com> Date: Wed, 19 Jun 2024 08:23:45 +1000 Subject: [PATCH 2/3] June Category Updates ## To Be Added: - P5: Server Security Misconfiguration - Email verification bypass - P5: Server Security Misconfiguration - Missing Subresource Integrity (SRI) - Varies: Server Security Misconfiguration - Software Package Takeover - P5: Sensitive Data Exposure - Token Leakage via Referer - Password Reset Token - Varies: Broken Access Control (BAC) - Privilege Escalation ## To Be Removed: - Varies: Broken Authentication and Session Management - Privilege Escalation --- .gitignore | 2 + .../privilege_escalation/guidance.md | 5 ++ .../privilege_escalation/recommendations.md | 13 +++++ .../privilege_escalation/template.md | 51 +++++++++++++++++++ .../password_reset_token/recommendations.md | 14 +++++ .../password_reset_token/template.md | 23 +++++++++ .../email_verification_bypass/guidance.md | 5 ++ .../recommendations.md | 7 +++ .../email_verification_bypass/template.md | 33 ++++++++++++ .../missing_subresource_integrity/guidance.md | 5 ++ .../recommendations.md | 3 ++ .../missing_subresource_integrity/template.md | 24 +++++++++ .../software_package_takeover/guidance.md | 5 ++ .../recommendations.md | 7 +++ .../software_package_takeover/template.md | 25 +++++++++ 15 files changed, 222 insertions(+) create mode 100644 submissions/description/broken_access_control/privilege_escalation/guidance.md create mode 100644 submissions/description/broken_access_control/privilege_escalation/recommendations.md create mode 100644 submissions/description/broken_access_control/privilege_escalation/template.md create mode 100644 submissions/description/sensitive_data_exposure/password_reset_token/recommendations.md create mode 100644 submissions/description/sensitive_data_exposure/password_reset_token/template.md create mode 100644 submissions/description/server_security_misconfiguration/email_verification_bypass/guidance.md create mode 100644 submissions/description/server_security_misconfiguration/email_verification_bypass/recommendations.md create mode 100644 submissions/description/server_security_misconfiguration/email_verification_bypass/template.md create mode 100644 submissions/description/server_security_misconfiguration/missing_subresource_integrity/guidance.md create mode 100644 submissions/description/server_security_misconfiguration/missing_subresource_integrity/recommendations.md create mode 100644 submissions/description/server_security_misconfiguration/missing_subresource_integrity/template.md create mode 100644 submissions/description/server_security_misconfiguration/software_package_takeover/guidance.md create mode 100644 submissions/description/server_security_misconfiguration/software_package_takeover/recommendations.md create mode 100644 submissions/description/server_security_misconfiguration/software_package_takeover/template.md diff --git a/.gitignore b/.gitignore index 80b86629..94197e66 100644 --- a/.gitignore +++ b/.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 diff --git a/submissions/description/broken_access_control/privilege_escalation/guidance.md b/submissions/description/broken_access_control/privilege_escalation/guidance.md new file mode 100644 index 00000000..f03774e5 --- /dev/null +++ b/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. diff --git a/submissions/description/broken_access_control/privilege_escalation/recommendations.md b/submissions/description/broken_access_control/privilege_escalation/recommendations.md new file mode 100644 index 00000000..9a12a28d --- /dev/null +++ b/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: + +- +- diff --git a/submissions/description/broken_access_control/privilege_escalation/template.md b/submissions/description/broken_access_control/privilege_escalation/template.md new file mode 100644 index 00000000..1177fcdf --- /dev/null +++ b/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}} diff --git a/submissions/description/sensitive_data_exposure/password_reset_token/recommendations.md b/submissions/description/sensitive_data_exposure/password_reset_token/recommendations.md new file mode 100644 index 00000000..4ec194fd --- /dev/null +++ b/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: + +- +- +- +- diff --git a/submissions/description/sensitive_data_exposure/password_reset_token/template.md b/submissions/description/sensitive_data_exposure/password_reset_token/template.md new file mode 100644 index 00000000..7d8aa8f7 --- /dev/null +++ b/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}} diff --git a/submissions/description/server_security_misconfiguration/email_verification_bypass/guidance.md b/submissions/description/server_security_misconfiguration/email_verification_bypass/guidance.md new file mode 100644 index 00000000..672aeb33 --- /dev/null +++ b/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). diff --git a/submissions/description/server_security_misconfiguration/email_verification_bypass/recommendations.md b/submissions/description/server_security_misconfiguration/email_verification_bypass/recommendations.md new file mode 100644 index 00000000..93849aa6 --- /dev/null +++ b/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. diff --git a/submissions/description/server_security_misconfiguration/email_verification_bypass/template.md b/submissions/description/server_security_misconfiguration/email_verification_bypass/template.md new file mode 100644 index 00000000..4c24f962 --- /dev/null +++ b/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 +2. Use a browser to navigate to: {{URL}} +3. Register User Account A +4. Using the HTTP interception proxy, intercept the following request: + +```HTTP +{{request}} +``` + +5. Modify the following parameters: + +{{payload}} + +6. Forward the request then turn off interception in the proxy +7. Observe that User Account A is activated without email verification. + +## Proof of Concept (PoC) + +The screenshot(s) below demonstrate(s) the vulnerability: + +{{screenshot}} diff --git a/submissions/description/server_security_misconfiguration/missing_subresource_integrity/guidance.md b/submissions/description/server_security_misconfiguration/missing_subresource_integrity/guidance.md new file mode 100644 index 00000000..672aeb33 --- /dev/null +++ b/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). diff --git a/submissions/description/server_security_misconfiguration/missing_subresource_integrity/recommendations.md b/submissions/description/server_security_misconfiguration/missing_subresource_integrity/recommendations.md new file mode 100644 index 00000000..00186896 --- /dev/null +++ b/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. diff --git a/submissions/description/server_security_misconfiguration/missing_subresource_integrity/template.md b/submissions/description/server_security_misconfiguration/missing_subresource_integrity/template.md new file mode 100644 index 00000000..a55d9632 --- /dev/null +++ b/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 `