Server-side request forgery (SSRF), explained

Web applications have become one of the most important assets for companies of all sizes. And due to this, they have also become a target. Web applications are getting more complex and bigger in size. This results in an increase in the attack surface for malicious actors. Bad actors are growing more skillful every day, and they use different tools and techniques to hack web applications. In this post, we’ll focus on one attack that’s been rising in popularity: server-side request forgery (SSRF) attacks. 

SSRF attacks have a range of risks, from the potential of stealing sensitive information from the application to bringing the whole application down. These attacks are used to target systems that are behind firewalls and restrict access from non-trusted networks. Protecting your application from such attacks is critical, so we’ll also talk about SSRF mitigation techniques in this post. But before that, let’s try to understand what SSRF is and how it works. 

What is SSRF?

Modern web applications have a complex structure, and it’s common to have multiple services that constitute a web application. For example, you could have a service just to take care of payments, a service for backend and admin actions, and a client-facing service. 

SSRF is a class of vulnerability that lets you make requests from a backend server to internal or external systems. 

Let’s take an example of a web application that has three services. The first is for handling sensitive information and its transactions, the second for admin actions, and the third for user actions. Admins usually have access to sensitive data and can perform actions such as viewing, editing, or deleting said data. So when an admin wants to perform some action on sensitive data, the admin server sends a request to the server dealing with sensitive information through APIs. The server will perform those actions and send the result back to the admin server. These servers have ACLs and authorization rules configured to establish trust between them. And only trusted entities are allowed to perform actions. 

In a vulnerable setup, hackers can misuse this “trust” to craft queries in order to do something malicious. You can craft input on the admin service and send a request to the server itself on localhost or 127.0.0.1. And because the request is coming from the server itself, there’s trust by default, and the request is executed. A critical high-risk example of this is if the HTTP request to the admin server is used to fetch the /etc/passwd file. If the contents are returned, hackers can brute-force the hashed passwords. 

Another example is the Redis database whose HTTP API can be abused to query data, update the configuration, and even cause remote code execution (RCE).

Now let’s understand in depth how SSRF works. 

How SSRF works

SSRF on localhost

Let’s say you have an e-commerce website that has different servers on the backend. The application has different categories with various products in each category, and the specifications for a product are stored on a different service. So, when you click on a product, the current server (where the application is hosted) sends a request to the other server to get specifications for the product. For simplicity, let’s consider that the request is as follows: 

https://bestproducts.com/products?url=https://productspecs.com/specs?id=34

So the server is sending a request to the productspecsserver to send details for the product with id 34. When this request is made, the productspecs server will find details for that product and send it to the main server. And the main server will display the contents. This setup is vulnerable to SSRF. 

In this example of a request, hackers can manipulate the URL parameter to make malicious requests. For example, let’s say the hacker modifies the request as follows: 

https://bestproducts.com/products?url=file:///etc/passwd

If there’s no protection from SSRF and if this request is executed, then the contents of the /etc/passwd file would be displayed. This is an example where SSRF is on the server making the request. But SSRF can be used on other servers as well. Let’s look at an example of that scenario. 

SSRF on internal/external systems

Consider the same example of an e-commerce web application and its setup. Now, instead of the request to get product specifications, you can get access to the admin portal by crafting the request as follows: 

https://bestproducts.com/products?url=https://productspecs.com/admin

If this request is executed successfully, then a hacker would get access to the admin portal that’s supposed to be accessible only from the local network. Furthermore, the hacker can get access to admin actions. And, needless to say, all kinds of nefarious activity could happen if hackers got ahold of such privilege. 

SSRF for port scanning

In many network architectures, most internal servers aren’t accessible to external networks. Only trusted internal servers can access them. In such cases, if someone wants to hack the restricted internal servers, they need to find a way to find information about them from within the internal network. SSRF can be used for port scanning of such internal servers. Hackers can craft requests to different ports on the server, and based on the response, they can conclude whether there’s a service running on that particular port or not. 

Take a look at this request: 

https://bestproducts.com/products?url=192.168.1.10:21

Based on the response from the server, a hacker can understand whether the server 192.168.1.10 has an FTP service on port 21 or not. They can send multiple requests to servers by changing the port number. And from the results, they’d get a list of which ports are open and can understand which services are running on that server. 

We can keep giving examples, but then this post would never end. Your imagination is the limit on how a hacker can craft a request for an SSRF attack. You can find some more examples in this SSRF cheatsheet. 

