Skip to content

Server-Side Request Forgery: The Backdoor That Can Take Down Your Infrastructure

In the realm of web security, Server-Side Request Forgery (SSRF) vulnerabilities stand out as one of the most critical and underestimated threats. They allow attackers to manipulate servers to make unauthorized HTTP requests to internal systems, compromising everything from APIs and cloud services to infrastructures protected by firewalls.

This attack technique, often overlooked, can turn a seemingly secure server into an entry point for cybercriminals, enabling them to access internal resources, steal sensitive data, and even launch attacks against third parties.

The result? Data theft, access to internal services, remote code execution, and ultimately, reputational damage, regulatory fines for non-compliance with laws like GDPR, and significant financial losses. A successful SSRF attack can cripple critical operations and erode customer trust.

What is an SSRF Vulnerability?

Server-Side Request Forgery (SSRF) vulnerabilities occur when an attacker can manipulate a server into making unauthorized requests. Imagine a web server acting as a messenger that normally delivers messages (requests) only to authorized recipients. Exploiting an SSRF attack would be equivalent to a stranger forcing the messenger to send letters to any recipient without filtering, bypassing customs, and using an official sender.

To see a more concrete case, consider a shopping application that checks product stock through requests to a REST API. The application passes the URL to the API endpoint via an HTTP request. An attacker who notices this could modify this URL to access other internal API endpoints, potentially retrieving unauthorized information such as other users' data.

Additionally, SSRF attacks are not limited to the HTTP protocol. In some cases, an attacker could attempt to use other URI schemes, such as file:// to access local files on the server, smb:// to force authentication and obtain an NTLM hash, or other diverse protocols.

Impact of SSRF Attacks

Generally, an SSRF attack can result in unauthorized access to internal resources. In some situations, the SSRF vulnerability could allow an attacker to execute arbitrary commands through a chain of vulnerabilities.

When an SSRF can be used to establish connections with third-party external systems, an attacker can leverage it for spoofing attacks. This means that attacks will appear to originate from the organization hosting the vulnerable application. For example, an attacker could use an SSRF-vulnerable server to scan ports on another company’s internal network or even launch a denial-of-service (DoS) attack against an external service, making it seem like the offensive originates from the compromised organization.

Another possible exploitation scenario is internal network (intranet) reconnaissance, where an attacker can leverage SSRF to send requests to internal addresses through the affected server. This would allow them to identify open ports, map internal services, and gather sensitive information about the network infrastructure. The severity of the attack increases if the compromised server has privileged access to internal resources that would normally be protected from external access.

Types of Server-Side Request Forgery

There are two main types of Server-Side Request Forgery (SSRF) attacks:

  • Standard SSRF: In this type of attack, the server's response is directly shown to the attacker. The server fetches the attacker-supplied URL and sends the content (or part of it) back in the response.
  • Blind SSRF: In this case, the response is not sent back to the attacker. The attacker must devise ways to confirm and exploit the vulnerability without seeing the server’s response directly.

Next, we will examine the characteristics and exploitation methods of each type of SSRF, along with possible approaches for detecting and mitigating these vulnerabilities.

Standard SSRF

The standard SSRF attack is the most direct form of this attack. In this scenario, the attacker can directly observe the server's response to the manipulated request, allowing them to collect detailed information about the internal network, identify accessible services, and retrieve potentially sensitive data.

Exploitation Methodology

Exploiting this type of SSRF follows three phases:

  1. Injection: The attacker injects a malicious URL into an application input field.
  2. Request: The server, without validating the URL, makes a request to the resource specified by the attacker.
  3. Disclosure: The server’s response is returned to the attacker, allowing them to access internal information.

In the following example, we have a web application that allows querying the stock of the products it offers. To better visualize the requests, we will use an application proxy like BurpSuite, so we can see the request made when querying the product stock:

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

stockApi=stockApi=http://internal-stock-api/check?productId=123

This request causes the client to receive the stock of the product indicated by the productId. However, an attacker could modify the request to the specified URL, such as:

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

stockApi=http://localhost/admin

By sending this request, if the /admin directory exists on the attacked machine and is processed without further validation, the attacker could gain access to the internal admin panel.

Exploitation Example to Access Amazon EC2 Metadata

A common case of SSRF exploitation is when the attacker accesses internal metadata of an EC2 instance on AWS:

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

stockApi=http://169.254.169.254/latest/meta-data/
Accessing this API could reveal sensitive information like access keys, IAM roles, or other sensitive data.

Specific countermeasures can be found in the AWS documentation.

