How it works

A sample application is demonstrated to explain the concept of how Server Side Request Forgery (SSRF) vulnerability works and the mitigation measures which needs to be taken by the developer.

For the sample application to work, your system should have docker installed. The guide to install the same can be found on Docker Installation.

Run the vulnerable projectasuras/ssrf application using docker (the application runs on port 5000):

docker run --rm -p5000:5000 --name ssrf projectasuras/ssrf

Note: Docker image version shown in the guide is v1.0.0.

Now, navigate to http://127.0.0.1:5000 to access the application’s web portal.

The demonstration application is a weather fetching application for some of the locations across the globe. Let’s click on Berlin or open the following URL endpoint to fetch Berlin’s weather.

http://127.0.0.1:5000/weather?url=https://goweather.xyz/weather/Berlin&country=Berlin

If you may have noticed the URL endpoint, the website is trying to make access to a third party website named goweather.xyz to fetch the weather information of the location.

Question

Cannot we change the location altogether to something not related to weather application?

Let’s change the value of url to a different website other than goweather.xyz, what can be a better page than projectasuras.com.

http://127.0.0.1:5000/weather?url=https://projectasuras.com

The HTML code of the projectasuras main website is returned by the sample application. One may wonder that we are able to access projectasuras.com. Can we access other locally hosted website within the application?

Let’s try to access website hosted at port 80 i.e. http://127.0.0.1:80

http://127.0.0.1:5000/weather?url=http://127.0.0.1:80

There is indeed a service running at port 80 and the directory listing of the service is displayed containing a file named flag.txt.

Todo

Can you get hands on access to flag.txt file hosted at web server on port 80?

In this exercise, we have demonstrated a simple SSRF vulnerable web application.

Note

Many a times, a web page is not rendered for the user but internally a server performs a HTTP request on the user’s behalf. There are various ways in which an attacker can validate whether the web application is making a HTTP request internally or not, by using, BurpSuite Collaborator, InteractSH client, DNSlog etc.

In the next part of the series, we will try to mitigate this vulnerability.