What Are Server-Side Request Forgeries And How To Exploit Them

Server-Side Request Forgeries (SSRF) vulnerabilities arise when any kind of web service or component (like an app or API) uses your input to craft a request on behalf of the server.

And this can have quite a few consequences, such as:

• Make requests to any external resource on behalf of the server
• Reach internal services (& read secrets such as AWS/GCP Metadata)
• Read local files (if local file read is supported & permitted)
• Execute code (in some severe cases)
• Cause Denial of Service

Common Web App Components That Are Vulnerable to SSRF:

• Profile image loaders (some allow you to load external images via a URL but don't validate response content-type)
• PDF Generators/Exporters (more on this later)
• CORS Proxies (used to bypass Cross-Origin Resource Sharing)
• Third-party integration support
• Etc.

Basic SSRF Exploitation:

I've had cases where it was this easy to exploit an SSRF, you just supply your own URL and you get the full response back:

You can find several cases like these by performing "more" & "better" content discovery.

Our built-in content discovery scanner, SPIDER X, is more than capable of finding app routes and API endpoints referenced in pages as well as in javascript files, on internet archives, or other common web config files.

Advanced SSRF Exploitation Techniques:

1) Protocol Validation Bypasses:

You'll come across filters most of the time and most of them will try to limit the protocol you specify.

Fortunately, there are bypasses when filters try to allow you to specify for example relative paths only.

//{HOST}
\\{HOST}
////{HOST}
\\\\{HOST}
http:{HOST}
https:{HOST}
/%09/{HOST}
/%0A/{HOST}
/%OD/{HOST}

Where {HOST} is a host that you control. Just in case you aren't aware yet, Nova Security Pentest Suite offers a personal Out-of-Band (OOB) server for you to use for examples like these!

2) Host Validation Bypasses:

Some developers take a step further and will validate the supplied resource or host as well.

Again, fortunately, there are bypasses for these types of filters as well.

.{HOST}
@{HOST}
example.com.{HOST}
example.com@{HOST}
example.comx.{HOST}
{HOST}#example.com
{HOST}?example.com
{HOST}#@example.com
{HOST}[email protected]
127.0.0.1.nip.io
example.com.127.0.0.1.nip.io
127.1
localhost.me

Same here as well, where {HOST} is a host that you control.

In some cases, you'll find yourself that only the main domain (or perhaps all its subdomains as well) is whitelisted.

In that case, you could use an open redirect vulnerability to bypass these restrictions as well. Fortunately for you, most request libraries follow redirects by default and Nova Security also features a scanner that can help you find Open URL Redirect vulnerabilities at scale!

An example:

Passing http://127.0.0.1 blocked our request, however, using an open URL redirect vulnerability that was found on one of the whitelisted domains did allow us to request the contents of http://127.0.0.1:

More Advanced SSRF Exploitation Techniques:

3) SSRF in PDF Generators and Exporters:

In case you find a vulnerable PDF generator or exporter feature and can inject HTML tags (like heading 1 or i-tags).

Try to inject an <iframe> that points to "localhost" or any other host to download the response:

<iframe src="http://127.0.0.1/"></iframe>

Or a script tag that allows you to fetch the contents of http:// localhost & inject it into the body:

<script>
  var r = new XMLHttpRequest();
  r.onload=function(){ document.write(this.responseText) };
  r.open('GET','file:///etc/hosts');
  r.send();
</script>

4) Second-Order Server-Side Request Forgeries (SSRFs):

Second-order server-side request forgeries (SSRFs) are much harder to spot as they require some experience with the web app you're testing.

Second-Order SSRFs are basically SSRF vulnerabilities but they require a prior request to be sent before reaching the vulnerable app layer.

An example:

I recently had a case where the front-end API would take my input and forward it to the backend API (without any kind of validation)

It would reflect my input right in the path of the URL that the backend URL would take to make the second request to the internal database.

As you can see in the illustration above, I injected my payload inside the customerId body parameter.

This same parameter would then get reflected in the following query on the backend API:

And that allowed me to be able to break-out and construct my URL that the backend server would then follow.

5) SSRF via DNS Rebinding:

Now say you've come across a situation where the developer has hardened SSRF exploitation for you.

The developer now made sure to:

1. First, make a quick DNS query to resolve the hostname of the supplied URL
2. Match that hostname against a whitelist
3. And based on the results make a request or block it

An example:

Believe it or not, this approach may seem robust but it is anything but that as it is vulnerable to TOCTOU (time of check, time of use).

To exploit a server-side request forgery via DNS rebinding, we could trick the vulnerable web app that it is going to make a connection to a trusted host while it isn't.

We do this by responding with 2 different DNS answers on the 2 different DNS queries made.

The first DNS answer will have the desired result for the vulnerable web app to continue with our request, and the second DNS answer will contain the hostname we want it to connect to.

In practice, this will look something like the following:

Of course, no third-party DNS server would want to comply with our special request, or at least not at the speed we need it to be.

This means that we will need to set up our own private DNS server. If you already have a domain name:

1. Go to your domain name registrar (this can be Namecheap, Cloudflare, AWS Route 53, etc.)
2. Next, setup custom nameservers for your domain (ns1 & ns2)
3. Point both of these nameservers to the IP of your VPS (the server you'll host your DNS server on)
4. Setup a custom DNS server on your VPS that will respond to DNS queries as mentioned above

You can create your own DNS rebinding server or use an open-source solution on GitHub.

Exploiting Blind Server-Side Request Forgeries (SSRF):

Blind server-side request forgery (SSRF) vulnerabilities are like full SSRF vulnerabilities with the exception that you won't be able to read the response in clear text (or sometimes only limited parts of it).

This means that you won't be able to read AWS/GCP metadata or see the response of internal services for example.

However, sometimes they can still prove impact. A few examples:

If you can spot a difference in the response returned (for example the status code) when an existing host is reached vs a non-existing one, you could:

- Map out an entire internal network (basically get all private IPs that are alive)
- Enumerate all active ports out of the 65 535 networking ports
- Send emails on behalf of the server (if SMTP is supported)
- In severe cases get a reverse shell by for example exploiting Redis < 7.0 (with Gopher enabled)

These are some of the most common SSRF exploitation techniques, I hope you've learned something new today!