Server-Side Request Forgery

Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs. When a web server accepts a URL parameter to retrieve external content—for example, to proxy images, validate webhooks, or import data—an attacker can manipulate that parameter to make the server send requests to unintended destinations. The critical issue is that these requests originate from the server itself, bypassing firewalls and network controls that would block direct external access.

Attacks come in several forms. Direct SSRF gives the attacker full control over the destination URL, allowing them to target internal services like http://localhost:8080/admin or cloud metadata endpoints at http://169.254.169.254/latest/meta-data/. Blind SSRF occurs when the application makes the request but doesn't return the response to the attacker—they must rely on timing differences or out-of-band techniques to confirm success. Partial SSRF restricts the attacker to modifying only part of the URL, such as the hostname or path, requiring more creative exploitation.

The typical attack flow starts with identifying URL parameters that trigger server-side requests. The attacker then probes for internal services by injecting internal IP addresses or localhost references. Common targets include administrative interfaces, internal REST APIs, Redis or Memcached instances, and especially cloud metadata services that expose IAM credentials. Attackers often employ bypass techniques like encoding IPs in decimal format (2130706433 for 127.0.0.1), exploiting URL parser discrepancies between validation and execution layers, or chaining with open redirects to evade basic filters.

• Access to internal services that should be network-isolated—admin panels, monitoring dashboards, configuration endpoints
• Cloud credential theft via metadata APIs, particularly AWS IAM role credentials exposed at 169.254.169.254
• Reading local files through file:// protocol support, exposing configuration files and source code
• Network reconnaissance to map internal infrastructure and identify additional attack targets
• Remote code execution on back-end systems like Redis or Elasticsearch that accept commands over HTTP
• Pivoting deeper into internal networks by using the compromised server as a proxy for further attacks

Capital One suffered a massive breach in 2019 when an attacker exploited SSRF in a web application firewall to query AWS metadata services, stealing credentials that granted access to over 100 million customer records. The vulnerability allowed requests to the internal metadata endpoint that should have been unreachable.

Shopify's infrastructure exposed internal Google Cloud metadata in 2020 through an image proxy feature. Security researchers demonstrated they could retrieve service account credentials by tricking the proxy into fetching from the metadata API, potentially compromising the entire GCP environment.

Numerous CVEs in enterprise products highlight SSRF in common features: webhook validators in GitLab, PDF generators that fetch remote images, and document conversion services. These typically manifest when URL validation assumes all requests will target external internet resources, failing to anticipate internal network abuse.

• Allowlist approved destination domains rather than trying to blocklist dangerous ones—only permit necessary external services
• Disable unnecessary URL schemes entirely (file://, gopher://, dict://)—restrict to https:// only where possible
• Network segmentation to prevent application servers from reaching internal infrastructure—use separate VLANs or VPCs
• Deploy cloud metadata protections like AWS IMDSv2 requiring session tokens, making metadata unavailable to simple HTTP requests
• Validate and parse URLs consistently using a single library, then verify resolved IP addresses aren't private ranges
• Remove response bodies from errors to prevent information disclosure in blind SSRF scenarios