SSRF Exploitation: Internal Network Scanning via Server-Side Request Forgery

To understand SSRF, imagine a web application that offers a "URL Preview" feature. When a user posts a link in a chat, the backend server automatically fetches the remote URL to grab the page title and a thumbnail image to display to the user.

If the application takes the user-supplied URL http://example.com/image.jpg and fetches it without validation, a malicious actor could instead submit a URL pointing to an internal IP address, such as http://192.168.1.10/admin-panel.

Because the request originates from the backend server—which resides behind the corporate firewall and is part of the trusted internal network—the firewall allows the request. The vulnerable server fetches the internal admin panel and returns the content to the attacker on the public internet. The attacker has successfully utilized the server as a pivot point to breach the internal perimeter.

In-Band vs. Blind SSRF:

• In-Band (Basic) SSRF: The attacker can see the direct response from the forged request. If they point the SSRF to an internal API, the contents of that API response are returned in the HTTP response of the vulnerable application. This makes exploitation straightforward.
• Blind SSRF: The application makes the backend request, but the response is not returned to the attacker's browser. The application might only return a generic "Upload Successful" or "Error" message. Blind SSRF is harder to exploit but still highly dangerous. Attackers can infer the status of internal services by observing time delays (a request to an open internal port might respond instantly, while a closed port might hang and timeout) or by using out-of-band (OOB) techniques, such as forcing the internal server to make a DNS lookup to an attacker-controlled domain.

An SSRF vulnerability is highly prized by Red Team operators because it acts as a launchpad for extensive post-exploitation activities deep within the target's infrastructure.

Internal Network Scanning and Port Probing: The immediate use of SSRF is reconnaissance. An attacker can script requests to systematically scan the internal network (e.g., iterating through 10.0.0.1 to 10.0.0.255) and probe for open ports. By analyzing the HTTP response codes, banners, or timing differences, the attacker can map the internal topology, identifying hidden databases (port 3306, 5432), internal development servers, or management interfaces (port 8080, 8443) that the security team assumed were safe from external access.

Cloud Metadata Exfiltration: In cloud environments (AWS, GCP, Azure), SSRF is arguably the most devastating vulnerability an application can possess. Cloud providers host internal metadata services accessible via specific, non-routable IP addresses (most famously 169.254.169.254 in AWS). If an application hosted on an EC2 instance is vulnerable to SSRF, an attacker can forge a request to http://169.254.169.254/latest/meta-data/iam/security-credentials/. This request forces the EC2 instance to query its own metadata service and return the temporary AWS IAM credentials associated with the instance's role. The attacker can then use these stolen credentials to access S3 buckets, spin up new infrastructure, or completely compromise the AWS environment.

Exploiting Internal Vulnerabilities (The Pivot): SSRF allows attackers to exploit vulnerabilities in legacy internal applications that were never designed to face the hostile internet. For example, an organization might have an unpatched, internal instance of Jenkins or Jira because "it's behind the firewall." Using SSRF, the attacker can craft a payload targeting a known Remote Code Execution (RCE) flaw in that internal Jenkins instance. The vulnerable front-end server dutifully forwards the exploit payload, achieving RCE deep within the corporate network.

Interacting with Non-HTTP Services: SSRF is not strictly limited to HTTP/HTTPS. Depending on the backend library making the request (such as cURL in PHP), the application might support various URI schemas. An attacker could use the file:// schema (e.g., file:///etc/passwd) to read sensitive local files on the server. They could use dict:// or gopher:// schemas to construct raw TCP packets. The gopher:// protocol is particularly dangerous, as it allows attackers to forge highly complex requests to interact with internal Redis databases, Memcached servers, or SMTP services, often leading to full server compromise.

As developers implement basic blacklists to prevent SSRF (e.g., blocking 127.0.0.1 or 169.254.169.254), attackers have developed sophisticated evasion techniques to bypass these weak filters.

Alternative IP Representations: If a simple regex blocks 127.0.0.1, attackers can represent the localhost IP address in various valid, mathematical formats that the backend networking stack will still resolve correctly. For instance, 127.0.0.1 can be written as:

• Decimal format: http://2130706433/
• Hexadecimal format: http://0x7f000001/
• Octal format: http://0177.0000.0000.0001/
• IPv6 representation: http://[::1]/

DNS Rebinding: DNS Rebinding is a complex attack designed to bypass validation checks that occur before the request is made. The attacker registers a domain (e.g., attacker.com) and sets the DNS Time-to-Live (TTL) to zero. When the server first resolves attacker.com to validate it, the DNS server returns a benign, external IP address, passing the security check. However, fractions of a second later, when the application actually makes the HTTP request, the DNS cache expires. The application resolves the domain again, but this time, the attacker's DNS server responds with a malicious internal IP address (e.g., 169.254.169.254). The check is bypassed, and the internal request succeeds.

URL Parsing Inconsistencies: Different parsing libraries (e.g., Python's urllib vs. the requests library) sometimes interpret complex URLs differently. An attacker can craft an ambiguous URL, such as http://[email protected]/. A weak validation function might parse expected-host.com and approve it, while the actual fetching library interprets expected-host.com as a username and connects to attacker-controlled-host.com.

Open Redirects: If the target application or an allowed third-party domain has an Open Redirect vulnerability, attackers can chain it with SSRF. The attacker provides a URL pointing to the trusted domain (passing the SSRF filter). The application fetches the URL, but the trusted domain immediately responds with an HTTP 302 redirect pointing to 127.0.0.1. If the application's HTTP client is configured to automatically follow redirects, it will unwittingly follow the redirect directly into the internal network.

Remediating SSRF requires strict, defense-in-depth architectural controls. Blacklisting specific IPs or domains is fundamentally flawed and easily bypassed. Organizations must adopt positive security models.

Enforce Strict Allowlisting: The most robust defense against SSRF is a strict allowlist (whitelist). If the application only needs to fetch profile pictures from s3.amazonaws.com and github.com, configure the backend code to explicitly reject any URL that does not strictly match those specific domains. Do not rely on regex; use dedicated URL parsing libraries to extract the hostname and compare it against the allowlist.

Disable Unused URI Schemas: Ensure that the HTTP client library making the backend requests is configured to explicitly disable unused URI schemas. If the application only needs to fetch web pages, strictly enforce http:// and https://. Disable highly dangerous schemas like file://, ftp://, dict://, and gopher:// to prevent local file reads and raw TCP socket manipulation.

Network-Level Defenses (Zero Trust): Do not rely solely on application-level filtering. Implement Network Policies or firewall rules to restrict the outbound network access of the application server. If a web server has no legitimate business reason to communicate with the internal HR database on port 1433, use firewall rules to block that specific outbound traffic. This containment strategy limits the blast radius of an SSRF vulnerability.

Protect Cloud Metadata Services: In cloud environments, protecting the metadata service is critical. In AWS, migrate from IMDSv1 to IMDSv2 (Instance Metadata Service Version 2). IMDSv2 requires all requests to include a specific, dynamically generated header that is obtained via a PUT request. This simple requirement completely neutralizes the vast majority of SSRF attacks, as an attacker controlling a simple GET request via SSRF cannot easily generate the required headers to access the IMDSv2 service.