Understanding Server-Side Request Forgery (SSRF) and How to Prevent It

Server-Side Request Forgery (SSRF) is a critical web vulnerability that allows attackers to trick a server into making unauthorized requests to unintended destinations. The prevalence of SSRF vulnerabilities and attacks has risen in recent years. 

According to a recent study by Bitdefender Labs, SSRFs are rapidly becoming very popular and commonly exploited by cybercriminals. The research performed between November 2022 and January 2023 showed that more than 100,000 organizations reported SSRF attacks over those two months, most of which were US and European companies from various industries. 

The impact of an SSRF attack can be devastating and the consequences far-reaching, from unauthorized access to sensitive internal networks to the exfiltration of critical data. An SSRF vulnerability can sometimes be a gateway to further attacks, potentially leading to system-wide compromise. 

That’s why understanding the nature of SSRF and how to prevent it is essential for any organization looking to safeguard its digital assets against this increasingly common and costly threat.

What is Server-Side Request Forgery (SSRF)?

SSRF is a web vulnerability that occurs when an attacker manipulates a server to make requests to unintended locations, often leading to unauthorized access or data exposure. In a typical SSRF attack, the attacker carefully crafts a request that the server then unwittingly executes. This allows the attacker to interact with internal systems, third-party services, or other external resources that would otherwise be inaccessible.

Unlike other vulnerabilities that target client-side components, SSRF directly exploits the server’s ability to make requests, leveraging the server’s privileged position in the network. This makes SSRF particularly dangerous, as it can be used to bypass firewalls, access sensitive information, or even take over internal services.

SSRF has been increasingly recognized as a significant threat and featured in various security guidelines, including the OWASP Top Ten—an authoritative list of the most critical web security risks.

Types of SSRF Attacks

Server-side request forgery attacks can take various forms, each with distinct methods and objectives. Understanding the different types of SSRF attacks is crucial for effectively defending against them. Here are some common types:

Basic SSRF

In a Basic SSRF attack, the attacker manipulates a server to make direct requests to internal or external services. This attack typically involves the attacker crafting a URL or other input the server uses to initiate a request. Since the request originates from the server, it often bypasses network security controls that restrict such access from outside.

For example, an attacker might exploit an SSRF vulnerability in a web application to send a request to an internal service, such as a database or an internal API. The server, believing the request to be legitimate, forwards it to the target service, potentially revealing sensitive information or allowing the attacker to perform unauthorized actions.

Basic SSRF can lead to unauthorized access to internal systems, data leakage, and even further exploitation if the attacker can chain the SSRF with other vulnerabilities.

Blind SSRF

Blind SSRF is a more challenging form of SSRF where the attacker does not receive direct feedback from the server after triggering the request. Unlike Basic SSRF, where the attacker might see the response and adjust their actions accordingly, Blind SSRF requires the attacker to infer information based on indirect clues, such as the time it takes for a request to complete or the side effects of the request.

For instance, an attacker might send requests to different internal endpoints, monitoring response times or changes in the system’s behavior to deduce whether the request was successful. Despite the lack of direct feedback, Blind SSRF can still be highly effective, particularly in reconnaissance and identifying exploitable internal services.

Blind SSRF can be used for internal network scanning, discovering sensitive endpoints, or accessing protected resources, all while leaving minimal traces.

DNS Rebinding in SSRF

DNS rebinding is a technique that can be combined with SSRF to escalate an attack further. In this scenario, the attacker first tricks the server into resolving a domain name they control. The server initially connects to an external IP address associated with the attacker’s domain. However, the attacker quickly changes the DNS resolution to point to an internal IP address within the victim’s network.

This change allows the attacker to leverage the SSRF vulnerability to interact with internal resources that are typically inaccessible from the outside. By rebinding the DNS to an internal address, the attacker can exploit the server’s trust in the domain to send requests to sensitive internal systems, potentially leading to a breach.

DNS rebinding in SSRF can enable attackers to bypass network security controls and access internal networks, posing a significant risk of data exfiltration, system compromise, and further network exploitation.

SSRF Attack Example

In 2019, Capital One, a major financial institution, suffered a significant data breach primarily caused by an SSRF vulnerability exploited by a former employee of Amazon Web Services (AWS).

The attacker exploited an SSRF vulnerability in Capital One's web application firewall (WAF), which is hosted on AWS. The flaw allowed the attacker to make unauthorized requests to the AWS metadata service, which returned sensitive credentials used to access Capital One’s cloud storage.

