Server - Side Request Forgery


A bug that would able to open and chain more exploits together


Introduction - What is Server - Side Request Forgery (SSRF)?


SSRF is a web security vulnerability that allows an attacker to make requests to an unintended location that is NOT open for usual users.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure.
In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.

Requirement


In order to get the best experience learning this Vulnerability, you should have basic knowledge in URL Structure


For more information: What is a URL

If you have learned this vulnerability before, why not going to solve my challenges here?

What can SSRF do?


A successful SSRF attack can often result in unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with. In some situations, the SSRF vulnerability might allow an attacker to perform arbitrary command execution.

SSRF against the server itself, but.. Internal?


In an SSRF attack against the server itself, the attacker induces the application to make an HTTP request back to the server that is hosting the application.
To be simple, let's look at this request:

 POST /product/stock HTTP/1.0
 Content-Type: application/x-www-form-urlencoded

 stockApi=http://stock.my-shop.com/product/stock/check?productId=6&storeId=1

Consider a shopping application that lets the user view whether an item is in stock in a particular store. To provide the stock information, the application must query to the back-end API with the productID and storeID information.

For the above example, the POST HTTP packet causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user.
As you known, the HTTP Request is all controlled by users, which means the whole POST HTTP packet is considered Untrusted Data.
So.. What if the attacker modifies and changes the URL that the server would request to gain stock information?

 POST /product/stock HTTP/1.0
 Content-Type: application/x-www-form-urlencoded

 stockApi=http://localhost/admin

At this point, the server will fetch the contents of the /admin endpoint and return it to the user, which can only be accessed by Internal.
From now on, the attacker can access the /admin panel and wider his / her attack.



Okay that's enough for the theory, let's experience the hacking techniques

CTFd Platform