Server-side Request Forgery (SSRF)
SSRF tests whether a server-side URL fetch can be redirected to internal services, cloud metadata, or non-HTTP schemes. The exam emphasises filter bypass and recognising blind SSRF when no response is returned.
Core rules and concepts
- Entry points include image or PDF fetchers, webhooks, URL previews, import-from-URL features, and redirect-following HTTP clients.
- Targets:
127.0.0.1,localhost,169.254.169.254for AWS/Azure/GCP metadata, private ranges10/8,172.16/12,192.168/16, and internal services such as Redis on 6379. - Schemes beyond HTTP:
file://,gopher://,dict://,ftp://. - Bypasses: decimal
2130706433, octal0177.0.0.1, hex0x7f.1, IPv6::1,[::ffff:127.0.0.1], DNS rebinding, redirects to internal hosts, and userinfo tricks likehttp://[email protected].
Worked example
An avatar feature accepts avatar_url=https://cdn.example.com/a.png. Replace it with http://127.0.0.1:8080/; the response body contains internal admin HTML. Then request http://169.254.169.254/latest/meta-data/iam/security-credentials/, which returns a role name; append that name to retrieve temporary credentials. If the hostname is blocked, host a redirect on your server that 302s to the metadata address, or switch loopback notation to http://127.1/. Reasoning: allowlists that check only the supplied hostname are bypassed by redirects or alternate IP encodings.
Traps that cost marks
- Concluding there is no SSRF because nothing is reflected - blind SSRF still matters.
- Forgetting that AWS IMDSv2 requires a PUT request to obtain a token first.
- Only testing an external collaborator instead of internal addresses.
- Assuming a blocked hostname means the resolved IP is blocked.
- Ignoring non-HTTP schemes and redirect handling.