Updates to SSRF family of findings

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.

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:
+
+- <https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html>
+- <https://portswigger.net/web-security/ssrf>
+- <https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/>

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 screenshot below shows the external DNS queries from the application:
+
+{{screenshot}}

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.

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:
+
+- <https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html>
+- <https://portswigger.net/web-security/ssrf>
+- <https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/>

submissions/description/broken_access_control/server_side_request_forgery_ssrf/external/template.md → 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 screenshot below shows incoming HTTP requests and the external queries from the application:
 
 {{screenshot}}

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.

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:
 
 - <https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html>
 - <https://portswigger.net/web-security/ssrf>
-- <https://owasp.org/Top10/A01_2021-Broken_Access_Control/>
-- <https://portswigger.net/web-security/access-control>
+- <https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/>

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
 

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.

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:
 
 - <https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html>
 - <https://portswigger.net/web-security/ssrf>
-- <https://owasp.org/Top10/A01_2021-Broken_Access_Control/>
-- <https://portswigger.net/web-security/access-control>
+- <https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/>

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
 

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:
 
 - <https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html>
 - <https://portswigger.net/web-security/ssrf>
-- <https://owasp.org/Top10/A01_2021-Broken_Access_Control/>
-- <https://portswigger.net/web-security/access-control>
+- <https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/>

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