SSRF and Unsafe Deserialization

Server-Side Request Forgery: When the Server Fetches What the Attacker Wants

Server-Side Request Forgery (SSRF) is a vulnerability that allows an attacker to coerce a server into making HTTP requests to internal hosts that the attacker cannot reach directly. The server becomes a proxy that accesses resources on behalf of the attacker, bypassing firewalls and network segmentation.

How SSRF Works

When a web application fetches a user-supplied URL without proper validation, the attacker can supply URLs that point to internal services:

# VULNERABLE — fetches user-supplied URL without validation
@app.route('/fetch')
def fetch_url():
    url = request.args.get('url')
    response = requests.get(url)  # Attacker controls the URL
    return response.text

An attacker supplies http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the server retrieves its own cloud IAM credentials.

SSRF Attack Targets

1. Cloud Metadata Endpoints

Cloud providers expose metadata services at 169.254.169.254 (AWS, GCP, Azure). These endpoints provide:

• Temporary IAM credentials
• User-data scripts (executed at instance boot)
• Instance configuration and network details

# AWS metadata — retrieve IAM credentials
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/my-role

# AWS user-data — retrieve boot scripts
curl http://169.254.169.254/latest/user-data

2. Internal Services

Internal services often have no authentication because they are only accessible from within the network:

• http://localhost:6379 — Redis (no auth by default)
• http://localhost:9200 — Elasticsearch (no auth by default)
• http://localhost:8080/manager/html — Tomcat manager (default credentials)
• http://127.0.0.1:22 — SSH (port scanning via response timing)

3. File Protocol Abuse

If the application uses a library that supports non-HTTP protocols:

file:///etc/passwd
file:///proc/self/environ
gopher://127.0.0.1:6379/_*1%0d%0a$4%0d%0aFLUSHALL%0d%0a

4. DNS Rebinding

An attacker controls a domain that resolves to a public IP during validation but to an internal IP (e.g., 127.0.0.1) when the server actually fetches it. This bypasses URL validation that checks the resolved IP.

SSRF Impact

• Credential theft: Cloud metadata endpoints expose temporary credentials
• Internal network scanning: Response timing and content reveal internal hosts and ports
• Data exfiltration: Internal services (Redis, Elasticsearch) can be read or modified
• Remote code execution: Some internal services allow command execution (e.g., Jenkins script console)

Real-World SSRF

In 2019, Capital One suffered a breach that exposed 100 million customer records. An SSRF vulnerability in a web application firewall allowed the attacker to access the AWS metadata service and retrieve temporary credentials for an IAM role with excessive permissions. The attacker then used these credentials to access S3 buckets containing sensitive data.

Defending Against SSRF and Understanding Deserialization Attacks

SSRF Defense Layers

1. URL Validation (Allow-List)

The most effective defense is to validate user-supplied URLs against an allow-list of permitted domains and IP ranges:

import ipaddress
from urllib.parse import urlparse

def is_safe_url(url):
    parsed = urlparse(url)
    
    # Only allow HTTP/HTTPS
    if parsed.scheme not in ('http', 'https'):
        return False
    
    # Resolve the hostname and check the IP
    try:
        ip = ipaddress.ip_address(socket.gethostbyname(parsed.hostname))
    except socket.gaierror:
        return False
    
    # Block private, loopback, and link-local addresses
    if ip.is_private or ip.is_loopback or ip.is_link_local or ip.is_reserved:
        return False
    
    return True

2. Network-Level Controls

• Egress filtering: Configure firewalls to block outbound requests from application servers to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16).
• Separate metadata endpoint: Use AWS IMDSv2 (Instance Metadata Service Version 2) which requires a session token obtained via a PUT request, preventing simple SSRF attacks.
• Disable unnecessary protocols: If the application only needs HTTP/HTTPS, disable support for file://, gopher://, dict://, etc.

3. Response Validation

• Do not return the full response body to the user. Parse and sanitize the response.
• Set a maximum response size to prevent large data exfiltration.
• Set a short timeout to prevent slow-response attacks.

Unsafe Deserialization

Deserialization is the process of converting a serialized byte stream back into an object. Unsafe deserialization occurs when an application deserializes untrusted data without verification, allowing attackers to instantiate arbitrary objects and trigger unintended code paths.

How deserialization attacks work:

1. Attacker crafts a serialized object that, when deserialized, executes a "gadget chain" — a sequence of method calls that leads to code execution.
2. The application deserializes the object without checking its type or integrity.
3. The gadget chain executes during or after deserialization.

Java deserialization example:

// VULNERABLE — deserializes untrusted data
ObjectInputStream ois = new ObjectInputStream(request.getInputStream());
Object obj = ois.readObject();  // Attacker controls the byte stream

Python pickle example:

# VULNERABLE — deserializes untrusted data
import pickle
data = pickle.loads(request.POST['data'])  # Attacker controls the data

PHP unserialize example:

// VULNERABLE
$data = unserialize($_POST['data']);

Gadget Chains

A gadget chain is a sequence of existing methods in the application's codebase (or its dependencies) that, when called in sequence during deserialization, produce a dangerous effect (command execution, file write, etc.). Common gadgets include:

• Templates: freemarker.template.utility.Execute (Java)
• Commons Collections: InvokerTransformer chain (Java)
• YAML: yaml.load with !!python/object/apply:os.system (Python)

Deserialization Defense

1. Do not deserialize untrusted data. Use JSON or other data-only formats instead.

2. If deserialization is required:

• Use integrity checks (HMAC signatures) to verify the data has not been tampered with:

import hmac, hashlib

def safe_deserialize(data, secret):
    # data = signature + payload
    sig, payload = data[:32], data[32:]
    expected = hmac.new(secret, payload, hashlib.sha256).digest()
    if not hmac.compare_digest(sig, expected):
        raise ValueError('Invalid signature')
    return pickle.loads(payload)

• Use type restrictions (e.g., Java's ObjectInputFilter in newer versions)
• Use safe serialization formats (JSON, Protocol Buffers) instead of native serialization

3. Keep dependencies updated. Many deserialization gadgets exist in third-party libraries (e.g., Apache Commons Collections, Spring Framework).