Server-Side Request Forgery (SSRF)

Feb 17 2022

An example of vulnerability
Preventing SSRF
- At the server-level configuration
- At the code level
Additional links

Server-Side Request Forgery is a security vulnerability that allows an attacker to send requests on behalf of a compromised server.

For example, an SSRF attack can occur if an application uses unverified external data to generate requests. Attackers can induce an application to send malicious requests to resources that are not directly accessible but are available to the server.

Another variant of an SSRF exploit is request masking. An attacker "hides" behind a vulnerable (intermediary) server to make requests to another server (target). In this case, the target server assumes that an intermediary induces all the requests.

It's worth noting that an XXE attack can cause SSRF.

Every year, the severity of SSRF is becoming higher due to several factors. Nowadays, developers are trying to provide users with more convenient functions. That's why, getting a user-provided URL becomes more popular. Cloud services are also developing rapidly. Architectures become more complex. This makes it difficult to create an effective protection against this attack.

In OWASP ASVS 4.0.3, SSRF is associated with 5.2.6 and 12.6.1 positions. In the OWASP Top Ten 2021 list, it belongs to the A10:2021 — Server-Side Request Forgery (SSRF) category. In Common Weakness Enumeration, this vulnerability corresponds to CWE-918.

An example of vulnerability

To better understand SSRF, let's consider the following example:

void ServerSideRequestForgery()
{
  var url = Request.QueryString["url"];
  WebRequest request = WebRequest.Create(url);
  WebResponse response = request.GetResponse();
  using (Stream stream = response.GetResponseStream())
  {
    using (StreamReader reader = new StreamReader(stream))
    {
      ....
    }
  }
  response.Close();
}

In the code fragment above, the user creates the URL to request the corresponding resource.

Here's an example of a server request to delete a user:

http://website/admin/delete?username=testSSRF

The server is expected to execute such requests only from itself or from trusted devices. If an attacker tries to send a request to delete a user directly (in the form presented above), the server will not process it.

However, an attacker can form a request in a different way:

http://localhost/admin/delete?username=testSSRF

Based on the passed address, the server addresses the request to itself. In this case, the request will be executed, and the user will be deleted.

Preventing SSRF

At the server-level configuration

Divide the network into segments and restrict access to resources outside of them to reduce the impact of SSRF.
Ensure "default deny" in the firewall policy to filter traffic.

At the code level

Input validation of data supplied by a user.
Use the URL schemas, port, and destination with allow list validation.

Also, to prevent SSRF, you should not use block list validation or regular expressions. Attackers can easily bypass these restrictions. For example, they can use redirection. In this case, an attacker creates an external resource that redirects to another URL as a response. Also, to bypass the restrictions, attackers can use alternative representations:

http://2130706433/ = http://127.0.0.1

http://0x7f000001/ = http://127.0.0.1

An example of SSRF prevention with the help of data verification:

string ServerSideRequestForgery()
{
  var url = Request.QueryString["url"];
  if (!wList.Contains(url))
    return "Forbidden URL";

  WebRequest request = WebRequest.Create(url);
  ....
}

In this case, only allowed addresses will receive the request. If such a solution is not suitable for some reason, then you should change the application logic. For example, if an image is required, a developer should request not the URL, but the file itself.