• What is server-side Request Forgery (SSRF)?
  • By Ian Muscat
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: MoonBall
  • Proofread: PassionPenguin, Kamly

The Server Request Forgery (SSRF) vulnerability lets an attacker send malicious requests from the back-end services of the vulnerable application. Attackers typically use SSRF to attack internal systems that lie behind firewalls and cannot be accessed from external networks. An attacker can also use SSRF to access services accessible through the server’s loopback interface ((127.0.0.1)).

SSRF vulnerabilities occur when an attacker has full or partial control over requests sent by an application. A common example is when an attacker can control the URL of a third-party service and the application will initiate a request corresponding to that URL.

Here is a PHP example that is vulnerable to SSRF attacks.


      

/** * check if the GET variable 'url' is set * e.g. -http://localhost/? url=http://testphp.vulnweb.com/images/logo.gif */
if (isset($_GET['url'])){
$url = $_GET['url'];

/** * make a request vulnerable to SSRF attacks because $URL is not validated before the request is made */
$image = fopen($url.'rb');

/** * send the correct response header */
header("Content-Type: image/png");

/** * echo the content of the image */
fpassthru($image); }Copy the code

In the example above, the attacker has full control over the URL parameters. An attacker can make GET requests to any web site 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. The Apache HTTP service has the mode_status mode enabled (which is enabled by default).

GET /? url=http://localhost/server-status HTTP / 1.1
Host: example.com
Copy the code

An attacker can also use SSRF to make requests to other internal resources that the Web server has access to, even though they are not publicly accessible. For example, an attacker could access metadata from cloud service instances like AWS/Amazon EC2 and OpenStack. Attackers can even get creative with the SSRF by doing port scans on internal IP addresses.

GET /? Url = http://169.254.169.254/latest/meta-data/ HTTP / 1.1
Host: example.com
Copy the code

In addition to the http:// and https:// URL protocols, attackers can use little-known or ancient 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
Copy the code

Some applications may allow attackers to use more bizarre URL protocols. For example, if an application uses cURL to make requests, an attacker can use the dict:// URL protocol to make requests to arbitrary hosts and ports and send custom data.

GET /? url=dict://localhost:11211/stat HTTP / 1.1
Host: example.com
Copy the code

The above request causes the application to connect to port 11211 of localhost and send the STAT string. Port 11211 is the default port for Memcached and is usually not exposed.

Check for server request forgery

To automatically detect server request forgery, you need to use an intermediate service, because checking for this vulnerability requires an externally accessible and time-delayed method. Acunetix solves this problem by using AcuMonitor as an intermediate service.

During scanning, Acunetix makes requests to different AcuMonitor urls. If AcuMonitor receives a request in these different urls, it notifies Acunetix. Acunetix then issues SSRF alerts.

The following image shows the results of an Acunetix scan using AcuMonitor, which checks for server 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 (if present) carried with the request. This information can help developers locate the source of the problem and fix it.

Eliminate server request forgery

Applying simple blacklists and regular expressions to user input is a poor way to neutralize SSRF attacks. Often, blacklists are an almost ineffective means of security control. Because attackers can always find a way around them. In this example, an attacker could bypass the blacklist using HTTP redirection, a wildcard DNS service (such as xip.io), or even an alternate IP encoding.

Whitelist and DNS resolution

The most robust way to avoid server request forgery is to whitelist DNS names and IP addresses that your application needs to access. If whitelisting doesn’t meet your needs and you have to rely on blacklisting, it’s important to validate user input properly. For example, requests to private IP addresses are not allowed (see RFC 1918 for private IP addresses).

However, in a blacklisting scenario, the correct way to eliminate the SSRF will vary from application to application. In other words, there is no silver bullet to fix SSRF vulnerabilities using a blacklist mechanism because it is highly dependent on application functionality and business requirements.

Process the response

To avoid exposing response data to attackers, you must ensure that the response you receive is what you expect. Under no circumstances should the original response body of a request sent by the server be passed to the client.

The URL protocol that is not used is disabled

If your application only uses HTTP or HTTPS to initiate requests, then only those URL protocols are allowed. If you disable unused URL protocols, attackers will not be able to initiate requests using potentially dangerous protocols such as file:///, dict://, ftp:// and gopher://.

The Intranet service performs identity authentication

By default, services like Memcached, Redis, Elasticsearch, and MongoDB do not require authentication. An attacker can exploit a server-side request forgery vulnerability to access these services without authentication. Therefore, to ensure the security of your application, it is best to enable authentication whenever possible, even for services on a local network.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.