Bypassing Restrictions

Bypassing Blacklist

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

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

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:

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

returns a redirection to:

http://evil-user.net

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

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

PreviousAttacksNextSSRF + Redis

Last updated