SSRF (Server-Side Request Forgery) Vulnerability Summary 1. Vulnerability Overview SSRF (Server-Side Request Forgery) is a web security vulnerability that allows an attacker to cause a server-side application to initiate requests to unexpected locations. In a typical SSRF attack, the attacker may force the server to connect to internal infrastructure within the organization or to arbitrary third-party systems, thereby leaking sensitive data such as authorization credentials. 2. Impact Scope Successful SSRF attacks typically result in the following consequences: Unauthorized operations or data access: Accessing data within internal organizational systems or other backend systems that the application can communicate with. Arbitrary command execution: In certain cases, an SSRF vulnerability may allow an attacker to execute arbitrary commands. Malicious follow-up attacks: This can lead to malicious follow-up attacks originating from the organization hosting the vulnerable application. 3. Common Attack Vectors 3.1 SSRF Attacks Against the Server The attacker causes the application to issue HTTP requests to the server hosting the application itself via the loopback network interface. This typically involves providing URLs pointing to the loopback adapter ( ) or . Normal Request Example: Attack Request Example (Modified URL to Local Address): Mechanism: The server perceives the request as coming from a trusted local location, thereby bypassing normal access controls and allowing access to administrative functions (e.g., ). 3.2 SSRF Attacks Against Other Backend Systems The application may interact with backend systems that typically have non-routable private IP addresses and are weakly secured. Attack Request Example: Mechanism: The attacker leverages the SSRF vulnerability to access backend management interfaces (e.g., ), which often lack authentication or have weak authentication. 4. Bypassing Common SSRF Defenses 4.1 Bypassing Blacklist-Based Input Filters Some applications block inputs containing specific hostnames (e.g., , ) or sensitive URLs (e.g., ). Bypass Techniques: Alternative IP Representations: For example, , , or . DNS Rebinding: Register a domain that resolves to the target IP (e.g., ). URL Encoding or Case Variations: Obfuscate blocked strings. Redirection: Provide a URL under your control that redirects to the target URL (e.g., redirecting from to ). 4.2 Bypassing Whitelist-Based Input Filters Some applications only allow values that match a whitelist. Bypass Techniques: Embedding Credentials: Use the character before the hostname in the URL. For example: . URL Fragments: Use the character to indicate a URL fragment. For example: . DNS Naming Hierarchy: Leverage DNS hierarchy to place the required input. For example: . URL Encoding Obfuscation: Use URL-encoded characters to obfuscate the URL parsing logic, or attempt double encoding. 4.3 Bypassing SSRF Filters via Open Redirection If the application has an open redirection vulnerability, it can be exploited to bypass filter-based defenses. Normal Request Example: Redirects to: Attack Request Example: Mechanism: The application first validates whether the URL is within the allowed domain, then requests that URL. This request triggers a redirect, ultimately initiating a request to the internal URL chosen by the attacker. 5. Other Key Information Blind SSRF Vulnerabilities: Occur when the application issues backend HTTP requests, but the response is not returned to the application's frontend. Blind SSRF is more difficult to exploit but can lead to full remote code execution on the server or other backend components. Identifying Hidden Attack Surfaces: Partial URLs in Requests: The application may accept only a hostname or a portion of a URL path as a parameter, but the server-side logic combines them into a complete URL. URLs within Data Formats**: For example, URLs embedded within JSON or XML.