Exploiting SSRF: From Basics to Advanced Bypass & Cloud Metadata Leaks
Discover how attackers exploit SSRF vulnerabilities, bypass defense mechanisms, and compromise cloud infrastructure through metadata services.
TL;DR - Key Insights
- SSRF allows attackers to make servers fetch data from internal systems
- Cloud metadata services (169.254.169.254) are prime targets for credential theft
- DNS rebinding can bypass naive IP blacklists dynamically
- IP encoding bypasses simple string-based filters
- Defense requires: Resolve → Inspect → Block approach
- Whitelist-based validation is more secure than blacklisting
Understanding SSRF: The Core Vulnerability
Server-Side Request Forgery (SSRF) is a critical web vulnerability that allows attackers to force a server to make unintended HTTP requests to arbitrary destinations. This transforms the compromised server into an unwitting proxy, accessing resources it was never designed to reach.
Attacker Input
Malicious URL targeting internal resources
Vulnerable Application
Server processes request without proper validation
Internal Target
Access to metadata services, admin panels, or databases
Data Compromise
Sensitive information exposed to attacker
Why SSRF Remains Critical
Despite being well-documented, SSRF continues to plague modern applications due to incomplete protections and over-reliance on hostname blacklists. The vulnerability's impact is amplified in cloud environments where it can lead to full infrastructure compromise.
Basic SSRF Exploitation
Typical SSRF Scenario
Example of how a URL preview feature can be exploited for SSRF
The vulnerability emerges when applications fail to properly validate or sanitize URL parameters, allowing attackers to redirect server requests to internal services.
Common SSRF Targets
Localhost Services
Internal applications and admin panels
Cloud Metadata
AWS, GCP, Azure instance metadata
Internal Networks
Private APIs and dashboards
Backend Services
Redis, Elasticsearch, databases
File Systems
Local file access via file:// protocol
Network Scanning
Port scanning and service discovery
Cloud Metadata Exploitation
The Goldmine: 169.254.169.254
This special IP address hosts instance metadata services across major cloud providers. Successful SSRF exploitation here can lead to complete cloud environment compromise through IAM credential theft and configuration exposure.
AWS Metadata Service v1
Direct access to instance metadata and IAM credentials
Endpoint:
http://169.254.169.254/latest/meta-data/cURL Command:
curl -X GET "http://169.254.169.254/latest/meta-data/"AWS Metadata Service v2 (IMDSv2)
v2Token-based metadata access with additional security
Endpoint:
http://169.254.169.254/latest/api/tokenRequired Headers:
X-aws-ec2-metadata-token-ttl-seconds: 21600cURL Command:
curl -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600"Google Cloud Metadata
Access to instance metadata and service account tokens
Endpoint:
http://169.254.169.254/computeMetadata/v1/instance/Required Headers:
Metadata-Flavor: GooglecURL Command:
curl -X GET "http://169.254.169.254/computeMetadata/v1/instance/" \
-H "Metadata-Flavor: Google"Azure Instance Metadata
Instance configuration and managed identity tokens
Endpoint:
http://169.254.169.254/metadata/instance?api-version=2021-02-01Required Headers:
Metadata: truecURL Command:
curl -X GET "http://169.254.169.254/metadata/instance?api-version=2021-02-01" \
-H "Metadata: true"Advanced Bypass Techniques
Decimal Encoding
Convert IP to decimal representation
2130706433 (127.0.0.1 in decimal)Hexadecimal Encoding
Use hex representation of IP addresses
0x7f000001 (127.0.0.1 in hex)Octal Encoding
Octal number representation
017700000001 (127.0.0.1 in octal)URL Encoding
Percent-encode characters in URLs
%31%32%37%2e%30%2e%30%2e%31DNS Rebinding
Dynamically resolve domain to internal IP addresses
evil.com → 127.0.0.1 (time-based)DNS Rebinding: Dynamic Origin Deception
DNS Rebinding is a sophisticated attack that dynamically resolves domain names to internal IP addresses, bypassing simple domain-based filters.
CRITICAL Bypass Technique
Attacker controls a domain that initially resolves to a public IP, passes validation, then resolves to 169.254.169.254 during the actual request.
Comprehensive Defense Strategies
Whitelisting vs Blacklisting
HIGH PRIORITYImplement strict allowlists of permitted destinations instead of trying to block known bad ones
Implementation Checklist:
- Define specific allowed domains and IP ranges
- Implement regex patterns for permitted URLs
- Regularly review and update whitelist entries
- Log all blocked requests for monitoring
Implementation:
if (!isWhitelisted(url)) { throw new SecurityException('URL not in allowlist'); }DNS Resolution Security
HIGH PRIORITYValidate both hostname and resolved IP addresses before making requests
Implementation Checklist:
- Resolve DNS before and after URL validation
- Block private IP ranges (RFC 1918, RFC 3927)
- Implement consistent DNS resolution timing
- Use secure DNS resolvers with monitoring
Implementation:
const resolvedIP = await dns.resolve(hostname); if (isPrivateIP(resolvedIP)) block();Network-Level Controls
HIGH PRIORITYImplement strict egress filtering
Implementation Checklist:
- Block access to metadata services
- Restrict outbound connections by default
- Allow only necessary external services
- Monitor and log all egress traffic
Implementation:
Outbound Firewall RulesApplication-Level Validation
MEDIUM PRIORITYInput sanitization and normalization
Implementation Checklist:
- Normalize URLs before validation
- Parse and validate each URL component
- Implement timeout controls
- Use dedicated HTTP client libraries
Implementation:
URL validation and parsing