Overview
Hunting SSRF begins by finding server-side fetchers — features where the server fetches a URL, potentially under user influence. This lesson covers identifying them.
Learning objectives
- Define server-side fetchers.
- Identify features that fetch URLs server-side.
- Frame SSRF hunting around them.
Core concept
Server-side fetchers are features where the server makes an outbound request to a URL — image fetchers, link previews, webhooks, document/URL importers, PDF/screenshot generators, and integrations (from the web-security SSRF module). SSRF hunting targets these because if the destination is user-influenced, an attacker may make the server request unintended locations (internal systems, cloud metadata). Hunting starts by identifying the application's server-side fetchers — any feature that takes a URL (or something that becomes one) and has the server retrieve it — as SSRF candidates.
How it works
The researcher looks across the application (using endpoint/parameter/client-side discovery) for features where the server fetches a URL based on input: a parameter that is a URL, a feature that generates previews or thumbnails from a link, a webhook configuration, an importer that pulls from a URL, etc. Each is a candidate because the server — not the client — makes the request, so a user-controlled destination could be abused (SSRF). The researcher notes these fetchers as SSRF candidates to test safely and in-scope, focusing on whether the destination is user-influenced and inadequately restricted (next lessons).
Practical example
Hunting an in-scope application, the researcher identifies several server-side fetchers: an "import from URL" feature, a link-preview generator, and a webhook setting — each takes a URL and has the server fetch it. These are SSRF candidates because the destination is user-influenced. The researcher notes them for safe, in-scope testing of whether the URL is properly validated/restricted. Identifying the server-side fetchers focused the SSRF hunt on exactly the features where the vulnerability can arise.
Cybersecurity relevance
Identifying server-side fetchers is the essential first step in SSRF hunting: SSRF can only exist where the server fetches a user-influenced URL, so finding these features focuses the hunt (from the web-security SSRF module). SSRF is a high-impact, increasingly-important class (especially in cloud environments, where it can reach metadata services), making it valuable in bug bounty. It builds on discovery to locate URL-fetching features. For defenders, it underscores knowing which features make server-side requests and restricting their destinations. Locating the fetchers sets up destination-validation and impact assessment.
Common mistakes
- Not identifying server-side fetchers, so SSRF candidates are missed.
- Overlooking non-obvious fetchers (webhooks, importers, preview/PDF generators).
- Confusing client-side fetches with server-side ones (only server-side fetches enable SSRF).
Key takeaways
- Server-side fetchers are features where the server fetches a URL (image fetchers, previews, webhooks, importers, generators, integrations).
- SSRF hunting targets them because a user-influenced destination lets an attacker make the server request unintended locations.
- Identifying all server-side fetchers (via discovery) focuses the SSRF hunt on where the vulnerability can arise — a high-impact class, especially in the cloud.
Check your understanding
- What is a server-side fetcher, and why is it the focus of SSRF hunting?
- Give examples of application features that are server-side fetchers.