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:
Highlight the
stockApi
parameter.Set it to :
http://192.168.0.§1§:8080/admin
Configure the payload to loop through 1 to 255.
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?