Server-Side Request Forgery (SSRF)

Technical Description

Server-Side Request Forgery (SSRF) occurs when an attacker can influence the destination of HTTP requests made by a server-side application. Instead of the application fetching the intended resource, the attacker redirects the request to an internal service, cloud metadata endpoint, or arbitrary external host.

The fundamental issue is that the server acts as a proxy, and any network access the server has becomes available to the attacker. This is particularly dangerous in cloud environments where instance metadata services (IMDS) are accessible at well-known addresses like http://169.254.169.254/.

Common SSRF attack patterns include:

• Cloud Metadata Exfiltration: Requesting http://169.254.169.254/latest/meta-data/iam/security-credentials/ on AWS to steal IAM role credentials. Similar endpoints exist on GCP (metadata.google.internal), Azure (169.254.169.254), and DigitalOcean.
• Internal Service Access: Reaching databases, admin panels, monitoring dashboards, and other services bound to 127.0.0.1 or internal VPC addresses that are not exposed to the internet.
• Port Scanning: Using the server as a pivot to map internal network topology by observing response times and error messages for different internal IP:port combinations.
• Protocol Smuggling: Exploiting URL parsers that support file://, gopher://, dict://, or other schemes to interact with non-HTTP services. The gopher:// protocol is especially dangerous as it allows sending arbitrary bytes to TCP services.

A typical vulnerable endpoint:

@app.route('/fetch')
def fetch_url():
    url = request.args.get('url')
    response = requests.get(url)  # No validation on destination
    return response.text

SSRF is often categorized as blind (the attacker cannot see the response but can observe side effects like timing) or full-read (the response content is returned to the attacker).

Real-World Impact

SSRF has been the initial access vector for some of the most significant cloud breaches:

• Capital One (2019): An SSRF vulnerability in a WAF allowed the attacker to query the AWS metadata service, obtain temporary IAM credentials, and exfiltrate over 100 million credit applications from S3 buckets. The breach cost Capital One over $300 million.
• Shopify (2020): Researchers demonstrated SSRF through the platform’s integration features, accessing internal Google Cloud infrastructure and earning a $15,000 bounty.
• GitLab (Multiple): GitLab has patched numerous SSRF vulnerabilities in its import/export and webhook features, with several enabling internal network access.

SSRF is especially impactful in environments with flat internal networks and cloud deployments that rely on metadata services for credential distribution.

Detection Methodology

SSRF detection requires careful analysis of all server-side request functionality:

1. Input Vector Mapping: Identify every feature where the application makes server-side HTTP requests based on user input: URL fetchers, webhook configurations, file imports, PDF generators, image processors, and OAuth callbacks.
2. Out-of-Band Testing: Supply URLs pointing to attacker-controlled servers (Burp Collaborator, interactsh) to confirm the server makes outbound requests. This detects blind SSRF where responses are not returned.
3. Internal Address Probing: Test with 127.0.0.1, localhost, 0.0.0.0, [::1], cloud metadata IPs, and private RFC 1918 ranges. Test bypass techniques: decimal IP encoding (2130706433 for 127.0.0.1), hex encoding, DNS rebinding, and URL parser inconsistencies.
4. Redirect Chaining: Test whether the application follows HTTP redirects. A redirect from an allowed external host to an internal address can bypass allowlist validation.
5. Protocol Testing: Attempt non-HTTP schemes (file:///etc/passwd, gopher://, dict://) to identify protocol-level SSRF.

How Revaizor Discovers This

Revaizor’s AI agents excel at identifying SSRF because they combine automated scanning with the reasoning of an experienced attacker:

• Comprehensive Surface Discovery: Revaizor maps every endpoint that accepts URLs, file references, or webhook configurations, including indirect vectors like PDF rendering engines, email template previews, and image processing pipelines that many scanners overlook.
• Bypass Intelligence: When basic SSRF payloads are blocked, Revaizor systematically tests bypass techniques: IP encoding variants, DNS rebinding, URL parser differentials, redirect chains, and protocol switching. The agents adapt their strategy based on observed filtering behavior.
• Cloud-Aware Exploitation: Revaizor identifies the cloud provider from reconnaissance data and targets provider-specific metadata endpoints, testing IMDSv1 and IMDSv2 (AWS), project metadata (GCP), and managed identity endpoints (Azure).
• Impact Demonstration: When SSRF is confirmed, Revaizor attempts to escalate by retrieving credentials, mapping internal services, and demonstrating lateral movement potential, providing a clear picture of the blast radius.

Remediation

Effective SSRF mitigation requires defense at multiple layers:

import ipaddress
from urllib.parse import urlparse

BLOCKED_RANGES = [
    ipaddress.ip_network('127.0.0.0/8'),
    ipaddress.ip_network('10.0.0.0/8'),
    ipaddress.ip_network('172.16.0.0/12'),
    ipaddress.ip_network('192.168.0.0/16'),
    ipaddress.ip_network('169.254.0.0/16'),  # Link-local / cloud metadata
]

def is_safe_url(url):
    parsed = urlparse(url)
    if parsed.scheme not in ('http', 'https'):
        return False
    # Resolve hostname to IP to prevent DNS rebinding
    ip = ipaddress.ip_address(socket.gethostbyname(parsed.hostname))
    return not any(ip in network for network in BLOCKED_RANGES)

Additional defensive measures include:

• Network Segmentation: Place application servers in network segments that cannot reach sensitive internal services. Use security groups and firewall rules to restrict outbound traffic to only necessary destinations.
• IMDSv2 Enforcement: On AWS, require IMDSv2 (token-based) which mitigates most SSRF-based metadata theft. Disable the metadata service entirely for instances that do not need it.
• Allowlist Over Denylist: If the application only needs to fetch from known domains, use a strict allowlist rather than attempting to block internal addresses (denylist approaches are consistently bypassed).
• Disable Unnecessary Protocols: Ensure HTTP clients do not follow non-HTTP redirects and cannot use schemes like file:// or gopher://.
• DNS Resolution Validation: Resolve the hostname and validate the IP address before making the request. Re-resolve after any redirects to prevent TOCTOU attacks via DNS rebinding.