Server-Side Request Forgery
web · medium · +35 XP
// what is Server-Side Request Forgery?
Server-Side Request Forgery (SSRF) = the server itself acts as a confused-deputy proxy. You give it a URL; it fetches that URL with its own network access. Reach internal services that aren't exposed to the public internet — admin panels, the cloud metadata service (169.254.169.254 → IAM creds → game over).
// how attackers detect it
- [01]Find URL-fetch endpoints — webhooks, image-from-URL features, PDF generators, link previews.
- [02]Replace the URL with
http://127.0.0.1/,http://[::1]/,http://0.0.0.0/. Does the response shape differ? - [03]Cloud-specific: try
http://169.254.169.254/latest/meta-data/iam/security-credentials/(AWS),http://metadata.google.internal/(GCP).
// how defenders prevent it
- ✓Network-layer isolation: outbound from the web service goes through a proxy that allow-lists external hosts.
- ✓Resolve the hostname server-side, then check the resolved IP isn't in
127.0.0.0/8,10/8,172.16/12,192.168/16,169.254/16, IPv6 loopback. - ✓AWS IMDSv2 (session-token required) defeats most metadata-SSRF attacks. Use it. GCP & Azure have equivalents.
// real-world incidents
CVE-2019-3396
Capital One breach (Paige Thompson)
WAF SSRF → IMDS → IAM creds → 100M customer records.
CVE-2021-43798
Grafana plugin path traversal + SSRF
Plugin /public path leak chained with SSRF.
// hands-on tips for this lab
- ›Blocklist contains
localhost,127.0.0.1,0.0.0.0. Tryhttp://[::ffff:127.0.0.1]/admin,http://2130706433/admin,http://0x7f.0.0.1/admin.
was this lesson helpful?