Server-Side Request Forgery: Definition, Mechanism, and Prevention

In the latest release of the OWASP Top 10 - 2021, SSRF has become the tenth most critical web application security risk. It indicates the prevalence of this vulnerability in comparison with previous releases in 2017 and 2013 which doesn’t make it in the top 10. Due to the prevalence and potential impact, it is added to the recent list and understanding this could be helpful to prevent unwanted events in the future.

What is SSRF?

Server-Side Request Forgery (SSRF) is a vulnerability that occurs when an attacker is able to manipulate an application to make unintended HTTP requests on behalf of the server. This can result in unauthorized access to internal or external resources, as the resource server trusts the request from the application server. This vulnerability can be exploited by an attacker to extract sensitive information or perform actions that the application server is authorized to do.

The problem

Validation

The application itself is meant to be accessible by the internal resources such as authentication database, stock database and so on. The issue lies to the validation of the request itself. In some cases, the resource server is not validating the requests assuming that everything that comes from the web application is legitimate.

The web application is facing the public or users directly, thus must be considered untrusted. What if the web application itself is letting the user modify the url parameter, body request or header request that is directly connected to the database? While it is true that such a vulnerability should not exist in the first place, failure to validate user input can lead to severe consequences. Attackers can exploit this vulnerability to retrieve sensitive information, modify or delete data, or execute unauthorized actions.

Network enumeration

Knowing that the SSRF attack may give the attacker access to the entire network, the developer should be aware that this vulnerability can lead to the attacker attacking the other backend system. Using some network enumeration techniques, the attacker can scan for the opening port inside the network by employing fuzzing tools. Once the attacker has identified open ports, they can attempt to exploit vulnerabilities in those systems to gain unauthorized access.

Types of SSRF

Regular SSRF / In band

This is the common common case of SSRF vulnerability where the resource server will give the response to the requester that is explicitly visible. In the other words, when the attacker is trying to access the resource server via SSRF (e.g admin page), the server will show up the content as the response of the attacker’s request (e.g. resource server is responding by displaying the admin page content).

It is the opposite of regular SSRF because the resource server will not display any content or return any response in the application frontend. The server will not give the requester any visible response just like regular SSRF, thus making it more challenging for the attacker to exploit this vulnerability.

Finding & exploiting SSRF

Before being able to exploit, the attacker needs to know how to find SSRF vulnerabilities.

IDOR vulnerability

One thing that is very common to look for is URL parameters or the editable HTTP request. It is very common for the website to interact using API. Oftentimes, the website sends data from the client side with the request attached to its HTTP Body.

Either the URL parameter or the body request is usually meant to do something that relies on user input. If this is the case, it could possibly lead to the SSRF vulnerability. However it is not always the case. The developer may also implement filtering or validation, so understanding how the filtering or validation may be useful.

Request Forgery

Once you find the IDOR vulnerability, you can try to modify the URL. Take a look at the request example below.

Header
POST /product/stock HTTP/2
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 107
Origin: https://example.com

Body
stockApi=http%3A%2F%2Fexample.com%2Fproduct%2Fstock%2Fcheck%3FproductId%3D1

What is this request doing is requesting for the current stock of product with ID 1. To make it easier for you to read, the request body is decoded into http://example.com/product/stock/check?productId=1. For SSRF, this URL can be replaced into, for example, http://localhost/admin.

The ‘localhost’ means that you are trying to access the internal network to leak sensitive data which is replaceable with 127.0.0.1. In a cloud environment which is very popular right now, changing this to 169.254.169.254 could work. Sometimes it may require you to specify a particular port you want to access, but for the above example, we just use the default port. Next, the ‘admin’ refers to the page we want to access.

Here we use http as a URL schema to get into the intranet. In some cases, changing this to another protocol like ftp:// or smb:// could help depending on the structure of the target’s network. In black-box testing scenario where you have no prior knowledge about how the internal network is structured, fuzzing can make all things easier for you. You can choose to use the payload or wordlists for the entire URL or just fuzzing some specific area like the port numbers.

DNS rebinding

In some cases, the application may restrict the access to the localhost. This could be caused by the use of a reverse proxy server that blocks localhost requests to the backend server. If this is the case then DNS rebinding could be another choice to penetrate the network.

To simplify, DNS rebinding occurs when an attacker tries to get the victim to access a website or domain that is controlled by the attacker. The attacker then changes the actual IP address of this domain to the localhost or any IP address in order to trick the victim into believing that the website is accessible from the trustable internal network. This attack relies on the web browser DNS resolution in order to bypass same-origin policy.

In the development phase, the developers often consider the local area network or the intranet as a safe haven. This could lead to severe consequences if the attacker can get into the inside of the victim’s network. This is the actual case of DNS rebinding attack, where the attacker is able to execute commands behind the victim’s firewall. Thus, every device within the network is vulnerable to the attack.

Open redirection

Open URL redirects bug can work as a stepping stone to discover SSRF. Sometimes, the websites’ developers are aware of this vulnerabilities, so the attacker won’t be able to redirect URL parameters to the external request (e.g. query to https://example.com).

With the open redirect vulnerability, it is the opposite. The website would be able to query any external domain and the attacker can exploit this by redirecting the URL to the one controlled by the attacker. This can lead to unintended or malicious redirection, as the redirect mechanism typically trusts the root domain and follows the redirect without verifying the final destination.

Preventing SSRF vulnerability

Sanitize and validate user input

Sanitizing and validating input is must not only in the case of SSRF but also for all kinds of vulnerabilities. Everything that comes from the user needs to be considered as untrusted and malicious.

Disable unused URL schemes

The unused and dangerous URL scheme needs to be blocked in order to block the attacker potentially using it in the future attacks. It includes file://, ftp://, gopher:// or any URL schemes that are not needed. It is better to limit the application to only using http://, https:// or any protocol that is specific to your business model to make requests.

Avoid sending raw response to user

Blind SSRF makes things more difficult for the attacker. For this reason, avoid using raw responses that are readable from the client-side in any circumstances.

Disable HTTP redirections

Disabling HTTP redirection entirely wouldn’t be practical in a real case scenario. Therefore, it is better to only whitelist the intended target location. This way, the application is enforced to follow this rule and rejects other redirect requests. Alternatively, generating a new token or unique ID for each redirection can help combat the issue.

Enforce network access control

Some services and devices may not have authentication mechanisms by default. However, it is important to use authentication for any internal service if possible. This is the action you can choose to reduce the impact of your other devices or resources once the attacker enters the intranet. Network security protocols like Kerberos can be helpful in this case.

In home networks, where IoT devices may get affected, it is also better to upgrade the firmware to get the latest security update, as the SSRF, as mentioned before, can affect the entire devices connected within the same network. In addition, proper access control is critical in preventing attackers from escalating their privileges vertically.