Server-side request forgery became one of the most discussed vulnerabilities in 2021 due to enormous damages caused first by APT actors and later by ransomware in attacks against Microsoft Exchange servers.

Do you want to have an in-depth understanding of all modern aspects of
Server-Side Request Forgery (SSRF)?
Read this article and bookmark it to get back later, we regularly update this page.

Server-side request forgery is a vulnerability that allows an attacker to force the web application into initiating requests to other systems. It may also allow to redirect output from an external service into a local file. In such case a remote code execution is possible. A very good example of the danger that may come from a simple SSRF is an infamous set of ProxyLogon vulnerabilities: CVE-2021-26855, CVE-2021-27065, CVE-2021-26857, and CVE-2021-26858.

A total of 400,000 Internet-connected Exchange servers were impacted by the ProxyLogon vulnerabilities when Microsoft issued the initial security patches

In 2021 OWASP has added SSRF into its TOP 10 list of most popular vulnerabilities in web applications.

What is SSRF?

SSRF or Server-side request forgery (CWE-918) allows an attacker to force the vulnerable application to send requests to local or remote systems. This means that the request is sent by the affected application itself with the privileges of the very application.

The vulnerability is caused by absent or insufficient filtration of attacker-supplied input that is used by the application to initiate a connection with a third-party. This could be features that are used to import information from a specific URL, to connect to a NoSQL database via RestAPI endpoint, work with files locally or remotely, etc.

What can be done with SSRF?

Usually, the attacker can read responses sent from the initial request. This can be used to perform a port scan of your internal network or the localhost, send requests to your database backend, access your external cloud services providers to obtain tokens, or read local files.

In combination of other application features or additional vulnerabilities it might be possible to write files to the server.

Example

A great example for Server-side request forgery is the recent vulnerability in Apache Solr known as CVE-2021-27905.

The affected component is ReplicationHandler, usually accessible via the /replication URI under the Apache Solr core. Purpose of the ReplicationHandler is to replicate data to another Solr core. It uses masterUrl parameter to connect to another instance for replication.

The PoC-code for such a request looks like this:

 http://[host]/solr/{core_name}/replication/?command=fetchindex&masterUrl={arbitrary URL} 

With the response, indicating a successful connection:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">24</int>
</lst>
<str name="status">OK</str>
</response>

This vulnerability can be used to send HTTP requests to arbitrary internal or external host.

Solution

The best way to protect your web application against SSRF is not send any requests to external systems. However, this is not always possible, especially if this is an application feature.

General recommendations to protect against SSRF in the functionality that is intended to send requests:

Do not allow application send requests to resources that are located on internal IP addresses or localhost.
Do not allow application send requests to resources that belong to your infrastructure or your cloud providers.
Do not allow attackers control over file names, if the application works with files.
Do not allow attackers use protocols other than expected, e.g. if the application is supposed to access contents of websites, allow only URLs that start with “https://”.

To know more about SSRF and its exploitation vectors, please read our article: https://www.immuniweb.com/vulnerability/ssrf.html