Server-Side Request Forgery: Impact, Examples & Defenses


What Is Server-Side Request Forgery (SSRF)?

Server-side request forgery (SSRF) is a security vulnerability that allows attackers to send crafted requests from the server on behalf of it. This typically targets internal systems behind a firewall that are otherwise not reachable by external actors.

The primary danger of SSRF is that it can be used to manipulate the server to carry out unintended actions, potentially accessing sensitive internal resources. Vulnerable systems allow attackers to bypass network security measures such as firewalls and execute requests that an external entity should not make.

SSRF exploits the server's connection capabilities, allowing malicious actors to interact with its network or external services. Attackers may enumerate open ports, access cloud metadata endpoints, or exfiltrate data. By exploiting SSRF, unauthorized requests are initiated from the server, masquerading as legitimate internal traffic. This vulnerability can lead to exposure and manipulation of critical data or services, severely impacting security and operational integrity.

This is part of a series of articles about API security

In this article:

How SSRF Vulnerabilities Work

SSRF attacks exploit server functionality that processes URLs or connections, often through web applications that fail to properly validate user input. Attackers can manipulate parameters within the application to send crafted requests to a server. These manipulated requests direct the server to interact with internal or external systems in ways that compromise its confidentiality or integrity. Such server-side code execution enables attackers to pivot from accessible systems into more secure areas, exploiting trust boundaries set in corporate networks.

The mechanics rely on abusing HTTP or similar protocols where the server might inadvertently forward unauthorized requests. When user inputs aren't sanitized, malicious actors craft URLs pointing to internal resources, bypassing security controls. Successful SSRF exploitation enables attackers to bypass boundary protections, carrying out unapproved interactions such as accessing restricted network segments or conducting reconnaissance on internal components.

Impact of SSRF Attacks

Here are some of the negative effects an SSRF attack can have on an organization:

Unauthorized Access to Internal Systems

SSRF attacks can lead to unauthorized access to internal systems that are otherwise protected from direct interaction. By leveraging the server's trust model, attackers redirect or originate requests from within the network, penetrating zones restricted by firewalls or security appliances. External adversaries gain maneuverability to probe internal infrastructure, potentially accessing configuration or sensitive data resources. Such unauthorized access undermines the organization's security posture and exposes critical system vulnerabilities.

These intrusions can facilitate lateral movement, where attackers explore network segments that hold valuable insights or control mechanisms. Internal systems, often unwatched for such indirect breaches, become entry points for deeper exploration or data extraction.

Data Exposure

Another severe impact of SSRF is data exposure, where sensitive information housed on internal systems or accessible via APIs can be leaked. Attackers use SSRF to initiate unauthorized requests to retrieve data directly or through interconnected services. These exploits can extract configuration details, cipher keys, or even personal data that backend services handle.

Data exposure through SSRF can serve as a precursor to more targeted or damaging attacks leveraging derived information. The unauthorized access not only puts proprietary data at risk but also federal regulations on data protection, leading to compliance challenges.

Denial of Service (DoS)

SSRF can also enable denial of service (DoS) attacks, where intentional requests overwhelm systems or components within the network. By leveraging SSRF, attackers target services with excessive processing demands, consuming resources and causing service disruptions. This indirect method of implementing DoS prevents legitimate traffic from being served efficiently, leading to decreased availability and potential business operation impacts.

Moreover, SSRF-based DoS can redirect resources toward undesired endpoints, intensifying unplanned server loads or accessing vulnerable services excessively to cause breakdowns. The server's role in unwillingly facilitating these demands heightens the impact, as internal servers may not be adequately configured to handle abrupt request surges.

Remote Code Execution (RCE)

In severe cases, SSRF could lead to remote code execution (RCE) when attackers manipulate requests to execute arbitrary code within the server environment. Such vulnerabilities arise when service endpoints fail to correctly validate and sanitize input, and attackers identify paths through which they can inject and run malicious payloads. This can result in total system compromise, as attackers gain the ability to execute scripts or commands on the server, often with elevated privileges.

RCE via SSRF represents a catastrophic security breach by bridging request forgery with unchecked execution capabilities. Attackers can deploy remote scripts for data exfiltration, lateral movement, or persistence within the target's infrastructure, posing long-term operational threats.

Learn more in our detailed guide to API attacks

Types of SSRF Attacks

Basic SSRF Attacks

Basic SSRF attacks involve manipulating URLs within applications to access internal addresses or external targets indirectly. Here, attackers craft URLs to deceive the server into executing requests that extend the reach of their influence. These approaches typically lead to data leaking from internal systems or unapproved actions executed by the server. Basic SSRF forms exploit the application's inadequacy in handling input data, utilizing seemingly innocuous entry points to achieve unauthorized access.

In these attacks, the core objective is to exploit an application's trust model by sending requests intended for internal resources. This manipulation might involve accessing local network resources or fixed endpoints like cloud instance metadata. Such attacks thrive in environments lacking stringent URL validations, where external inputs are trusted implicitly or regulated insufficiently.

