SSRF (Server-Side Request Forgery)

ID

ssrf

Severity

low (Phase A: URL-shaped param) / high (Phase B: + outgoing fetch in handler)

Remediation Complexity

medium

Remediation Risk

medium

Remediation Effort

medium

Family

API7:2023 - Server Side Request Forgery

CWE

CWE-918

Resource

configuration

Language

any (model-level) + Java / C# / Python / JS (AST Phase B) + Go / PHP (regex Phase B)

Description

Fires on endpoints that accept a URL-shaped input parameter (url, callback, redirect, webhook, target, image_url, …) — this is the Phase A shape signal.

Severity lifts to HIGH (Phase B) when the handler file also shows an outgoing HTTP-fetch call: Spring RestTemplate / WebClient, Python requests / httpx / urllib, JS fetch / axios / node-fetch, C# HttpClient, Go http.Get / http.Client.Do, PHP Guzzle / file_get_contents / curl_exec.

The detector is endpoint-shape oriented and complements the SAST taint-tracking SSRF rules, which trace user input through actual code paths.

Rationale

SSRF — Server-Side Request Forgery — lets the attacker turn the server into a proxy that makes outbound requests on the attacker’s behalf, from inside the network. The high-value targets are:

  • Cloud metadata services — 169.254.169.254 (AWS / GCP), 100.100.100.200 (Alibaba), metadata.google.internal. A single GET reveals temporary IAM credentials, instance-role tokens, and SSH keys.

  • Internal services not exposed externally — admin dashboards, internal APIs, Redis on 127.0.0.1:6379, Elasticsearch on :9200, Kubernetes API. Many of these have no authentication because they assumed network isolation.

  • Local files — file:///etc/passwd, file:///proc/self/environ if the fetch library honours non-HTTP schemes.

  • Cross-protocol attacks — gopher:// and dict:// schemes have been used to talk SMTP, Redis, FTP through HTTP-fetch libraries.

The 2019 Capital One breach is the canonical example: a server-side WAF was tricked into reading the EC2 metadata endpoint and leaking IAM credentials, leading to the exfiltration of 100M customer records.

Remediation

  • Allowlist target hosts. Validate the URL against a fixed set of expected destinations before fetching. Allowlist by resolved IP in addition to hostname — DNS rebinding bypasses hostname-only checks.

  • Reject private / loopback / link-local addresses. 127.0.0.0/8, ::1, RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), 169.254.0.0/16 (link-local — covers cloud metadata), 100.64.0.0/10 (CGNAT).

  • Reject non-HTTP(S) schemes. No file://, gopher://, ftp://, dict://, ldap://. Build an explicit allowlist {'http', 'https'}.

  • Disable redirects in the fetch client, or follow them through the same validation. A 302 to a private IP is the canonical SSRF bypass.

  • Use an egress proxy with policy enforcement — every outbound request hops through a proxy that enforces the allowlist centrally; individual services cannot misconfigure their way around it.

  • Block IMDSv1 on AWS — require session-token-based IMDSv2 so a single GET to 169.254.169.254 is no longer sufficient.

  • On the cloud side, scope the instance role tightly so an SSRF that does succeed leaks the minimum permissions.

Configuration

This detector does not require specific configuration. The URL-shaped parameter names and the outgoing-fetch call signatures are built in.

References