Blind SSRF with OAST
Confirm a server-side fetch without retrieving internal data, then map DNS, HTTP, redirects, and parser behavior as separate gates.
Every step requires authorization. Review side effects before running commands against a live system.
Define the boundary before the test.
- Preconditions
- Current scope, observed technology, reachable feature, controlled identities or data, and a recovery plan.
- Expected evidence
- One observable response, state, or callback that distinguishes the hypothesis from normal behavior.
- Negative control
- The same action with the security-sensitive variable removed, replaced, or bound to its rightful owner.
- False-positive checks
- Cache, retry, race, reflection, proxy rewriting, stale sessions, and unrelated asynchronous activity.
- Chain gate
- Record the proven primitive and the next missing prerequisite. Do not expand impact until scope and authorization still permit the next step.
Inventory URL-consuming features
Look for webhooks, imports, link previews, image or document rendering, feed readers, callback validation, remote attachments, avatar fetches, PDF generation, and URLs inside JSON, XML, headers, or uploaded documents. Tie each candidate to an observed feature and current scope.
Establish a unique direct callback
Use a fresh HTTPS callback hostname for one field in one request. Submit a second request with a valid benign URL or an inert non-URL marker as the negative control. Do not open the callback URL in your own browser.
https://ssrf-014-req88-avatar.UNIQUE.oast.example/directSeparate resolution from fetch
Record whether the listener receives DNS only, DNS plus HTTP, repeated fetches, or no interaction. DNS only may mean blocked egress, preflight validation, a security scanner, or a failed connection. HTTP proves a request reached the listener but not access to any internal resource.
interactsh-client -server YOUR_PRIVATE_INTERACTSH_SERVER -json -o ssrf-direct.jsonlTest parser boundaries safely
When policy permits, compare HTTP vs HTTPS, an explicit port on the same controlled host, a scheme-relative URL, a hostname in userinfo position, and a fragment variation. Keep every request pointed at your controlled listener and change only one URL component at a time.
https://[email protected]/probeTest one controlled redirect
Only if your listener supports explicit response control and the program allows it, compare a direct callback with one single-hop redirect to a second unique controlled hostname. Record each hop independently. Do not redirect to loopback, link-local, private, or third-party destinations.
Bound impact and stop
Report the demonstrated fetch primitive, protocol, method, visible headers, redirect behavior, and reproducibility. Do not access cloud metadata, internal panels, credentials, or unrelated hosts merely to make blind SSRF sound more severe.
Common guidance
- A callback from a browser or link scanner is not server-side request forgery. Preserve user agent, source, timing, and trigger controls.
- Use a new token for direct, redirect, userinfo, port, and scheme variants so the accepted parser form is unambiguous.
- The one-way nature of blind SSRF can limit demonstrated impact. State that limit instead of assuming internal reachability.
- Never use a public listener for target requests or expose raw callback logs.
Mapped workflow tools
References
- https://portswigger.net/web-security/ssrf/blind ↗
- https://portswigger.net/web-security/ssrf ↗
- https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html ↗
- https://docs.projectdiscovery.io/opensource/interactsh/usage ↗
Version history: normalized permanent page created 2026-08-20.