-
Notifications
You must be signed in to change notification settings - Fork 49
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fixes to match Blockchain CRT update
To match VRT: - Fixed missing Blockchain and SAML Replay templates. - Modified the naming of the IDOR categories.
- Loading branch information
Showing
32 changed files
with
91 additions
and
10 deletions.
There are no files selected for viewing
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
File renamed without changes.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
File renamed without changes.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
File renamed without changes.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
File renamed without changes.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7 changes: 7 additions & 0 deletions
7
...escription/broken_authentication_and_session_management/saml_replay/guidance.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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). |
13 changes: 13 additions & 0 deletions
13
...ion/broken_authentication_and_session_management/saml_replay/recommendations.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
# Recommendation(s) | ||
|
||
SAML replay attacks can be remediated by implementing a handful of best practices relating to authentication and session management to ensure secure implementation. These include: | ||
|
||
- SAML assertions must include time-limited tokens with precise timestamps. The Service Providers (SPs) must check these timestamps, rejecting any assertion that is outside the validity window. | ||
- Validate SAML assertions against the originating identity provider to ensure authenticity. | ||
- Regularly monitor authentication logs for unusual patterns, such as repeated use of the same token. | ||
|
||
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) guide located at: | ||
|
||
- <https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html> |
24 changes: 24 additions & 0 deletions
24
...escription/broken_authentication_and_session_management/saml_replay/template.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
SAML replay is a vulnerability where an attacker intercepts and reuses a valid Security Assertion Markup Language (SAML) token to gain unauthorized access to a system. This occurs when the application fails to implement proper safeguards, such as token expiration, or single-use tokens. An attacker can use the replayed token to access sensitive data, or perform unauthorized actions within the application on behalf of a user. | ||
|
||
**Business Impact** | ||
SAML Replay attacks can lead to unauthorized access to sensitive data, and can cause financial, reputational, and legal damages. This vulnerability could also result in reputational damage for the business through the impact to customers’ trust. | ||
|
||
**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 following request that includes a valid SAML assertion: | ||
|
||
``` | ||
{{request}} | ||
``` | ||
|
||
1. Replay the captured SAML assertion by sending it to the target application without modification. | ||
1. Observe that the application grants access based on the replayed token | ||
|
||
|
||
**Proof of Concept (PoC)** | ||
|
||
The screenshot below demonstrates the broken authentication and session management: | ||
|
||
{{screenshot}} |
File renamed without changes.
File renamed without changes.
File renamed without changes.
5 changes: 5 additions & 0 deletions
5
...sitive_data_exposure/token_leakage_via_referer/password_reset_token/guidance.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
# Guidance | ||
|
||
Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability and list out all effected hosts. This will speed triage time and result in faster rewards. | ||
|
||
Describe the impact of the tokens being exposed and do your best to describe what the impact of this may be to the company. |
14 changes: 14 additions & 0 deletions
14
...data_exposure/token_leakage_via_referer/password_reset_token/recommendations.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
# Recommendation(s) | ||
|
||
The application should transmit sensitive tokens via 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 guides: | ||
|
||
- <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> |
18 changes: 18 additions & 0 deletions
18
...sitive_data_exposure/token_leakage_via_referer/password_reset_token/template.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
The `Referer` HTTP request header is used to show the URL of the page a user requested the resource from. This application’s `Referer` header leaks valid password reset tokens which can be intercepted by an attacker performing a Person-in-The-Middle (PiTM) attack, or by exploiting third-party vendors. With access to the exposed token in the `Referer` HTTP header, the attacker could reset the password 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 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. Capture the request using the HTTP interception proxy | ||
1. Observe the token in `Referer` header | ||
|
||
**Proof of Concept (PoC)** | ||
|
||
The following screenshot shows the token exposed within the `Referer` HTTP request header: | ||
|
||
{{screenshot}} |