SSRF Attacks: Making Servers Attack Themselves

Server-Side Request Forgery (SSRF) is one of the most impactful vulnerability classes in modern web applications. It occurs when an attacker can influence server-side HTTP requests, causing the application to send requests to unintended destinations. In today's cloud-native architectures, where internal services communicate over HTTP and cloud metadata APIs are a single request away, SSRF has escalated from a moderate finding to a critical one. It was added to the OWASP Top 10 as a standalone category in 2021, reflecting its growing real-world significance.

Types of SSRF

Understanding the different SSRF variants is essential for thorough testing:

• Basic (In-Band) SSRF - The server fetches a URL and returns the response directly to the attacker. This is the easiest to exploit and confirm, as you can immediately see internal service responses, file contents, or metadata in the HTTP response body.
• Blind SSRF - The server makes the request but does not return the response to the attacker. You must rely on out-of-band techniques such as DNS lookups, timing differences, or external callback servers (Burp Collaborator, interactsh) to confirm the vulnerability. Exploitation is harder but the impact can be equally severe.
• Partial (Semi-Blind) SSRF - The server returns limited information, such as HTTP status codes, response times, or error messages that differ depending on whether the target is reachable. This can be leveraged for port scanning or inferring internal service availability.

Impact Analysis

SSRF impact varies based on the target environment, but common consequences include:

• Internal service access - Reaching admin panels, databases, caches (Redis, Memcached), or internal APIs that are not exposed to the internet. Many internal services run without authentication because they rely on network-level isolation.
• Cloud metadata exploitation - This is the most dangerous SSRF scenario. Cloud metadata services expose IAM credentials, API keys, user data scripts, and infrastructure configuration to any process running on the instance.
• Internal port scanning - Mapping internal network topology by observing response times, status codes, or error messages for different IP:port combinations. This provides reconnaissance data for further attacks.
• Local file read - When the application supports the file:// protocol scheme, SSRF can read local files such as /etc/passwd, application configuration files, or private keys stored on the server filesystem.
• Remote code execution - In some cases, SSRF can be chained into RCE by targeting internal services with known vulnerabilities, such as unauthenticated Redis instances (writing a crontab entry) or internal Jenkins servers.

Cloud Metadata Endpoints

Cloud metadata APIs are the primary SSRF target because they can yield credentials that grant access to the entire cloud account:

• AWS IMDSv1 - http://169.254.169.254/latest/meta-data/ provides instance identity, network configuration, and most critically, IAM role credentials at /latest/meta-data/iam/security-credentials/[role-name]. The user-data endpoint at /latest/user-data/ often contains initialization scripts with hardcoded secrets.
• AWS IMDSv2 - Requires a PUT request to /latest/api/token with the header X-aws-ec2-metadata-token-ttl-seconds to obtain a session token. This token must then be included in subsequent GET requests. IMDSv2 mitigates basic SSRF but can still be exploited if the application follows redirects or allows PUT methods.
• GCP - http://metadata.google.internal/computeMetadata/v1/ requires the header Metadata-Flavor: Google. Access tokens are at /instance/service-accounts/default/token. GCP tokens often have broad scopes including storage and compute access.
• Azure - http://169.254.169.254/metadata/instance?api-version=2021-02-01 requires the header Metadata: true. Managed identity tokens are available at /metadata/identity/oauth2/token. The wireserver endpoint at 168.63.129.16 can also leak configuration data.

Bypass Techniques

Applications often implement SSRF protections that can be circumvented through various techniques:

• URL encoding - Single, double, or triple URL-encoding the target IP or hostname. For example, 169.254.169.254 becomes %31%36%39%2e%32%35%34%2e%31%36%39%2e%32%35%34 or encoded further.
• IP format tricks - The IP address 169.254.169.254 can be represented as decimal (2852039166), hexadecimal (0xa9fea9fe), octal (0251.0376.0251.0376), IPv6 mapped (::ffff:169.254.169.254), or mixed notation (0xa9.254.0251.0xfe). Many parsers and validation libraries handle these formats inconsistently.
• DNS rebinding - Register a domain that alternates between resolving to an allowed external IP and the target internal IP. The validation check passes on the first resolution, but the actual request hits the internal target on the second resolution. Tools like rbndr.us simplify this.
• Redirect chains - Host a URL on an attacker-controlled server that returns a 302 redirect to the internal target. If the application follows redirects after validation, the check passes on the external URL but the final request reaches the internal one.
• URL parser differentials - Different URL parsing libraries interpret ambiguous URLs differently. Using @ symbols (http://allowed.com@169.254.169.254), fragments, backslashes, or Unicode characters can cause the validator to parse a different host than the HTTP client.
• Alternative protocols - Trying gopher://, dict://, or ftp:// schemes to interact with internal services in ways HTTP cannot, such as sending arbitrary TCP data via gopher to exploit Redis or SMTP services.

Real-World SSRF Scenarios

During penetration tests, I frequently encounter SSRF in these application features:

• Webhook functionality - Applications that send HTTP callbacks to user-configured URLs. These often have the fewest restrictions since they are designed to make arbitrary outbound requests.
• PDF generators - Server-side HTML-to-PDF rendering (wkhtmltopdf, Puppeteer, WeasyPrint) that processes user-supplied HTML. Embedding an iframe or image tag pointing to internal resources can exfiltrate data in the generated PDF.
• Image processors - Features that fetch images from URLs for resizing, cropping, or avatar importing. The ImageMagick library has historically supported SVG files that reference external URLs.
• URL previews and link unfurling - Chat applications and social platforms that fetch URL metadata (title, description, thumbnail) when users share links. Slack, Discord, and similar tools have all faced SSRF issues in this functionality.
• Import/export features - Importing data from external URLs, RSS feeds, XML documents with external entities (XXE-to-SSRF), or XSLT stylesheets.

Detection and Prevention

A defense-in-depth approach is essential because no single control eliminates SSRF entirely:

• URL allowlisting - Maintain a strict allowlist of permitted destination hosts, IP ranges, ports, and protocols. Deny by default and only permit known-good destinations. Validate after DNS resolution to prevent DNS rebinding.
• IMDSv2 enforcement - On AWS, enforce IMDSv2-only mode on all EC2 instances. Set the hop limit to 1 to prevent containers and forwarded requests from reaching the metadata service. Consider disabling IMDS entirely on instances that do not need it.
• Network segmentation - Use VPC configurations, security groups, and network ACLs to prevent application servers from reaching sensitive internal services. Place applications that must make outbound requests in isolated subnets with restricted egress.
• URL validation best practices - Resolve the hostname before making the request and validate the resolved IP against a denylist of private ranges (RFC 1918, link-local, loopback). Re-validate after every redirect. Disable unnecessary protocol schemes.
• Disable redirects - Where possible, do not follow HTTP redirects. If redirects are necessary, apply the same validation to each redirect target before following it.

Testing Tools

• Burp Collaborator / interactsh - Detect blind SSRF by observing out-of-band DNS and HTTP callbacks from the target server.
• ssrf-sheriff - Automated SSRF detection tool that generates payloads for various bypass techniques and monitors for callbacks.
• Custom wordlists - Build target-specific wordlists containing internal hostnames, cloud metadata paths, common internal service ports, and known IP bypass representations for thorough fuzzing.
• Gopherus - Generates gopher:// payloads for exploiting internal services like MySQL, Redis, SMTP, and FastCGI through SSRF.