In this article, we are going to solve the SSRF with whitelist-based input filter lab. This is part 6 of the SSRF series and the labs we are practicing on are from PortSwigger Web Security.
In this lab, we have a stock check feature that allows us to fetch data from an internal system. To solve this lab, we need to access the internal system by using the stock check feature. We can access it through https://localhost/admin and then we need to delete Carlos’ account.
The developer has implemented an anti-SSRF defense which we need to bypass.
Firstly, we need to access the lab and then intercept the request by clicking on the check stock button of any product.
After intercepting the request, we need to send it to the repeater. The stockApi key will be encoded in the form, and we need to decode it for better understanding.
As you can see, when I removed the port and extra stuff from the stockApi, an internal server error occurred.
To solve this problem, I used port 8080, but it resulted in a bad request.
I then added the @ sign after port 8080 and inserted Burp Collaborator’s payload to test it.
However, even after using Burp’s payload, an error was displayed.
To resolve the error, I added a # before the @ sign, but it resulted in another error. To solve the issue, I double-encoded the value of #, which is %2523.
Now, I received the requests for DNS and HTTP in Burp Collaborator, confirming that the system is vulnerable to SSRF.
Next, I removed the Burp Collaborator’s payload and accessed localhost/admin.
When I tried to directly access localhost/admin, I received an error from the server.
I appended /admin to the end of the request, which allowed me to access the admin panel.
Finally, I executed the following command to delete Carlos’ account and successfully solved the lab.
If the above command does not work, you can try using this command: http://localhost:80%[email protected]/admin/delete?username=carlos
we have successfully solved the lab SSRF with whitelist-based input filter, Web Security.