A Server-Side Request Forgery (SSRF) is a vulnerability that allows an attacker to force a server to initiate HTTP requests to unintended destinations. Instead of sending the request directly, the attacker abuses server-side functionality so that the server itself performs the request, often with higher privileges and network access. This can be used to make the server connect to:

  • internal-only services within the organization's infrastructure, or
  • arbitrary external systems controlled by the attacker.

SSRF attacks commonly exploit an implicit trust relationship between the server and internal resources, which are often not designed to handle untrusted input.

SSRF Against the Server Itself

In this scenario, the attacker forces the server to send requests to its own internal interfaces. By intercepting and modifying a request (for example at the API call level) the destination can be changed to an internal endpoint such as:

http://localhost/admin

Although this endpoint is not directly accessible by the user, the server can reach it, because the request is executed by the server, the response is considered trusted and may be returned indirectly to the attacker, effectively bypassing access controls through a trusted execution context.

SSRF Against Backend Services

Here, SSRF is used to target other backend services that the main server can communicate with, but which are not directly reachable by users. These services may include internal APIs, microservices, or management interfaces. In many architectures, such services:

  • are accessible only from the internal network
  • and are sometimes not protected by authentication, as they are assumed to be unreachable externally.

SSRF allows an attacker to pivot into these internal systems, potentially leading to data exposure, privilege escalation, or further lateral movement.

Blind SSRF

A Blind SSRF occurs when the server makes the forced backend request, but no response is reflected in the frontend. From the attacker's perspective, there is no immediate feedback. To confirm exploitation, the attacker typically forces the server to send HTTP or DNS requests to an attacker-controlled endpoint and monitors out-of-band interactions. Any incoming request confirms that the server executed the payload, even without a visible response.

Attack Surface: The Referer Header

An often overlooked SSRF attack surface is the Referer header. This header is commonly used to track visitors and is frequently processed by third-party analytics or monitoring services. If an application forwards or processes the Referer value without proper validation, an attacker may inject a malicious URL, causing the server or an integrated third-party service to issue unintended backend requests. This can lead to SSRF, especially in environments where external services are implicitly trusted.

Risks Associated with SSRF

The impact of an SSRF vulnerability can be severe. It may allow attackers to:

  • access internal services and administrative interfaces,
  • retrieve sensitive data from internal systems,
  • interact with cloud metadata services,
  • perform internal network scanning and pivoting.

In cloud environments, SSRF is particularly dangerous due to the presence of metadata endpoints that can expose credentials and configuration data.

Remediation and Mitigation Strategies

To mitigate SSRF vulnerabilities, organizations should implement multiple defensive measures:

  • Enforce strict allowlists for outbound request destinations.
  • Block access to internal IP ranges and localhost addresses.
  • Disable or tightly control HTTP redirects.
  • Validate and sanitize all user-supplied URLs and headers.
  • Restrict outbound network access at the infrastructure level.
  • Protect cloud metadata services using network-level controls.

SSRF is often the result of implicit trust assumptions. Eliminating those assumptions is key to reducing risk.

SSRF Practical : last task of the THM room

In this challenge, the goal is to understand and exploit a Server-Side Request Forgery (SSRF) vulnerability through an apparently harmless feature: user avatar selection. The application exposes an internal endpoint, /private, which cannot be accessed directly from a browser due to an IP-based restriction. However, the avatar feature allows the server to fetch an image based on a user-controlled path. By manipulating this parameter, it is possible to force the server to request internal resources on our behalf. Although a deny list blocks direct access to /private, this protection can be bypassed using a directory traversal technique (../). When the server resolves the path, it effectively requests the protected endpoint from its own IP address, successfully bypassing the access control. The response from the internal endpoint is then embedded into the page using a Base64-encoded Data URI. Decoding this content reveals the flag.

Just follow the steps provided by the challenge, it's sufficient to retrieve the flag! :) Hope you liked it