diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/dns_query_only/recommendations.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/dns_query_only/recommendations.md deleted file mode 100644 index caf3e040..00000000 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/dns_query_only/recommendations.md +++ /dev/null @@ -1,14 +0,0 @@ -# Recommendation(s) - -There is no single technique to stop SSRF from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of SSRF. Some best practices include the following: - -WIthin the application layer, use allow lists for input validation -Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to -Validate any external domain or IP address that the application attempts send a request to - -For more information, refer to the following resources: - -- -- -- -- diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/dns_query_only/template.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/dns_query_only/template.md deleted file mode 100644 index bc9784fd..00000000 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/dns_query_only/template.md +++ /dev/null @@ -1,28 +0,0 @@ -# DNS-Only Server-Side Request Forgery - -## Overview of the Vulnerability - -Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to internal or external domains. Such domains may include internal cloud server meta-data which consists of sensitive configuration information, internal HTTP database interfaces allowing database access, or using `file://` URI to read sensitive files. A SSRF vulnerability was found in this application which allows an attacker to request a DNS query from the application. - - -## Business Impact - -DNS-only SSRF can result in the application and internal network being less secure, as an attacker is able to use the known DNS queries to mount further attacks. - -## 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. Forward the following payload to the endpoint: - -```HTTP -{{request}} -``` - -1. Observe DNS interaction in the HTTP interception proxy - -## Proof of Concept (PoC) - -The screenshot below shows incoming DNS queries from the application: - -{{screenshot}} diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external/recommendations.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external/recommendations.md deleted file mode 100644 index caf3e040..00000000 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external/recommendations.md +++ /dev/null @@ -1,14 +0,0 @@ -# Recommendation(s) - -There is no single technique to stop SSRF from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of SSRF. Some best practices include the following: - -WIthin the application layer, use allow lists for input validation -Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to -Validate any external domain or IP address that the application attempts send a request to - -For more information, refer to the following resources: - -- -- -- -- diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/dns_query_only/.gitkeep b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/.gitkeep similarity index 100% rename from submissions/description/broken_access_control/server_side_request_forgery_ssrf/dns_query_only/.gitkeep rename to submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/.gitkeep diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/guidance.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/guidance.md new file mode 100644 index 00000000..9b245414 --- /dev/null +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/guidance.md @@ -0,0 +1,7 @@ +# 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. + +For this type of SSRF, the best evidence is usually a screenshot of incoming requests, and external DNS queries. + +Where possible and safe, escalate the SSRF to have some kind of tangible security impact, such as exfiltrating data. If this is possible, provide a full Proof of Concept (PoC). If no impact can be demonstrated other than receiving external interactions, this will most likely be considered as P5/informational severity. diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/recommendations.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/recommendations.md new file mode 100644 index 00000000..4ba6f1c2 --- /dev/null +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/recommendations.md @@ -0,0 +1,14 @@ +# Recommendation(s) + +There is no single technique to stop SSRF from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of SSRF. Some best practices include the following: + +- Within the application layer, use allow lists for input validation +- Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to +- Validate any external domain or IP address that the application attempts send a request to +- Display generic error handling messages to the client when an error occurs, and for all error types. E.g. When invalid data is received and when a request fails server-side. + +For more information, refer to the following resources: + +- +- +- diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/template.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/template.md new file mode 100644 index 00000000..9d679dd4 --- /dev/null +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_dns_query_only/template.md @@ -0,0 +1,27 @@ +# External - DNS Query Only + +## Overview of the Vulnerability + +Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to external domains. An external SSRF vulnerability was found in this application which allows an attacker to trigger external DNS-based interactions from the application. + +## Business Impact + +External DNS-only SSRF can result in the application and internal network being less secure, as an attacker is able to use the known DNS queries to mount further attacks. + +## 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. Forward the following payload to the endpoint: + +```HTTP +{{request}} +``` + +1. Observe DNS interaction in the HTTP interception proxy + +## Proof of Concept (PoC) + +The following screenshot(s) demonstrate(s) this vulnerability: + +{{screenshot}} diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external/.gitkeep b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/.gitkeep similarity index 100% rename from submissions/description/broken_access_control/server_side_request_forgery_ssrf/external/.gitkeep rename to submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/.gitkeep diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/guidance.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/guidance.md new file mode 100644 index 00000000..b25feb21 --- /dev/null +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/guidance.md @@ -0,0 +1,7 @@ +# 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. + +For this type of SSRF, the best evidence is usually a screenshot of incoming requests, and a summary of the data that was exfiltrated through exploitation. + +Where possible and safe, escalate the SSRF to have some kind of tangible security impact, such as exfiltrating data. If this is possible, provide a full Proof of Concept (PoC). If no impact can be demonstrated other than receiving external interactions, this will most likely be considered as P5/informational severity. diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/recommendations.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/recommendations.md new file mode 100644 index 00000000..dba41631 --- /dev/null +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/recommendations.md @@ -0,0 +1,14 @@ +# Recommendation(s) + +TThere is no single technique to stop SSRF from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of SSRF. Some best practices include the following: + +- Within the application layer, use allow lists for input validation +- Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to +- Validate any external domain or IP address that the application attempts send a request to +- Display generic error handling messages to the client when an error occurs, and for all error types. E.g. When invalid data is received and when a request fails server-side. + +For more information, refer to the following resources: + +- +- +- diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external/template.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/template.md similarity index 65% rename from submissions/description/broken_access_control/server_side_request_forgery_ssrf/external/template.md rename to submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/template.md index 83eaa616..70d68d48 100644 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external/template.md +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/external_low_impact/template.md @@ -2,7 +2,7 @@ ## Overview of the Vulnerability -Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to internal or external domains. Such domains may include internal cloud server meta-data which consists of sensitive configuration information, internal HTTP database interfaces allowing database access, or using `file://` URI to read sensitive files. A SSRF vulnerability was found in this application which allows an attacker to create arbitrary external HTTP requests, such as those outlined above. +Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to external domains. An external SSRF vulnerability was found in this application which allows an attacker to query external services from the application. ## Business Impact @@ -22,6 +22,6 @@ External SSRF can lead to data theft and through an attacker accessing, deleting ## Proof of Concept (PoC) -The screenshot below shows incoming HTTP requests and DNS queries from the application: +The following screenshot(s) demonstrate(s) this vulnerability: {{screenshot}} diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/guidance.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/guidance.md index 90dd5009..b25feb21 100644 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/guidance.md +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/guidance.md @@ -1,6 +1,7 @@ # 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. -For this type of SSRF, the best evidence is usually a screen recording or image of incoming requests, and a summary of the data that was exfiltrated through exploitation. + +For this type of SSRF, the best evidence is usually a screenshot of incoming requests, and a summary of the data that was exfiltrated through exploitation. Where possible and safe, escalate the SSRF to have some kind of tangible security impact, such as exfiltrating data. If this is possible, provide a full Proof of Concept (PoC). If no impact can be demonstrated other than receiving external interactions, this will most likely be considered as P5/informational severity. diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md index caf3e040..4ba6f1c2 100644 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md @@ -2,13 +2,13 @@ There is no single technique to stop SSRF from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of SSRF. Some best practices include the following: -WIthin the application layer, use allow lists for input validation -Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to -Validate any external domain or IP address that the application attempts send a request to +- Within the application layer, use allow lists for input validation +- Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to +- Validate any external domain or IP address that the application attempts send a request to +- Display generic error handling messages to the client when an error occurs, and for all error types. E.g. When invalid data is received and when a request fails server-side. For more information, refer to the following resources: - - -- -- +- diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_high_impact/template.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_high_impact/template.md index 2017b559..7ea295ce 100644 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_high_impact/template.md +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_high_impact/template.md @@ -2,7 +2,7 @@ ## Overview of the Vulnerability -Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to internal or external domains. Such domains may include internal cloud server meta-data which consists of sensitive configuration information, internal HTTP database interfaces allowing database access, or using `file://` URI to read sensitive files. A SSRF vulnerability was found in this application which allows an attacker to perform a request to an internally networked resource, which is considered high impact. +Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to internal domains. A SSRF vulnerability was found in this application which allows an attacker to perform a request to an internally networked resource, which is considered high impact. ## Business Impact @@ -22,6 +22,6 @@ SSRF can lead to data theft and through an attacker accessing, deleting, or modi ## Proof of Concept (PoC) -The screenshot below shows the full exploit: +The following screenshot(s) demonstrate(s) this vulnerability: {{screenshot}} diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/guidance.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/guidance.md index cb291783..b25feb21 100644 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/guidance.md +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/guidance.md @@ -1,6 +1,7 @@ # 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. -For this type of SSRF, the best evidence is usually a screen recording or image of incoming requests, and a summary of the data that was exfiltrated through exploitation. -As this VRT item refers to internal scans, be sure to demonstrate exactly what can be accessed internally, for example a list of active hosts. If this SSRF is not able to achieve this, take a look at some of the other SSRF VRT items to see if there is another one that is more appropriate. +For this type of SSRF, the best evidence is usually a screenshot of incoming requests, and a summary of the data that was exfiltrated through exploitation. + +Where possible and safe, escalate the SSRF to have some kind of tangible security impact, such as exfiltrating data. If this is possible, provide a full Proof of Concept (PoC). If no impact can be demonstrated other than receiving external interactions, this will most likely be considered as P5/informational severity. diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/recommendations.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/recommendations.md index caf3e040..4ba6f1c2 100644 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/recommendations.md +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/recommendations.md @@ -2,13 +2,13 @@ There is no single technique to stop SSRF from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of SSRF. Some best practices include the following: -WIthin the application layer, use allow lists for input validation -Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to -Validate any external domain or IP address that the application attempts send a request to +- Within the application layer, use allow lists for input validation +- Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to +- Validate any external domain or IP address that the application attempts send a request to +- Display generic error handling messages to the client when an error occurs, and for all error types. E.g. When invalid data is received and when a request fails server-side. For more information, refer to the following resources: - - -- -- +- diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/template.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/template.md index 1525e401..a8731ef3 100644 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/template.md +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/template.md @@ -2,7 +2,7 @@ ## Overview of the Vulnerability -Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to internal or external domains. Such domains may include internal cloud server meta-data which consists of sensitive configuration information, internal HTTP database interfaces allowing database access, or using `file://` URI to read sensitive files. A SSRF vulnerability was found in this application which allows an attacker to perform arbitrary internal requests and internal network scanning. +Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to internal or external domains. A SSRF vulnerability was found in this application which allows an attacker to perform arbitrary internal requests and internal network scanning. ## Business Impact @@ -28,6 +28,6 @@ SSRF can lead to data theft and through an attacker accessing, deleting, or modi ## Proof of Concept (PoC) -The screenshot below shows the Burp intruder results filtering out active hosts: +The following screenshot(s) demonstrate(s) this vulnerability: {{screenshot}} diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/recommendations.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/recommendations.md index caf3e040..4ba6f1c2 100644 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/recommendations.md +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/recommendations.md @@ -2,13 +2,13 @@ There is no single technique to stop SSRF from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of SSRF. Some best practices include the following: -WIthin the application layer, use allow lists for input validation -Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to -Validate any external domain or IP address that the application attempts send a request to +- Within the application layer, use allow lists for input validation +- Within the network layer, apply segregation principles to limit the network access of the application to only areas of the network it needs to connect to +- Validate any external domain or IP address that the application attempts send a request to +- Display generic error handling messages to the client when an error occurs, and for all error types. E.g. When invalid data is received and when a request fails server-side. For more information, refer to the following resources: - - -- -- +- diff --git a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/template.md b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/template.md index c464804f..146d8e6b 100644 --- a/submissions/description/broken_access_control/server_side_request_forgery_ssrf/template.md +++ b/submissions/description/broken_access_control/server_side_request_forgery_ssrf/template.md @@ -2,7 +2,9 @@ ## Overview of the Vulnerability -Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to internal or external domains. Such domains may include internal cloud server meta-data which consists of sensitive configuration information, internal HTTP database interfaces allowing database access, or using `file://` URI to read sensitive files. A SSRF vulnerability was found in this application which allows an attacker to make requests to an unintended location within the application. +Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to internal domains. A SSRF vulnerability was found in this application which allows an attacker to perform a request to an internally networked resource, which is considered high impact. + +Server-side request forgery (SSRF) is a vulnerability that exploits the trust relationship between a server and an application, or other backend systems. An attacker can take advantage of this trust to forge server-side traffic and make HTTP requests to internal or external domains. A SSRF vulnerability was found in this application which allows an attacker to make requests to an unintended location within the application. ## Business Impact @@ -22,6 +24,6 @@ SSRF can lead to data theft and through an attacker accessing, deleting, or modi ## Proof of Concept (PoC) -The screenshot below shows the full exploit: +The following screenshot(s) demonstrate(s) this vulnerability: {{screenshot}}