> For the complete documentation index, see [llms.txt](https://riteshs4hu.gitbook.io/infosec-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://riteshs4hu.gitbook.io/infosec-notes/web-appsec/server-side-request-forgery-ssrf.md).

# Server-Side Request Forgery (SSRF)

Server-Side Request Forgery (SSRF) is a vulnerability that occurs when a web application fetches a remote resource based on user-supplied input without properly validating the destination.

Instead of sending requests directly from their own system, an attacker can force the vulnerable server to make requests on their behalf. This allows the attacker to interact with internal systems, cloud services, localhost services, or other resources that may not be accessible from the internet.

SSRF is commonly found in features that accept URLs, such as:

* Image importers
* File downloaders
* URL preview generators
* Webhooks
* PDF generators
* API integrations

***

### Vulnerable Code

```php
<?php

$url = $_GET['url'];

$response = file_get_contents($url);

echo $response;

?>
```

***

### Code Explanation

The application accepts a URL from the user:

```php
$url = $_GET['url'];
```

The server then retrieves the content of the supplied URL:

```php
$response = file_get_contents($url);
```

Finally, the response is returned to the user:

```php
echo $response;
```

The vulnerability exists because the application allows users to control where the server sends requests without validating the destination.

As a result, the server may be tricked into accessing resources that were never intended to be exposed.

***

### How to Exploit

1. Identify functionality that accepts a URL or remote resource location from the user.
2. Confirm that the server makes outbound requests based on the supplied input.
3. Determine whether the application validates or restricts the destination address.
4. If no restrictions are in place, the attacker may be able to force the server to send requests to unintended locations.
5. The attacker attempts to access internal services that are reachable from the server but not directly accessible from the internet.
6. The application's response, error messages, or behavioural differences may reveal information about internal systems.
7. Depending on the environment, the attacker may be able to interact with internal applications, cloud metadata services, administrative interfaces, or other protected resources.

The severity of SSRF often depends on the network access available to the vulnerable server.

***

### Impact

* **Access internal services:** Reach internal systems that are not publicly accessible.
* **Sensitive data disclosure:** Access confidential information from internal applications.
* **Network reconnaissance:** Enumerate internal hosts, ports, and services.
* **Firewall bypass:** Abuse the vulnerable server to access restricted network resources.
* **Remote code execution:** Exploit vulnerable internal services to execute arbitrary code.

***

### Prevention

* **Validate destination URLs:** Allow requests only to trusted hosts using an allowlist.
* **Block internal addresses:** Deny requests to private, loopback, link-local, and metadata IP ranges.
* **Restrict outbound network access:** Use firewall rules to limit external and internal connections.
* **Disable unnecessary URL schemes:** Permit only required protocols such as HTTP and HTTPS.
* **Normalize and validate input:** Prevent URL parsing and encoding bypass techniques.