Capitalizing on a server-side request forgery vulnerability, attackers target a vulnerable application’s backend server and coax it to execute malicious requests for performing unintended actions. Through SSRF attacks, hackers can infiltrate other systems connected to the webserver or target internal resources they cannot reach from outside the network. With the changing threat landscape, SSRF is listed in the tenth spot (A10) of the 2021 OWASP top ten vulnerabilities and continues to be considered a major security risk for application-owning organizations.
This article discusses the importance of server-side request forgery attacks, common approaches through which hackers exploit SSRF vulnerabilities, and their prevention techniques.
How to Prevent SSRF Attacks and Its Importance in Security
Inter-server requests are essential for web applications to access remote resources of other applications by importing metadata of the resources from the URLs. If the target URL is built using user-controllable data, a threat actor can change parameter values within the application to craft malicious requests from the backend server. Controlling server-side requests allows hackers to orchestrate a wide range of offensive pursuits on internal networks, thereby causing SSRF prevention a priority concern for organizations. The following section discusses SSRF prevention and its importance in application security.
Server-Side Request Forgery Prevention
Some standard techniques to prevent server-side request forgery attacks include:
DNS Domain Whitelisting
An ideal approach to restrict sending malicious requests from an application’s backend server for unauthorized actions is to allow access of the application to the required external entities by creating a domain whitelist. Whitelisting offers a trusted approach for ensuring communication with allowed DNS entries and IP addresses, ensuring the system’s assets are only accessible from valid machines.
Disable Unused URL Schemas
The application should only allow the schema being used to make requests while disabling all others. Disabling unused URL schemas is an effective preventive measure against SSRF attacks as this stops attackers from exploiting URL schemas to craft malicious URLs to access backend resources. Some commonly exploited URL schemas include file://,ftp://,dict://, and gopher://. An industry best practice is to use https:// as it adds a layer of security and trust to the network, disallowing hackers from accessing resources even after gaining access to the web application.
Enforce Internal Authentication
Most web systems do not require users to authenticate for internal services like MongoDB, Memcached, ElasticSearch, Redis, etc. In the absence of appropriate authentication mechanisms, attackers may craft malicious server-side requests targeting such susceptible services. Enforcing authentication for all services, including those within the local network, is recommended to safeguard sensitive information and assets.
An application’s internal servers should be restricted from sending raw response bodies present in the request to the client. Responses sent to the client should be verified against the anticipated response to prevent leakage of response data to the attacker.
Use a Web Application Firewall
A web application firewall allows developers to implement policies for the external resources the application can interact with. This enables the control of any outbound connections based on the application’s/client’s request deterring unintentional resource access. A firewall should be placed on each host, with Access Control Lists to manage inter-server communication as a recommended practice.
Why Is It Important to Secure Your Business from SSRF Vulnerabilities?
The impacts of a successful server-side request forgery attack range from mild to devastating, depending on how the target application handles responses from remote hosts. As a result, implementing preventive techniques is crucial and differs for organizations. SSRF attacks affect the vulnerable server and utilize the target system as an intermediary to pass requests to external resources/networks. The attack allows hackers to extend their reach beyond the firewall to internal systems typically inaccessible from the internet.
SSRF attacks pose various threats to application security, such as:
Abuse of Trust Between Systems – Attackers use SSRF to circumvent controls governing interactions with other systems that trust the vulnerable application. This facilitates attackers to exchange data, queries, and malicious commands across ports that are otherwise closed from public networks.
Allows for Network Enumeration – Attackers use invalid requests to extract network information from error messages, service banners, and page load time to check for open ports and service availability. By executing different combinations of invalid requests, attackers interpret the behavior of the target server and exploit application functionality.
Exposure of Files and Internal Resources – Attackers use file://, ftp://, or gopher:// URL schemas to map resources or read files from the host’s local file system.
Server-Side Request Forgery Examples
There are multiple approaches to performing SSRF exploits. A few of them are listed below:
Port Scanning Using SSRF
An open SSRF vulnerability can be exploited to port scan target application servers for gathering information about open ports and services running within the network. To do so, hackers create a set of requests to various ports on the server and analyze the response to collect information about the services running on the ports.
Assuming an e-commerce website uses the following request to get the specifications of a particular product:
Given the request mechanism through the URL, a hacker can modify the URL parameter in the request as below:
Based on the server responses, attackers infer whether or not the host 192.168.1.10 has an FTP service running on port 21. They extend sending secondary requests to the server by changing the port number request parameter to obtain a list of open ports and services running on the server.
SSRF on Localhost
Assuming the server sends the following request to obtain product details:
The attacker can manipulate the request to obtain directory and folder information of the vulnerable server:
If the server executes this request, the contents of the file /etc/passwd file are displayed, allowing unintended account access.
SSRF for Internal Access
Assuming the same application that uses the following request for product specifications:
The attacker can craft a malicious request to obtain access to internal portals:
This would let the hacker access the admin portal that can only be viewed within the network. The hacker can escalate its privileges with administrative access to extend the exploit further.
Why is blacklisting not effective prevention against SSRF attacks?
Blacklisting of IP addresses and domains is considered an ineffective defense technique as there are various bypasses that hackers may utilize to avoid the blacklist validation measures. For instance, in applications that blacklist the localhost by blocking the localhost DNS entry and IP addresses like 127.0.0.1, exploits can still be orchestrated in several ways, including:
Other blacklist bypass techniques include: altering decimal IP location, malformed URLs, address embedding, and short-handing IP addresses.
What is the difference between CSRF and SSRF vulnerabilities?
A CSRF attack targets the user to execute malicious requests on behalf of the attacker. On the other hand, an SSRF attack primarily targets the backend server to read or update internal resources from an external network.