diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_dns_query_only/recommendations.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_dns_query_only/recommendations.md index 4ba6f1c2..5af11b17 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_dns_query_only/recommendations.md +++ b/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: diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/guidance.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/guidance.md index b25feb21..11ef8477 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/guidance.md +++ b/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. diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/recommendations.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/recommendations.md index dba41631..ad892355 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/recommendations.md +++ b/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: diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/template.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/template.md index 59eea21c..1612d9a8 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/external_low_impact/template.md +++ b/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** diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/.gitkeep b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/.gitkeep similarity index 100% rename from submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/.gitkeep rename to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/.gitkeep diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/guidance.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/guidance.md similarity index 100% rename from submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/guidance.md rename to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/guidance.md diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/recommendations.md similarity index 84% rename from submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md rename to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/recommendations.md index 4ba6f1c2..5af11b17 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/recommendations.md +++ b/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: diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/template.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/template.md similarity index 69% rename from submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/template.md rename to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_data_exposure/template.md index 92dbc9a2..cfd6df19 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/template.md +++ b/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** diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/.gitkeep b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/.gitkeep similarity index 100% rename from submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/.gitkeep rename to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/.gitkeep diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/guidance.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/guidance.md new file mode 100644 index 00000000..6bc4509f --- /dev/null +++ b/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. diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/recommendations.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/recommendations.md similarity index 84% rename from submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/recommendations.md rename to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/recommendations.md index 4ba6f1c2..5af11b17 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/recommendations.md +++ b/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: diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/template.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_exposure_presence_data_secrets/template.md new file mode 100644 index 00000000..8a376de7 --- /dev/null +++ b/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}} diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_only/.gitkeep b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_only/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_only/guidance.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_only/guidance.md new file mode 100644 index 00000000..3d16723d --- /dev/null +++ b/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. diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_only/recommendations.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_only/recommendations.md new file mode 100644 index 00000000..5af11b17 --- /dev/null +++ b/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: + +- +- +- diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/template.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_only/template.md similarity index 62% rename from submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/template.md rename to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_scan_only/template.md index cc837a43..e75b9ab3 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_scan_and_or_medium_impact/template.md +++ b/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** diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/.gitkeep b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/guidance.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/guidance.md new file mode 100644 index 00000000..3dd24f9b --- /dev/null +++ b/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. diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/recommendations.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/recommendations.md new file mode 100644 index 00000000..5af11b17 --- /dev/null +++ b/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: + +- +- +- diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/template.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_port_service_scan/template.md new file mode 100644 index 00000000..8d23fea4 --- /dev/null +++ b/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}} diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/.gitkeep b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/guidance.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/guidance.md similarity index 100% rename from submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_high_impact/guidance.md rename to submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/guidance.md diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/recommendations.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/recommendations.md new file mode 100644 index 00000000..5af11b17 --- /dev/null +++ b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/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: + +- +- +- diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/template.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/template.md new file mode 100644 index 00000000..820d6749 --- /dev/null +++ b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/internal_secrets_exposure/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 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 can retrieve secrets from internal infrastructure, such as cloud metadata credentials, API keys, database connection strings, or authentication tokens. These secrets can be used to authenticate to other services, escalate privileges, or access sensitive data across the environment. + +**Business Impact** + +SSRF can lead to data theft and 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. + +**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}} diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/recommendations.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/recommendations.md index 4ba6f1c2..5af11b17 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/recommendations.md +++ b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/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: diff --git a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/template.md b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/template.md index 837cd900..7ca44434 100644 --- a/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/template.md +++ b/submissions/description/server_security_misconfiguration/server_side_request_forgery_ssrf/template.md @@ -1,6 +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 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. +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 which allows an attacker to perform a request to an internally networked resource, which is considered high impact. **Business Impact**