SSRF: What is Server Side Request Forgery?

SSRF is a type of web application vulnerability and the associated family of attacks that force a target server to execute requests against other resources that the target server has access to, including read and write operations to local and internal assets. The SSRF acronym stands for “Server-Side Request Forgery,” as the attacker forces the server (forging) to perform malicious unintended requests.

Server Side Request Forgery is a serious application security risk and a candidate to become part of the next edition of the OWASP Top 10 ranking. The consequences of an SSRF breach can be very damaging, for instance, the well-known Capital One 2019 hack involved a form of Server Side Request Forgery.

This post will review the SSRF risk, both from a vulnerability and attack perspective, the two different types (blind and basic), describe the typical attack scenarios, and provide practical mitigation advice.

What is SSRF
Server Side Request Forgery example
SSRF Vulnerability detection and mitigation
SSRF attack protection
Hdiv Security detects and protects the SSRF Risk

What is SSRF

In a Server Side Request Forgery, a vulnerable application takes a request parameter and uses it to perform a subsequent operation. An attacker takes advantage of the access rights of the target server to perform a broad array of unauthorized actions.

Examples of these actions are browsing server private directories, remote execution of code in the target server, accessing local machines behind the network firewall (port scans), and many others. A type of unauthorized action that deserves special attention is when the attacker takes advantage of the vulnerable server as a stepping stone to enable larger compound attacks, in particular combinations of SSRF and XXE.

The SSRF exploits are not limited to web access. A crafty attacker will be able to forge non-web payloads involving protocols such as ftp, smtp, and smb.

There are two main types of Server Side Request Forgery:

Basic SSRF

Basic Server Side Request Forgery occurs when the attacker actually receives back the response to the SSRF payload, meaning that the request loop closes back to the attacker. This type of attack is able to perform read and write operations.

Blind SSRF

Blind Server Side Request Forgery exploits do not return a response to the attacker. Because of this open-loop, read operations are not immediate, but blind attacks can be used easily to conduct write operations for which the attacker does not need to see the response.

Server Side Request Forgery examples

SSRF vulnerability example

Server Side Request Forgery is easy to understand by seeing a code example. In the following Java Springboot SSRF example, adapted from the Java Sec project, a request input parameter is used to build a secondary request. There is no validation.

Imagine a use case to create user accounts, including a profile picture for each user. The user uploads a picture, and it is placed in a separate storage service, such as an S3 bucket. The URL of the uploaded user profile picture is stored along with the user data, and when the user profile page is rendered, the HTML code includes a call to the following service to obtain the image:

@GetMapping("/profilepics")
public void openStream(@RequestParam String url, HttpServletResponse response) 
  throws IOException {

  InputStream inputStream = null;
  OutputStream outputStream = null;

  String downLoadImgFileName = 
    WebUtils.getNameWithoutExtension(url) + "." + WebUtils.getFileExtension(url);
  // download
  response.setHeader(
    "content-disposition", 
    "attachment;fileName=" + downLoadImgFileName);

  URL u = new URL(url);
  int length;
  byte[] bytes = new byte[1024];
  inputStream = u.openStream(); // send request
  outputStream = response.getOutputStream();
  while ((length = inputStream.read(bytes)) > 0) {
      outputStream.write(bytes, 0, length);
  }

}

As you see, the code is taking input data from a request parameter. This data is untrusted and should be validated. This represents an insecure direct object reference risk, as well. The vulnerability happens when the unvalidated input data is used to open a different request and return it to the user.

SSRF attack example

Server Side Request Forgery attacks are attempts to exploit an SSRF vulnerability by sending a payload that makes the target server take an unintended action, as described above. Normally, the attacker uses a client-side proxy, such as OWASP ZAP to capture the traffic, and modify the values of the parameters, and based on clues on the error messages and responses, guess what points are potentially vulnerable.

The morphology of the attack and the particular payload structure will greatly depend on whether it is a basic vs blind, as well as on the intended action.

Going back to the vulnerability example described above, an immediate attack would be to simply request the following URL:

http://coolapp.com/profilepics?url=file:///etc/passwd

This request would return the server etc/passwd file, because the vulnerable code simply returns the contents of any URL, regardless of protocol and scope.

As part of the discovery process, some attackers attempt to have the target server contact a server they control to see how and when the target server is exploitable and does, in fact, connect to the hacker server. Essentially, it is a trial and error process. This is similar to how a web scanner DAST would attempt to detect the presence of the vulnerability.

SSRF Vulnerability detection and mitigation

