v1.18.1 update - SSRF categories

To align  the Templates repo with the updates mentioned in VRT Issue 496 - bugcrowd/vulnerability-rating-taxonomy#496

Author: RRudder

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**
 

…rgery_ssrf/internal_high_impact/.gitkeep …ery_ssrf/internal_data_exposure/.gitkeepsubmissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/.gitkeep renamed to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/.gitkeep submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/.gitkeep renamed to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/.gitkeep

@@ -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:

…al_scan_and_or_medium_impact/guidance.md …_ssrf/internal_data_exposure/guidance.mdsubmissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/guidance.md renamed to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/guidance.md submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/guidance.md renamed to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/guidance.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**
 

…/internal_high_impact/recommendations.md …nternal_data_exposure/recommendations.mdsubmissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md renamed to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/recommendations.md submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md renamed to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/recommendations.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.