Server-Side Request Forgery (SSRF) is a vulnerability that targets web applications where an attacker can manipulate the server into making a malicious request.
In this post, we will provide a comprehensive guide on how to exploit SSRF step-by-step using various examples from the PortSwigger lab environments. We will walk you through the process of exploiting SSRF, demonstrate the potential impact of an attack, and provide methods to prevent it.
Earlier, “Welcome SSRF! Take a Look at the New Members of OWASP Top 10!”, we discussed in detail what SSRF is and how to prevent it.
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.
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:
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:
The Burp Suite screenshot below displays the original check stock post request:
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:
STEP #4: Now we have the user delete function URL info and SSRF vulnerability. Let’s delete the User Carlos:
After this step, the Main Application Page will be indicating that Lab is 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:
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:
The Burp Suite screenshot below displays the intruder payload configuration for the 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:
STEP #4: If we send the request to the relevant endpoint, we can see that we deleted the User Carlos:
This article may interest you: What is Endpoint Security?
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:
The Burp Suite screenshot below displays the check stock payload for the blocked stockApi parameter:
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:
STEP #3: Now we can access the admin panel and delete the User Carlos:
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:
The Burp Suite screenshot below displays the check payload for the blocked stockApi parameter:
STEP #2: After a few tries we found a payload that will allow us to bypass the filter:
STEP #3: Now we can access the admin panel and delete the User Carlos:
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:
STEP #2: After a few tries we found a valid path that will allow us to redirect:
STEP #3: Now we can access the admin panel via open redirection and delete the User Carlos:
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.
It is important to note that staying secure from SSRF attacks requires comprehensive vulnerability management.
We recommend checking out our Vulnerability Management and Penetration Testing services to stay secure. We hope you find this blog post useful and informative.