Blind SSRF Attacks

Blind SSRF attacks occur without direct feedback to the attacker, making them more challenging to detect. These attacks aim for side effects, such as logging events or network traffic, which provide indirect confirmation of successful exploitation. Unlike standard SSRF, blind variations depend on external observation of results, such as timing discrepancies or anomalies in log entries.

Despite the lack of immediate response, blind SSRF attacks can still result in significant breaches, as their stealth allows them to covertly penetrate secure systems. Here, attackers utilize inference and timing-based side channels to discern whether their requests reach intended internal services.

SSRF via Headers and Data Formats

SSRF exploits can also target HTTP headers or rely on specific data formats to initiate server requests. By manipulating headers like the “Host” field, attackers can deceive servers into route requests in unintended directions. This method is especially potent when combined with server misconfigurations that misinterpret these headers as instructions, leading to unapproved resource interaction.

Moreover, manipulating serialized data or exploiting vulnerable deserialization processes can enable SSRF attacks. Here, attackers craft payloads in formats the application mishandles, tricking it into processing malicious data as genuine. This approach circumvents traditional input filtering mechanisms, making it a sophisticated method for executing SSRF on systems that inadequately address data validation controls.

Common Techniques Used in SSRF Exploitation with Examples

Bypassing Input Filters

Attackers often bypass input filters by encoding malicious URLs in various formats, such as hexadecimal or Unicode. Some applications only check for specific patterns in user input, like "http://" or "https://", and fail to detect encoded or obfuscated URLs, allowing attackers to circumvent the filters. For example, an input filter might block requests to internal IP addresses but fail to detect encoded forms of those addresses.

Example:

If an input filter blocks requests to http://127.0.0.1, an attacker can encode the IP in different ways, like using the decimal representation http://2130706433, and still bypass the restriction.

import requests

url = "http://2130706433" # Decimal form of 127.0.0.1

response = requests.get(url)

print(response.content)

Exploiting Open Redirections

Open redirection vulnerabilities allow attackers to trick the server into redirecting requests to unintended locations, facilitating SSRF. By manipulating redirect mechanisms, attackers can send requests to internal services or malicious endpoints. Many web applications implement redirects without verifying the final destination, leaving them open to exploitation.

Example:

A vulnerable application might redirect users based on a URL parameter. If not properly validated, attackers can use this mechanism to access internal services.

import requests

# Redirect to an internal service via open redirection

url = "http://example.com/redirect?url=http://internal-service.local"

response = requests.get(url)

print(response.content)

Leveraging Partial URLs

In some cases, attackers leverage partial URLs where the application appends missing parts of the URL, inadvertently creating SSRF opportunities. If the server automatically completes an incomplete URL provided by the user, an attacker can craft requests to internal services by leaving part of the URL blank, allowing the server to fill in the rest.

Example:

An application might allow user-provided URLs like /path/to/resource, assuming it will be appended to a safe domain. Attackers could exploit this by providing a partial URL leading to internal resources.

import requests

# Attacker provides partial URL

partial_url = "/admin" # Appended to a trusted domain internally

base_url = "http://example.com/fetch?resource="

response = requests.get(base_url + partial_url)

print(response.content)

Preventing SSRF Attacks

1. Validate and Sanitize User Input

Robust input validation and sanitization are foundational practices to prevent SSRF attacks, focusing on enforcing strict URL or input constraints. Applications must reliably filter and sanitize user-provided data to remove or neutralize potentially harmful content before processing. This technique extends to monitoring for undefined proxy usage or improper cross-site scripts that may funnel unintended input operations toward vulnerable server processes. Validations must accommodate all input formats, ensuring integrity across data inflow practices.

By implementing rigorous filters, organizations neutralize common SSRF vectors, preventing malicious input from traversing application workflows unchecked. Such measures are integral in denying adversaries the foothold necessary to exploit data blind spots or routing flaws.

2. Implement Allowlisting of Allowed Domains

Domain allowlisting provides an effective method to curb SSRF attacks by restricting server requests to predetermined trusted domains. This involves maintaining a list of trusted endpoints applications can communicate with, ensuring unauthorized destinations are never reached. Allowlisting prevents uncontrolled URL submissions from redirecting requests to malicious locations, containing communication strictly within established safe channels.

To implement domain allowlisting with efficiency, careful maintenance of allowed domain registries is essential, ensuring only necessary endpoints retain access rights. Comprehensive auditing ensures allowlisting reflects current operational needs without excess permissions.

3. Disable Unnecessary URL Schemes

Disabling unnecessary URL schemes restricts SSRF potential by ensuring only approved connection frameworks are active, narrowing attack vectors. Applications should disable URL schemes not required for their operation that could be exploited for SSRF-related redirect or unauthorized access exploits. This means rejecting unsupported protocols that may inadvertently expose server processes to external or irrelevant interactions.

