Server-side request forgery (SSRF)

In this section, we explain what Server-side Request Forgery is, describe some common examples, and explain how to find and exploit various SSRF vulnerabilities.

What is the SSRF

SSRF Server request forgery is a Web vulnerability that allows an attacker to induce a server program to make an HTTP request to any address the attacker chooses.

In a typical SSRF example, an attacker might cause a server to establish a connection to itself, to other Web-based services in the organization’s infrastructure, or to external third-party systems.

Impact of SSRF attacks

Successful SSRF attacks typically result in unauthorized operations or access to data within an organization, either in the vulnerable application itself or in other back-end systems that the application can communicate with. In some cases, the SSRF vulnerability may allow an attacker to execute arbitrary commands.

The SSRF vulnerability can be exploited to manipulate a server application to make malicious requests to external third-party systems with which it is connected, resulting in potential liability and reputational damage.

Common SSRF attacks

SSRF attacks typically exploit the trust relationships of server applications to launch attacks and perform unauthorized operations. This trust relationship may include trust in the server itself or with other back-end systems within the organization.

The SSRF attacks the server itself

In an SSRF attack on the server itself, an attacker induces an application to make an HTTP request to itself, usually by providing a URL with a host name of 127.0.0.1 or localhost.

For example, consider a shopping application that allows the user to see if an item is available in a particular store. To provide inventory information, the application needs to query other back-end services through the REST API, and the URL addresses of the other back-end services are included directly in the front-end HTTP request. Therefore, when a user views the inventory status of an item, the browser may issue the following request:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
Copy the code

This causes the server to make a request to the specified URL to retrieve the inventory status and then return the result to the user.

In this case, an attacker can modify the request to specify a URL local to the server, for example:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin
Copy the code

At this point, the server will access the local /admin URL and return its contents to the user.

Of course, an attacker could access the /admin URL directly, but this usually doesn’t work because administrative functions basically require proper authentication, and normal access control can be bypassed if requests to the /admin URL are local to the machine. The server application may grant full access to administrative functions because the request appears to be coming from a trusted location.

Why does the application behave this way and implicitly trust requests from local sources? This could be for a number of reasons:

  • Access control checks could be another microservice. When the server connects to itself, access control checks are bypassed.
  • For disaster recovery purposes, an application may allow any user from the local machine to have administrative access without logging in. This provides a way for administrators to recover the system if credentials are lost. The assumption here is that only fully trusted users can come directly from the server locally.
  • The administrative interface may be a different port number from the main application because users may not be able to access it directly.

In this trust relationship, requests from the local machine are handled differently than normal requests, which often makes SSRF a serious vulnerability.

SSRF attacks against other back-end systems

Another trust relationship exploited by the SSRF is the interaction between application servers and internal backend systems that are not directly accessible to users. These backend systems often have private IP addresses that are not routable and are often insecure because of the protection of network topologies. In many cases, internal back-end systems contain sensitive capabilities that can be accessed without authentication by anyone able to interact with the system.

In the previous example, suppose the back-end systems have a management interface at https://192.168.0.68/admin. At this point, an attacker can exploit the SSRF vulnerability to access the management interface by submitting the following request:

POST /product/stock HTTP/1.0 content-type: application/x-www-form-urlencoded content-length: 118 stockApi = http://192.168.0.68/adminCopy the code

Circumvent common SSRF defenses

Often applications contain SSRF behavior and defenses against malicious attacks, but these defenses can be circumvented.

SSRF based on blacklist filtering

Some applications prohibit sensitive urls such as 127.0.0.1, localhost, or /admin. In this case, various tricks can be used to bypass the filtering:

  • use127.0.0.1Alternative IP address representation of, for example2130706433.017700000001.127.1 。
  • Register your domain name and resolve it to127.0.0.1, you can use it directlyspoofed.burpcollaborator.net 。
  • Obfuscate blocked strings using URL encoding or case changes.

SSRF based on whitelist filtering

Some applications only allow you to enter a value that matches, contains, or begins with a value from a whitelist. In such cases, inconsistencies in URL resolution can sometimes be used to bypass filters.

The URL specification contains many features that are easily overlooked when implementing URL parsing and validation:

  • You can use it before the host name@Symbol embedded credentials. For example,https://expected-host@evil-host 。
  • You can use#Symbol represents a URL fragment. For example,https://evil-host#expected-host 。
  • You can use the DNS command hierarchy to put the required input into standard DNS names that you control. For example,https://expected-host.evil-host 。
  • You can confuse THE URL parsing code with URL-encoded characters. This is especially useful if the implementation of the filter handling THE URL-encoding is different from the code executing the back-end HTTP request.
  • You can use a combination of these techniques.

Bypass the SSRF filter with open redirection

Open redirection vulnerabilities are sometimes used to bypass any filter-based defenses.