A Server Side Request Forgery vulnerability is a security bug that happens when an application takes untrusted user input, typically a POST or GET request parameter, and uses it without proper validation to generate a subsequent request. As a general rule, all untrusted input should always be validated, and SSRF vulnerabilities can be avoided by using good coding practices. However, it is better not to rely on the human factor and also incorporate automatic validation tools to ensure that all code is free of SSRF vulnerabilities at all times.

Let’s take a look at the different strategies that help teams automate the detection of SSRF security vulnerabilities:

SSRF static analysis detection is unreliable

Static analysis tools (SAST) attempt to find the code patterns that suggest the presence of an SSRF vulnerability. However, a static view of the application is highly inaccurate since the untrusted input parameters could follow a complicated dynamic path that it is hard to disentangle by just looking at the source code. This results in SASTs missing SSRF vulnerabilities, and also false positives due to the SAST pattern matching approach.

SSRF DAST detection is unreliable

Some detection strategies, typically used by DAST web scanners involve sending probe commands to the target applications, and then monitor whether or not the probe command is successful at connecting to an external resource used as control element. This approach has serious shortcomings because it is not 100% reliable, so it will miss some SSRF vulnerabilities. This approach also requires a third-party control server to detect the outgoing probe requests, which is cumbersome and complicates the deployment.

IAST tools find SSRF reliably

SSRF is a great example of the advantages of observing the applications in runtime, from the inside. Interactive Application Security Testing tools use server instrumentation to follow the input data through the different layers of the application. By tracking all input data in real-time and seeing how the application is actually using it, an IAST will reliably detect that an untrusted input is involved in sensitive operations, both internal and external. Check out this post to learn more about what is IAST to learn all about Interactive Application Security Testing.

Passive IASTs, in particular, do not need to use specific inputs or probing traffic, and can reliably identify SSRF vulnerabilities with no false positives. Active IASTs will have to rely on specific attack traffic to identify SSRF vulnerabilities. Learn more about the difference between active and passive IASTs in this other post.

SSRF attack protection

WAFs do not provide full SSRF protection

Perimeter defenses such as WAFs rely on blacklists and pattern matching to guess what activities constitute attacks. Regarding SSRF, WAFs might try to find specific URLs or IP patterns that should not be part of a regular request. Another tactic is to block specific protocols, such as file or smb. In any case, the guessing approach that WAFs attempt results in frequent false positives and bypasses. A common SSRF WAF bypass tactic is to envelop the payload with multiple levels of encoding and encryption. Another bypass tactic is to take advantage when the application combines the values of different input parameters.

In sum, since a WAF is external and does not see what the application does with the input data, it is impossible to ensure 100% SSRF protection.

RASP protection from SSRF

Runtime Application Self Protection technology (RASP) shares some of the architectural advantages with the IAST approach discussed above, in the vulnerability detection section. By combining static visibility with real-time runtime visibility, a RASP can be very efficient in detecting Server Side Request Forgery.

For each request, a RASP has the ability to follow all the input data and examine in real-time what the application is doing with this data. If the input data ends in a sensitive spot, the RASP can then look at the payload behavior. If the RASP detects a malicious payload reaching a vulnerable piece of code, it will identify the attack and block the exploitation of the vulnerability.

Hdiv Security detects and protects the SSRF Risk

The Hdiv Security unified application security platform covers extensively this risk, both from a code fix point of view and also from attack blocking point of view:

Hdiv Detection IAST

Hdiv Detection, a passive IAST, finds all occurrences of Server Side Request Forgery vulnerabilities in the code, from the very beginning.

Hdiv Protection RASP

For production systems, Hdiv Protection, based on RASP technology, protects SSRF vulnerabilities from attacks without using blacklists or pattern-matching. To increase the efficiency and the accuracy of the protection, Hdiv Protection will only monitor payloads in the points of the application that actually are vulnerable to Server Side Request Forgery. This means that there is no need to validate all the input, but only those pieces that reach a critical code hotspot. Hdiv Protection will also help to manage non-web protocols such as ftp, so the team can decide what’s allowed and what’s not.

Furthermore, some applications might have a need to take inputs and use them to create subsequent requests. Hdiv Protection allows the configuration of automatic domain whitelists, so only the approved resources can be reached. This eliminates the risk of exploiting the functionality while allowing the developers the ability to introduce certain application behaviors.

We hope that this deep dive into Server Side Request Forgery was useful. If you want to experience Hdiv, you can request an immediate Hdiv Security Online Demo, and download our IAST white paper below.