A Server Side Request Forgery (SSRF) attack gives an attacker the ability to use your web application to send requests to other applications running on the same machine, or to other servers which can be on the same or on a remote network. Since the requests are being piggybacked via your server, the target might let its guard down, allowing requests which would otherwise not be possible from an untrusted source.

In this article, we take a deep look at two types of SSRF – Trusted SSRF and the Remote SSRF as discussed by Alexander Polyakov, and Dmitry Chastuhin at Blackhat Security (PDF).

Trusted Server Side Request Forgery

Trusted Server Side Request Forgery forges requests to predefined trusted connections through trusted links which the attacker uses to send requests from. In order to perform such an attack the attacker must either have access to the application or else to a vulnerability that can be used to perform the attack.

An example of a Trusted SSRF attack using an Oracle Database with public rights can be seen below:

SELECT * FROM myTable@HostX
EXECUTE Schema.Package.Procedure('Parameter')@HostX

The use of an Oracle trusted link enables the attacker to send requests to and receive responses from ‘Host X’. This type of SSRF attack would not raise any alerts since HostX is configured to trust connections from the Oracle database.

There are some stumbling blocks for the attack to be successful. The attacker would need to make use of reconnaissance techniques to identify the existence of Host X. The attacker would also require a trusted connection to the database, which can be achieved by exploiting other vulnerabilities such as SQL injection, and incorrectly configured access control for the database user used by the web application.

Remote Server Side Request Forgery

Remote Server Side Request Forgery allows an attacker to initiate connections and make requests to any remote server, directly from the vulnerable web application or web service. The attacker can thus use the vulnerable server to perform port scans, initiate attacks to other hosts, and perform any other type of malicious activity on other servers using the vulnerable server.

From the attacker’s point of view, this presents various advantages. These include the ability to better conceal malicious actions, the ability to use the processing power of the vulnerable server to initiate other attacks, and the possibility of using a farm of servers, which might be running the same vulnerable software, as a launch pad of a distributed attack.

SSRF attacks can be initiated through various vulnerabilities. These vulnerabilities can be classified in different groups such as the processing of an XML file format through XML External Entities (XXE). SSRF attacks can also be initiated by direct sockets access through CRLF injection, by processing URLs of a net library such as cURL or the ASP.NET URI, and by making use of links to external data in databases such as PostgreSQL.


In this article, we have seen how Server Side Request Forgery (SSRF) vulnerabilities may be used as a gateway through your firewall into your internal network or to launch attacks against third-party systems.

Acunetix Web Vulnerability Scanner can detect SSRF vulnerabilities through its AcuMonitor service. When a scan is performed on a website, Acunetix WVS will inject various payloads instructing a vulnerable server to make HTTP requests to the AcuMonitor server. Acunetix WVS will then verify if the server has indeed performed the requests as instructed. Acunetix WVS will then provide information about the HTTP request that was performed such as the IP address of the server that made the request and the page where the payload was injected.


Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.