How to Detect and Exploit Server-Side Request Forgery (SSRF)

The rapidly evolving world of cybersecurity brings with it an ever-expanding catalog 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 application security, requiring our utmost attention. In this article, we’ll take a deep dive into SSRF, including how to identify it, verify its presence, and responsibly exploit it for security testing.

What is Server-Side Request Forgery or 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 video on SSRF exploits:

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. We can follow a simple five step process to find out if this is a valid target for an SSRF attack.

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 http://192.168.0.1.

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 http://192.168.0.2:8080, 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.

Input-Based Discovery

When using input-based discovery methods, you 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. You can use these findings to determine if there is an SSRF vulnerability.

Are you interested in reaching our community of security professionals? Fill out our sponsorship form to learn more about advertising opportunities with TCM Security.

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

Once you have identified and validated that SSRF vulnerabilities exist, you can begin to exploit them. Some of the most common SSRF exploits include: 

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.

Conclusion

Server-side request forgery is just one way that web applications can be exploited. If you are interested in learning more about web app vulnerabilities, the TCM Security Academy offers several courses on web app hacking including Practical Bug Bounty, Practical API Hacking, and Practical Web Hacking. 

Tune into Alex Olsen’s stream this Wednesday, June 5th to learn more about our latest web app penetration testing certification- the Practical Web Penetration Tester (PWPT). In addition, you can visit our YouTube channel for free resources and join our email list to stay up to date with new offerings.