TCM Security is offering free Active Directory Health Checks to any company with 10 or more employees. To inquire, please contact us.

The rapidly evolving world of cybersecurity brings with it an ever-expanding catalogue of threats. One such vulnerability, which has been gaining traction recently in the API space, is Server-Side Request Forgery (SSRF). Though it’s not a new concept, SSRF has emerged as a significant threat to web security, requiring our utmost attention. In this article, we’ll take a deep dive into SSRF, how to identify it, verify its presence, and responsibly exploit it for security testing.

What is SSRF?

Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing. Typically, SSRF vulnerabilities occur when an application receives a URL or part of it from an untrusted source and fails to validate or sanitize it.

Prefer to watch? Check out our SSRF video here https://www.youtube.com/watch?v=eVI0Ny5cZ2c

Step-by-step example

Let’s use an example of a web application with a feature that allows users to fetch images from a URL to be used as their profile picture.

chart detailing the steps to identify SSRF

Step 1: Identify the Functionality First, as an attacker, you need to find a functionality that could potentially be exploited for SSRF. In this case, you find that the web application fetches images from a URL provided by the user for their profile picture.

Step 2: Manipulate the Input The next step is to manipulate the input. Instead of a URL pointing to an image, you input an internal, non-routable IP address like

Step 3: Analyze the Response If the application throws an error or behaves abnormally (e.g., the server takes an unusually long time to respond or times out), this could be a sign that the server tried to connect to that internal IP address. This might indicate the presence of an SSRF vulnerability.

Step 4: Verify the Vulnerability To confirm, use an external server you control (for example, https://webhook.site) and put its URL in the picture URL field. If your server logs an incoming connection from the web application, this confirms the SSRF vulnerability.

Step 5: Exploit the Vulnerability Now that you’ve confirmed the SSRF vulnerability, it can be exploited to carry out malicious actions. For example, you could use this vulnerability to make requests to internal network services that are normally not accessible from the outside. As an example, if there was a database management system running on, you could potentially use the SSRF vulnerability to interact with it.

Detecting SSRF Vulnerabilities

Detecting SSRF vulnerabilities requires a keen understanding of web application behavior and architecture. Here are some methods you can use:

Input-based Discovery

Review the application for any input fields or functionality that requires an external resource fetch. Examples could be URL fields, file upload functions, or image fetch functionality. Manipulate these inputs to provoke abnormal behavior, such as entering an internal IP or localhost in a URL field.

Verifying SSRF Vulnerabilities

Once potential SSRF vulnerabilities are identified, the next step is to verify them. Here are a couple of ways you can do so:

External endpoint

To confirm SSRF, you can use an external server you control, like https://webhook.site. Send a request to your unique endpoint and if the application sends a request to it, it’s a confirmed SSRF.

Internal network scanning

If the application interacts with private, internal IP addresses, there’s a strong indication of SSRF. Try entering an internal IP or DNS, and see if the application fetches the data.

Exploiting SSRF

Fetching Internal Files

One of the most common SSRF exploits involves reading internal files. By manipulating the URL, you might gain access to sensitive information such as private keys or system files.

Bypassing Firewalls

SSRF can be used to bypass firewalls or access internal systems that aren’t directly accessible from the internet. By making requests from the server, an attacker can interact with backend systems.

Remote Code Execution (RCE)

In some instances, SSRF can lead to Remote Code Execution, especially in systems that allow URL schemas (like file:// or dict://) which can trigger certain processes.

Prevention of SSRF Attacks

Key preventive measures include validating, filtering, and/or sanitizing user inputs, employing allowlists for outbound connections, and segmenting internal networks to restrict the potential reach of an SSRF attack.

SSRF vulnerabilities serve as a potent reminder that we must always validate inputs and be careful with the capabilities we provide to web applications.