Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure, effectively bypassing firewalls.
The Mechanics of SSRF
Web applications frequently need to fetch data from external sources. For example, a social media app might fetch a preview image when a user posts a URL. If the application doesn't properly validate the URL provided by the user, an attacker can supply a URL pointing to an internal server. Because the request originates from the trusted server itself, it can access resources that are normally protected by network boundaries.
Types of SSRF
There are generally two forms of SSRF: 1. **Basic SSRF**: The application returns the response from the forged request back to the attacker. This is extremely dangerous as it allows direct interaction with internal services, reading files, or extracting cloud metadata. 2. **Blind SSRF**: The application makes the request but does not return the response to the attacker. While harder to exploit, attackers can still infer information based on time delays or HTTP status codes, or use it to trigger state-changing actions internally.
Cloud Environments and Metadata
One of the most devastating impacts of SSRF today occurs in cloud environments like AWS, GCP, and Azure. These platforms expose instance metadata services (IMDS) at a predictable local IP address (`169.254.169.254`). If an application is vulnerable to SSRF, an attacker can query this endpoint to retrieve highly sensitive information, including IAM temporary credentials.
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-roleWith these credentials, the attacker can often escalate their privileges and compromise the entire cloud environment.
Mitigation Strategies
Preventing SSRF requires a defense-in-depth approach. First, implement a strict **allowlist** of permitted domains or IP addresses. If an application only needs to fetch images from a specific trusted CDN, enforce that restriction. Second, disable unused URI schemas like `file://`, `gopher://`, or `dict://`, which attackers often use to exploit SSRF for local file inclusion or port scanning. Finally, in cloud environments, enforce IMDSv2 (or equivalent protections), which requires a session token in a custom header to access metadata, rendering basic SSRF attacks ineffective.