v1.18.1 update - SSRF categories

submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_dns_query_only/recommendations.md

@@ -2,9 +2,9 @@
 
 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 that include permitted hostnames, IP addresses, or URL schemes that the application is expected to interact with. 
+- 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:

submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/guidance.md

@@ -2,6 +2,6 @@
 
 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.
+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. Include a screenshot of the HTTP listener log showing an incoming request from the target server's IP address. Show the submitted payload and the captured request headers. 
 
 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/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/recommendations.md

@@ -2,9 +2,9 @@
 
 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
+- Within the application layer, use allow lists for input validation that include permitted hostnames, IP addresses, or URL schemes that the application is expected to interact with. 
+- 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:

submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/template.md

@@ -1,8 +1,8 @@
-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.
+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 an external, attacker controlled domain. An external SSRF vulnerability was found in this application which allows an attacker to query external services from the application and observe server-side request headers, IP address, and user-agent information.
 
 **Business Impact**
 
-External SSRF can lead to data theft and through an attacker accessing, deleting, or modifying data from within the application via their access to server-side systems. This could also 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.
+While no internal data is directly exposed, this information may assist in identifying the hosting environment and planning further attacks. This could 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**
 

submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md → submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/recommendations.md

@@ -2,9 +2,9 @@
 
 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 that include permitted hostnames, IP addresses, or URL schemes that the application is expected to interact with. 
+- 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:

submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/template.md → submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/template.md

@@ -1,4 +1,4 @@
-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 domains that are not accessible from the internet. A SSRF vulnerability was found in this application which allows an attacker to read data from internal services such as internal API responses, application configuration, or content from internal web interfaces. While the exposed data does not include authentication secrets or credentials, it may contain business data, internal documentation, user records, or system configuration details.
 
 **Business Impact**
 

submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/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. Include screenshots or HTTP responses showing distinguishable server behaviour for existing and non-existing internal resources. Show at least two requests with different responses that confirm resource presence without revealing secret values.
+
+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/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/recommendations.md → submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/recommendations.md

@@ -2,9 +2,9 @@
 
 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 that include permitted hostnames, IP addresses, or URL schemes that the application is expected to interact with. 
+- 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:

submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/template.md

@@ -0,0 +1,23 @@
+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 manipulate the URL parameter to force the server to issue requests to internal IP addresses on arbitrary ports. A SSRF vulnerability was found in this application where the server's response differs depending on whether a requested resource is present. This allows an attacker to confirm that specific data, or secrets, exist on an internal service, such as enumerating internal paths, keys, or configuration entries. However, the attacker is unable to retrieve the internal data or secret's values.
+
+**Business Impact**
+
+SSRF that confirms the presence of internal data or secrets gives an attacker knowledge of what sensitive resources exist and where they are stored. This information helps an attacker prioritize targets if a higher-impact vulnerability is found elsewhere. While no secret values are directly exposed, confirming the existence of credentials, API keys, or sensitive configuration entries on specific internal endpoints reveals the internal security architecture. This could 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. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
+1. Use a browser to log in and navigate to: {{URL}}
+1. Forward the following payload to the endpoint:
+
+```http
+{{request}}
+```
+
+1. Observe the sensitive response
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_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 a summary of the data that was exfiltrated through exploitation. Include screenshots or HTTP responses showing different server behaviour for open and closed ports on internal hosts. Show at least two distinct port states with measurable differences in response time or error messages.
+
+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/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_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 that include permitted hostnames, IP addresses, or URL schemes that the application is expected to interact with. 
+- 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/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/template.md → submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_only/template.md

@@ -1,8 +1,8 @@
-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.
+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 manipulate the URL parameter to force the server to issue requests to internal IP addresses on arbitrary ports. A SSRF vulnerability was found in this application which allows an attacker to determine whether internal ports are open or closed by observing differences in response timing or error messages. However, they are limited to only mapping which ports are open on internal hosts.
 
 **Business Impact**
 
-SSRF can lead to data theft and through an attacker accessing, deleting, or modifying data from within the application via their access to server-side systems. This could also 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.
+While no internal data is directly exposed, internal port scanning assists an attacker in identifying the internal network environment and planning further attacks. This could 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**
 

submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/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. Include screenshots or HTTP responses showing different server responses for open and closed ports on internal hosts. Show at least two distinct port states and any service banner or version data returned.
+
+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/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/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 that include permitted hostnames, IP addresses, or URL schemes that the application is expected to interact with. 
+- 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/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/template.md

@@ -0,0 +1,23 @@
+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 manipulate the URL parameter to force the server to issue requests to internal IP addresses and ports. A SSRF vulnerability was found in this application where an attacker can scan internal hosts and enumerate running services by observing differences in response timing, status codes, or content that is returned.This allows an attacker to identify which ports have active services, and view service banners or version information that are not intended to be visible externally.
+
+**Business Impact**
+
+SSRF that enables internal port and service scanning provides an attacker with a detailed map of internal infrastructure, allowing them to identify vulnerable software and plan targeted attacks. This could 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. Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
+1. Use a browser to log in and navigate to: {{URL}}
+1. Forward the following payload to the endpoint:
+
+```http
+{{request}}
+```
+
+1. Observe the sensitive response
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}