The authoritative source for the definition, vulnerable patterns, example attack scenarios (webhook to internal admin, file import hitting cloud metadata, URL preview with file://) and prevention guidance in this module. CWE reference: CWE-918 (Server-Side Request Forgery). This course is an independent study companion — not affiliated with or endorsed by OWASP.

Paige Thompson exploited an SSRF vulnerability in a misconfigured WAF running on AWS EC2 to access the instance metadata endpoint (169.254.169.254). She retrieved IAM role credentials and used them to download over 100 S3 buckets containing personal data for 100 million US customers and 6 million Canadian customers. Capital One paid an $80 million OCC fine and reached a $190 million class-action settlement. Thompson was convicted of computer fraud and abuse in June 2022. Referenced in slides 1, 5, 10, 11, 26. Primary sources: DOJ press releases (July 2019, June 2022), OCC enforcement action (August 2020), court documents (USDC W.D. Washington, Case 2:19-cr-00159).

An unauthenticated SSRF vulnerability in GitLab’s CI lint endpoint (/api/v4/ci/lint) allowed attackers to specify arbitrary URLs in YAML include directives. GitLab would fetch the specified URL server-side and return an error that included the response body — enabling cloud metadata endpoint access on cloud-hosted GitLab instances. The vulnerability affected GitLab CE/EE versions prior to 13.10.3, 13.9.6, and 13.8.8. Patch released June 2021. Referenced in slides 13, 26. Primary source: GitLab Security Advisory GLSA-2021-06-01, CVE-2021-22214 NVD entry.

AWS documentation on the EC2 instance metadata service at 169.254.169.254. IMDSv1 (GET-based, no session token) was the default at the time of Capital One. IMDSv2 (requires PUT to get a session token before making metadata requests) was introduced in November 2019 as a partial SSRF mitigation. AWS now recommends requiring IMDSv2 on all instances and allows disabling IMDSv1 entirely. Relevant to slides 5, 24.

Technical guidance on SSRF prevention including allowlist vs blocklist comparison, DNS rebinding attack patterns, IP range validation, redirect handling, and protocol restriction. Directly informs MIT 01 through MIT 04 in this module. The cheat sheet’s “Application Layer Defence” and “Network Layer Defence” sections map to MIT 01–05 and MIT 06 respectively.

DNS rebinding is a technique where an attacker controls a domain’s DNS record with a short TTL, causing it to resolve to different IPs at different times. In the SSRF context: validates as a public IP at check time, resolves to an internal IP at fetch time. The fix is to resolve DNS once, validate the resulting IP, and make the connection directly to the resolved IP. Relevant to slides 14 (webhook scenario) and 20 (MIT 02).

Google Cloud Platform exposes the metadata endpoint at metadata.google.internal (resolves to 169.254.169.254) and requires a specific header (Metadata-Flavor: Google) for requests. Azure exposes its IMDS at 169.254.169.254/metadata/. Both GCP and Azure have their own token formats for credential access. Relevant to slide 4 (cloud metadata vectors).

Interactive SSRF labs covering: basic SSRF against internal services, SSRF against the loopback interface, blind SSRF (where the response is not returned), SSRF bypass techniques (blocklist bypass, allowlist bypass, open redirect chains). Recommended hands-on practice after completing this module.

Comprehensive technical reference for SSRF exploitation techniques including: URL schemes (file://, dict://, gopher://), IP notation bypasses (decimal, octal, hex, IPv6), DNS rebinding, redirect chains, cloud provider metadata endpoints, and blind SSRF exfiltration. Useful reference for understanding the full range of bypass techniques that make blocklists unreliable.