Server-Side Request Forgery [CWE-918]

Server-Side Request Forgery or SSRF describes a case where the attacker can leverage the ability of a web application to perform unauthorized requests to internal or external systems.

Created: November 12, 2018
Latest Update: December 28, 2020

Table of Content

1. Description
2. Potential impact
3. Affected software
4. Exploitation Examples
5. Severity and CVSS Scoring
6. Mitigations
7. References

Want to have an in-depth understanding of all modern aspects of
Server-Side Request Forgery [CWE-918]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

Server-side request forgery or SSRF leverages the ability of a web application to perform unauthorized requests to internal or external systems. If the web application contains functionality that sends requests to other servers and the attacker can interfere with it, it is possible to turn your web server into a proxy. Depending on the configuration of the web server, an attacker can reach systems that are otherwise behind a firewall, or access private resources on the localhost itself.

2. Potential impact

The severity can vary from low to critical, depending on what the affected functionality can reach, either internally or externally.

Internal Service Interaction:

This is due to the vulnerable web application being used to interact with certain internal services, which in certain cases do not require authentication. Such examples are MongoDB and Redis. The impact can vary from minor information disclosure to database access, and even to remote code execution.

Information Disclosure:

Information disclosure via a port scan of internal hosts and enumeration of returned service banners is a common example. In some cases verbose error message will be returned to indicate the status of the port, in other cases a time-based approach must be used.

If the web application is being hosted via a hosting provider, it is possible to disclose its instance metadata, such as public SSH keys, credentials, and private IP address blocks.

Local File Disclosure:

The vulnerability can also be used in some cases to read contents of local files on the web server. This is achieved by using an alternate handler: 'file://'. This can also lead to web application source code, configuration files, and various other sensitive files being read by an attacker.

Phishing:

SSRF can be used in conjunction with HTTP redirects to redirect a victim to a malicious web page. This can be used to serve malware, to harvesting credentials.

3. Affected software

Any code residing on the web server that an attacker can manipulate to insert arbitrary locations. This includes base web application functionality or third-party components.

4. Exploitation Examples

Case 1:

A typical exploitation scenario for web applications hosted on hosting provider platforms such as Amazon EC2 and Digital Ocean is to request the instance metadata service of each provider, which returns information about the hosted instance, such as the private IP subnet, OpenSSH public keys, and account details.

An example request is as follows, the 'url' HTTP GET parameter is part of a vulnerable script that queries a remote URL and returns its contents to the page, in this case it will return the Amazon EC2 instance's public OpenSSH key:

GET /search.php/?url=http://[host]/latest/meta-data/public-keys/0/openssh-key HTTP/1.1
Host: companyx.com
Content-Type: text/html


Case 2:

Another common example is for the vulnerable application to be used to read local files that the web server has the relevant access rights to. Examples could be database credentials, web application source code, SSH keys, or configuration files.

The format of the following example request is the same as above. In this case it will return the '/etc/passwd' UNIX file, revealing the users of the underlying system. Note that the 'file://' handler is used instead of 'https://', this references local files:

GET /search.php/?url=file:///etc/passwd HTTP/1.1
Host: companyx.com
Content-Type: text/html


An example of vulnerable PHP code is shown below:

cURL:

<?php
$req = curl_init();
curl_setopt($req, CURLOPT_URL, $_POST["handler"]);
curl_setopt($req, CURLOPT_RETURNTRANSFER, 1);
$output = curl_exec($req);
curl_close($req);
echo $output;
?>


fopen():

<?php
if(isset($_GET['url']))
{
$url = $_GET['url'];
$grab = fopen($url, 'rb');
fpassthru($grab);
header('Content-Type: text/html');
echo $grab;
}
?>


An example of vulnerable Ruby code is shown below:

'open-uri' wrapper:

open(URI(params[:url])).read

An example of vulnerable Java code is shown below:

InetAddress inetAddress = InetAddress.getByName(url.getHost());
HttpURLConnection req = (HttpURLConnection)(url.openConnection());
req.setInstanceFollowRedirects(true);
req.connect();
IOUtils.copy(req.getInputStream(), out);


5. Severity and CVSS Scoring

The nature of what can be determined and accessed via the SSRF vulnerability will dictate the overall CVSS score. A few examples are shown below:

If a level of privilege is required to exploit the vulnerability, and the SSRF vulnerability can be used to access the cloud host instance metadata and return credentials which can be used to access the instance, it should be scored as follows:

8.8 [CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H] – High severity.

If no privilege is required, and the SSRF vulnerability can be used to determine open ports on the web server hosting the web application and other internal subnets, it should be scored as follows: 5.3 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N] – Medium severity.

If no privilege is required, and the SSRF vulnerability can be used to read local files from the web server (in this example, files that reveal sensitive information), it should be scored as follows:

7.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N] – High Severity

6. Mitigations

Maintain a whitelist of allowed DNS or IP addresses that the web application can access. If a blacklist is necessary, ensure that thorough validation is performed on user input, and that private IP addresses are not permitted. Ensure that only the HTTP(S) protocols can be used, and as before if it necessary to use alternate handlers, make sure robust whitelist is used. It is also necessary to prevent HTTP redirects.

Common Fix Errors and Bypasses:

It is dangerous to rely on a blacklist to filter user input, there are numerous techniques an attacker can use for various exploitation cases. A few basic examples are listed below:

IP Address Encoding:

Alternate IP addresses encodings can fool weak blacklists:

http://127.0.0.1:80/

http://0.0.0.0:80/ https://127.0.0.1:80/ http://[::]:80/ http://0000::1:80/ http://1077.0.0.1/ http://3232235521/

If certain domain names are blacklisted, HTTP redirects can be used to bypass this restriction:

http://companyx.app.localhost.127.0.0.1.nip.io - will use the ‘nip.io’ DNS service and resolve to localhost.

URL Scheme Manipulation:

file://\/\/etc/passwd

7. References

• CWE-918: Server-Side Request Forgery (SSRF) [MITRE]
• Server Side Request Forgery [OWASP]

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.

↑ Back to Top