Blind SSRF occurs when the server makes a request on the attacker's behalf but never returns the response body or an error message that reflects the response content. The attacker sees no output, yet the request still reaches the target. Detection relies entirely on side-channels: out-of-band callbacks, timing differences, and error condition inference.
- Distinguish blind SSRF from non-blind SSRF by observable signals.
- Use out-of-band (DNS/HTTP) callback techniques to confirm a blind request.
- Apply timing-based inference when callback channels are unavailable.
- Detect blind SSRF through error-oracle patterns in application behaviour.
- Out-of-band (OOB) detection
- A technique where the attacker monitors an external service (DNS, HTTP server) for callbacks generated by the target server when it processes a malicious URL (CWE-918).
- Timing oracle
- Inferring request success by measuring response latency — a request to an internal host may timeout (slow) while a blocked one returns instantly.
- Error oracle
- Deducing internal state from subtle differences in error messages, status codes, or response lengths when the target URL is reachable vs. unreachable.
When the server swallows the response
In a standard SSRF, the attacker sees the response body — HTML, JSON, or error text — giving them direct feedback. In a blind SSRF, the application fetches a URL internally but never renders the result. Common contexts include webhook callbacks, document preview generators, SSO SAML assertion retrieval, and server-side image resize proxies. The request reaches the internal service, but the attacker has no window into what came back.
The lack of feedback makes blind SSRF harder to detect and exploit. Attackers must rely on secondary channels: a DNS lookup against their own controlled domain confirms the server resolved the hostname; an HTTP callback to a listener confirms the full TCP handshake; a measurable delay indicates a connection attempt to a live internal host; and a shift in error verbosity between reachable and unreachable targets can hint at internal state.
Detect blind callbacks
The sandbox below simulates a webhook processor that fetches a user-supplied URL but never shows the response. Toggle the detector to see which requests trigger callbacks, and try to determine whether your URL reached an internal resource.
ProxyShell and the blind callback chain
In 2021, the Microsoft Exchange Server ProxyShell attack chain (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) used blind SSRF as a critical link. The attacker sent a crafted request to the Exchange backend that triggered an outbound HTTP call to an attacker-controlled server. The Exchange server fetched the URL silently — no response body was returned to the attacker — but the callback proved the request executed, enabling the next stage of the chain. Blind SSRF is the weapon of choice when the application acts as a proxy without a feedback channel.
Block callbacks at the network layer
Because blind SSRF gives no direct feedback, the defender's goal is to prevent outbound connections to untrusted destinations entirely. Egress filtering, strict DNS resolution policies, and network segmentation make OOB detection much harder for the attacker. A layered defence treats every outbound request from the application server as a potential data channel.
// VULNERABLE — fetches user URL, response discarded but callback leaks
const url = req.body.webhook_url;
const resp = await fetch(url); // request still reaches the target
// SAFER — block outbound to non-essential destinations
const allowedHosts = ['hooks.internal.example.com'];
const parsed = new URL(url);
if (!allowedHosts.includes(parsed.hostname)) {
return res.status(403).json({ error: 'destination not allowed' });
}
const resp = await fetch(url);
// SAFEST — deny all outbound egress from app tier at network level
// iptables -A OUTPUT -d 10.0.0.0/8 -j ACCEPT
// iptables -A OUTPUT -o eth0 -m owner --uid-owner app -j DROPWhat to remember
- Blind SSRF never returns the response body — detection relies on side-channels alone.
- OOB callbacks (DNS, HTTP) are the most reliable confirmation method for blind SSRF.
- Timing and error oracles provide weaker but still useful signals when callback channels are blocked.
- Egress filtering and allowlist-based DNS resolution are the primary defences against blind callback exfiltration.
- Every outbound HTTP request from an app server is a potential data channel — treat it as such.
Knowledge check
0/3 answered · 0 correct1.What distinguishes blind SSRF from non-blind SSRF?
2.You control a URL that a webhook processor fetches silently. Which technique most reliably confirms the server made the request?
3.An application returns the same generic error regardless of the URL. What is your best next step to confirm blind SSRF?