ssrf

Server-side request forgery is a vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location.

In a typical SSRF attack, the attacker could cause the server to connect to internal services in the organization’s infrastructure or to arbitrary external systems. This could lead both to the leakage of sensitive data, such as authorization credentials, and to the performance of unauthorized actions.

SSRF Against the Server

In a server-side SSRF attack, the attacker causes the application to send an HTTP request to the server that hosts it, using a URL pointing to localhost or 127.0.0.1.

Example:

Imagine a store that queries an API to check stock, using a URL that travels in the HTTP 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

The attacker can modify the request to specify a local URL on the server.

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
 
stockApi=http://localhost/admin

Since the request to /admin comes from the local machine, access controls are normally bypassed and the server returns its content to the attacker.

SSRF Against Other Back-end Systems

Often the application server can interact with other back-end systems on the private network that are not accessible to users.

These back-end systems often have weaker security because they are on a private network and assume that no one can access them.

Example:

In the previous example there is an administrative interface at http://192.168.0.68/admin. An attacker can send the following request to access it:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
 
stockApi=http://192.168.0.68/admin

Bypassing Security Systems

Blacklists

Some applications block input that contains hostnames such as 127.0.0.1 and localhost, or sensitive URLs such as /admin. In this situation, you can often bypass the filter using the following techniques:

• Use an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001, or 127.1.
• Obfuscate blocked strings using URL encoding or case variation.
• Provide a URL that you control and that redirects to the target URL. Try different redirect codes and protocols for the target URL. For example, changing from an http: URL to an https: one during the redirect has been shown to bypass some anti-SSRF filters.

Example script that creates a server that redirects to a URL:

Script

from http.server import BaseHTTPRequestHandler, HTTPServer
 
class RedirectHandler(BaseHTTPRequestHandler):
   def do_GET(self):
       # Redirect destination
       destination = "http://localhost/admin"
 
       self.send_response(302)
       self.send_header("Location", destination)
       self.end_headers()
 
       self.wfile.write(b"Redirecting...")
 
HTTPServer(("127.0.0.1", 8080), RedirectHandler).serve_forever()

Note

To make the server accessible from outside your local network you can use Cloudflare Tunnel

Whitelists

Some applications only allow input that matches a whitelist of permitted values. The filter may look for a match at the beginning of the input or within it. It is possible to bypass this filter by exploiting inconsistencies in URL parsing.

• You can insert credentials into a URL before the hostname, using the @ character.

https://expected-host:fakepassword@evil-host

• You can use the # character to indicate a URL fragment.

https://evil-host#expected-host

• You can exploit the DNS naming hierarchy to place the required information in a full DNS name that you control.

https://expected-host.evil-host

• You can encode characters in the URL to confuse the URL parsing code. You can also try double-encoding characters. Some servers recursively decode the input they receive, which can create additional discrepancies.

SSRF + Open Redirect

Imagine that the URL is rigorously validated to prevent SSRF. However, the application whose URLs are allowed is vulnerable to Open Redirect; you can construct a URL that satisfies the filter and results in a request redirected to the desired target server.

For example, the following application contains an open redirect:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

Redirects to http://evil-user.net

The open redirect vulnerability can be exploited to bypass the URL filter and exploit the SSRF vulnerability.

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

Blind SSRF

A Blind SSRF occurs when an HTTP request can be sent to a back-end server but its response is not visible in the front end.

The most reliable way to detect blind SSRF vulnerabilities is through out-of-band techniques (OAST). This involves attempting to send an HTTP request to an external system and monitoring the network interactions with that system.

Note

A good option for detecting out-of-band interactions is Interactsh

How to Exploit Blind SSRF

Since you cannot see the response to the server’s request, this behavior cannot be used to explore the contents of the systems that the application server has access to.

However, it can be used to probe other vulnerabilities in the server itself or in other back-end systems, by scanning the internal IP address space, sending payloads designed to detect known vulnerabilities, which also employ OAST techniques.

Another route is to induce the application to connect to a system under the attacker’s control and return malicious responses to the HTTP client that establishes the connection. If a serious client-side vulnerability can be exploited, remote code execution within the application’s infrastructure could be achieved.

Detecting Hidden Attack Surfaces

Partial URLs

Sometimes an application includes only a hostname or part of a URL path in the request parameters. The supplied value is incorporated into the server to generate the full requested URL.

SSRF via the Referer Header

Some applications commonly log the Referer header in requests, to track inbound links.

Often, analytics software visits third-party URLs that appear in the Referer header to analyze the content of the referring sites. As a result, the Referer header is often a useful attack surface for SSRF vulnerabilities.