title: 【Reprint】What is Server-Side Request Forgery (SSRF)?
date: 2021-08-14 09:01:57
comment: false
toc: true
category:
- Share
tags: - Server-Side
- Forgery
- SSRF
- Request
This article is reprinted from: What is Server-Side Request Forgery (SSRF)?
- Original link: What is Server-Side Request Forgery (SSRF)?
- Original author: Ian Muscat
- Translation source: Juejin Translation Project
- Permanent link to this article: github.com/xitu/gold-m…
- Translator: MoonBall
- Proofreader: PassionPenguin, kamly
Server-Side Request Forgery (SSRF) vulnerabilities allow attackers to send malicious requests from the backend services of vulnerable applications. Attackers typically use SSRF to target internal systems located behind firewalls, which cannot be accessed from the external network. Attackers can also exploit SSRF to access services available through the server's loopback interface (127.0.0.1).
SSRF vulnerabilities occur when an attacker can fully or partially control the requests sent by the application. A common example is when an attacker can control the URL of a third-party service, and the application will initiate a request to that URL.
Here is a PHP example that is vulnerable to SSRF attacks.
<?php
/**
* Check if the GET variable 'url' is set
* For example - http://localhost/?url=http://testphp.vulnweb.com/images/logo.gif
*/
if (isset($_GET['url'])){
$url = $_GET['url'];
/**
* Initiate a request vulnerable to SSRF because
* there is no validation of $url before making the request
*/
$image = fopen($url, 'rb');
/**
* Send the correct response header
*/
header("Content-Type: image/png");
/**
* Respond with the content of the image
*/
fpassthru($image);}
In the example above, the attacker can fully control the url parameter. The attacker can make GET requests to any website on the internet and to resources on the attacked server (localhost).
In the following example, the attacker makes a request to the Apache HTTP service. This Apache HTTP service has mode_status enabled (which is enabled by default).
GET /?url=http://localhost/server-status HTTP/1.1
Host: example.com
The attacker can also use SSRF to make requests to other internal resources that the web server has access to, even if they are not publicly accessible. For example, the attacker can access metadata of cloud service instances like AWS/Amazon EC2 and OpenStack. Attackers can even get creative with SSRF, performing port scans on internal IPs.
GET /?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
Host: example.com
In addition to http:// and https:// URL protocols, attackers can use lesser-known or outdated URL protocols to access files on local systems or internal networks.
The following example uses the file:/// protocol.
GET /?url=file:///etc/passwd HTTP/1.1
Host: example.com
Some applications may allow attackers to use more obscure URL protocols. For instance, if the application uses cURL to make requests, the attacker can use the dict:// URL protocol to make requests to any host and port, sending custom data.
GET /?url=dict://localhost:11211/stat HTTP/1.1
Host: example.com
The above request causes the application to connect to port 11211 on localhost and send the stat string. Port 11211 is the default port for Memcached, which is typically not exposed to the outside.
Checking for Server-Side Request Forgery#
To automatically detect server-side request forgery, you need to use an intermediary service, as checking for this type of vulnerability requires an externally accessible method with latency. Acunetix addresses this issue by using AcuMonitor as an intermediary service.
During the scan, Acunetix makes requests to different AcuMonitor URLs. If AcuMonitor receives a request at any of these different URLs, it will notify Acunetix. Acunetix will then issue an SSRF alert.
The following image shows the Acunetix scan results using AcuMonitor, which checks for server-side request forgery. The alert contains information about the HTTP request. It includes the IP address of the server that initiated the request and the User-Agent string carried in the request (if present). This information can help developers locate the source of the problem and fix it.
Eliminating Server-Side Request Forgery#
Applying simple blacklists and regular expressions to user input is a poor method for eliminating SSRF attacks. Generally, blacklists are a nearly ineffective security control measure. Attackers can always find ways to bypass them. In this case, attackers can use HTTP redirection, wildcard DNS services (like xip.io), or even alternative IP encoding to bypass blacklists.
Whitelisting and DNS Resolution#
The most robust way to avoid server-side request forgery is to add the DNS names and IP addresses that your application needs to access to a whitelist. If the whitelisting mechanism does not meet your needs and you must rely on a blacklist mechanism, it becomes very important to validate user input properly. For example, requests to private IP addresses should not be allowed (private IP addresses refer to RFC 1918).
However, in scenarios using blacklists, the correct way to eliminate SSRF will vary by application. In other words, there is no silver bullet for fixing SSRF vulnerabilities using blacklist mechanisms, as it highly depends on application functionality and business requirements.
Handling Responses#
To avoid leaking response data to attackers, you must ensure that the responses received are the expected content. Under no circumstances should the raw response body of the server's request be passed to the client.
Disabling Unused URL Protocols#
If your application only uses HTTP or HTTPS to make requests, then only allow those URL protocols. By disabling unused URL protocols, attackers will not be able to make requests using potentially dangerous protocols, such as: file:///, dict://, ftp://, and gopher://.
Authentication for Internal Services#
By default, services like Memcached, Redis, Elasticsearch, and MongoDB do not require authentication. Attackers can exploit server-side request forgery vulnerabilities to access these services without authentication. Therefore, to ensure the security of the application, it is best to enable authentication whenever possible, even for services on the local network.
If you find any errors or other areas for improvement in the translation, feel free to modify the translation and submit a PR at Juejin Translation Project to earn corresponding reward points. The Permanent link to this article at the beginning of the article is the Markdown link for this article on GitHub.
Juejin Translation Project is a community for translating high-quality internet technology articles, with sources from English sharing articles on Juejin. The content covers fields such as Android, iOS, Frontend, Backend, Blockchain, Product, Design, Artificial Intelligence and more. To see more high-quality translations, please continue to follow the Juejin Translation Project, official Weibo, and Zhihu column.