EMZETT.SSRF: Server-side request forgery
In short: An attack in which an attacker gets a server to send requests on the attacker’s behalf to other addresses, often to internal systems.
In more detail: Many applications load content from a URL supplied by the user (image preview, webhook, import). If the application does not check the address, an attacker can point it to internal services that are not reachable from outside. The server becomes the attacker’s tool. Since 2021 SSRF has been its own item in the OWASP Top 10.
In Depth
Example
A page loads a profile picture from https://example.com/image.png. An attacker enters http://169.254.169.254/latest/meta-data/ instead, the address of the metadata service of many cloud providers. The server queries it and may return temporary access keys. Similarly, http://localhost:8080/admin or addresses in the company network can be addressed.
Why it is dangerous
The server is often inside the internal network and is treated differently by firewalls than outsiders. Consequences are reading internal data, triggering internal actions, scanning the internal network and, in cloud environments, theft of credentials. With blind SSRF the attacker does not see the response but can draw conclusions from timing or side effects.
Protective measures
- Define permitted targets by allowlist (domains, protocols, ports) instead of blocking the forbidden.
- Check the address after DNS resolution and reject internal ranges (127.0.0.0/8, 10.0.0.0/8, 169.254.0.0/16, …); keep DNS rebinding in mind.
- Do not follow redirects automatically, or check again.
- Allow only
httpandhttps, nofile:,gopher:or similar schemes. - Restrict the server’s outbound traffic by firewall; in the cloud harden the metadata service (for example IMDSv2).
Classification
SSRF resembles CSRF only in name: with CSRF an attacker abuses a user’s browser, with SSRF the application’s server.
See also: OWASP Top 10, Firewall, CSRF