Learn About Server-Side Request Forgeries (SSRFs)
By: Vickie Li
Tags: Cybersecurity, Technology, Programming, Computer Science, Software Development

Preventing SSRFs

SSRFs happen when servers need to send requests to obtain external resources. For example, when you post a link on Twitter, it would need to fetch an image from that external site to create a thumbnail. This is a normal and necessary behavior. But if the server does not stop users from accessing internal resources, SSRF vulnerabilities occur.

To prevent SSRFs, you need to validate the user-supplied URL. And depending on the external resources you are trying to fetch using that endpoint, you can either implement a whitelist or a blacklist to filter the URLs.

First, you can check if the URL belongs to an approved whitelist if you know where you need to fetch resources from. For example, if you are only fetching images from a particular server, you can limit requests to that IP address or hostname. If you are using a whitelist, make sure that you fix open redirect vulnerabilities within the whitelisted domains. If attackers can find an open redirect within a whitelisted domain, they can request a whitelisted URL that redirects to a restricted internal URL. And make sure that the regexes you are using are properly designed. For example, a weak regex pattern that simply checks if a URL contains the legitimate domain can be bypassed easily with these URLs:

https://victim.com.attacker.com

https://attacker.com/victim.com

On the other hand, if you need to allow users to fetch resources from arbitrary locations, you need to use a blacklist to restrict access to sensitive internal resources. When you are using a blacklist, make sure that you are accounting for different encoding schemes. For example, does your blacklist filter out the same URLs, but in hex, octal, dword, URL, and mixed encoding? And does it account for both internal IPv4 and IPv6 addresses?

A way that attackers can bypass blacklists — even when they are well designed — is by using redirects. Attackers can use a URL that they control but redirects to the blacklisted address. For example, they can host a page that redirects to the local address like this:

<?php header(“location: http://127.0.0.1"); ?>

This way, when your server requests the attacker’s page, it is actually redirected to a restricted internal address. You can prevent this type of attack by disabling the support for the following of the redirects in your web client.

Another way attackers bypass blacklist protections is by modifying the DNS records of a domain they control and making it point to internal addresses. For example, they can create a DNS A record and make http://attacker.com resolve to a sensitive internal address. When your server requests http://attacker.com, it would think that that domain is located at the internal address and access that address instead! So when you are validating domain names, you also need to ensure that the user-provided domain does not resolve to an internal IP address.

SSRFs are a dangerous vulnerability that can compromise an entire network. But they can be prevented with a good amount of diligence and proper filtering.

That’s it for today’s security lesson. Thanks for reading!