Accueil / retour à la liste

Server-Side Request Forgery (SSRF)

10) Server-Side Request Forgery (SSRF)

What it is

SSRF happens when attacker input controls a URL/request that the server makes.

Important point:

  1. The attacker is outside.
  2. But the request is sent by your trusted server.
  3. So attacker can reach places they normally cannot.

Very simple picture

Your app has feature: “fetch URL / import from URL / generate preview from link.”

Flow:

  1. User gives URL.
  2. Server fetches URL.
  3. Attacker gives malicious internal URL instead.
  4. Server fetches internal/private resources on attacker’s behalf.

Why it is dangerous

Your server may access:

  1. Internal admin panels (http://internal-admin)
  2. Private services in VPC
  3. Cloud metadata endpoints (credentials)
  4. Localhost-only services (127.0.0.1)
  5. Non-HTTP internal protocols (in some cases)

So SSRF can become:

  1. Data theft
  2. Cloud credential theft
  3. Internal network scanning
  4. Remote code execution chain (depending on reachable internal services)

Step-by-step attack example (cloud metadata case)

  1. App has endpoint /preview?url=....
  2. Attacker sends URL pointing to cloud metadata service.
  3. Server fetches metadata because it can access it locally.
  4. Response includes temporary cloud credentials.
  5. Attacker uses credentials to access storage/secrets.
  6. Breach escalates quickly.

Common SSRF entry points

  1. URL preview or screenshot service
  2. Import-by-URL feature
  3. Webhook tester/callback feature
  4. PDF/image renderer fetching remote assets
  5. SSO/OpenGraph/avatar fetchers
  6. “Ping this host” admin utilities

Tricky concepts explained

1) Why server-side is special

If attacker calls internal URL directly, firewall blocks them. But your server is inside trusted network, so it can reach internal targets. SSRF abuses that trust position.

2) URL parser confusion

Attackers bypass weak filters using:

  1. Alternative IP forms
  2. Redirect chains
  3. DNS rebinding
  4. Mixed schemes/userinfo tricks

So simple string checks like “block if contains 127.0.0.1” are not enough.

3) Allowlist vs blocklist

  1. Blocklist: “deny bad destinations” (usually bypassable).
  2. Allowlist: “permit only known safe destinations.”

For SSRF, allowlist is far safer.

4) DNS rebinding

Domain initially resolves to safe IP during validation, then changes to internal IP during request. If app validates only once and trusts DNS too much, attacker can bypass.

How to prevent SSRF (clear implementation order)

  1. Avoid server-side URL fetching unless business-critical.
  2. If required, use strict destination allowlist (domain + scheme + port).
  3. Resolve hostname and verify final IP is not:
  4. Loopback (127.0.0.0/8, ::1)
  5. Link-local
  6. Private/internal ranges
  7. Metadata IPs
  8. Disable or tightly control redirects.
  9. Re-validate destination after each redirect.
  10. Allow only needed protocols (https mostly); block file://, gopher://, etc.
  11. Use egress firewall rules so app can only call approved external targets.
  12. Put URL-fetching service in isolated network segment with minimal privileges.
  13. Require short timeouts, response size limits, and method restrictions (GET only if possible).
  14. On cloud, harden metadata access (e.g., IMDSv2 and block metadata where not needed).
  15. Log outbound requests and alert on suspicious destinations.

Detection checklist

  1. Do any endpoints accept user-supplied URLs?
  2. Can they reach localhost, private IPs, metadata addresses?
  3. Are redirects followed without strict validation?
  4. Is egress network access open to the internet/internal network broadly?
  5. Are suspicious outbound calls logged and alerted?

Business impact

  1. Exposure of secrets and cloud credentials.
  2. Lateral movement into internal network.
  3. Compromise of internal admin tools/services.
  4. Full environment takeover when chained with other weaknesses.