# Bypassing Restrictions

## Bypassing Blacklist <a href="#ssrf-with-blacklist-based-input-filters" id="ssrf-with-blacklist-based-input-filters"></a>

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 various techniques:

* Using an alternative IP representation of `127.0.0.1`, such as `2130706433`, `017700000001`, or `127.1`.
* Registering your own domain name that resolves to `127.0.0.1`. You can use `spoofed.burpcollaborator.net` for this purpose.
* Obfuscating blocked strings using **URL encoding** or **case variation**.

## Bypassing Whitelist <a href="#ssrf-with-whitelist-based-input-filters" id="ssrf-with-whitelist-based-input-filters"></a>

The server could have implemented its whitelist via **poorly designed regular expressions (regexes)**. Regexes are often used to construct more flexible whitelists. For example, instead of checking whether a URL string is equal to `expected-host`, a site can check regex expressions like `.*expected-host.*` to match the subdomains and filepaths of `expected-host` as well. In those cases, you could bypass the regex by placing the allowlisted domain in the request URL. You can try the following methods to bypass the regex:

* You can embed **credentials** in a URL before the hostname, using the `@` character. For example: `https://expected-host@evil-host`
* You can use the `#` character to indicate a **URL fragment**. For example: `https://evil-host#expected-host`
* You can leverage the **DNS naming hierarchy** to place required input into a fully-qualified DNS name that you control. For example: `https://expected-host.evil-host`
* You can **URL-encode** characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request.
* You can use combinations of these techniques together.

## Bypassing SSRF Filters via Open Redirection <a href="#bypassing-ssrf-filters-via-open-redirection" id="bypassing-ssrf-filters-via-open-redirection"></a>

It is sometimes possible to circumvent any kind of filter-based defenses by exploiting **open redirection**. In the preceding SSRF example, suppose the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target. For example, suppose the application contains open redirection in which the following URL:

```url
/product/nextProduct?currentProductId=6&path=http://evil-user.net
```

returns a redirection to:

```uri
http://evil-user.net
```

You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows:

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

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin
```

This SSRF exploit works because the application first validates that the supplied `stockAPI` URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection, and makes a request to the internal URL of the attacker's choosing.

## Reference

{% embed url="<https://portswigger.net/web-security/ssrf>" %}
What is SSRF (Server-side request forgery)? Tutorial & Examples - Web Security Academy
{% endembed %}


---

# 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://ret2basic.gitbook.io/ctfnote/web/csrf-and-ssrf/server-side-request-forgery-ssrf/bypassing-restrictions.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.