What Is SSRF?

In an SSRF attack, the attacker typically manipulates input that is used to specify the target URL for a server-side HTTP request. This can result when an application does not validate or sanitize a URL input by a user before pulling data from a remote resource. The attacker can make the targeted server perform requests to arbitrary destinations, potentially leading to various security risks. 

These attacks can also result if the targeted resource has trust relationships with other systems, such as a cloud metadata service or backend APIs, allowing an attacker to make requests to those trusted services and extract sensitive information or perform unauthorized actions.

As modern web applications provide end-users with convenient features, fetching a URL has become a common scenario. As a result, the incidence of SSRF is increasing. Also, the severity of SSRF increases as APIs and cloud services have become more prevalent and computing architectures more de-centralized and complex.

SSRF is one of the OWASP Top 10 Application Security Risks, a widely recognized compilation of the most critical web application security risks. SSRF is also one of the OWASP Top Ten security risks that are common to both apps and APIs, and bears special consideration when implementing security solutions. 

Here's how an SSRF attack works:

• The application allows user input to determine the target URL or resource for a server-side request. This input might come from parameters in a URL, user inputs from form fields, or other data sources.
• The attacker submits a specially crafted request, manipulating the input to point to a resource the attacker wants to access or exploit. This resource could be an internal server, a backend service, an API, or other internal systems that are behind firewalls and are not accessible from the external network.
• The server processes the user's malicious input and constructs a request to the specified URL. This request is made from the server's perspective, not the user's browser, making it a server-side request.
• If the targeted server is within an internal network, the attacker may attempt to access and retrieve sensitive information from internal resources and then exfiltrate that data to an external location controlled by the attacker. SSRF can also be used to scan ports on internal systems, helping the attacker identify potential weaknesses and vulnerabilities.
• SSRF attacks are particularly concerning in cloud environments where instances might have access to sensitive metadata services.
• The impact of an SSRF attack can be severe, ranging from unauthorized access to sensitive data and services to the exploitation of internal systems and even compromise of entire cloud environments.

Here’s how an SSRF attack can play out in real life.

Imagine an unsecured web application that allows users to upload images for processing, with a feature that lets users provide a URL to an image they want to process. However, instead of providing a legitimate image URL, the attacker submits a carefully crafted input containing a malicious URL that points to an internal resource on the application server, such as an internal file or a backend database. The application server blindly processes the malicious URL, and following the attacker's input, makes a request to the internal resource specified by the URL to fetch sensitive data or query a database and return the data to the attacker.

Once the server is compromised, the attacker can also make requests to external systems, probe for vulnerabilities, or interact with services that the server has access to. The impact of an SSRF attack can vary based on the system's architecture and the permissions of the compromised server. Attacks can lead to unauthorized data access, service disruption, or compromise of internal systems.

SSRF attacks can be classified into different types based on how the attacker interacts with the server and extracts information.

In a standard SSRF attack, the attacker injects a malicious URL as part of the user input, triggering the server to make a request to the specified resource. The attacker can directly observe the response from the server and gather information about the internal network, such as how to retrieve data or identify accessible services.

In blind SSRF attacks, the attacker does not directly receive the response from the server. Instead, the attacker indirectly confirms the success or failure of the SSRF attack by observing changes in the application's behavior.

The attacker submits a crafted input, forcing the server to make a request to an external or internal resource. The attacker looks for observable changes in the application's activity, such as differences in error messages, response times, or other side effects. This information helps the attacker infer whether the SSRF was successful, even though the attacker doesn't directly see the response.

Time-based blind SSRF attacks involve exploiting delays in the server's responses to infer the success or failure of the SSRF without directly seeing the response.

As in other SSRF attacks, the attacker submits a malicious input, causing the server to make a request to an external or internal resource. The attacker observes the time it takes for the application to respond. Delays in response time may indicate that the SSRF was successful. The attacker iteratively adjusts the payload and monitors the time delays to extract information about the internal network or resources.

To protect against SSRF attacks, implement a combination of preventative cybersecurity measures including: 

• Input validation. Validate and sanitize user-supplied input rigorously, especially when the application is making requests to external resources. Implement URL allowlisting, allowing only trusted domains or specific URLs that the application needs to access. Ensure that only the expected protocols, such as http and https, are allowed and avoid allowing potentially risky protocols such as file:// or ftp://, which are often exploited in SSRF attacks. Also, validate that URLs provided by users adhere to expected patterns or formats, reducing the likelihood of injecting malicious URLs.
• Allowlists for hosts and IP addresses. Maintain an allowlist of allowed hosts and IP addresses that the application is permitted to interact with. This can help restrict requests to trusted and intended destinations, reducing the attack surface for SSRF. 
• Restrict access to internal resources. Implement network segmentation to limit the exposure of internal resources. Ensure that external-facing servers have minimal access to internal systems and services. Configure web application firewalls (WAFs) and access controls to restrict outbound connections from the application server. Only allow necessary and predefined connections and block unnecessary outbound traffic. Deploy a reverse proxy to act as an intermediary between the application and external resources. Configure the proxy to control which external resources the application can access, adding an additional layer of control.

How do these preventative measures help prevent SSRF attacks? Let’s look at a hypothetical scenario.

An online content management system allows users to input URLs to embed external images into their posts. This system processes user-supplied URLs without proper input validation. An attacker, aware of the lack of input validation, attempts to exploit the system by providing a malicious URL pointing to an internal resource, such as an internal API endpoint or a database server. However, the application’s security team enhances the system's input validation to enforce strict rules on accepted URLs. The system begins validating that the URLs provided by users adhere to expected patterns, and the team implements a whitelist of allowed domains for external resources. 

The attacker submits the post with a crafted URL intended to exploit the SSRF flaw, but the input validation now detects the malicious URL. The input validation rejects the malicious URL during processing, preventing the application from making a request to the internal resource specified by the attacker. The SSRF attack is thwarted by the enhanced input validation: The system does not allow unauthorized requests to internal resources, and the integrity and security of internal systems are preserved.

By implementing input validation, the application can reject or sanitize malicious input, preventing unauthorized requests and mitigating the risk of SSRF attacks.

SSRF attacks are dangerous because they allow attackers to bypass traditional network security measures such as firewalls and access controls to access sensitive information and resources that are typically protected within an organization's internal network and not intended to be directly accessible from the Internet. Because SSRF attacks pose significant risks to the confidentiality, integrity, and availability of both data and systems, organizations must implement robust security measures and best practices, including WAFs, proper input validation, access controls, and network segmentation, to mitigate the threat of SSRF vulnerabilities and protect against potential exploitation.

F5 WAF solutions block and mitigate a broad spectrum of risks stemming from the OWASP Top 10, including SSRF. F5 WAF solutions combine signature and behavioral protections, including threat intelligence from F5 Labs and automated security via machine learning (ML) to keep pace with emerging threats. They ease the burden and complexity of consistently securing applications across clouds, on-premises, and edge environments, and are available in a choice of deployment options. BIG-IP Advanced WAF is a robust solution that can keep your applications safe from SSRF attacks and provide a critical stopgap for software vulnerabilities, while F5 Distributed Cloud WAF secures apps everywhere with dramatically simplified operations through an easy-to-use, as-a-Service security platform.  

F5 Web Application and API Protection (WAAP) solutions defend the entirety of the modern app attack surface with comprehensive protections that include WAF, API security, L3-L7 DDoS mitigation, and bot defense against malicious automation and automated threats. The distributed platform makes it simple to deploy consistent policies and scale security across your entire estate of apps and APIs regardless of where they’re hosted, and integrate security into the API lifecycle and broader ecosystems.