Blind SSRF with Out-of-Band Detection in Bug Bounty
Some SSRF bugs never return the fetched page. A webhook validator says “saved,” an image importer shows a generic failure, or a PDF job runs in the background. The server still makes the request; you simply need to observe it somewhere else. That is blind SSRF, and out-of-band callbacks turn the invisible network action into evidence.
Use a collaborator service or a domain you control that records both DNS and HTTP. Create a fresh token for every parameter and attempt, for example avatar-3f91.your-callback.example. Unique labels answer three questions later: which input fired, when it fired, and whether a delayed worker caused it. Reusing one hostname across a whole scan destroys that clarity.
Place the callback URL in features that plausibly fetch remote content: webhooks, URL previews, image imports, feed readers, PDF generators, SSO metadata, repository integrations, and “test connection” buttons. Try JSON values, form fields, and headers only where the application advertises URL handling. Blind spraying into every parameter is noisy and hard to defend.
Read DNS and HTTP separately
A DNS lookup proves that something resolved your name, but not necessarily that the target application connected. Email scanners, security gateways, and your own browser can produce lookups. An HTTP request from a cloud address, carrying a target-specific user agent or arriving seconds after the feature ran, is stronger.
Log method, path, headers, source network, and time. Put the canary in the URL path too:
https://oast.example/bugflare/avatar/3f91
If only DNS arrives, report the evidence honestly and keep investigating. Try ports you control, HTTP versus HTTPS, and a redirect from your server to another unique hostname. A server-side client that follows the redirect demonstrates more control and can reveal whether allowlisting happens before or after redirection.
Safe escalation
The central impact question is whether the fetcher can reach places an attacker cannot. You can test parser behavior with loopback spellings and private-address redirects, but avoid touching sensitive metadata or internal admin actions without explicit permission. A safe pattern is to redirect toward an unroutable private address and compare timing, or toward a callback endpoint reached through a controlled DNS-rebinding setup where rules allow it.
If the program permits cloud metadata testing, request a harmless path first and never exfiltrate credentials casually. Blind SSRF can become critical, yet the mere presence of a callback does not prove cloud takeover. Egress source, allowed schemes, methods, custom headers, redirect handling, and network reach determine severity.
Callbacks may be delayed by queues. Wait long enough for document jobs and retry with a new token rather than hammering the endpoint. Compare a valid URL, a dead hostname, and a slow response. Timing differences help map timeouts but should support OOB evidence, not replace it.
Reporting what actually happened
Give triage the vulnerable request, the unique callback URL, timestamped DNS and HTTP logs, and any redirect chain. Explain why a browser or third-party scanner could not have generated the hit. State confirmed capabilities precisely: “server performed an HTTPS GET and followed one redirect” is better than “full SSRF.”
Fixes belong at the outbound boundary. Allowlist required destinations and schemes, resolve hostnames before connecting, reject loopback, link-local, private, and reserved ranges after every resolution, and re-check each redirect. Pin the resolved address to prevent DNS rebinding. Network egress policy should block sensitive internal ranges even if application validation fails. Blind does not mean harmless; it only means the response takes another road.