Server-side request forgery (SSRF) in depth
You see how URL-taking features open the server to the internal network, show in the lab why block-lists are not enough, and build a lasting defence with allow-lists, an egress proxy and metadata protection.
Level 301 · 15 lessons · 12 practice labs
Lessons
How SSRF is born
- Features open to SSRF: URL previews, webhooks, PDF rendering and imports
- SSRF in code: fetching the user-supplied URL directly
- Impact: internal services, admin interfaces and cloud metadata
- Blind SSRF and observing the outbound request
- Short task: list four URL-taking features in the lab app and rank them by risk
Weak defences
- Why block-lists fail: alternative IP notations
- Redirects and DNS rebinding
- URL parser differences: the validator and the fetcher see different things
- Non-HTTP schemes: file, gopher and dict
- Short task: show in the lab that a block-list can be bypassed
Solid defence
- Allow-list design: resolve, validate and connect to the same IP
- An egress proxy and network segmentation
- IMDSv2 and similar protections for the cloud metadata service
- Catching SSRF in egress logs and DNS
- Capstone: redesign a webhook feature against SSRF and retest it
Practice labs
- Rank the URL-taking features by risk: Find the four features in the lab app that take a URL, test where each can send requests and rank them by risk.
- An internal page in PDF generation: Prove the HTML-to-PDF service puts an internal admin page into the PDF and turn off external resource loading.
- Blind SSRF: no response, but a trace: Confirm the SSRF in an import feature that returns nothing through a connection seen in the lab's request catcher and close it.
- A block list misses another IP notation: Show in the lab a filter that blocks 127.0.0.1 but misses other notations of the same address and swap the block list for an allow list.
- Validation bypassed with a redirect: Show the request follows a redirect from an allowed domain to an internal address and turn off redirect following or check each hop.
- A local file through the file scheme: Prove the URL feature accepts the file scheme and allow only https.
- A second resolution through DNS rebinding: Show the flaw with a lab domain that resolves to a different IP between check and request and apply validation that connects to the resolved IP.
- Parser mismatch: the validator and the requester: Show the URL validation library and the HTTP client read the same address differently and fix it to use one parser.
- Close the internal network with an egress proxy: Route the app's outbound requests through the lab egress proxy and show requests to internal addresses are refused.
- Requiring a session token on the metadata service: Switch the mock metadata service to the token-requiring version and show old-style requests no longer return data.
- Catch SSRF in DNS and egress logs: Write a query that catches the app server's DNS lookups and outbound requests to unusual domains.
- Redesign a webhook feature: Rewrite the webhook feature of the fictional Orvik Notify service with a resolve-check-connect pattern and test it against every bypass attempt.
About this course
You see how URL-taking features open the server to the internal network, show in the lab why block-lists are not enough, and build a lasting defence with allow-lists, an egress proxy and metadata protection.
What you will learn
- How SSRF is born
- Weak defences
- Solid defence
Prerequisites
You should be comfortable with the level 101 and 201 topics of the same path.
Lab environment
Lessons run on your own Kali Linux desktop in the browser, with the tools ready in their windowed interfaces. Nothing to install; a computer screen is recommended.
Frequently asked questions
- Is this course right for my level?
- The course is at level 301; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.