SSRF Testing Against Cloud Metadata Boundaries
SSRF turns a server’s network position into an attacker-controlled request capability. Cloud metadata endpoints make this severe when workload credentials are reachable. CWE-918 describes server-side request forgery; AWS documents IMDSv2 token use.
Test network assumptions
Exercise URL features with loopback, private ranges, link-local addresses, redirects, alternate IP notation, and DNS changes after validation. Example: an image importer follows a redirect from public host to metadata address. Example: a PDF previewer resolves a hostname to a private service after initial allowlist check.
Metadata boundary checklist
| Boundary | Verify | Failure signal |
|---|---|---|
| egress | deny metadata and private ranges | connection blocked |
| metadata | IMDSv2 required | v1 request fails |
| workload role | minimum permissions | credential cannot list unrelated data |
| fetcher | no automatic redirects | redirect recorded and denied |
Decision rule: a URL-fetching workload must not reach metadata services unless that path is expressly required and separately authorized.
Remediation
Use outbound proxy policy, IMDSv2, short-lived workload credentials, and destination validation after every redirect and resolution. Tests require written authorization because they touch internal boundaries. Web application testing can validate approved paths.
Prove the boundary in deployment
Test application behavior and network behavior separately. Validation must evaluate every resolved address, including IPv6, and redirect handling must repeat destination checks before connection. Do not rely on a hostname appearing public. Egress policy should deny metadata and private destinations even if a future code path misses validation. AWS documents that IMDSv2 uses a token acquired by PUT and can be required so tokenless IMDSv1 calls receive unauthorized responses.
Capture an approved test against blocked metadata, loopback, private address, link-local address, and public-to-private redirect. Confirm the fetcher cannot use proxy variables or inherited credentials to bypass policy. Keep workload role permissions narrow so a broken request cannot enumerate unrelated resources. Owner: platform owner. Pass: every prohibited destination is blocked and no credential response appears. Fail: any fetcher path reaches metadata or internal service. Exceptions need intended destination, business rationale, egress rule, compensating control, risk approval, remediation owner, and expiry.
Metadata test boundary
Never use production credentials. In an approved environment, test fetcher inputs targeting cloud metadata IPv4 and IPv6 endpoints. Expected result: connection denial before a response body is read. Separately inspect metadata setting and demonstrate tokenless access fails where IMDSv2 is required. Preserve redacted policy evidence.
Metadata egress proof
Expected output: fetch request ID, parsed destination, every A and AAAA answer, redirect hop, firewall verdict, IMDS option, workload role. This network trace distinguishes resolver failure from metadata reachability.
Worked failure: A public image URL redirects to a link-local address. The fetcher must stop before reading headers and egress logs must show the denied destination.
Edge case: A service may need metadata through an approved SDK path. That path must not grant the user-controlled fetcher the same network route.
Closure test: Run the redirect case after a DNS cache refresh. Closure passes when application and network telemetry agree that no metadata response was returned.
Network control exercise
List every component that can originate HTTP, DNS, image conversion, document rendering, or callback traffic. The inventory often finds workers that do not use the main fetch helper. For each component, record subnet, security group or firewall policy, proxy route, and service identity. A denial test should include decimal and IPv6 literals, not only a familiar metadata hostname. It should also verify that redirect response bodies are discarded rather than partially processed before destination review.
When a workload legitimately accesses instance metadata, isolate that client path from user input. It should request only documented metadata through an SDK or fixed destination and should not inherit arbitrary URL, header, method, or proxy configuration. Review role permissions after metadata hardening: blocking the endpoint reduces exposure, while least privilege reduces effect if another credential path exists. Keep an emergency rollback instruction, but require recorded platform approval before weakening IMDS settings.
Metadata defense needs observability during failed fetches. Emit a bounded metric or audit category for denied destination class without storing requested URL query values. Compare policy denies with firewall denies; a mismatch suggests one layer is bypassed or misconfigured. Test container and host networking separately because hop limits and proxy paths can differ. The closure record should name the runtime image and network policy revision used for the test.
Final metadata test confirms untrusted input cannot select metadata destination, method, headers, or proxy route. Expected result: legitimate fixed client remains functional while user-controlled fetches are denied before connection. Edge case: IPv6 or DNS resolution reaches equivalent local address; include it in enforcement tests. Close after runtime identity and network policy evidence match deployed workload.