Description
Server Side Request Forgery (SSRF) is a malicious web attack that enables an attacker to manipulate a server into making unintended HTTP requests to internal or external resources. In an SSRF attack, the attacker tricks the server into sending requests on their behalf, potentially accessing sensitive information or services that were never meant to be exposed to the public internet. This type of vulnerability can have serious consequences, as it may lead to data leaks, unauthorized access, and even the complete compromise of a system’s security. It is essential for web developers and administrators to be vigilant and employ security measures to prevent and mitigate the risks associated with SSRF attacks.
Example
Let’s explore an example of SSRF in action. I highly recommend checking out the PortSwigger Academy lab, which provides an excellent demonstration of this type of attack.
Suppose we have an application that acts as an online store. The objective of this lab is to find a way to gain access to the /admin panel and delete the user named carlos.
When attempting to access /admin, the server returns a message indicating that this page is reserved for administrators.
While browsing the application, I noticed that when clicking on a product, there was a button called “Check Stock.” After clicking the button, the application returned the number of items in stock for that product.
In Burp Suite, I examined the request made when checking stock. It passes a URL to stockApi, which decodes to http://stock.weliketoshop.net:8080/product/stock/check?productId=3&storeId=1.
This application is making a request to another URL to fetch information. This presents a potential SSRF vulnerability, as applications sometimes behave differently when accessed internally.
To test for SSRF, I changed the URL to http://localhost/admin and URL-encoded it. Upon submitting the request, the server successfully accessed the Admin panel and displayed a URL leading to /admin/delete?username=. This is a page where any user can be deleted!
Using the stockApi, I submitted another request by injecting http://127.0.0.1/admin/delete?username=carlos, successfully completing the lab.
