Informational (P5) Update

submissions/description/broken_authentication_and_session_management/excessive_jwt_lifetime/guidance.md

@@ -0,0 +1,7 @@
+# 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.
+
+Include a screenshot showing the decoded JWT payload with the `iat` and `exp` claims visible. Calculate and state the token lifetime in hours or days. Do not submit tokens belonging to other users. A screenshot from a JWT decoder tool such as `jwt.io` is acceptable as evidence.
+
+Attempt to escalate the broken authentication or session management 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/broken_authentication_and_session_management/excessive_jwt_lifetime/recommendations.md

@@ -0,0 +1,15 @@
+# Recommendation(s)
+
+Broken authentication issues can be remediated by implementing a handful of best practices relating to authentication and session management to ensure secure implementation. These include:
+
+- Reducing the JWT lifetime to the minimum duration required for the application's use case
+- Pairing all short-lived access tokens with a refresh token mechanism that allows the client to obtain new access tokens without requiring reauthentication
+- Storing refresh tokens securely, rotating them on each use, and making them revocable by the server
+- Ensuring that server-side token revocation for logout and password change events is implemented.
+
+The verification logic of the application, as well as all of the above, should be thoroughly tested during the development and QA phases of an application build.
+
+For further information, refer to Open Web Application Security Project (OWASP) guides located at:
+
+- <https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html>
+- <https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/>

submissions/description/broken_authentication_and_session_management/excessive_jwt_lifetime/template.md

@@ -0,0 +1,20 @@
+JSON Web Tokens (JWTs) are used by the application for session management or API authentication. The application issues JWTs with an excessively long expiration time, meaning a token remains valid for an extended period after it is issued. The long lifetime gives an attacker a larger window to use the stolen token before it expires. This increases the impact of any token compromise by extending the period during which the attacker can impersonate the legitimate user.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+**Steps to Reproduce**
+
+1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
+1. Use a browser to navigate and perform a login at: {{URL}}
+1. Capture the JWT issued in the {{token_location}}
+1. Decode the JWT payload at {{jwt_decode_tool}} and examine the `exp` claim
+1. Calculate the token lifetime by comparing the `iat` and `exp` values
+1. Confirm that the token lifetime is {{token_lifetime}}, which exceeds a reasonable session duration
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/broken_authentication_and_session_management/secret_questions_account_verification/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.
+
+Include a screenshot showing the secret question presented during the account recovery or verification flow. Show that the question is used as a verification factor rather than as supplementary information. Do not attempt to access other users' accounts. Your own account is sufficient to demonstrate the weakness.

submissions/description/broken_authentication_and_session_management/secret_questions_account_verification/recommendations.md

@@ -0,0 +1,3 @@
+# Recommendation(s)
+
+Remove secret questions and replace them with stronger verification methods such as email-based or SMS-based verification codes, time-limited password reset tokens, or multi-factor authentication. If a secondary verification step is required, use a one-time code sent to a pre-registered contact method rather than static knowledge-based questions.

submissions/description/broken_authentication_and_session_management/secret_questions_account_verification/template.md

