Glossary
What Is SSRF?
SSRF (Server-Side Request Forgery) is a vulnerability where an application is induced to make HTTP (or other) requests to attacker-controlled or internal destinations — allowing an attacker to reach services not exposed to the public internet, including cloud metadata endpoints (169.254.169.254) that hand out IAM credentials.
How SSRF gets exploited in practice
Any feature that accepts a URL and fetches it server-side is a candidate: PDF rendering (server-side headless Chrome), webhook configuration, image proxy, social-card previewer, OAuth callback validator, document import-from-URL, RSS feed parsing. The attacker submits a URL pointing at http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS), http://metadata.google.internal/ (GCP), or an internal service URL. The server makes the request and either returns the response or leaks it via side channels (PDF content, image content, error message).
How SQUR detects SSRF
For every endpoint where the attack-planner identifies URL-accepting input, the validator submits a callback URL pointing at a SQUR-controlled out-of-band (OOB) server (using Interactsh-style infrastructure). The validator confirms exploitation when the OOB server receives the request, capturing the server's outbound IP, the user-agent, and any data exfiltrated through DNS or HTTP headers.
Remediation pattern
Defence in depth: allowlist outbound destinations (only fetch from approved domains); block link-local and private RFC1918 ranges at the egress point; isolate the URL-fetching service in its own network namespace with no IAM credentials and no access to internal services; never use raw user-supplied URLs in template rendering; consider running URL fetches in a sidecar container with a restricted egress proxy.
Frequently asked questions
Why are cloud metadata endpoints so dangerous?
AWS, GCP, and Azure expose VM-specific metadata at well-known link-local addresses. The metadata service returns the VM's IAM credentials (temporary, but valid). An SSRF that reaches metadata gives the attacker the same privileges as the EC2/GCE instance running the vulnerable code — often broad write access to S3, EC2, IAM.
Are IMDSv2 / metadata v2 enough?
IMDSv2 (AWS) requires a token-flow handshake that's harder to exploit via SSRF, but not impossible. POST-based SSRF that can manipulate headers can still reach IMDSv2. Defence in depth is required: IMDSv2 + egress controls + role-of-least-privilege.