In the previous example, it was assumed that the URL submitted by the user was rigorously validated to prevent malicious exploitation of the SSRF, but the application that allowed the USE of the URL contained an open redirect vulnerability. If the API used to initiate a back-end HTTP request supports redirection, you can construct a URL that meets the filter’s requirements and redirect the request to the desired back-end destination.

For example, suppose the application contains an open redirect vulnerability in the form of the following URL:

/product/nextProduct? currentProductId=6&path=http://evil-user.netCopy the code

Redirect to:

http://evil-user.net
Copy the code

You can use the open redirection vulnerability to bypass URL filters and exploit SSRF vulnerabilities for attacks such as:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin
Copy the code

This SSRF attack is effective because first the stockAPI URL is on a domain that the application allows, then the application makes a request to the supplied URL, triggering a redirection, and finally to the internal URL that was redirected.

Blind SSRF – SSRF vulnerabilities are not visible

Blind SSRF vulnerability is where an application can be induced to make a back-end HTTP request to the URL provided, but the response to the request is not returned in the application’s front-end response.

Invisible SSRF vulnerabilities are generally harder to exploit, but can sometimes lead to remote code execution on servers or other back-end components.

Look for hidden attack surfaces for SSRF vulnerabilities

Many SSRF vulnerabilities are relatively easy to detect because the application’s normal communication includes full URL request parameters. Other cases are trickier.

Partial URL in the request

Sometimes the application only puts the host name or part of the URL path into the request parameter, and then the submitted value is merged into the full URL of the server request. If the value is easily recognized as a host name or URL path, the potential attack surface may be obvious. However, the availability of the SSRF is limited because you have no control over the URL that is ultimately requested.

URL within the data format

Some applications transfer data in a certain data format, and the URL is included in the specified data format. An obvious example of a data format here is XML, and when an application accepts data in XML format and parses it, it may be subject to XXE injection, which in turn completes SSRF attacks through XXE. There will be a section on the XXE injection vulnerability.

SSRF via the Referer header

Some applications use server-side analysis software to track visitors, which often records the Referer header in requests because it is particularly useful for tracking incoming links. Often, analysis software will actually access any third-party URLS that appear in the Referer header. This is typically used to analyze the content of the reference site, including anchor text used in incoming links. Therefore, the Referer header is usually an effective attack surface for SSRF vulnerabilities. See Blind SSRF for an example of a vulnerability involving the Referer header.

Blind SSRF

In this section, we will explain what invisible server request forgery is, describe some common examples of invisible SSRF, and explain how to find and exploit invisible SSRF vulnerabilities.

What is invisible SSRF

An invisible SSRF vulnerability is where an application can be induced to make a back-end HTTP request to a supplied URL, but the response from the back-end request is not returned in the application’s front-end response.

The impact of the SSRF vulnerability is not visible

Invisible SSRF vulnerabilities tend to have less impact than fully visible SSRF vulnerabilities because they are unidirectional, and while in some cases they can be exploited to retrieve sensitive data from back-end systems, they cannot be easily exploited to achieve full remote code execution.

How to find and exploit invisible SSRF vulnerabilities

The most reliable method for detecting invisible SSRF vulnerabilities is to use out-of-band (OAST) techniques. This includes trying to trigger HTTP requests to external systems that you control and monitoring network interactions with that system.

The simplest and most effective way to use OAST technology is to use Burp Collaborator(this feature requires a fee). You can use the Burp Collaborator Client to generate a unique domain name, send it as a payload to the application that detects the vulnerability, and monitor any interactions with this domain name. If you observe incoming HTTP requests from the application, the application has an SSRF vulnerability.

Note: When testing SSRF vulnerabilities, it is common to observe DNS lookups for the supplied domain names, but no subsequent HTTP requests. It is usually the application view that makes an HTTP request to the domain, which results in an initial DNS lookup, but the actual HTTP request is intercepted by the network. It is relatively common for the infrastructure to allow outbound DNS traffic because it is needed for many purposes but blocks HTTP connections to unexpected destinations.

Simply identifying an invisible SSRF vulnerability that can trigger an out-of-band HTTP request does not by itself provide a path to exploit. Since you can’t see the response from the back-end request, you can’t tell what it is. However, it can still be used to detect additional vulnerabilities on the server itself or other back-end systems. You can blindly scan the internal IP address space and send payloads designed to detect known vulnerabilities, and if those payloads also use out-of-band technology, you might find a serious unpatched vulnerability on the internal server.

Another way to exploit an invisible SSRF vulnerability is to induce an application to connect to a system under the attacker’s control and send a malicious response back to the CONNECTED HTTP client. If you can exploit a serious client-side vulnerability in the server-side HTTP implementation, then you might be able to do remote code execution in your application infrastructure.