Server-Side Request Forgery (SSRF) has evolved from a niche web vulnerability into one of the most critical threats facing modern cloud-native applications. As organizations move toward microservices and complex cloud infrastructures, the trust relationship between internal components becomes a primary target for attackers. In an SSRF attack, the adversary manipulates a server-side application into making HTTP requests to an arbitrary domain of the attacker's choosing, effectively using the server as a proxy to bypass firewalls and access internal resources.

What is Server-Side Request Forgery (SSRF)?

At its core, Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can force a server to perform unintended requests. Typically, these requests are directed at internal systems that are not reachable from the public internet. Because the request originates from the trusted server itself, internal security controls—like firewalls or Access Control Lists (ACLs)—often permit the traffic, assuming it is legitimate.

SSRF occurs when a web application fetches a remote resource without properly validating the user-supplied URL. For example, a feature that allows a user to "Import an Image from a URL" or "Preview a Website" is a classic entry point for SSRF. If the backend code takes the URL provided by the user and makes a GET request to it without strict filtering, an attacker can replace the intended URL with an internal IP address or a sensitive cloud metadata endpoint.

How SSRF Vulnerabilities Occur

To understand how SSRF happens, let's look at a common technical scenario. Imagine a web application that provides a service to check if a remote server is online. The user submits a URL, and the backend fetches the status.

Vulnerable Code Example (Python/Flask)

Consider this simplified Python snippet using the requests library:

from flask import Flask, request
import requests

app = Flask(__name__)

@app.route("/check-status")
def check_status():
    # The application takes a URL from the user-controlled 'url' parameter
    target_url = request.args.get('url')
    
    try:
        # The server makes a request to the provided URL
        response = requests.get(target_url, timeout=5)
        return f"Status of {target_url}: {response.status_code}"
    except Exception as e:
        return str(e), 500

In this example, there is no validation on target_url. An attacker could provide http://localhost:8080/admin or http://192.168.1.1/config. The server, residing inside the internal network, will attempt to fetch these pages and return the status code to the attacker. This confirms whether specific internal services are active.

Types of SSRF Attacks

SSRF attacks generally fall into two categories based on how the server responds to the malicious request.

1. In-band (Regular) SSRF

In an In-band SSRF attack, the attacker receives the response from the server-side request directly in the application's output. This is the most dangerous form because the attacker can read sensitive data, such as configuration files, internal API responses, or database contents. For instance, if the server fetches a file and displays its content on the screen, the attacker can use the file:// protocol to read /etc/passwd on Linux systems.

2. Blind SSRF

