Server-Side Request Forgery (SSRF) is a common and dangerous web vulnerability that allows an attacker to make the server perform unintended requests. These requests can often access internal services, local files, or protected resources that are not normally exposed to external users.

In this blog post, I'll walk through how I solved a Hackerwise lab that contains an SSRF vulnerability in a PHP-based web application. The objective of the lab was simple: exploit the SSRF vulnerability to retrieve the server's hostname.

Let's go step by step through the entire process.

Understanding the Lab Objective

The lab states that the application contains a Server-Side Request Forgery (SSRF) vulnerability in a URL parameter. The goal is to exploit this vulnerability and retrieve the server's hostname.

In many SSRF scenarios, the vulnerable parameter allows the application to fetch external resources such as images, APIs, or files. If the server does not properly validate the input URL, attackers may be able to force the server to access internal resources or local files.

This is exactly what we are going to do.

Step 1: Analyzing the Web Application Requests

The first step was to open the lab application in the browser and start analyzing the network traffic.

I opened the Developer Tools in the browser and navigated to the Network tab to observe all the requests made by the application.

While inspecting the requests, I noticed something interesting.

The application was making multiple requests to fetch images, and these requests contained a parameter called url.

Example request pattern:

/fetch.php?url=<image_url>

After carefully observing the network tab, I found that five different image requests were being made using this parameter. This immediately suggested that the server was fetching resources based on the user-controlled URL parameter, which is a common indicator of an SSRF vulnerability.

Step 2: Testing the Parameter for SSRF

Once I identified the potentially vulnerable parameter, the next step was to test it for SSRF.

To do this, I used Burp Suite, which is a popular tool for intercepting and modifying HTTP requests.

First, I enabled the proxy in Burp Suite and intercepted one of the image requests made by the application. After capturing the request, I sent it to the Repeater so that I could manually modify and resend the request multiple times.

The intercepted request looked similar to this:

GET /fetch.php?url=https://example.com/image.jpg

Since SSRF vulnerabilities sometimes allow access to local files, I decided to test whether the application could read files from the server.

Step 3: Attempting to Read Local Files

A common file that attackers try to access during SSRF testing is the Linux system file:

/etc/passwd

This file contains user account information and is often used as a quick test to confirm whether local file access is possible.

I modified the request in Burp Repeater to the following:

GET /fetch.php?url=../../../../etc/passwd

When I sent the request, the response successfully returned the contents of the file. This confirmed that the application was vulnerable and that it allowed reading local files using the file:// protocol.

This was a strong indication that the SSRF vulnerability could be used for Local File Inclusion via SSRF.

Step 4: Exploring Other Local Files

After confirming the vulnerability, I continued testing other files that might contain useful information.

One of the files I tested next was:

/etc/hosts

I modified the request as follows:

GET /fetch.php?url=../../../../etc/hosts

The response revealed entries including:

• debian
• localhost

At first, I assumed that one of these values might be the required hostname. However, when I submitted them as answers in the lab, they turned out to be incorrect.

So I needed to dig a little deeper.

Step 5: Finding the Actual Hostname

On Linux systems, the actual hostname of the machine is typically stored in the following file:

/etc/hostname

So I modified the request again in Burp Repeater:

GET /fetch.php?url=file:///etc/hostname

This time, the response returned the server's hostname, which was exactly the value required to solve the lab.

Key Takeaways

This lab highlights several important lessons about SSRF vulnerabilities:

1. User-controlled URL parameters are dangerous If an application fetches resources using user input without proper validation, it may allow attackers to access unintended resources.

2. SSRF can lead to local file disclosure Using protocols like file://, attackers may be able to read sensitive files from the server.

3. Enumeration is important Finding the correct file often requires testing multiple common system files such as:

• /etc/passwd
• /etc/hosts
• /etc/hostname

Conclusion

In this lab, we successfully exploited an SSRF vulnerability in a PHP-based web application to retrieve the server's hostname. By analyzing the network traffic, identifying a vulnerable parameter, and using Burp Suite to manipulate requests, we were able to access sensitive files on the server.

This exercise demonstrates how powerful SSRF vulnerabilities can be and why developers must implement strict input validation and allowlists when dealing with URL-based requests.