@@ -0,0 +1,17 @@
+The application uses secret questions (also known as security questions or knowledge-based authentication) as a method for verifying a user's identity during account recovery or sensitive operations. Secret questions weaken the overall security of the application as the answers are often guessable, publicly available through social media, or shared across multiple services. An attacker who can determine or guess the answer to a user's secret question can bypass the intended verification step and gain access to the account recovery flow.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+**Steps to Reproduce**
+
+1. Use a browser to navigate to: {{URL}}
+1. Enter a username and proceed to the account verification step
+1. Observe that the application presents a secret question: {{secret_question}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/insufficient_security_configurability/no_2fa_implementation/guidance.md

@@ -0,0 +1,7 @@
+# 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.
+
+Include a screenshot of the account security settings page showing the absence of any 2FA or multi-factor authentication option.
+
+Attempt to escalate the broken authentication or session management 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/insufficient_security_configurability/no_2fa_implementation/recommendations.md

@@ -0,0 +1,3 @@
+# Recommendation(s)
+
+Implement 2FA support, preferably using time-based one-time passwords (TOTP) or hardware security keys (WebAuthn/FIDO2) as as a stronger option. Provide backup recovery codes during enrollment. Enforce 2FA for accounts with administrative privileges and encourage adoption across all user accounts.

submissions/description/insufficient_security_configurability/no_2fa_implementation/template.md

@@ -0,0 +1,18 @@
+The application does not offer Two-Factor Authentication (2FA) as an option for user accounts. Without 2FA, account security relies only on the strength of the user's password, with no additional verification step to prevent unauthorized access. An attacker who obtains a user's password can access user's accounts, including those with access to sensitive data or administrative functions.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+
+**Steps to Reproduce**
+
+1. Use a browser to navigate and log in at: {{URL}}
+1. Navigate to the account security settings at {{security_settings_url}}
+1. Confirm that no 2FA or multi-factor authentication option is available
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/insufficient_security_configurability/publicly_accessible_robots/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.
+
+Include a screenshot showing the contents of the robots.txt file with sensitive paths highlighted. Navigate to at least one disclosed path and show whether it is accessible. 

submissions/description/insufficient_security_configurability/publicly_accessible_robots/recommendations.md

@@ -0,0 +1,3 @@
+# Recommendation(s)
+
+Remove references to sensitive paths from `robots.txt` and enforce access controls directly on those endpoints. Access controls must be enforced at the application or web server level rather than through `robots.txt`. Sensitive endpoints should require authentication and should not rely on obscurity for protection. Regularly review the `robots.txt` file to ensure it does not disclose internal paths.

submissions/description/insufficient_security_configurability/publicly_accessible_robots/template.md

@@ -0,0 +1,17 @@
+The application exposes a `robots.txt` file at the web root that discloses internal URL paths, directory structures, or administrative endpoints. While `robots.txt` is intended to instruct search engine crawlers which paths to avoid indexing, the file is publicly accessible and readable by anyone. An attacker can user a `robots.txt` file to enumerate administrative panels, staging environments, API endpoints, or other paths that the application owner intended to keep out of public view.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+**Steps to Reproduce**
+
+1. Use a browser to navigate to: {{URL}}
+1. Review the contents of the `robots.txt` file and identify entries that reference internal or sensitive paths such as {{sensitive_path}}
+1. Navigate to {{sensitive_path}} and confirm whether the path is accessible
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/insufficient_security_configurability/sensitive_information_disclosed_jwt/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.
+
+Include a screenshot showing the decoded JWT payload with the sensitive data fields highlighted. Identify which claims contain sensitive information and explain why the data should not be client-readable. Do not decode or submit tokens belonging to other users. Use your own session token as evidence.

submissions/description/insufficient_security_configurability/sensitive_information_disclosed_jwt/recommendations.md

@@ -0,0 +1,3 @@
+# Recommendation(s)
+
+It is best practice to limit JWT claims to the minimum required for authentication and authorization. Remove all sensitive data from JWT payloads and use opaque identifiers such as user IDs or session references rather than email addresses, roles, permissions, or internal system details. If sensitive data must be associated with a session, store it server-side and reference it by the token's subject claim. If encrypted tokens are required, use JSON Web Encryption (JWE) rather than JSON Web Signature (JWS).

submissions/description/insufficient_security_configurability/sensitive_information_disclosed_jwt/template.md

@@ -0,0 +1,19 @@
+The application includes sensitive information within the payload of the JSON Web Tokens (JWTs) that issued to clients. JWT payloads are Base64-encoded and are not encrypted. An attacker who intercepts or receives the token can decode and read its contents. Internal identifiers, roles, email addresses, or other sensitive fields can be included within JWTs which can aid an attacker in privilege escalation, account enumeration, or social engineering.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure. If personal data is included, this may also create compliance obligations under data protection regulations.
+
+**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. Capture the JWT issued in the {{token_location}}
+1. Copy the JWT payload (the second Base64-encoded section between the dots) and decode the it using {{jwt_decode_tool}}
+1. Observe that the decoded payload contains {{sensitive_data_type}} in the {{claim_name}} field
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/insufficient_security_configurability/weak_jwt_hashing_algorithm/guidance.md

@@ -0,0 +1,7 @@
+# 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.
+
+For a broken authentication or session management vulnerability, please include a simple URL or HTTP payload that can be executed to easily demonstrate and reproduce the issue.
+
+Attempt to escalate the broken authentication or session management 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/insufficient_security_configurability/weak_jwt_hashing_algorithm/recommendations.md

@@ -0,0 +1,5 @@
+# Recommendation(s)
+
+Implement a strong asymmetric signing algorithm such as RS256 or ES256 with properly managed keys, or use HS256 with a cryptographically random secret of at least 256 bits and never exposed in client-side code. 
+
+Explicitly reject the none algorithm in the JWT validation logic. Validate the alg header against a server-side allowlist and reject tokens with unexpected algorithms. If using a symmetric algorithm, ensure the signing secret is at least 256 bits of cryptographically random data and is never exposed in client-side code.

submissions/description/insufficient_security_configurability/weak_jwt_hashing_algorithm/template.md

@@ -0,0 +1,20 @@
+The application issues JSON Web Tokens (JWTs) signed with a weak hashing algorithm such as HS256 with a short or predictable secret, or uses the `none` algorithm. A weak signing algorithm allows valid tokens to be forced by brute-forcing the signing secret or by modifying the token header to bypass signature verification entirely. This allows an attacker to create arbitrary tokens and impersonate any user, including administrative accounts.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+**Steps to Reproduce**
+
+1. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
+1. Use a browser to navigate  and log in at: {{URL}}
+1. Capture the JWT issued in the {{token_location}}
+1. Decode the JWT header and confirm that the `alg` field is set to {{algorithm}}
+1. Use {{tool}} to attempt to crack the signing secret or modify the algorithm to none
+1. Submit the forged or modified token to {{endpoint}} and confirm that the server accepts it
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/server_security_misconfiguration/misconfigured_file_share/anonymous_ftp_enabled/guidance.md

@@ -0,0 +1,5 @@
+# Guidance
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. Your submission must include evidence of the vulnerability and not be theoretical in nature.
+
+Include a screenshot or terminal output showing a successful connection to the misconfigured file share and a directory listing. Show at least one file download confirming data is retrievable. State the protocol, access level, and type of data exposed.

submissions/description/server_security_misconfiguration/misconfigured_file_share/anonymous_ftp_enabled/recommendations.md

@@ -0,0 +1,3 @@
+# Recommendation(s)
+
+If FTP is not required for application operations, disable the FTP service and migrate file transfer functionality to SFTP or SCP, both provide encrypted transport by default. If FTP must remain active, restrict access to named accounts with strong passwords and limit file system permissions to the minimum required directories for each user.

submissions/description/server_security_misconfiguration/misconfigured_file_share/anonymous_ftp_enabled/template.md

@@ -0,0 +1,19 @@
+Anonymous File Transfer Protocol (FTP) is a configuration that allows any remote user to connect to the FTP server without providing credentials. When anonymous access is enabled on a server hosting application files or internal resources, an attacker can connect to the FTP service and view, download, or upload files. This allows an attacker to access files stored on the server, which may include application source code, configuration files containing credentials, database backups, or internal documentation.
+
+**Business Impact**
+
+A misconfigured file share may expose internal files to unauthorized parties. This can 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. Open an FTP client and connect to {{ftp_host}} on port {{ftp_port}}
+1. Log in using the username `anonymous` and any value for the password, such as {{email_address}}
+1. Confirm that the server accepts the anonymous login and presents a directory listing
+1. Navigate to {{directory_path}} and identify files accessible without authentication
+1. Download {{filename}} to confirm that file contents are retrievable by an unauthenticated user
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/server_security_misconfiguration/misconfigured_file_share/anonymous_smb_enabled/guidance.md

@@ -0,0 +1,5 @@
+# Guidance
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. Your submission must include evidence of the vulnerability and not be theoretical in nature.
+
+Include a screenshot or terminal output showing a successful connection to the misconfigured file share and a directory listing. Show at least one file download confirming data is retrievable. State the protocol, access level, and type of data exposed.

submissions/description/server_security_misconfiguration/misconfigured_file_share/anonymous_smb_enabled/recommendations.md

@@ -0,0 +1,8 @@
+# Recommendation(s)
+
+Enable the following defensive measures across all file share services:
+
+- Disable anonymous or guest access on all file share protocols (FTP, SMB, NFS).
+- Disable SMBv1 and enforce SMBv3 with signing and encryption to protect data in transit.
+- Apply share-level and file system permissions using the principle of least privilege, granting access only to accounts that require it. 
+- If the SMB service is not required, disable it entirely.

submissions/description/server_security_misconfiguration/misconfigured_file_share/anonymous_smb_enabled/template.md

@@ -0,0 +1,18 @@
+Server Message Block (SMB) is a network file sharing protocol used to access files and directories on remote servers. When anonymous session access is enabled on an SMB share, an attacker can connect and view or download shared files without credentials. This allows an attacker to access files on the share, which may include application configuration, internal documentation, database exports, or credentials stored in plaintext.
+
+**Business Impact**
+
+A misconfigured file share may expose internal files to unauthorized parties. This can 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. Open an SMB client such as `smbclient` and connect to {{smb_host}} using a null session: `smbclient -L //{{smb_host}} -N`
+1. Confirm that the server returns a list of available shares without requiring credentials
+1. Navigate to {{directory_path}} and list the files available
+1. Download {{filename}} to confirm that file contents are retrievable by an unauthenticated user
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/server_security_misconfiguration/misconfigured_file_share/guidance.md

@@ -0,0 +1,5 @@
+# Guidance
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. Your submission must include evidence of the vulnerability and not be theoretical in nature.
+
+Include a screenshot or terminal output showing a successful connection to the misconfigured file share and a directory listing. Show at least one file download confirming data is retrievable. State the protocol, access level, and type of data exposed.

submissions/description/server_security_misconfiguration/misconfigured_file_share/non_sensitive_data_exposure_ftp_smb/guidance.md

@@ -0,0 +1,5 @@
+# Guidance
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. Your submission must include evidence of the vulnerability and not be theoretical in nature.
+
+Include a screenshot or terminal output showing a successful connection to the misconfigured file share and a directory listing. Show at least one file download confirming data is retrievable. State the protocol, access level, and type of data exposed.

submissions/description/server_security_misconfiguration/misconfigured_file_share/non_sensitive_data_exposure_ftp_smb/recommendations.md

@@ -0,0 +1,9 @@
+# Recommendation(s)
+
+Enable the following defensive measures across all file share services:
+
+- Enforce authentication restrict access to authorized accounts using the principle of least privilege. 
+- Disable anonymous or guest access on all file share protocols (FTP, SMB, NFS).
+- Restrict share permissions to named accounts that require access and grant the minimum necessary privilege level (read-only where write is not needed).
+- Ensure file share services are not exposed to untrusted networks by restricting access through firewall rules or network segmentation. If a file share service is not required, disable it entirely. 
+- Migrate to encrypted protocols such as SFTP or SMBv3 with encryption where file transfer is necessary.