Adding non-rewardable templates

submissions/description/broken_authentication_and_session_management/excessive_json_web_token_lifetime/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/broken_authentication_and_session_management/excessive_json_web_token_lifetime/recommendations.md

@@ -0,0 +1,5 @@
+**Recommendation(s)**
+
+Reduce the lifetime of the JWT by setting a shorter expiry value in the token’s payload. 
+
+This should be appropriate to the specific use case in question, with the aim of shortening the lifetime of the token to the lowest practical value. For example, JWTs used to grant an active session to an application should expire in 24 hours, or less if the application is handling sensitive data.

submissions/description/broken_authentication_and_session_management/excessive_json_web_token_lifetime/template.md

@@ -0,0 +1,15 @@
+The JSON Web Tokens (JWT) used for authentication and authorization with the application were found to have an excessively long lifetime. This increases the risk of an attacker gaining unauthorised access to the application in the event of a token being stolen.
+
+The lifetime of a JWT can be managed by the value of the expiry (“exp”) parameter specified within the token’s payload. Tokens used after this expiry time has passed should be regarded as invalid, resulting in access to the system being denied.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+**Proof of Concept (PoC)**
+
+The following code snippet contains the base64 decoded payload from a JWT provided by the application, in which the date issued “iat” corresponds to {{value}} whilst the expiry “exp” corresponds to {{value}}. This equates to a lifetime of {{value}}.
+
+```
+<Base64 decoded JWT Contents>
+```

submissions/description/broken_authentication_and_session_management/secret_questions_used_for_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 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/broken_authentication_and_session_management/secret_questions_used_for_account_verification/recommendations.md

@@ -0,0 +1,5 @@
+**Recommendation(s)**
+
+Do not use secret questions for user verification. 
+
+Other methods of user verification that do not rely on potentially guessable and static information should be used. For example, Two Factor Authentication (2FA). 

submissions/description/broken_authentication_and_session_management/secret_questions_used_for_account_verification/template.md

@@ -0,0 +1,13 @@
+The application used security questions (also referred to as 'secret questions') for the purposes of user verification. 
+
+In general, the use of security questions when determining authentication or authorisation outcomes can weaken the overall security of the application. This is due to the likelihood that the answers to such questions can be publicly discoverable, easily guessed or trivial to answer. This likelihood is made greater when users are able to specify the security questions themselves, leading to no restrictions being in place for minimum requirements of complexity.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+**Proof of Concept (PoC)**
+
+The following screenshot demonstrates the applications use of security questions to verify the identity of the user:
+>
+>{{screenshot}}

submissions/description/insufficient_security_configurability/weak_json_web_token_hashing_algorithm/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/weak_json_web_token_hashing_algorithm/recommendations.md

@@ -0,0 +1,3 @@
+**Recommendation(s)**
+
+Deprecate use of the HS256 algorithm and instead opt to use an asymmetrical algorithm such as RS256 (RSA Signature with SHA-256) to sign JWTs.

submissions/description/insufficient_security_configurability/weak_json_web_token_hashing_algorithm/template.md

@@ -0,0 +1,17 @@
+The application used JSON Web Tokens (JWT) for authentication and authorization. The JWT's were signed using the HS256 (HMAC with SHA-256) algorithm.
+
+Due to the symmetrical nature of this algorithm which uses a shared secret key, the secret that is used to generate the JWT signature is susceptible to brute-force guessing techniques. If the secret is sufficiently short in character length and weak in entropy, then it may be possible to discover the secret as the result of performing an automated secret-guessing attack ("brute-forcing" the hash).
+
+Should the secret key be compromised, an attacker would be able to create valid JWTs and gain unauthorized access to the application. Furthermore, as the identity, roles and privileges of the user are specified in the JWT, this could also allow the impersonation of any user and the escalation of privileges to gain administrative permissions over the application.
+
+**Business Impact**
+
+This vulnerability could lead to data theft through the attacker’s ability to manipulate data through their access to the application, and their ability to interact with other users, including performing other malicious attacks, which would appear to originate from a legitimate user. These malicious actions could also result in reputational damage for the business through the impact to customers’ trust.
+
+**Proof of Concept (PoC)**
+
+The following code snippet contains the base-64 decoded header contents of the JWT, in which the algorithm used to sign the JWT can be seen within the 'alg' field: 
+
+```
+<JWT Header>
+```

submissions/description/sensitive_data_exposure/sensitive_information_disclosed_in_json_web_token/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/sensitive_data_exposure/sensitive_information_disclosed_in_json_web_token/recommendations.md

@@ -0,0 +1,5 @@
+**Recommendation(s)**
+
+Do not store any sensitive data in a JWT. While these tokens are signed to prevent forgery or manipulation, the claims are base64 encoded and trivial to decode.
+
+For example, do not include a user's email address in a JWT. Instead store a server side identifier that is opaque and have the server then perform a lookup and the user’s identifier. If you do need to store sensitive information in a JWT, JSON Web Encryption (JWE) should be implemented as an encrypted alternative.

submissions/description/sensitive_data_exposure/sensitive_information_disclosed_in_json_web_token/template.md

@@ -0,0 +1,22 @@
+The JSON Web Tokens (JWT) disclosed sensitive information such as Personally Identifiable Information (PII) and role details, including the following:
+
+* First name
+* Last name
+* Username
+* Email address
+* Account permissions for the application
+
+A JWT is a compact means of representing information (referred to as claims) to be transferred between client and server. Whilst tokens are signed to prevent forgery or manipulation, the claims are base64 encoded and trivial to decode. An attacker that can recover an old JWT would be able to read this information and enumerate limited user details.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+
+**Proof of Concept (PoC)**
+
+The following code snippet contains the base64 decoded contents of the JWT:
+
+```
+<Base64 decoded JWT Contents>
+```

submissions/description/sensitive_data_exposure/sensitive_information_disclosure_robots_txt/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/sensitive_data_exposure/sensitive_information_disclosure_robots_txt/recommendations.md

@@ -0,0 +1,3 @@
+**Recommendation(s)**
+
+As an alternative approach, consider using Robots META tags instead of entries in the robots.txt file.

submissions/description/sensitive_data_exposure/sensitive_information_disclosure_robots_txt/template.md

@@ -0,0 +1,15 @@
+The application contained a 'robots.txt' file, which is intended to prevent web 'robots' from visiting certain directories in a website for maintenance or indexing purposes. 
+
+A malicious user may also use the contents of robots.txt to enumerate sensitive files or directories on the affected site and either retrieve them directly or target them for other attacks.
+
+**Business Impact**
+
+This vulnerability can lead to reputational damage and indirect financial loss to the company as customers may view the application as insecure.
+
+**Proof of Concept (PoC)**
+
+The following hidden or sensitive directories and files were disclosed in the Robots.txt file:
+
+```
+<Code snippet containing sensitive robots.txt entries>
+````