SSRF: how it works and how we can protect against it
Last updated
Was this helpful?
Last updated
Was this helpful?
An attacker can usually only reach applications that are exposed to the Internet. Applications running locally on the server (i.e. bound to the localhost interface - 127.0.0.1), or non-internet exposed applications running in the same network as the server are usually not reachable to the attacker. However, through a successful server-side request forgery attack the attacker can trick the server into executing requests and thereby circumvent these restrictions. Indeed, since these requests are initiated by the server, they are treated with much more trust.
Visually, the attack looks as follows:
Examples of requests to applications that are not intended to be exposed but that are likely to succeed when they are executed from the trusted server:
requests to the localhost interfaces;
requests to other applications on the same private network;
requests to servers that have IP filtering enabled.
The first defense would of course be to not have any back-end functionality in place that requires calling an external URL based on user input.
However, if such functionality is required, the following defense mechanisms should be deployed:
allowlist + input validation: ensure that the url that is called based on user input is part of a allowlist;
allowlist + network layer protection: ensure that only allowlisted urls can be reached via the network (e.g. through firewall configurations);
blocklist: if a allowlist approach is infeasible, ensure that there is a blocklist which at least comprises the localhost interface and all private internet address ranges (such as 192.168.0.0). This list must be completed with all internally used domain names if the blocklist check occurs at application level (since the DNS translation happens after the blocklist has been checked).
Some parts of this page are based on Server Side Request Forgery and Server Side Request Forgery Prevention by OWASP, which is licensed under FLOSS.