A Complete Guide To Server-Side Request Forgery (SSRF)

November 10, 2021



We have talked in detail about what Server-Side Request Forgery (SSRF) is and how to prevent an SSRF attack in our “Welcome SSRF! Take a Look at the New Members of OWASP Top 10!” blog post earlier.

This post will show how to exploit SSRF step-by-step with example cases used in lab environments from the PortSwigger

How Does an SSRF Attack Take Place?

In summary, the user sends the HTTP request to the application and the application sends the request to the relevant server. In return, the server sends the response to the application and the application presents a response to the user.

What if the user can control the request which is sent by the application? This is where the Server-Side Request Forgery (SSRF) rises.

The illustration shows how an SSRF attack takes place.

Common SSRF Attacks

1. SSRF Attacks Against the Server Itself

In this type of SSRF attack, the application requests the server that is already hosting the application itself.

CONDITION: To solve the lab, we need to access the admin panel and delete User Carlos.

STEP #1: We are looking for application functionalities for finding the SSRF vulnerable endpoint. You can see the Main Application Page below indicating that Lab is not solved:

Main application page - Lab Not Solved

STEP #2: We found a check stock function by making API calls in the post request body. You may see the Check Stock Function page below:

Check stock function page

The Burp Suite screenshot below displays the original check stock post request:

Burp Suite screenshot displaying the check stock post request (original)

STEP #3: In the screenshot below, we are changing the “stockApi” parameter value to http://127.0.0.1 and trying to reach the admin panel through the localhost. As we can see, the admin panel delete function URL is reflected in the response:

Burp Suite screenshot displaying the check stock post request for admin panel

STEP #4: Now we have the user delete function URL info and SSRF vulnerability. Let’s delete the User Carlos:

Burp Suite screenshot displaying the check stock post request for deleting the User Carlos

After this step, the Main Application Page will be indicating that Lab is solved:

Main application page - Lab Solved

2. SSRF Attacks Against Other Back-End Systems

Another type of SSRF attack is where the application server can interact with other back-end systems that are not directly reachable by users. These systems often have non-routable private IP addresses.

CONDITION: To solve the lab, we need to access the admin panel through a non-routable private IP address and delete the User Carlos.

STEP #1: We changed the same check stock parameter value to private IP in the HTTP POST request and reviewed the response. The Burp Suite screenshot below displays the original check stock post request:

Burp Suite screenshot displaying the check stock post request (original)

STEP #2: In this step, we are trying to learn which private IP is valid. We can use Intruder for this step. We are choosing only the last octet of IP addresses and setting the payload options as in the image below:

Burp Suite screenshot displaying the intruder payload position for check stock post request

The Burp Suite screenshot below displays the intruder payload configuration for the check stock post request:

Burp Suite screenshot displaying the intruder payload configuration for check stock post request

STEP #3: After finishing the intruder attack, we can see the valid private IP and the URL for deleting the User Carlos:

Burp Suite screenshot displaying the intruder attack results

STEP #4: If we send the request to the relevant endpoint, we can see that we deleted the User Carlos:

Burp Suite screenshot displaying the check stock post request for deleting the User Carlos

Circumventing Common SSRF Defenses

1. SSRF With Blacklist-Based Input Filters

This type of SSRF attack has a blacklist that sanitizes, deletes, or rejects the inputs according to the blacklist. However, the attackers can bypass the blacklist filters with various methods.

CONDITION: To solve the lab, we need to access the admin panel and delete the User Carlos.

STEP #1: As we can see in the previous examples, the first step is inspecting the different requests and responses. We found the check stock function. We noticed that some inputs were rejected by the server: 

Burp Suite screenshot displaying the check stock post request (original)

The Burp Suite screenshot below displays the check stock payload for the blocked stockApi parameter:

Burp Suite screenshot displaying the Check stock payload for stockApi parameter (blocked)

STEP #2: After a few tries we found a payload that will allow us to bypass the filter. The Burp Suite screenshot below displaying the check stock payload for bypassed stockApi parameter:

Burp Suite screenshot displaying the check stock payload for stockApi parameter (bypassed).

STEP #3: Now we can access the admin panel and delete the User Carlos:

Burp Suite screenshot displaying the check stock post request for deleting user.

2. SSRF With Whitelist-Based Input Filters

This type of SSRF attack is similar to the blacklist type attacks but whitelist attacks only allow input that matches, begins with, or contains a whitelist of permitted values.

CONDITION: To solve the lab, access the admin panel and delete the User Carlos.

STEP #1: The first step is finding the endpoint as always. We can see the error message in the HTTP response body. The Burp Suite screenshot below displays the original check stock post request:

Burp Suite screenshot displaying the check stock post request (original)

The Burp Suite screenshot below displays the check payload for the blocked stockApi parameter:

Burp Suite screenshot displaying the check payload for stockApi parameter (blocked)

STEP #2: After a few tries we found a payload that will allow us to bypass the filter:

Burp Suite screenshot displaying the check stock post request (bypassed)

STEP #3: Now we can access the admin panel and delete the User Carlos:

Burp Suite screenshot displaying the check stock post request for deleting the user

3. Bypassing SSRF Filters via Open Redirection

In this type of SSRF attack, the attacker cannot access the internal services directly. However, the attacker can add redirection to the SSRF endpoint URL and redirect the second service to the internal service.

CONDITION: To solve the lab, access the admin panel and delete the User Carlos.

STEP #1: We are trying to find a valid endpoint for the SSRF attack. After a little walking in the application, we found an endpoint that has a redirection path parameter. We are inspecting the endpoint URL, adding a path parameter, and feeding the stock check function with this URL for the redirection:

Burp Suite screenshot displaying the GET request with path variable for redirection

STEP #2: After a few tries we found a valid path that will allow us to redirect:

Burp Suite screenshot displaying the check stock post request with path variable for redirection

STEP #3: Now we can access the admin panel via open redirection and delete the User Carlos:

Burp Suite screenshot displaying the check stock post request for deleting the user.

In this blog post, we have explored various example cases to exploit for SSRF attacks. We have talked about different types of common SSRF attacks and circumventing common SSRF defenses. Hope you find it useful!