By assessing URL capabilities within the web application framework, IT teams tailor configurations to include only essential connective pathways. This restriction thwarts attempts to sidestep input filtering via uncommon URL scheme usage, bolstering defense against SSRF manipulations.

4. Enforce Authentication on Internal Services

Enforcing authentication on internal services creates additional security layers against SSRF attacks by restricting access through verified identity checks. Authentication mandates ensure internal resource interactions necessitate valid credentials, thwarting unauthorized requests initiated by compromised servers.

Implementing multi-tier authentication processes for services creates barriers against impersonation, ensuring only authorized entities can fulfill sensitive requests. Employing strong authentication protocols ensures internal service accesses remain aligned with organizational security objectives.

5. Use Network Segmentation and Firewalls

Network segmentation and firewall configurations act as critical countermeasures to SSRF attacks, compartmentalizing systems to manage unauthorized traffic. Segmentation splits the network into isolated zones, allowing strict policy enforcement that controls data traffic flow, inhibiting SSRF exploits from reaching sensitive areas.

This structural enforcement confines potential exploitations within designated bounds, preventing lateral movements or privilege escalations indicative of successful SSRF operations. By configuring firewalls with precise rule sets aligned with segmentation strategies, systems enhance their resistance against SSRF, reducing the potential of successful breaches.

SSRF Protection with Radware

A positive security model is critical to successfully mitigate the risks associated with the SSRF vulnerability. To that end, it’s important to keep the following capabilities in mind when evaluating a WAF: API security protection, parameter filters, strong input validation, sensitive data exposure and signature creation related to direct file access—all of which require a WAF that can employ a positive security model.

Radware offers a range of solutions to detect and mitigate SSRF attacks:

API Protection

Radware’s API Protection solution is designed to safeguard APIs from a wide range of cyber threats, including data theft, data manipulation, and account takeover attacks. This AI-driven solution automatically discovers all API endpoints, including rogue and shadow APIs, and learns their structure and business logic. It then generates tailored security policies to provide real-time detection and mitigation of API attacks. Key benefits include comprehensive coverage against OWASP API Top 10 risks, real-time embedded threat defense, and lower false positives, ensuring accurate protection without disrupting legitimate operations.

Cloud Application Protection Services

Radware’s Cloud Application Protection Services provide a unified solution for comprehensive web application and API protection, bot management, client-side protection, and application-level DDoS protection. Leveraging Radware SecurePath™, an innovative API-based cloud architecture, it ensures consistent, top-grade security across any cloud environment with centralized visibility and management. This service protects digital assets and customer data across on-premise, virtual, private, public, and hybrid cloud environments, including Kubernetes. It addresses over 150 known attack vectors, including the OWASP Top 10 Web Application Security Risks, Top 10 API Security Vulnerabilities, and Top 21 Automated Threats to Web Applications. The solution employs a unique positive security model and machine-learning analysis to reduce exposure to zero-day attacks by 99%. Additionally, it distinguishes between “good” and “bad” bots, optimizing bot management policies to enhance user experience and ROI. Radware’s service also ensures reduced latency, no route changes, and no SSL certificate sharing, providing increased uptime and seamless protection as businesses grow and evolve.

Alteon Integrated WAF

Radware’s Alteon Integrated WAF (see CyberPedia: Web Application Firewall) ensures fast, reliable and secure delivery of mission-critical Web applications and APIs for corporate networks and in the cloud. Recommended by the NSS, certified by ICSA Labs, and PCI compliant, this WAF solution combines positive and negative security models to provide complete protection against web application attacks, access violations, attacks disguised behind CDNs, API manipulations, advanced HTTP attacks (such as slowloris and dynamic floods), brute force attacks on log-in pages and more.

Cloud WAF

Radware’s Cloud WAF service is part of our Cloud Application Protection Service which includes WAF, API protection, Bot management, Layer-7 DDoS protection and Client-Side Protection. The service analyzes web apps to identify potential threats, then automatically generates granular protection rules to mitigate those threats. It also offers device fingerprinting to help identify bot attacks, AI-powered API discovery and protection to prevent API abuse, full coverage of OWASP Top 10 vulnerabilities, and data leak prevention, which prevents the transmission of sensitive data. Radware Cloud WAF is NSS recommended, ICSE Labs certified, and PCI-DSS compliant.

Kubernetes WAF

Radware Kubernetes WAF is a comprehensive and scalable web application firewall designed for CI/CD environments orchestrated by Kubernetes. It provides robust data and application protection, integrating seamlessly with Kubernetes orchestration and common DevOps tools. The solution offers advanced automation, autoscaling, and elasticity, ensuring security for microservices architectures. It combines both negative (signature-based) and positive security models to protect against known and unknown threats, including zero-day attacks. Additionally, it provides detailed visibility and analytics for DevSecOps teams, reducing total cost of ownership with minimal false positives.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Locations
Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

Get Social

Connect with experts and join the conversation about Radware technologies.

Blog
Security Research Center
CyberPedia