Server-Side Request Forgery

EXPLOITATION

SSRF stands for Server-Side Request Forgery. These vulnerabilities can cause a webserver to make an extra or edited HTTP request to target a resource or arbitrary domain on the vulnerable web app of the attackers' choosing. This is a more general term for using a target-server request for the benefit of the attacker, but it should be noted that remote and local file inclusions are more specific types of SSRFs.

Think of this as a way of "tricking" the server by asking it to do something that the creators of the web app didn't want it to do, but didn't create the necessary preventions to stop it from executing this modified request.

There are two main types of SSRF vulnerabilities:

Regular SSRF
Blind SSRF

In a regular SSRF, data is returned to the attacker's screen, and in a blind SSRF, no information is returned to the attacker, but the attack is still successful.

Impacts of a successful SSRF attack include:

Unauthorized access to data
Ability to manipulate data
Remote control execution (RCE)
Reveal sensitive authentication information/tokens

For more information, check out this guide to SSRF vulnerabilities by Cobalt.

HOW TO SPOT SSRF VULNERABILITIES

When an address bar contains a full URL in a parameter
The use of a partial URL such as just the hostname
The use of a URL path

EXPLOITING AN SSRF VULNERABILITY

The following are common ways that an SSRF vulnerability can be exploited, but a lot of this will depend on the web app server structure, software, and how hardened or vulnerable it is. Source: HackTricks

Accessing to local files (file://)
Trying to access to local IP
Local IP bypass
DNS spoofing (domains pointing to 127.0.0.1)
DNS Rebinding (resolves to an IP and next time to a local IP: http://rbnd.gl0.eu/dnsbin). This is useful to bypass configurations which resolves the given domain and check it against a white-list and then try to access it again (as it has to resolve the domain again a different IP can be served by the DNS). More info here.
Trying to make an internal assets discovery and internal port scan.
Accessing private content (filtered by IP or only accessible locally, like /admin path).

A lot of testing and exploiting SSRF vulnerabilities has to do with trial and error, viewing source code, and combining other aspects of web app pentesting to see which HTTP requests can be exploited to make fraudulent or unintended requests.

DEFENSES AGAINST SSRF

Experienced web developers will know about the risks of SSRFs and will take necessary precautions to patch up any vulnerabilities that would exist that would allow an attacker to make forged server requests. Here are some common defenses that web developers may employ and also ways to get around them. For more info, here is an SSRF defense cheat sheet.

Deny List - also known as blacklist-based input filters, can be used to block certain input resources from being accessed. This could include denying any input that contains hostnames or sensitive URLs like /admin.
- Ways to circumvent deny lists:
  - 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.
  - Using null bytes to bypass URL filters
Allow List - also known as whitelist-based input filters, can be used to allow only specified types of input and block all others. This is a much safer method than blacklisting since it doesn't require specifying all the undesired types of input, instead, you just have to specify the input that will be accepted.
- Ways to circumvent allow lists:
  - 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.

OPEN REDIRECT

A good way to bypass any and all filter-based protection is by using an open redirection vulnerability. This is a guide from PortSwigger:

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 an open redirection vulnerability 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.

Page updated

Google Sites

Report abuse