OSWA study materials
OSWA study resources

OSWA: Server-side Request Forgery (SSRF)

OSWA · Work through your exam, one topic at a time.

All guide sections

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.254 for AWS/Azure/GCP metadata, private ranges 10/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, octal 0177.0.0.1, hex 0x7f.1, IPv6 ::1, [::ffff:127.0.0.1], DNS rebinding, redirects to internal hosts, and userinfo tricks like http://[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.