A10 — Server-Side Request Forgery Insecure

1000-ft view: this page shows what happens when a server blindly fetches user-provided URLs: internal services exposed, metadata theft, port scans, and weird schemes being parsed as files. Each attack calls a deliberately vulnerable endpoint.

Attack 1 Attack 2 Attack 3 Attack 4 Attack 5

Attack 1 — Direct Internal IP

no CIDR checks

Why it’s bad: the server can reach addresses end-users can’t, like 127.0.0.1 or 169.254.169.254 (cloud metadata). Fetching these leaks secrets.

  1. Use the prefilled URL (loopback admin).
  2. Click Fetch (insecure) — the server will request it and echo whatever it gets.

Attack 2 — Hostname Resolves to Private IP

DNS tricks allowed

Why it’s bad: if code validates only the hostname string and never checks the resolved IP, an attacker can point a friendly name at a private address.

  1. Try http://localhost/… (resolves to 127.0.0.1).
  2. Click Fetch (insecure) to see the internal response.

Attack 3 — Open Redirect → Internal

follows redirects blindly

Why it’s bad: even if the first hop is public, a 302 to a private address will be followed by default with typical HTTP clients.

  1. We call our redirector, which forwards to 127.0.0.1.
  2. Click Fetch (insecure) — it should follow and reveal the internal page.

Attack 4 — Non-HTTP & Port Scanning

raw sockets allowed

Why it’s bad: exposing a “reachability test” gives attackers a port scanner from your network. They can probe SSH (22), SMTP (25), DB ports, etc.

  1. Probe any host:port (e.g., 127.0.0.1:22).
  2. Click Probe (insecure) to attempt a socket connection.

Attack 5 — Scheme Abuse & IPv6 Tricks

accepts anything

Why it’s bad: naive parsing treats file:// paths or IPv6 localhost as valid targets; userinfo like https://user:pass@host hides destination in logs.

  1. Click a preset to prefill a weird URL, then Fetch (insecure).
  2. Watch the server happily try to read local files or internal hosts.