Skip to content

Server Side Request Forgery (SSRF)

Overview

Hostnames constructed from user-controlled data may allow an attacker to access unexpected resources, like private services running in the same network as your API. Access to those private services may be leveraged to escalate privileges, leak data, bypass IP filters, or exploit vulnerable services.

The impact of an SSRF can vary, depending on what services the API can communicate with, how much the attacker can control the payload, and whether the response is returned back to the attacker. Attackers may be able to: - Map your private network to gather information about internal services that could be used in follow-up attacks. - Access internal and private services, including cloud metadata services. With this access, attackers may obtain keys that allow full or partial control of your cloud infrastructure. - When combined with CRLF vulnerabilities, potentially escalate to remote code execution.

Endpoints accepting URL callbacks or webhooks are commonly vulnerable to SSRF attacks.

In addition, note that input parsing libraries like XML or SVG parsers, among others, may lead to unexpected user-controlled network requests and suffer from the same vulnerabilities.

Recommendation

We recommend working with your security team to build and verify your SSRF mitigation, whether or not you are using an existing library. As we mentioned, SSRF attacks are very tricky to mitigate correctly.

Input Validation

Validate user input before using it to construct web requests. We strongly recommend using libraries included with your web framework to validate urls constructed from user input. Make sure to read about the library to ensure that it protects against: - IPv4 and IPv6 private IPs - Public domains that resolves to a private IP - Domains that resolves to a public IP, but which HTTP redirects to a private IP - DNS rebinding, where the domain name resolves to a safe public IP during validation, but switches to a private IP when the

The best libraries will have the same interface as a regular HTTP client library, and perform all of those safety checks for you under the hood.

There are many tricks to bypass common SSRF validations. If you cannot reuse an existing library, you will need to block all connections to private IPs: - 127.0.0.1/8 - ::1 (IPv6) - 10.0.0.0/8 - 172.16.0.0/12 - 169.254.0.0/16 - 192.168.0.0/24 - For HTTP connections: Disable redirects or validate the redirect destination - To mitigate DNS rebinding attacks, resolve the DNS once and use the IP after validation instead of the domain name.

Restrict URL Schemes

Allow only URL schemes that your APIs uses. There is no need to have ftp://, file:// or even http:// enabled if your API doesn't require it.

Enable authentication on internal services

Make sure that authentication is enabled on any service that is running inside your network even if they don’t require it. Services like redis, mongo and others don’t require authentication by default, and this means they are common SSRF targets.

If authentication cannot be easily added, a weaker but easier option is to require a custom header when accessing an internal service. For instance, the Google Cloud metadata server -- a common target -- now requires requests to contain the following HTTP header: Metadata-Flavor: Google. SSRF requests will not usually contain this header, so SSRF requests will be rejected. Attackers will need to chain a SSRF vulnerability with a CRLF injection to inject the custom headers, raising the bar for attackers.

Proxies

When an API makes requests on behalf of users, using an external proxy can be a good idea. The proxy would be hosted on an isolated server without access to any internal network resources. Ideally, this should be set up with a cloud provider in a different account then where critical resources live.

Firewalls and Network Segmentation

Most API servers don’t need the ability to connect to all your internal network service. Using network segmentation or firewall rules can help and applying the principle of least privilege to outbound connections from your API can minimize the severity of SSRF vulnerabilities.

Examples

References