Unmasking SSRF: The Stealthy Cyber Threat You Need to Know

What is Server Side Request Forgery (SSRF)?

Server Side Request Forgery, or SSRF, is a sneaky cyber vulnerability that happens when a hacker manipulates a web application into sending unauthorized requests from the server. This can lead to some serious consequences, such as:

Gaining access to sensitive data without permission
Breaching internal services
Performing actions that users shouldn’t be able to, like adding, deleting, or modifying data

What Causes SSRF Vulnerabilities?

Several factors can lead to SSRF vulnerabilities:

Lack of URL validation: Without proper validation, malicious URLs can slip through the cracks.
Partial URL inclusion: Sometimes, applications only include parts of a URL or hostname in request parameters. These values are then incorporated into the full URL on the server side, potentially opening up attack surfaces.
Data formats with URL specifications: Some applications transmit data in formats that allow URLs to be requested by the data parser. For example, the XML data format, commonly used in web applications to transmit structured data from the client to the server, can be vulnerable to XXE injection, which in turn can lead to SSRF vulnerabilities.

How to Detect SSRF Vulnerabilities

Detecting SSRF vulnerabilities can be achieved through several methods:

Internal server requests: If an application can be manipulated to make requests to another internal server, an SSRF vulnerability may be present.
API information retrieval: If an application retrieves information from an API, attempting to gain access through this API can reveal vulnerabilities.
Referrer header modifications: Changes to the Referrer header in outgoing requests can also help identify SSRF vulnerabilities.

Real-World Examples

Let’s dive into some practical examples using PortSwigger labs to better understand how SSRF vulnerabilities can be exploited.

Lab 1: Basic SSRF against the local server

In this lab, our goal is to delete the user ‘carlos’. We start by examining a product page and intercepting a request to check stock levels. We notice that the stock information is retrieved from an API. By modifying the stock API value to https://localhost, we receive a 200 response, indicating no protection is in place.

We then open the response in the browser and find an admin panel where we can delete the user ‘carlos’. However, we need the correct API parameters to perform the deletion. By appending delete?username=carlos to the stock API parameter, we successfully delete the user and complete the lab.

Lab 2: Basic SSRF against another back-end system

In this lab, we again aim to delete the user ‘carlos’. We intercept the API request to check stock levels and try accessing localhost:/admin, but we get a 500 error. We then use the Intruder tool to test non-routable IP addresses. By setting the API value to 192.168.0.0:8080 and configuring the payload to range from 1 to 255, we find that the IP address 192.168.0.171 returns a 200 response.

We then use this IP address to access the admin panel and delete the user ‘carlos’, completing the lab.

Lab 3: SSRF with blacklist-based input filter

In this lab, we encounter a blacklist-based input filter. We start by intercepting the API request and trying to access localhost, but we get an error. We then attempt URL encoding to bypass the filter. After several attempts, we find that using 127.1 instead of 127.0.0.1 allows us to bypass the blacklist.

We then URL encode the /admin path twice and append it to the API request, successfully accessing the admin panel and deleting the user ‘carlos’.

Lab 4: SSRF with filter bypass via open redirection vulnerability

In this lab, we exploit an open redirection vulnerability to bypass the filter. We start by intercepting the API request and trying to access localhost, but we get an error. We then use the open redirection vulnerability to redirect the request to the internal server.

By modifying the request to include the path parameter, we successfully access the admin panel and delete the user ‘carlos’, completing the lab.

Lab 5: Blind SSRF with out-of-band detection

In this lab, we use out-of-band detection to identify the SSRF vulnerability. We intercept the request to view a product and modify the Referer header to include a domain address from Burp Collaborator Client.

We then use the ‘Pull now’ button in the Collaborator Client to retrieve the requests and complete the lab.

Lab 6: SSRF with whitelist-based input filter

In this lab, we encounter a whitelist-based input filter. We start by intercepting the API request and trying to access localhost, but we get an error. We then examine the whitelist and find that certain domains are allowed.

By modifying the request to include an allowed domain, we successfully access the admin panel and delete the user ‘carlos’, completing the lab.

For more information on SSRF vulnerabilities, you can refer to the PortSwigger SSRF guide.