SSRF (Server Side Request Forgery)

Server Side Request Forgery (SSRF) refers to an attack where the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or a modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like http enabled databases or perform post requests towards internal services which are not intended to be exposed.SSRF is usually used to target internal systems behind firewalls that are normally inaccessible to an attacker from the external network. Additionally, it’s also possible for an attacker to leverage SSRF to access services from the same server that is listening on the loopback interface (127.0.0.1).

Typically Server Side Request Forgery (SSRF) occurs when a web application is making a request, where an attacker has full or partial control of the request that is being sent. A common example is when an attacker can control all or part of the URL to which the web application makes a request to some third-party service.

The target application may have functionality for importing data from a URL, publishing data to a URL or otherwise reading data from a URL that can be tampered with. The attacker modifies the calls to this functionality by supplying a completely different URL or by manipulating how URLs are built (path traversal etc.).

When the manipulated request goes to the server, the server-side code picks up the manipulated URL and tries to read data to the manipulated URL. By selecting target URLs the attacker may be able to read data from services that are not directly exposed on the internet:

• Cloud server meta-data - Cloud services such as AWS provide a REST interface where important configuration and sometimes even authentication keys can be extracted
• Database HTTP interfaces - NoSQL database such as MongoDB provide REST interfaces on HTTP ports. If the database is expected to only be available to internally, authentication may be disabled and the attacker can extract data
• Internal REST interfaces
• Files - The attacker may be able to read files using file:// URIs

The attacker may also use this functionality to import untrusted data into code that expects to only read data from trusted sources, and as such circumvent input validation.

Mitigating Server Side Request Forgery (SSRF)

Whitelists and DNS resolution

Implementing simple blacklists or regular expressions directly on the user’s input to filter out which IP addresses or domains can make requests is a bad approach to take when mitigating an SSRF.

In general, blacklists are a poor security control because there will always be bypasses not envisaged by a developer. In this case, bypass by an attacker are as easy as using an HTTP redirect, a wildcard DNS service such as xip.io or even alternate IP encoding.

Instead, the most robust way of dealing with Server Side Request Forgery (SSRF) is to whitelist the DNS name or IP address which your application needs access to. If a whitelist approach does not suit your use case, and you must rely on a blacklist, it’s important to validate user input properly. An example of this is to not allow requests to private (“non-routable”) IP addresses (detailed in RFC 1918), however, in the case of a blacklist, the correct mitigation to adopt will vary from application to application. In other words, there is no universal “fix” to SSRF since it highly depends on the application’s functionality and business requirements.

Response handling

Ensuring that the response received by the remote server is indeed what the server is expecting is important to prevent any unforeseen response data leaking to the attacker. Above all else, under no circumstances should the raw response body from the request sent by the server be delivered to the client.

Disable unused URL schemas

If your application only makes use of HTTP or HTTPS to make requests, only allow those URL schemas. Disabling unused URL schemas will prevent a web application from making requests using potentially dangerous URL schemas such as file:///, dict://, ftp:// and gopher://.

Authentication on internal services

Services such as Memcached, Redis, Elasticsearch and MongoDB do not require authentication by default. Server Side Request Forgery vulnerabilities could provide an attacker with the opportunity to access some of these services without any authentication standing in the way. Therefore, it’s best to enable authentication wherever possible as another defense mechanism.