SSRF Lab: Make a Server Fetch Its Own Cloud Secrets

This article presents an interactive lab teaching server-side request forgery (SSRF) through a practical scenario where an avatar fetcher application can be exploited to retrieve cloud metadata credentials. SSRF is a critical vulnerability because it abuses a server's internal network access and trust relationships to reach systems the attacker cannot access directly. The lab demonstrates why this matters: a misconfigured URL fetcher becomes a pivot point into cloud infrastructure, and understanding this attack is essential for both defensive and offensive security practitioners.

• How SSRF exploits server trust relationshipsSSRF works because metadata services on cloud platforms trust requests originating from the server itself, operating at a fixed internal address like AWS's 169.254.169.254. When the server fetches a user-supplied URL pointing to this address, the metadata service treats it as legitimate, returning sensitive data including temporary access keys and IAM role credentials that would normally be inaccessible to external attackers.
• The AvatarFetcher vulnerability mechanismThe application accepts any URL without validation, requests it from the server, and returns the response directly to the user. The lab requires no allowlist and no destination checking, meaning an attacker can simply replace a legitimate image URL with the cloud metadata service address to retrieve the server's internal secrets in one request.
• Real-world impact and precedentThe 2019 Capital One breach exposed over 100 million people's data by using SSRF against a misconfigured web application firewall to reach AWS metadata and steal credentials. This breach was significant enough that SSRF was added as its own category to the OWASP Top 10 in 2021, and AWS subsequently released IMDSv2 partly to mitigate this specific attack vector.
• Validation timing and DNS rebinding preventionA key defensive principle is to block internal ranges—loopback, private, link-local, and metadata address ranges—after DNS resolution, not before. This prevents attackers from bypassing allowlists with DNS tricks or redirects; the check must happen after the domain resolves and again after each redirect the server follows.
• IMDSv2 as a targeted mitigationAWS introduced IMDSv2, which requires a session token obtained via a PUT request before any metadata can be read. This stops simple SSRF attacks from retrieving metadata via GET requests, but the article notes it does not fix SSRF against other internal services, making it one layer of defense rather than a complete solution.
• Allowlist over blocklist strategyThe article recommends allowlisting destinations by hostname where possible instead of trying to block bad ones. This shifts the burden to the defender to explicitly permit only known safe destinations, a stronger security posture than attempting to enumerate all dangerous addresses.
• Broader SSRF attack surfaceThe article identifies any feature that accepts a URL as a potential SSRF vector: avatars, link previews, webhooks, PDF generators, and import-from-URL tools. This wide attack surface means SSRF defense must be built into all user-facing URL-handling functionality, not just specialized services.
• Response validation prevents data exfiltrationBeyond blocking dangerous destinations, the article recommends not returning raw responses to users; validate that the fetched content is actually an image. This reduces the attacker's ability to see metadata or internal error messages that reveal system topology and credentials.

Bottom line: SSRF is a critical vulnerability that turns a server's network access into a weapon against itself, and cloud environments amplify the risk because metadata services expose credentials at fixed, predictable addresses. Effective defense requires multiple layers: allowlisting destinations, blocking internal ranges after DNS resolution, enforcing IMDSv2 or equivalent, isolating the fetching function, and validating response content.