Types of SSRF

Based on how the victim server responds to the request, SSRF can be divided into two types: 

1. Basic SSRF
2. Blind SSRF

Basic SSRF

This is the type of SSRF in which the victim server returns data to the hacker. When they perform an SSRF attack, a hacker is sending a request to a victim server. Basic SSRF is when the victim server sends back some data after the crafted request is made. A hacker would use Basic SSRF when they want to get data from the server or want to access unauthorized features. 

Blind SSRF

As the name indicates, in this type of SSRF, hackers don’t get data back from the server. You see this commonly when the request is just to trigger some action on the victim server without returning anything back to the requesting server. Hackers use this type of SSRF when they want to make some changes using the victim server. Because they needn’t see results for the activity. 

Now that we’ve covered what SSRF is and how it works, let’s get to the defense side and understand how bad SSRF can be for you. 

Why is SSRF dangerous?

While looking at the examples mentioned earlier, you probably got a pretty good idea of how harmful SSRF can be. What harm SSRF can do completely depends on the configuration of systems and the attacker’s creativity. But to give you an even better idea of its effects, here are some of the most common risks of SSRF. 

Data exposure

Hackers use SSRF to query internal services that can only be accessed through trusted servers. If the server is in such isolation, it’s needless to say that it contains something valuable. You would also see bastion hosts in the network to add an extra layer of protection. Hackers can use SSRF to bypass such restrictions and gain access to sensitive information. 

Internal recon

To decrease the attack surface from external networks, it’s a common security practice to minimize the number of public servers. All the rest of the servers are for internal communication. Hackers can use SSRF to learn about the internal network by running scans. This information would be helpful after a hacker gets unauthorized access to the server to attack other servers in the network. 

Denial-of-Service (DoS) attack

The number of requests coming to the internal servers is usually less than the traffic to public servers. Hence they’re configured to have less bandwidth. Hackers can use SSRF to send multiple requests to internal servers to eat up their bandwidth, resulting in a DoS attack. 

Apart from these common attacks, hackers can use SSRF to execute unauthorized or malicious actions, plant malware, etc. The more we know about such risks, the scarier it gets. But not to worry: you can also take measures to prevent such attacks. So let’s look at some of the most straightforward ways to add protection from SSRF. 

Remote code execution (RCE)

Some modern services are meant to be completely interfaced with using HTTP queries. Unrestricted control of the URL can thus let the hacker manipulate such services and lead to anything, up to and including remote code execution on the underlying server (Redis is one such famous example).

SSRF mitigation

Passlist and denylist

This approach is really simple. Allow only what you know is safe and block everything else. Suppose you know that the request to an internal server should be only to 192.168.1.10/productSpecs. Then allow only those requests that are going to this location. If there’s any other URL, block it. This is passlisting. 

Similarly, if you know what requests are unsafe, block all the requests having unsafe parameters. You can allow the rest of the requests. For example, if a server has nothing to do with sending a request to itself, then having “localhost” or “127.0.0.1” in the URL parameter is unsafe, so you can simply block such requests. This is denylisting. However, hackers have many tricks up their sleeves to bypass a denylist (HTTP redirections, URL obfuscation, DNS rebinding, and more). Passlisting should be preferred if at all possible.

Passlisting and denylisting are really helpful, but only when you know exactly what’s safe and what’s unsafe. On their own, they are not sufficient however.

Restrict request protocols

You generally use HTTPS, or occasionally HTTP, requests to servers. So, if you know that only these protocols are used, block requests with ftp://, gopher:// because we know this isn’t supposed to happen. You can also block file://to prevent attackers from fetching files. This is similar to allowlisting but focuses on the protocols used. 

Wrapping up

The basic prevention methods discussed in this post are a good place to begin if you’ve just started working on cybersecurity. But they aren’t enough on their own. Even after setting these mitigations, you’ll have to continuously monitor your traffic and figure out how it can be improved. Hackers are aware of the common mitigation techniques and so they work on stealth requests. The only way to keep yourself secure is by staying ahead of the hackers in creativity and security implementations. 

If you’re interested in learning more about SSRF, check out the SSRF Reference Guide for everything you’ve ever wanted to know on the topic.

This post was written by Omkar Hiremath. Omkar is a cybersecurity analyst who is enthusiastic about cybersecurity, ethical hacking, data science, and Python. He’s a part time bug bounty hunter and is keenly interested in vulnerability and malware analysis.