Exploitation Example to Read Local Files:

If the application allows the use of the file:// scheme, an attacker could attempt to read system files as follows:

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

stockApi=file:///etc/shadow

Blind SSRF

Blind SSRF attacks are more challenging since the server does not return the response directly to the attacker. In this type of attack, the attacker must infer the success of their intrusion through observable changes in application behavior or by interacting with an external server.

Exploitation Methodology

Imagine a web application that allows users to upload profile pictures. The application verifies that the image is valid by making a request to the provided URL but does not display the result of this verification to the user.

A rudimentary implementation might look like this:

import requests
def verify_image(url):
  try:
    response = requests.get(url, timeout=5)
    if response.headers.get('content-type', '').startswith('image/'):
      return True
  except:
    pass
    return False

  user_provided_url = "https://example.com/image.jpg"
  if verify_image(user_provided_url):
    print("Valid image")
  else:
    print("Rejected URL")

In this case, the server receives a URL, which in this case is https://example.com/image.jpg, and then makes an HTTP request to that URL to check if it contains an image. Finally, if the provided URL returns a resource with Content-Type: image/*, it will be considered valid.

The problem lies in the fact that the server blindly trusts URLs provided by users, allowing arbitrary HTTP requests to be made.

If an attacker supplies a URL they control or one that points to an internal resource of the server, such as http://internal-server/sensitive-data, the attacker will not directly see the server's response, but they can deduce whether the request was successful by observing certain behaviors:

  • Response time: An internal resource that takes longer to respond might indicate that the server accessed the resource.
  • Error messages: Differences in the errors returned by the server can confirm the existence of the resource.

To check if the request is being made to the provided URL, out-of-band (OOB) techniques are used, such as monitoring DNS or HTTP requests to domains controlled by the attacker. For example, it could be the following URL http://internal-server.sensitive-data.attacker-domain.com. Here, attacker-domain is a domain controlled by the attacker. If the vulnerable server processes this URL, it will try to resolve the domain and make an HTTP request to it. This allows the attacker to detect the activity by monitoring their own DNS or web server. This functionality is integrated through the Collaborator in the professional version of BurpSuite.

How to Prevent SSRF Attacks

As we have seen earlier, SSRF attacks are particularly dangerous as they facilitate the exploitation of internal resources. To protect against this type of vulnerability, it's crucial to implement a combination of robust security measures. Below are the most effective strategies:

Strict Input Validation

To protect against an SSRF attack, we can use the following:

  • Whitelists: We can allow the server to access specific, trusted URLs for the proper functioning of the application. Instead of allowing any URL, define a whitelist of domains and paths that the server is permitted to access. Any request that does not match this whitelist should be rejected. Example: allowed = ["api.example.com/products", "images.example.com"].
  • Blocking Internal Addresses: We can block requests to internal URLs to prevent access to internal server resources (e.g., localhost or any IP in the range 192.168.x.x). Configure the server to reject any request to private IP addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and to localhost (127.0.0.1). This prevents unauthorized access to internal network resources, preventing an attacker from manipulating the server to access services or data that should be protected.
  • Restrict Protocols: We can block protocols such as smb://, file://, and others. Limiting protocols to HTTP(S) reduces the attack surface, preventing the use of other potentially insecure protocols to access internal or external resources.

Use of Web Application Firewalls (WAFs)

We can configure a WAF with specific rules to help detect and block suspicious patterns related to SSRF. WAFs can act as an additional layer of defense by monitoring and filtering outgoing traffic from the server.

Network Segmentation

We can divide the network into segments and limit access between them. For example, if the web server should not have direct access to the database because it uses an API, then the ability to send traffic directly to the database server should be restricted. Generally, the host should not be able to access more internal services than those strictly necessary for its operation, minimizing the attack surface. This approach should be adapted to the specific situation of each service.

Implement Monitoring

Although blind SSRF does not show responses directly to the attacker, out-of-band techniques leave traces that can help detect malicious attempts. To detect these techniques, it is crucial to configure monitoring for DNS requests made by application servers to identify unexpected requests to external domains.

Periodic Security Testing

Conduct periodic security audits to protect your web applications against this and other threats.

Conclusion

Preventing SSRF attacks requires a layered security approach, combining input validation, the use of WAFs, regular updates, network segmentation, and security testing. By implementing these measures, we can significantly reduce the risk of our infrastructure being compromised by this vulnerability. Remember, security is an ongoing process, and it is important to stay updated on the latest vulnerabilities and attack techniques.

Stay safe. Stay smart. Stay secure.