Blind SSRF and Out-of-Band Detection

In blind SSRF the application makes the server-side request but does not return the response body to the caller. The application may validate a URL during account setup, process a webhook configuration asynchronously, or fetch a resource in a background job. No content reaches the attacker directly. The presence of the vulnerability is confirmed through indirect signals.

DNS-Based Detection

The most reliable out-of-band channel for detecting SSRF is DNS. When the application resolves a hostname to make an HTTP request, the DNS query for that hostname reaches the DNS server for the attacker-controlled domain. The attacker observes the query at their authoritative DNS server even when the subsequent HTTP request fails, is blocked by egress filtering, or returns no content.

The detection flow: the attacker supplies a URL with a subdomain they control, such as http://unique-id.attacker.com/path. If the application performs DNS resolution for this hostname, a query for unique-id.attacker.com arrives at the attacker's DNS server. The query's source IP is the server's IP, confirming the application makes outbound DNS lookups for user-supplied hostnames. The unique subdomain correlates the DNS query to the specific test.

This technique confirms that the application resolves hostnames from user input. It does not confirm that an HTTP request completed, that the response was received, or that internal resources are reachable. The DNS query alone establishes that the SSRF surface exists.

HTTP Callback Detection

If the application's outbound HTTP traffic is not blocked, an HTTP request to an attacker-controlled server provides stronger confirmation than DNS alone. The callback includes the HTTP method, headers, and any body the application sends. User-Agent strings, custom headers, or authentication tokens that the application appends to outgoing requests all appear in the callback, providing information about the HTTP client and the application's behavior.

If the callback does not arrive but the DNS query does, the application resolves hostnames but outbound HTTP is blocked at the network level. This is common in production environments with strict egress controls. The SSRF surface still exists for internal targets; the external callback is simply not reachable.

Timing Channels

When DNS and HTTP callbacks are blocked and no response content is returned, timing differences can confirm SSRF and reveal internal port states.

An HTTP connection to an open port completes the TCP handshake and returns a response (or timeout after a longer delay). A connection to a closed port receives an immediate RST. A connection to a filtered port (no rule) results in a timeout after the OS or application connection timeout period, typically seconds.

By measuring response time for requests to different internal IP:port combinations, an attacker can distinguish open ports (fast response or application-level timeout) from closed ports (fast rejection) from filtered ports (slow timeout). This enables internal network port scanning through the application, without any response content leaving the server.

Exploiting Blind SSRF

Confirming blind SSRF is not the end of the assessment. Even without response content, a confirmed SSRF can reach internal services and cause state changes: sending Redis commands via gopher://, triggering requests to internal APIs that perform actions (deleting data, modifying configuration), or reaching the cloud metadata service. The absence of response content limits information retrieval but does not prevent side-effect-based exploitation.