Server-Side Request Forgery vulnerabilities occur when a user is able to cause an application to make HTTP requests to an attacker-determined domain. If an application has access to private/internal networks, an attacker could also cause the application to make requests to internal servers.
We’ll take a closer look at this with some examples to better understand what it looks like in action.
Consider an API that takes a URL from a user and generates a picture of the URL provided by the user, such as for a preview or export of a page.
Because the URL parameter is controlled by the user, it allows an attacker to simply access any URL they want. In some cases, depending on the library used to access the URL, it can even be local files using the ‘file://’ scheme.
A common way of abusing an SSRF vulnerability, when hosted on AWS, is to use it to access the AWS Metadata API which can contain credentials for the AWS API. This can lead to further access to other AWS resources within the account which, as you can imagine, is not ideal.
Mitigating SSRF vulnerabilities can be very tricky at times, and depend heavily on what the code in question is trying to achieve. Depending on the requirements, there are different mitigations that can be put in place.
Avoid user-determined URLs
In some cases, you may be able to implement a feature in a way that doesn’t rely on a user providing an arbitrary URL. If this is at all a possibility, it's the most effective way of mitigating the risk of SSRF.
If you’re implementing a PDF export function, one might be inclined to simply use a headless browser and take a screenshot of the page. This isn’t always advisable, given the complexity of browsers and the sheer number of capabilities and attack surfaces that browsers expose.
It's important to use the right tool for the job at hand. In some cases, a simple HTTP client will be sufficient. There are always things that can be done to minimize the capabilities, and thus the attack surface/vectors available. For instance, in the case of an HTTP client:
Redirects & iframes
A common way of protecting against SSRF on private resources (IP addresses, or internal hostnames) is to parse the URL provided by a user and use a ‘deny-list’ to prevent access to sensitive resources.
Another "type" of redirect can also be done through DNS. One common way of trying to prevent SSRF attacks is to do the following:
This method isn’t really effective due to it being vulnerable to "DNS Rebinding". DNS Rebinding works because of the standard behavior of most network stacks (Such as those of Linux and Windows) when a TCP connection is closed by a remote host.
When a remote host forcefully closes a connection, it will attempt to reconnect after doing another DNS query to re-resolve the IP address.
This allows an attacker to do the following:
This effectively bypasses the protection against providing URLs that resolve to private IP addresses.
IPv4 vs IPv6
Another common way of bypassing any ‘deny-list’ is the use of IPv6. Because all IPv4 addresses can be expressed in terms of an IPv6 address, it’s often possible to bypass deny-lists by using an IPv6 address that also maps to an IPv4 address that one would want to access.
We secure software through developer-driven security at the start of the software development lifecycle.Visit Secure Code Warrior