SSRF / Cloud Metadata Lab

Server-Side Request Forgery has been a top-10 web vulnerability since OWASP added it in 2021. The reason it stays there: every cloud platform exposes a metadata service at 169.254.169.254 that, until you harden the chain end-to-end, hands out IAM credentials to anything that asks.

Capital One, 2019. 100 million records. The finding chain: a misconfigured WAF allowed an outbound request, the request hit IMDSv1, the response carried IAM credentials, and the attacker walked the perms across the account. Every link of that chain is fixable. Most production environments still haven't fixed all of them.

URL analyzer →

Paste any URL — or one of 8 attacker-crafted samples (decimal, hex, octal IPs, gopher://, alias hostnames). The analyzer decodes the canonical destination and flags 8 SSRF-relevant properties (SSRF01–SSRF08).

Targets →

The five endpoints attackers point SSRF at: AWS IMDS, GCP metadata, Azure IMDS, internal Redis, Kubernetes API. Real request/response pairs for each.

Hardening →

Four layers that work together: IMDSv2 (or platform equivalent), egress firewall, URL validation that resolves before checking, and identity-layer scoping. Ranked by impact.

Why this matters more in 2026 than 2019

Every AI agent that fetches URLs on a user's behalf is one misvalidated input away from being an SSRF tool. Browser-using agents, RAG pipelines that pull URLs from documents, summarize- this-link bots — all of them ship with the same primitive that Capital One's WAF had: "fetch what the input says, return the body."

That's why this lab pairs with Prompt Injection. A successful prompt-injection that gets the agent to fetch http://169.254.169.254/latest/meta-data/iam/... is the same Capital One attack chain — just routed through an LLM instead of a WAF rule.

Read in order

Analyzer — get a feel for what bypasses look like.
Targets — what's actually at the other end.
Hardening — what to ship.