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.

Table of contents

What is SSRF
Typical dangerous SSRF Use Cases
Server Side Request Forgery example
SSRF and CapitalOne breach
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.

Typical dangerous SSRF Use Cases

Why do developers introduce risky practices that can lead to SSRF? Here are some examples of common use cases that can lead to a server side request forgery vulnerability when the proper validations are not introduced: download and fetching of resources, Webhooks, request forwarding, and open redirect.

Resources download

Some applications store images and other resources in the server filesystem. A SSRF occurs when the application includes a component that takes untrusted input to fetch a server resource and it does not perform security validations. Linking or embedding user profile images, as described in the example below, is a common example.

Webhooks

Webhooks are a modular way to extend the functionality of an application by including flexible and standardized “plugins.” The external site plugins (webhooks) are called after a triggering event in the origin application. For instance, a mailing service can expose a webhook that our application can use when a new user is registered so that a welcome email is sent by the mailing service. They are similar to APIs, but simpler and more standardized. Once again, the SSRF vulnerability occurs when the webhook call is formulated to include unvalidated user input.

Request forwarding

As applications gain modularity and complexity, the reliance on external services increases. Authentication is a good example. If an application simply assembles user input to build an external request to an authentication service, it is potentially introducing a SSRF vulnerability. Querying APIs are another common example. From the point of view of the API, the origin of the request is the SSRF-compromised server, which opens the door to abuse.

File processing

Some applications accept and process URLs located in files uploaded to the server, including configuration files, scripts, and import-export formats. This leads to SSRF. In combination with other risks such as XXE or open redirects and forwards, file processing is one of the most common features that constitute SSRF vectors.

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 and CapitalOne breach

The CapitalOne breach in 2019 is one of the most well known and damaging cases of SSRF. It led to the disclosure of over 100 million client records. Like many other high-exposure cases, the root cause of the breach is a combination of risky practices and bugs. In any case, SSRF was one of the key vulnerabilities behind the breach.

The CapitalOne AWS SSRF vulnerability allowed the attacker to obtain AWS credentials using the application server itself as a “jumping stone”, because AWS allows the application to obtain its own metadata. After obtaining the credentials, the attacker simply exfiltrated the stolen data likely using the AWS management infrastructure, such as CLI and E3 storage.

The CapitalOne breach is relevant because the application WAF (ModSecurity) was unable to identify and block the attack. It is not clear whether a WAF bypass was used, or simply the WAF was turned off. This common condition highlights the importance of adopting self-protecting behaviors, with no dependence on perimeter defenses. Additionally, the access roles were too permissive, which represents an additional security misconfiguration 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.