Basic SSRF against another back-end

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.

Intercepting the request reveals something interesting:

We see that the application fetches stock information from a backend service using a full URL with IP provided by the stockApi parameter. This tells us the stock check feature makes a server-side request to the URL provided in the stockApi parameter. Since we can fully control this URL, this is a strong SSRF indicator.

http://192.168.0.1:8080/product/stock/check?productId=1&storeId=1

Step 3: Scanning for the Internal Admin Interface

The lab's objective says there's an internal admin interface located somewhere in the 192.168.0.X range on port 8080. But we don’t know the exact IP.

So we perform a basic internal scan using Burp Intruder:

  1. Highlight the stockApi parameter.

  2. Set it to : http://192.168.0.§1§:8080/admin

  3. Configure the payload to loop through 1 to 255.

  4. Start the attack and look at the status codes in the responses.

After it's done we can find that we got 200 status code from payload 101

This tells us the internal admin panel is located at:

http://192.168.0.101:8080/admin

Step 4: Deleting the Carlos User

Now that we’ve located the admin panel, we try to interact with it directly via SSRF.

We modify the stockApi parameter in the request to:

stockApi=http://192.168.0.101/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.

Last updated

Was this helpful?