Server-Side Forgery

A10 is about forging requests on the server's behalf. If a web server fetches a URL provided by an attacker, the attacker can make the server request internal resources, cloud metadata, or other services — effectively using the server as a proxy into the network the server trusts. SSRF is the server-side cousin of CSRF (which forges requests from the browser). The CSRF course touched on this as a related attack; A10 brings it into focus.

A10: Server-Side Request Forgery (SSRF)

This category covers vulnerabilities where the server makes HTTP requests to a URL that an attacker controls (or influences). The attacker crafts a URL pointing to an internal resource, the server fetches it, and the attacker learns something (or causes an action) they shouldn't be able to. Common targets are internal APIs, cloud metadata services, localhost services, databases, and internal dashboards.

The Attack Landscape (What Attackers Target)

How SSRF Attacks Work

The attack flow:

1. Attacker-controlled URL parameter — app has a feature like "fetch and embed a preview of this URL" or "download a file from this URL" or "webhook callback to this endpoint."
2. Attacker crafts a malicious URL — pointing to an internal resource (e.g., http://localhost:8080/admin, or http://169.254.169.254/latest/meta-data/).
3. Server makes the request — the server's HTTP client (curl, requests, urllib) fetches the URL on the attacker's behalf.
4. Attacker gains information or causes an action — either the response is returned to the attacker (informative SSRF), or the attacker infers success from side effects (blind SSRF, timing, error messages).

SSRF vs CSRF (Cousins, Not Twins)

Both are forgery attacks, but the actor is different:

• CSRF (Cross-Site Request Forgery) — attacker tricks the user's browser into making a request (e.g., POST to /transfer-money). The request comes from the user's IP and session. The user's browser makes the request.
• SSRF (Server-Side Request Forgery) — attacker tricks the server into making a request (e.g., fetch a URL). The request comes from the server's IP and network privileges. The server makes the request.

CSRF is blocked by same-site cookies, CSRF tokens, and origin checks. SSRF is blocked by URL validation and network filtering (don't allow the server to request internal resources).

Defences Against SSRF

1. URL Validation / Allowlisting (the primary defence)

• Allowlist expected domains — if the feature is "fetch an image from a user-provided URL," explicitly list which domains are allowed (e.g., only images.cdn.example.com). Reject anything else.
• Block dangerous IP ranges — 127.0.0.1, localhost, 0.0.0.0, 169.254.169.254 (AWS), 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (private networks). Reject any URL that resolves to these.
• Validate after DNS resolution — an attacker might use DNS rebinding (first lookup returns attacker's IP, second returns localhost). Validate the resolved IP, not the hostname.

2. Network Filtering (defence in depth)

• Egress filtering — the server's firewall rules prevent outbound connections to internal IPs or certain ports (e.g., database ports 5432, 27017, 3306). The server can't reach them, even if SSRF is exploited.
• Restricted HTTP client — use an HTTP client that doesn't follow redirects (an attacker could redirect to an internal URL), doesn't support dangerous schemes (file://, gopher://), and enforces timeouts.

3. Least Privilege for Outbound Requests

• Separate network segment — outbound requests come from a sandboxed service with no access to internal APIs / databases / metadata.
• VPC/network isolation — the server is in a subnet that cannot reach internal services (only specific, whitelisted external services).

Hands-On Exercises