Server-Side Request Forgery (SSRF) – Internal Network Access

Description

Server-Side Request Forgery (SSRF) occurs when an attacker manipulates a vulnerable server into making unauthorized HTTP requests to internal or external services. When SSRF is used to access internal networks, attackers can scan internal systems, query sensitive services, or exploit insecure internal applications that are not meant to be publicly accessible.

Many internal applications, databases, admin panels, and cloud metadata services are only accessible from within the network and are not exposed to the internet. However, if an application is vulnerable to SSRF, an attacker can use it as a proxy to bypass firewall restrictions, gaining access to internal assets, cloud services, and critical infrastructure.

Examples

Scanning Internal Network Services

A vulnerable application allows users to fetch external URLs, but it does not validate input properly:

GET /fetch?url=https://example.com

An attacker can scan the internal network by changing the URL parameter to query local IP ranges:

GET /fetch?url=http://192.168.1.1

If the server responds with 200 OK, the attacker confirms that an internal service is running on 192.168.1.1.

Accessing Internal Applications

Some enterprises host internal admin panels, monitoring dashboards, or databases at private IP addresses (e.g., 10.0.0.1, 192.168.1.1). If an SSRF vulnerability exists, an attacker can access these services.

Example: Accessing an Internal Jenkins Server

GET /fetch?url=http://10.0.0.5:8080

If Jenkins is running internally, the attacker may reach the admin login panel.
If no authentication is required, the attacker may run commands on the internal CI/CD pipeline.

Querying Cloud Services (Kubernetes, Docker APIs)

In cloud environments, SSRF can be used to query internal APIs, such as:

Kubernetes API Server (https://10.0.0.1:6443)
Docker Remote API (http://localhost:2375)
AWS Metadata Service (http://169.254.169.254/latest/meta-data/)

Example: Listing Kubernetes Pods

GET /fetch?url=https://10.0.0.1:6443/api/v1/namespaces/default/pods

If the Kubernetes API is misconfigured, the attacker might retrieve internal pod names and container metadata.

Bypassing Network Access Controls

Some web applications restrict admin panels or internal APIs based on IP address (e.g., only accessible from 127.0.0.1).

If SSRF is present, an attacker can force the vulnerable server to make a local request on their behalf, bypassing these restrictions:

GET /fetch?url=http://127.0.0.1/admin

If the application is misconfigured, the attacker can now access internal admin functionality remotely.

Remediation

Block Requests to Internal IP Ranges
- Restrict access to internal networks (127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
- Example rule to deny requests:
```
if request.url contains "127.0.0.1" or "169.254.169.254" or matches "10\..*" {
     block request;
}
```
Validate and Restrict Outbound Requests
- Whitelist only trusted domains instead of allowing open URL input.
- Reject requests containing IP addresses, localhost, or internal services.
- Example regex filter:
```
^(https?:\/\/(www\.)?trusted-domain\.com\/.*)$
```
Use a Proxy for Outbound Requests
- Route all requests through a secure outbound proxy that enforces domain whitelisting.
- Block direct requests to internal network resources.
Enforce Network Segmentation
- Prevent web servers from directly accessing internal applications or cloud metadata services.
- Use VPC security groups and firewall rules to restrict server-to-server communication.
Disable Unnecessary Internal Services
- Close exposed internal services (e.g., Jenkins, Redis, Elasticsearch) that do not need to be accessible internally.
- Require authentication and IP whitelisting for internal web applications.

Haxoris Wiki