> For the complete documentation index, see [llms.txt](https://kruknight.gitbook.io/daemon-of-hacking/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kruknight.gitbook.io/daemon-of-hacking/writeups/portswigger-labs/server-side-request-forgery-ssrf.md).

# Server-Side Request Forgery (SSRF)

### Overview

Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to induce a server-side application to make HTTP requests to an unintended location. This has to be internal (e.g., within a private network).

A successful SSRF attack can result in:

* Unauthorized access to internal systems or data
* Information leakage
* Account compromise
* Remote code execution (RCE)
* Attacks that appear to originate from within the organization's infrastructure

SSRF attacks often exploit implicit trust between applications and their backend systems.

***

### Common SSRF Attacks

#### SSRF Against the Server Itself

Involves tricking the server into making requests to itself, typically via `localhost` or `127.0.0.1`, potentially bypassing access controls.

**Example:**

```http
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin
```

* Admin interfaces accessible via localhost can be exposed.
* Some APIs may not enforce auth checks on internal traffic.

#### SSRF Against Internal Systems

Targets services on private IPs, often overlooked due to their presumed safety.

**Example:**

```http
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin
```

* Backend systems may expose sensitive endpoints.

***

### Bypassing SSRF Protections

#### Deny-List Filters

Applications that block specific strings like `localhost` or `127.0.0.1` can be bypassed using:

* Alternative notations:
  * `2130706433` (Decimal for 127.0.0.1)
  * `017700000001` (Octal for 127.0.0.1)
  * `127.1` (Shortened form)
* Custom DNS domains pointing to 127.0.0.1
* URL encoding or case variation

#### Allow-List Filters

Applications that only allow specific domains can be tricked via URL parsing quirks:

* `https://expected-host@evil-host`
* `https://evil-host#expected-host`
* `https://expected-host.evil-host`
* URL encoding the input

#### Using Open Redirects

If an application has an open redirect vulnerability, SSRF can be smuggled through that:

```http
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=https://example.com/redirect?path=http://192.168.0.68/admin
```

***

### Blind SSRF

Occurs when the server makes the backend request, but does not return the result to the attacker. Impact is often lower, but it can still lead to RCE.

#### Detection

* Out-of-Band (OAST) techniques: Use a server you control and monitor for DNS or HTTP callbacks.
* DNS is commonly used since DNS requests are often allowed even when HTTP is not.

#### Exploitation

* Scan internal networks with known exploits or payloads
* Send responses designed to exploit SSRF vulnerabilities (e.g., malicious HTML or scripts)

***

### Prevention

* Block all outbound requests by default; safelist only necessary destinations.
* Use constant, hardcoded URLs/IPs in internal requests where possible.
* Implement strict allow-lists and validate input thoroughly.
* Monitor and limit DNS lookups to trusted sources.
* Protect against open redirection vulnerabilities.