Server-side request forgery is a well-known vulnerability and a regular item on the Open Web Application Security Project’s list of top 10 web application security risks. Within the OWASP top ten for 2021, it received its class as A10:2021, Server-Side Request Forgery (SSRF). It was included as a separate class based on the results of a community survey.

As modern web applications get complicated and interconnected, fetching a URI has become a fundamental operation for delivering content and functionality. With the increase in server-side requests, SSRF vulnerabilities have become more common. In the meantime, their scope and impact are increasing due to the growing prevalence of cloud services and complex cloud-based application architectures, Through a compromised server, attackers can gain access to web infrastructures and cloud data sources.

What is SSRF?

In a Server-Side Request Forgery (SSRF) attack, the attacker will abuse functionality on the server to scan or update internal resources. The attacker can modify a URL that the code running on the server will read or submit information. The attacker may be able to scan server configuration, such as AWS data, connect to internal services, such as HTTP-enabled databases, or send POST requests to internal services that aren’t supposed to be exposed, by carefully selecting URLs.

The target application may have functionality for importing information from a URL, publishing data to a URL or otherwise reading data from a URL that can be tampered with. The attacker modifies the calls to the current functionality by supplying a different URL or manipulating how URLs are designed (like path traversal, etc.).

When the manipulated request goes to the server, the server-side code picks up the manipulated URL and tries to scan data to the manipulated URL. By selecting target URLs, the attacker may be able to review information from services that are not directly exposed on the internet:

Cloud server meta-data: Cloud services such as AWS provide a REST interface on http://169.254.169.254/ where important configuration and sometimes even authentication keys can be extracted.

Database HTTP interfaces: NoSQL data like MongoDB offer REST interfaces on HTTP ports. If the data is expected only to be out there internally, authentication is also disabled, and therefore the attacker can extract data from internal REST interfaces.

Files: The attacker may be able to browse files using file:// URIs. The attacker may additionally use this functionality to import untrusted information into code that expects to only browse data from trusted sources and, as such, circumvent input validation.

Types of SSRF

Based on how the victim server responds to the request, SSRF can be divided into two types:

Basic SSRF

This is the kind of SSRF in which the victim server returns data to the hacker. When they perform an SSRF attack, a hacker sends a request to a victim server. Basic SSRF is when the victim server sends back some data when the crafted request is formed. A hacker would use Basic SSRF when they wish to induce data from the server or want to access unauthorized features.

Blind SSRF

As the name indicates, during this kind of SSRF, hackers don’t get data back from the server. You see this usually when the request is to trigger some action on the victim server without returning anything to the requesting server. Hackers use this sort of SSRF when they want to form some changes using the victim server. Because they didn’t see results for the activity.

What are the potential impacts of SSRF attacks?

The direct impact of exploiting server-side request forgery vulnerability is nearly always information disclosure because attackers obtain a lot of useful information about systems and resources that should be inaccessible. The indirect consequences, on the other hand, can be devastating, because SSRF allows malicious actors to:

• Use the vulnerable server as a port and science scanner for internal and external systems
• Interact with protocols like Gopher (if enabled) to perform extra intelligence activity
• Find out what IP addresses the servers behind a reverse proxy have.
• Obtain remote code execution

Because SSRF is primarily an access channel for more probes and attacks, several alternative prospects count on how the vulnerable web application uses responses from the remote resource. Combined with alternative vulnerabilities and inappropriate conditions, SSRF can have severe consequences.

Typical exploitation of SSRF vulnerability

In a typical SSRF situation, an external attacker who wants to access an internal server can’t use direct requests because the firewall could block them. Instead, malicious actors will exploit an SSRF vulnerability to form their attack via a vulnerable web server:

• The malicious actor sends a forged request to a web server at risk of SSRF and resides on an identical internal network as the target server.
• The vulnerable web server bypasses the firewall and sends the attacker-controlled request to the victim’s server.
• The victim’s server responds to the webserver with the requested data.
• If the SSRF vulnerability permits it, the information is sent back to the attacker. In most cases, the attacker will need to exfiltrate or infer this data by alternative means (out-of-band).

Why is SSRF dangerous?

You’ve probably figured out how dangerous SSRF can be. What harm SSRF will do completely depends on the configuration of systems and the attacker’s creativity. But to give you an even better idea of its effects, here are some of the foremost common risks of SSRF.

Data exposure

Hackers use SSRF to query internal services which can only be accessed through legitimate servers. If the server is in such isolation, it’s unnecessary to mention that it contains something valuable. You would also see bastion hosts within the network to add a layer of protection. Hackers will use SSRF to bypass such restrictions and access sensitive information.

Internal recon

To decrease the attack surface from external networks, it’s a typical security practice to reduce the number of public servers. All the remainder of the servers is for internal communication. Hackers will use SSRF to learn about the internal network by running scans. This information would be useful once a hacker gets unauthorized access to the server to attack other servers in the network.

Remote code execution (RCE)

Some modern services are meant to be fully interfaced with using HTTP queries. Unrestricted management of the URL can thus let the hacker manipulate such services and lead to anything, up to and including remote code execution on the underlying server (Redis is one such famous example).

Denial-of-Service (DoS) attack

Hackers will use SSRF to send multiple requests to internal servers to eat up their bandwidth, leading to a DoS attack. The number of requests returning to the internal servers is usually less than the traffic to public servers. Hence they are configured to have less bandwidth. Apart from these common attacks, hackers will use SSRF to execute unauthorized or malicious actions, plant malware, etc. The more we know regarding such risks, the scarier it gets.

Mitigating Server-Side Request Forgery

Safelists and DNS resolution

The most robust way to avoid server-side request forgery (SSRF) is to safelist the hostname (DNS name) or IP address that your application has to access. If a safelist approach doesn’t suit you and you must rely on a blocklist, it’s vital to validate user input properly. For example, don’t permit requests to endpoints with private (non-routable) IP addresses (detailed in RFC 1918).

However, in the case of a blocklist, the proper mitigation to adopt can vary from application to application. In other words, there’s no universal fix to SSRF because it depends on application functionality and business needs.

Restrict request protocols

You usually use HTTPS or HTTP requests to servers. So, if you recognize that only these protocols are used, block requests with FTP://, Gopher:// because we know this isn’t alleged to happen. You can also block files:// to forestall attackers from accessing files. This is the same as allowing listing but focuses on the protocols used.

Disable unused URL schemas

If your application only uses HTTP or HTTPS to make requests, enable only these URL schemas. If you disable unused URL schemas, the attacker will be unable to use the web application to make requests using potentially dangerous schemas such as file:///, dict://, FTP://, and gopher://.

Response handling

You must ensure that the received response is as expected to prevent response data from being leaked to the attacker. Under no circumstances should the client be given the raw response body from the server’s request.

Authentication of internal services

By default, services like Memcached, Redis, Elasticsearch, and MongoDB don’t need authentication. An attacker will use server-side request forgery vulnerabilities to access a number of these services without any authentication. Therefore, to safeguard your sensitive information and ensure web application security, it’s best to enable authentication, even for network services.

To avoid these vulnerabilities/issues a penetration testing must be performed frequently which can be done by ThreatScan. ThreatScan’s automated engine and fully managed manual penetration test, we test over 120+ different checklists which includes owasp top 10 and additional checks designed for your web application. ThreatScan is considered to be one of the best penetration testing as a service platform in the industry.