SSRF with blacklist based input filter

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.

The developer has deployed two weak anti-SSRF defenses that you will need to bypass.

Approach

Upon accessing the lab, I immediately delved into exploring the "check the stock" functionality. Notably, this feature triggered a POST request to /product/stock, with a crucial parameter named stockApi, designed to fetch data from an external URL.

POST /product/stock HTTP/2
Host: 0a04000303895e29810d9d3900a70039.web-security-academy.net
Cookie: session=xLRHDABB5bpvMJlpuCXrIFIFrwpepLWG
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://0a04000303895e29810d9d3900a70039.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 107
Origin: https://0a04000303895e29810d9d3900a70039.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

My initial attempt to manipulate the stockApi parameter, substituting it with http://localhost/admin, was met with an error message stating "External stock check blocked for security reasons." Given the lab's challenge description mentioning two weak anti-SSRF defenses, I speculated that the first defense targeted the IP address or domain part of the URL, which in this case was "localhost". I then proceeded to explore various manipulations, including formatting changes such as:

• 2130706433

• 017700000001

• 0177.0.0.1

• 127.1

Remarkably, using 127.1 bypassed the first check, as indicated by the 200 status code received and the visible webpage.

Moving to bypass the second part, the endpoint /admin, I discovered a simple case variation would suffice. By changing /admin to /Admin, I successfully accessed the admin panel.

However, my endeavor to delete the user "Carlos" was thwarted by my lack of admin privileges, discerned from the session cookie.

Nonetheless, armed with access to the admin panel, I recognized an opportunity to exploit the situation by employing Server-Side Request Forgery (SSRF). Crafting a request to delete the "Carlos" user through SSRF, I successfully executed the action, ultimately solving the lab.

This meticulous approach enabled me to overcome the lab's challenges and accomplish the task at hand.