Basic SSRF against the local server

Lab Description

Step 1: Observing the Application

Upon accessing the lab, we're presented with a simple store page listing several products.

When we select any item, we notice a "Check Stock" button.

Naturally, our first move is to intercept the request using Burp Suite.

Step 2: Analyzing the Request

Intercepting the request reveals something interesting:

We see that the application fetches stock information from a backend service using a full URL provided by the stockApi parameter. This immediately hints at a possible SSRF, since the server is fetching the data on our behalf using a URL we can control.

Step 3: Testing for SSRF

To test this, we tamper with the stockApi parameter and set it to a different internal address:

stockApi=http://localhost/admin

After sending the modified request, we receive a valid response containing the admin panel interface. This confirms that we’ve successfully triggered an SSRF, allowing us to access internal services not normally available to external users.

Step 4: Exploiting the Admin Functionality

Following the lab’s objective, we aim to delete the carlos user. Based on the structure of the admin interface, we try the following payload:

stockApi=http://localhost/admin/delete?username=carlos

Upon submitting the request, we observe a 302 Found status code in the response—indicating that the request was processed and redirected. This behavior confirms the action succeeded.

We revisit the lab page and are greeted with a "Congratulations" message, meaning the lab has been successfully completed.

Lessons Learned

This lab illustrates a basic but impactful SSRF scenario. Let’s break down the key takeaways:

• Blind trust in user-controlled URLs (like stockApi) can lead to SSRF.

• Internal services such as localhost should never be accessible through user input.

• Proper input validation, URL whitelisting, and the use of metadata-based protections can help prevent SSRF.