This article was originally published at stackzero.net/ssrf-introduction

Server-side request forgery (SSRF) is a type of web application vulnerability that allows an attacker to send a crafted request from a vulnerable web application to an arbitrary destination. This can include internal systems, such as a database server or a file server.

The vulnerability occurs when the web application takes an unsanitized user-supplied input and uses it to build a request.
In this way is possible to craft a malicious request and force the vulnerable server to send it.

For example, imagine a web application that:

• takes a URL as an input

• displays the content of the associated web page.

Suppose the web application does not properly validate or sanitize the user input. In that case, an attacker could enter a URL that points to an internal system and then retrieve sensitive information.

SSRF VS CSRF in a nutshell:

What is the difference between SSRF and CSRF?

• CSRF: the target is a user/client and he has to perform some actions, to become a victim. The vulnerability does not depend directly on him, but on the server hosting a potentially vulnerable application.

• SSRF: a hacker can use the application itself to send malicious requests from a trusted domain. In this case, the vulnerability does not depend on external factors but directly on the application’s code.

Server-Side Request Forgery attack by example

In this short hands-on, we will perform a very simple exploit on a badly coded server. This is not a real situation but can help a lot to understand the vulnerability.

What I’m going to do is prepare our Kali Machine in VirtualBox in a way that we have two servers running:

• The first one is the vulnerable application (inside the project’s main directory).

• The second one is a server that shows the content of a secret directory and is only visible from localhost (runs inside a secret directory).

Now let’s create our directories and create the following structure in your lab:

If you have doubts you can find the whole code in the GitHub repository.

The SSRF-vulnerable server

Before writing the code of the vulnerable server we need the IP address, so let’s type on a terminal:

ifconfig

After taking the IP we can write the code of a vulnerable application.
For example, if it was 192.168.1.116 this will be the related code to run a server in LAN on port 8000.

from flask import Flask, request
import requests


app = Flask(__name__)

my_ip = '192.168.1.116'

@app.route("/")
def index():
    url = request.args.get("url")
    response = requests.get(url)
    return response.text


if __name__ == "__main__":
    app.run(host=my_ip, port=8000)

Let’s comment a bit on this code, even if it’s self-explanatory.

This application has a single endpoint that takes a URL as a query parameter and makes a GET request to that URL using the requests library. The response from the request is then returned to the user.

In this way, we can force the webserver to show us what it can see, even if we don’t have the rights.

We can run the application by typing in our terminal:

python vulnerable_application.py

If you don’t have flask installed, you should do it with the command:

pip install flask

The vulnerability in this application is that it allows an attacker to craft a URL that points to an internal service but let’s see how to do it.

The Internal Service

I want to make this introduction as simple as possible, so to run an internal service I’m going to use a python internal module: http.server.
We want to run it on localhost on port 8888:

1. Open a terminal or command prompt.

2. Navigate to the directory “supersecretdir” that contains the flag.

3. Type the following command to start the server:

python -m http.server 8888

Exploit SSRF

It’s time to exploit, and if everything is clear, you could do it autonomously. However, I’m going to show the steps:

• Move on your host machine

• Open the browser

• Try to connect to this URL: http://192.168.1.116:8000?url=http://localhost:8888

And that’s what we get!

So we got access to an internal server that we couldn’t normally access!
As we expected the exploit is working fine!

Conclusion

We have seen just a simple proof of concept even though in real-world scenarios, the vulnerability could be more complex to exploit and prevent. However, I hope this article has been interesting and has provided value to those looking to learn more about Server Side Request Forgery (SSRF).

With the increasing prevalence of web applications and cloud infrastructure, it is more important than ever to be aware of the potential security vulnerabilities posed by SSRF attacks. By understanding the basics of SSRF, its impact, and how to prevent it, we can better protect our systems and data from malicious actors. Remember, prevention is always better than reaction, and by taking proactive steps towards securing our web applications, we can avoid potentially disastrous consequences down the line.

If you found this article informative, then I invite you to follow my blog for more insights on cybersecurity.
Stay up-to-date on the latest trends and techniques to protect your systems from potential threats. Don’t hesitate to leave a comment or share this article with others who may find it useful.
Thank you for reading and we look forward to seeing you on the blog!