> For the complete documentation index, see [llms.txt](https://kruknight.gitbook.io/daemon-of-hacking/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kruknight.gitbook.io/daemon-of-hacking/writeups/portswigger-labs/server-side-request-forgery-ssrf/basic-ssrf-against-the-local-server.md).
# 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.