In a Blind SSRF scenario, the application does not return the content or even the status of the backend request to the attacker. However, the request is still executed. Attackers exploit Blind SSRF by monitoring for out-of-band (OOB) interactions. They might provide a URL pointing to a server they control (e.g., http://attacker-controlled.com/log) and check their web server logs to see if the vulnerable server made a connection. While harder to exploit, Blind SSRF can still be used for internal port scanning or triggering remote code execution on internal services via unauthenticated GET requests.

Common SSRF Exploitation Techniques

Attackers use several techniques to maximize the impact of an SSRF vulnerability, moving from simple connectivity tests to full data exfiltration.

Internal Port Scanning

An attacker can use the vulnerable server to map the internal network. By iterating through common ports on localhost or internal IP ranges (like 10.0.0.0/8), they can identify running services:

• http://127.0.0.1:22 (SSH)
• http://127.0.0.1:6379 (Redis)
• http://127.0.0.1:3306 (MySQL)
• http://127.0.0.1:9200 (Elasticsearch)

If the server returns a "Connection Refused" error for port 21 but a "200 OK" or a timeout for port 6379, the attacker knows Redis is likely running internally.

Accessing Cloud Metadata Services

This is perhaps the most critical exploitation path in cloud environments (AWS, Azure, GCP). Cloud providers offer a Metadata Service (IMDS) accessible via a non-routable IP address (169.254.169.254). This service provides information about the instance, including IAM roles and temporary security credentials.

AWS Example Payload:

GET /check-status?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role HTTP/1.1
Host: vulnerable-app.com

If successful, the response might contain an AccessKeyId, SecretAccessKey, and Token. The attacker can then use these credentials to access the organization's AWS resources directly from their own machine.

Google Cloud (GCP) Example Payload:
Note that GCP requires a specific header (Metadata-Flavor: Google), which makes SSRF harder unless the attacker can also control HTTP headers. However, if the application allows header injection or uses a client that automatically forwards headers, it remains a risk.

http://metadata.google.internal/computeMetadata/v1/instance/disks/?recursive=true

Bypassing SSRF Whitelists and Blacklists

Developers often try to fix SSRF by blacklisting certain keywords (like localhost or 169.254.169.254) or whitelisting specific domains. Experienced attackers have multiple ways to bypass these filters.

1. Using Different IP Encodings

Instead of 127.0.0.1, an attacker can use:

• Decimal: http://2130706433/
• Hexadecimal: http://0x7f000001/
• Octal: http://017700000001/
• Shortened IP: http://127.1/

2. DNS Rebinding

This is a sophisticated technique where the attacker controls a domain (e.g., rebind.attacker.com). They set the DNS TTL (Time to Live) to a very short value (e.g., 1 second).

1. When the server first checks the URL against a whitelist, the DNS resolves to a safe, public IP.
2. When the server actually performs the GET request a moment later, the DNS record has expired, and the attacker's DNS server now resolves the domain to 127.0.0.1.

3. URL Schema Manipulation

If the application doesn't restrict the protocol to http or https, attackers can try other schemas:

• file:///etc/passwd (Read local files)
• gopher://localhost:11211/ (Communicate with Memcached/Redis)
• dict://localhost:11211/ (Dictionary server protocol)
• ftp://attacker.com:21 (Bypass certain firewall rules)

4. Redirects

If the application prevents requests to internal IPs but follows HTTP redirects, an attacker can host a script on a public server that redirects to an internal resource:

<?php
header("Location: http://169.254.169.254/latest/meta-data/");
?>

The application validates http://attacker-controlled.com/redirect.php (which is public and "safe"), but then follows the redirect to the metadata service.

Real-World Impact of SSRF

The impact of SSRF can range from minor information disclosure to total infrastructure compromise.

1. Data Exfiltration: Accessing internal databases, configuration files, or proprietary source code.
2. Cloud Account Takeover: Stealing IAM credentials from metadata services allows attackers to move laterally through the cloud environment.
3. Remote Code Execution (RCE): By interacting with internal services like Redis or Docker APIs, attackers can often execute arbitrary commands on the internal network.
4. Bypassing Authentication: Many internal services do not require authentication because they assume the network perimeter is secure. SSRF allows attackers to interact with these unauthenticated services.

One of the most famous examples of SSRF was the 2019 Capital One breach, where an attacker exploited an SSRF vulnerability in a web application firewall (WAF) to access AWS metadata, leading to the theft of personal data from over 100 million customers.

How to Prevent SSRF Vulnerabilities

Defending against SSRF requires a defense-in-depth approach. Relying on simple blacklists is rarely sufficient.

• Implement Strict Whitelisting: Only allow requests to a predefined list of trusted domains or IP addresses. Ensure the validation happens on the resolved IP address, not just the hostname, to prevent DNS rebinding.
• Validate the Protocol: Explicitly allow only http and https. Disable support for file://, gopher://, dict://, and other dangerous schemas.
• Network Segmentation: Use VPC security groups and firewalls to ensure the web server cannot communicate with sensitive internal services unless absolutely necessary. Specifically, block access to the cloud metadata IP (169.254.169.254) from the application layer if it's not needed.
• Use IMDSv2: If you are using AWS, enforce the use of Instance Metadata Service Version 2 (IMDSv2), which requires a session-oriented header (X-aws-ec2-metadata-token), making traditional SSRF much harder to exploit.
• Sanitize User Input: Treat all user-supplied URLs as untrusted. Never concatenate user input directly into a request string.
• Disable Redirects: Configure your HTTP client to not automatically follow redirects, or manually validate the redirect location before the next request is made.

Conclusion

Server-Side Request Forgery is a potent reminder that the internal network is not a "safe zone." As applications become more interconnected, the ability for an attacker to pivot from a public-facing web form to a sensitive internal database is a risk that every developer and security professional must address. By understanding the mechanics of SSRF—from basic port scanning to complex DNS rebinding—you can build more resilient applications and protect your organization's most critical assets.

To proactively monitor your organization's external attack surface and catch exposures like SSRF-vulnerable endpoints before attackers do, try Jsmon.