SSRF
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 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
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.
Steps to Reproduce
Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
Use a browser to login and navigate to: {{URL}}
Forward the following payload to the endpoint:
{{request}}Observe the sensitive response
Proof of Concept (PoC)
The following screenshot(s) demonstrate(s) this vulnerability:
{{screenshot}}
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.
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:
Last updated