Understanding SSRF: From Basic to Blind

Server-Side Request Forgery has evolved from a niche vulnerability to one of the most critical issues in cloud-native applications. When researchers demonstrate SSRF leading to full AWS account takeover, security teams pay attention. But understanding SSRF deeply—beyond the basic "make the server request localhost" explanation—is essential for both finding and preventing these vulnerabilities.

Let's go deep on SSRF. Not the textbook version, but the practical reality of how these vulnerabilities appear in production applications and how attackers chain them into serious compromises.

The Fundamental Pattern

SSRF occurs when an application makes HTTP requests based on user-controlled input without adequately validating the destination. The server becomes a proxy that attackers can use to reach resources they couldn't access directly.

The most basic example is a URL preview feature. User provides a URL, server fetches the content to generate a thumbnail or extract metadata, user sees the result. If the server doesn't validate URLs, an attacker can request internal resources: http://localhost/admin, http://169.254.169.254/latest/meta-data/, http://internal-service.local/api/secrets.

But modern SSRF is rarely this straightforward. Applications have learned to block obvious private IP addresses. Attackers have learned to evade these blocks. The result is an arms race where understanding the details matters enormously.

Finding SSRF in Real Applications

SSRF doesn't always involve obvious URL parameters. It appears in:

Webhook configurations where users specify callback URLs. When a webhook fires, the server makes a request to the user-specified endpoint. If validation is weak, attackers specify internal URLs.

Document converters that fetch remote resources. PDF generators loading images, office document converters processing embedded links, HTML-to-PDF services rendering external stylesheets. Each of these follows URLs specified in the input document.

Integration features connecting to user-specified APIs. OAuth implementations that fetch user profiles, payment integrations that verify callbacks, any feature where users configure external service endpoints.

Proxy and gateway features where the application routes requests on behalf of users. API gateways, caching proxies, and load balancers all make requests to destinations that may be attacker-controlled.

When testing, look for any feature that might cause the server to make HTTP requests. Then try to control the destination of those requests. The URL might be in a query parameter, a request body, an HTTP header, or embedded in uploaded content.

Bypassing Common Defenses

Most applications implement some SSRF protection. The challenge is finding gaps in that protection.

IP-based blocking typically denies requests to private IP ranges and localhost. Bypasses include:

DNS rebinding, where you control a domain that initially resolves to a permitted address but later resolves to a private IP. The application validates the initial resolution but follows the later one.

URL encoding and obfuscation where private IPs are represented in unusual formats. 127.0.0.1 can be written as 2130706433 (decimal), 0x7f000001 (hex), 0177.0.0.1 (octal), or 127.1 (abbreviated). Different URL parsers handle these differently.

DNS records pointing to private IPs. If the application only checks the URL format but not where the hostname resolves, you can use a external domain that has an A record pointing to 127.0.0.1.

IPv6 representations that map to IPv4 private addresses. ::ffff:127.0.0.1 is localhost in IPv6-mapped-IPv4 format. Some validation blocks IPv4 private ranges but forgets the IPv6 equivalents.

Redirect chains where the initial request goes to an external server you control, which then redirects to an internal address. If the application follows redirects without re-validating each hop, the final request reaches internal resources.

Protocol handlers beyond HTTP. Some SSRF-vulnerable features support file://, gopher://, or other protocols that provide additional attack capabilities even when HTTP requests are restricted.

Cloud Metadata Services

The reason SSRF became critical is cloud metadata services. AWS, GCP, Azure, and other cloud providers expose credential endpoints on link-local addresses that are reachable from any VM in the cloud environment.

On AWS, http://169.254.169.254/latest/meta-data/ provides information about the running instance, and more critically, /latest/meta-data/iam/security-credentials/ returns temporary credentials for any IAM role attached to the instance. An attacker with SSRF can steal these credentials and use them from anywhere.

AWS has mitigated this with IMDSv2, which requires a token from a PUT request before metadata can be retrieved. This blocks simple SSRF because most vulnerable features only issue GET requests. But applications must explicitly enable IMDSv2 enforcement—many don't.

GCP and Azure have similar services with similar risks. Any cloud-hosted application with SSRF is potentially vulnerable to credential theft and full account compromise.

Blind SSRF

Sometimes SSRF exists but you can't see the response. The server makes the request, but the result isn't reflected back to you. This is blind SSRF, and it's still dangerous.

Blind SSRF enables:

Port scanning of internal networks. Request http://internal-host:{port}/ for each port and observe timing differences or error messages that reveal which ports are open.

Service detection by observing how different services respond. Database connections might timeout differently than web servers. Error pages might leak service names.

Interaction with internal services that have side effects. Making the server authenticate to an attacker-controlled SMB share captures NTLM hashes. Requesting internal APIs might trigger actions even if you don't see responses.

When testing blind SSRF, use out-of-band interaction detection. Tools like Burp Collaborator or webhook.site confirm whether requests are being made even when you don't see responses in the application.

Chaining SSRF

SSRF becomes powerful when chained with other vulnerabilities or features:

SSRF + Exposed admin interfaces. Many internal services have admin panels without authentication, assuming network isolation provides security. SSRF bypasses that assumption.

SSRF + Internal APIs. Microservice architectures often trust requests from other internal services. SSRF lets attackers impersonate internal components.

SSRF + File read vulnerabilities. Some URL handlers support file:// protocol, turning SSRF into local file read. Combined with exposed credentials or configuration files, this leads to full compromise.

SSRF + Misconfigured proxies. Internal proxies might be configured to forward requests without authentication. SSRF through these proxies provides authenticated access to protected resources.

Defense in Depth

Defending against SSRF requires multiple layers:

Validate and sanitize URLs rigorously. Use allowlists where possible. Check resolved IP addresses, not just URL format. Validate after following redirects.

Network segmentation ensures that even successful SSRF can't reach critical resources. Put metadata services behind firewalls that only permit access from specific instances.

Disable unnecessary URL schemes. If your feature only needs HTTP/HTTPS, explicitly block other protocols.

Use IMDSv2 on AWS and equivalent protections on other clouds. These significantly raise the bar for exploitation.

Monitor for unusual outbound requests. Requests to metadata services, internal IPs from public-facing applications, or unexpected protocols might indicate SSRF exploitation.

Conclusion

SSRF has evolved from interesting technique to critical vulnerability class. In cloud environments, it's often the shortest path from web application to full infrastructure compromise. Understanding the nuances—how to find these vulnerabilities, how to bypass common defenses, how to chain them into meaningful attacks—is essential for security practitioners.

RaSEC's agents understand SSRF deeply. They don't just try the basic textbook examples. They test bypass techniques, detect blind SSRF through out-of-band interactions, and identify the chained attacks that make SSRF truly dangerous. That's the kind of depth required for real security testing.