The breach resulted in the unauthorized access of the personal information of over 100 million customers. It cost Capital One an estimated $150 million in expenses, and the Office of the Comptroller of the Currency (OCC) fined the company $80 million for failing to establish effective risk management processes before moving its IT operations to the cloud.

How SSRF Attacks Work

SSRF attacks most commonly occur when an attacker tricks a server into requesting unintended destinations. Typically, servers are designed to send requests to external or internal services as part of their regular operation—fetching data from an API, interacting with another service, or retrieving a web resource. SSRF exploits this capability by manipulating the server to make these requests to malicious or unauthorized locations.

The attacker usually starts by injecting a crafted input—such as a URL—into a vulnerable web application. The server processes this input and then makes a request to the specified address. Suppose the server fails to validate or sanitize the input properly. In that case, the attacker can direct the request to an internal service, a local file, or an external resource under their control.

Some of the most common SSRF attack vectors include: 

• URL parameters: An attacker might manipulate a parameter that specifies a resource location (e.g., image_url=http://example.com/image.jpg) to point to a malicious or unauthorized destination.
  
  
• HTTP headers: If HTTP headers such as the Host, Referer, or X-Forwarded-For headers are improperly processed, an attacker might inject a malicious URL the server uses in a request.
  
  
• Third-party integrations: If you have third-party integrations that make server-side requests based on user input or external data, they could be exploited by SSRF if proper validation is not in place.

Typically, an attacker identifies an SSRF vulnerability in the application and then crafts a malicious payload, such as a URL or header, designed to exploit the vulnerability. This payload is carefully constructed to trick the server into requesting a target location.

The attacker then injects the payload into the application through the vulnerable parameter or input field to access internal resources, exfiltrate sensitive data, or use the SSRF as a pivot point for further attacks.

How to Prevent SSRF Attacks

Preventing SSRF attacks requires a combination of security best practices. Some of the most effective strategies to safeguard your applications against SSRF vulnerabilities include: 

Input Validation and Sanitization

Validate and sanitize all user inputs that influence server-side requests. This involves setting strict rules on what constitutes valid input, such as allowing only specific characters, data types, or URL formats. Sanitization refers to cleaning up the input by removing or encoding any potentially harmful elements, such as particular characters or scripts, before they are used in a server-side request.

This practice helps prevent attackers from injecting malicious data designed to manipulate server requests by processing only well-formed and safe inputs. 

Allowlisting

Implement strict allowlists for URLs and resources that the server can access. This means defining a list of specific, trusted URLs or IP addresses your application can interact with. The server should automatically block any request to access resources outside this predefined list.

Allowlisting ensures your application only communicates with known, safe destinations. Even if an attacker manages to manipulate a server-side request, they will be restricted to accessing only the resources you have explicitly allowed, significantly reducing the potential for harm.

Network Access Restrictions

Using firewall rules and network segmentation, limit the server’s network access to only necessary resources. Firewalls should be configured to block outbound traffic to unauthorized destinations, while network segmentation involves dividing your network into isolated segments, each with its security controls.

This practice reduces the attack surface by ensuring that even if an SSRF attack succeeds, restricting network access limits the attacker’s ability to interact with sensitive internal systems and move laterally within the network.

Request Monitoring and Logging

Implement monitoring and logging for all server-side requests, mainly external or user-supplied URLs. This includes setting up real-time alerts for unusual or suspicious activity and maintaining detailed logs that can be analyzed for patterns or anomalies.

Continuous monitoring and logging allow you to detect SSRF attacks in progress and respond promptly to mitigate their impact. The data collected through logging also helps in forensic analysis, enabling you to understand how an attack occurred and to improve your defenses against future incidents. 

Security Testing

Regularly test for SSRF vulnerabilities using automated security tools. Automated tools can quickly scan your codebase and application for known vulnerabilities.

Proactive security testing helps you identify and fix SSRF vulnerabilities before attackers can exploit them. By conducting regular assessments, you stay ahead of new and emerging threats, ensuring that your application remains secure over time. 

Prevent SSRF Attacks with Automated Security Scanning

If you need an affordable and scalable tool for code analysis to enhance your application's security, consider trying Codacy. Our code quality and security platform includes SAST features, allowing you to scan your source code for vulnerabilities such as SSRF, XSS, SQL injection, broken access control, insecure design, and other critical issues highlighted in the OWASP Top 10.

Codacy also helps you detect hard-coded secrets, such as exposed API keys, encryption keys, and passwords, that could put your application at risk.

Start your free trial today to experience Codacy’s comprehensive code security and quality features.