Guide 09 in Sarah’s Welcome to Web Security Series #

In this series, Sarah discusses some common vulnerability classes found in web security and how you can find and exploit them. Today’s focus is server-side request forgery (SSRF), a class of vulnerability that can cause the server-side application to make requests to an external (and often malicious) location.

Introduction #

Server-Side Request Forgery, usually abbreviated to SSRF, is a dangerous vulnerability that causes applications to fetch resources from an external URL. This means that attackers can redirect the application, causing significant damage to the system or gain access to authorised systems. In 2021, SSRF was number 10 in OWASP’s top 10 vulnerabilities as despite its low occurrence rate, it had high Exploit and Impact ratings. With the rise of cloud computing and the complexity of modern architectures, it is expected that SSRF will remain a dangerous exploit that cybersecurity professionals must remain vigilant of.

Finding SSRF Vulnerabilities #

SSRF vulnerabilities are often quite easy to find, as you simply have to look out for any requests that contain full URLs as a parameter. If that URL is also able to be manipulated by the user, it immediately indicates that it is vulnerable to SSRF. In other cases, only partial URLs are accessible, which means the scope of the vulnerability may be more limited but it is still possible to exploit it. SSRF can also be executed through a secondary process, for example through a data parser or through a referrer header. Once a suitable entry point is found, it is a matter of identifying all defences, bypassing them and choosing a suitable payload (which is usually just a malicious URL, either to an external resource or a privileged internal one).

Exploiting SSRF Vulnerabilities #

Generally speaking, there are two ways SSRF can be exploited. It can either be used against the server itself or to target other back-end systems, which are not directly accessible to the user yet are trusted sources by the server. In some rarer cases, SSRF vulnerabilities can lead to the application sending requests to any external IP address or domain, which is usually controlled by an attacker. In that case, the process is the same but the attacker may have to bypass more complex defence mechanisms in the network, which may prevent data from being sent out. However, in the case of attacking the server itself, attackers will make the request back to the server itself using its loopback network interface using an address like 127.0.0.1 or localhost. From here, an attacker can access restricted systems or information, such as configuration files or admin panels.

An example of this might be an online scoreboard system that shows a user’s score. The request to access that information might be done like this:

scoreApi = https://scoreboard.awesome-game.net:8080/users/scores?playerID=1337

Having determined that this system is vulnerable to SSRF and hosts an admin panel on the server at /admin-panel which is accessible to local users, we can modify the URL using the hostname localhost:

scoreApi = https://localhost/admin-panel

And this should redirect us to the admin-panel, bypassing the local user access controls. In cases where accessing the admin panel requires additional authentication, an attacker might have to combine the SSRF attack with another vulnerability to gain full control of the system.

The other way SSRF can be exploited, by attacking another back-end system, is similar. Rather than using the loopback network interface, we simply enter the IP address of the targeted system. Most of these systems will have non-routable private IP addresses.¹ Note that many of these back-end systems are often easier to attack because developers assume that the network topology will protect them.² Using the same example from before:

scoreApi = https://192.168.0.68/admin-panel

In some cases, developers will implement simple defences such as blacklists/whitelists in an attempt to filter user input though, if poorly configured, such defences are trivial to bypass. Simple URL encoding or obfuscation can often slip through weak filters.

Defending Against SSRF #

SSRF can be a difficult vulnerability to secure, given the complexity of the interactions involved. In its 2021 report, OWASP provides a high-level overview of different protections that can be used and it also has a highly detailed cheat sheet with examples. In short, defences should be employed at both the network and application level.

For the network layer, remote resources access functionality should be segregated to mitigate the impact of any SSRF attacks. Moreover, only essential intranet traffic should be allowed, following the “deny by default” principle. This can be enforced through firewalls’ configuration and/or through network access control rules.

At the application layer, user input sanitisation and validation is always a good idea. Where possible whitelists (allow lists) should be used instead of blacklists (deny list) as they are often a little harder to bypass. Furthermore, HTTP redirections should be disabled if possible and raw responses should not be sent to clients. In some cases, DNS rebinding or race conditions can lead to SSRF vulnerabilities so developers should be aware of URL consistency and any sensitive endpoints where race conditions may arise.

Conclusion #

Although SSRF attacks are not very common, they can have very serious impacts on systems and thus they should be carefully guarded against. SSRF attacks are also used as the first step in complex, multistage attacks so being able to prevent and defend against SSRF can go a long way in securing a system.

If you are interested in learning more about SSRF and web security, the WebSecurity Academy is a fantastic resource. You can create a free account and explore their labs here.