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
stockApiparameter.Set it to :
http://192.168.0.§1§:8080/adminConfigure 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=carlosUpon 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?