Server-side request forgery (SSRF)

What is Server-side request forgery (SSRF)?

SSRF is a type of exploit where an attacker can abuse some functionality of a web server, making it access or manipulate information on behalf of that server. In other words, it is possible to make HTTP/HTTPS requests to the desired location using the exploited application. The most basic example of that would be using SSRF to make server-side requests to the admin panel, thus opening access to it to an unauthorized user.

Applications and consequences of SSRF

A successful SSRF attack can easily result in unauthorized actions or access to data that should not be accessible to a normal (client) user. In some cases, it is possible to transform the server-side request forgery into fully-functional remote code execution (RCE).

So, as you might have guessed by this point, finding SSRF on a server is extremely dangerous and can be turned into a good bug bounty report. SSRF has earned over $2.9 million to people finding it according to HackerOne.

Types of SSRF attacks

Open SSRF

In this type of server-side request forgery, the attacker will be able to see the output directly in the exploited application. This is the best possible outcome since there's no need to do anything, rather than start exploiting directly.

Let's take a look at an example of an open SSRF attack and allow ourselves to see an admin panel without being logged in as administrators. Free lab link: https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost

The goal of this lab is to access the /admin panel and delete user carlos, by exploiting an SSRF vulnerability in the stock checking feature.

The website itself is a simple shop that has a list of products and the login page:

Going to /admin gives us the following error message:

Since we don't know the login or password for the admin user, all we can do is exploit the SSRF in the stock checking feature. Click on any product and intercept a stock checking request using Burp Suite. Send it to the Repeater using Ctrl+R. You should see a similar result:

The stock checking feature is sending a POST request to the stock checking API, where the product number is encoded in the stockApi variable. If you decode the value of this variable, you'll get:

http://stock.weliketoshop.net:8080/product/stock/check?productId=1&storeId=2

This immediately tells you that the back-end server is making a request to this address, indicating a potential SSRF vulnerability. What we can do now is change that link to http://localhost/ and encode it as URL.

The following request outputs the main page's code, even though this feature was supposed to be checking for stock information. After finishing identifying the SSRF, we can start making requests to any location we want by simply encoding it as URL and putting them to stockApi. Our next target will be http://localhost/admin.

Just like that we are able access the admin panel. As you can see, in order to delete user carlos, we need to make a request to /admin/delete?username=carlos. Do that and you'll see a nice banner congratulating your success in exploiting SSRF.

Just as easy as that, we were able to access information we were not supposed to see. In addition to that, we also performed an admin-level action: deleting a user.

Blind SSRF

Blind SSRF is by far the most common and hardest type of this vulnerability. In blind situation we are not able to see the output, like we did in open SSRF. That implies that it is a bit harder to identify a SSRF vulnerability, since we most likely to assume that no output = not vulnerable. Let's see how this claim can be proven wrong.

The easiest and most reliable way to detect blind SSRF vulnerability is sending an HTTP request to an external system that you control and able to monitor. In other words, you should try sending those requests to your own server and see if the request reaches it. Let's see that in practice here: https://portswigger.net/web-security/ssrf/blind/lab-out-of-band-detection

Here we see a website with nothing but the products. We don't even see the stock feature here. That's because this lab is oriented on exploiting the referrer HTTP header. Generally speaking, the referer request header contains the address of the page making the request.

Visit any product page and intercept that request using Burp Suite. Use the Repeater again for ease of operation.

In this request, the referrer header is set to be the website itself, meaning that the application is making an internal request to itself. Changing the referrer to http://localhost/ or http://localhost/admin does not make any change in the response, making us think that it is not vulnerable to SSRF. The way we can see the vulnerability is by setting an external server as a referrer. If you have Burp Suite Pro, you can launch a burpcollaborator interface and get a unique address that you can use to send requests to.

Burp Suite Free users can simply make requests to http://burpcollaborator.net in order to solve the lab. If you see a banner on the main page, that means that the server has made a request to an external source and you have successfully exploited the blind SSRF.

Bypassing SSRF blacklisting

We also need to understand that many developers are aware of SSRF and can sometimes set up blacklisting to avoid these kind of vulnerabilities. What you should do is always try bypassing the blacklist by these 3 simple methods:

• Writing the 127.0.0.1 differently, for example, 2130706433, 017700000001, or **127.1**.

• Use your own domain name that resolves to 127.0.0.1. Use xxxxxxxx.burpcollaborator.net if you have Burp Suite Pro.

• Obfuscating URL or inventing your own methods.

Afterword

SSRF seems like a pretty easy vulnerability to exploit. The hardest part is that you will most likely see more blind SSRF than open in the wild. So keep an eye on that and never give up if you receive no expected output.

Featured picture credit: PortSwigger Web Academy