Server-Side Request Forgery (SSRF)

In this chapter, we are going to learn about server-side request forgery (or also called SSRF).

Type of vulnerability:	Server-Side
Chances to find:	Common; SSRF is ranked #10 in the “OWASP Top-10 Vulnerabilities“
TL;DR:	An SSRF vulnerability allows an attacker to send requests from an asset behind the firewall. This enables an adversary to potentially access otherwise locked down applications and allows for confidential data extraction.

What is server-side request forgery?

In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like http enabled databases or perform post requests towards internal services which are not intended to be exposed. (src: OWASP)

Let’s have a look at an example. A company might expose a web shop running on port 443 (https) to the public internet. Regular users can browse that website in order to buy something online. The web shop allows to configure a webhook to e.g. configure Slack notifications. This could be useful to get informed once a product is coming out that you have been waiting for.

In order to get a notification sent to your Slack instance, you need to tell the web shop the URL, to which it should send the message. An example HTTP request could look like this:

POST /webshop/user/notification/create HTTP/1.1
Host: example.com
Content-Length: 110

endpoint_type=slack&endpoint_url=https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

The web shop would typically test the notification you are trying to setup and give you some form of visual feedback. This could for example be by displaying the HTTP response coming back from the configured endpoint.

An attacker could now go ahead trying to query some different URL from the one that was intended by the developers of the application. Let’s look at this example:

POST /webshop/user/notification/create HTTP/1.1
Host: example.com
Content-Length: 51

endpoint_type=slack&endpoint_url=file:///etc/passwd

If there is no sanitization, whitelisting or any other preventive measures on the server in place, an attacker could end up reading the content of the passwd file.

The impact of server-side request forgery!

Next to the example in the previous paragraph, there is more impact of an SSRF vulnerability. SSRF typically has a wide range of negative effects on a company. The more common vulnerability reports however find these issues:

Access to a cloud provider’s metadata API (e.g. often allowing retrieval of confidential access token. Examples are listed here)
Access to local files (e.g. disclosing confidential passwords in configuration files)
Access to internal IP addresses which are not reachable from the public network (e.g. allowing exploitation of common vulnerabilities / CVEs)
Access to internal databases without authentication (e.g. allowing to dump all data)

The examples mentioned above only demonstrate a tiny fraction of what is possible when you exploit an SSRF vulnerability. Exploitability depends heavily on the internal network structure and services / applications used by the target.

Where to search for server-side request forgery?

The first thing to do when searching for SSRF vulnerabilities is to use an intercepting proxy (such as Burp Suite) in order to monitor all outgoing requests. Once this is set up, browse the target application and check if there are URLs included in the HTTP request. Make sure to check:

Parameters in the path of a URL or in the body of a request
Request headers (e.g. the referer header) apart from the “Host:” header
Content of data sent to the webserver (e.g. XML files)

Do note that it’s not always the case that URLs are sent in one piece. There is also a good chance that the backend server is using multiple pieces of information to build a URL which it is sending a request to. For testing purposes, this means that you can also try to enter parts of a URL into e.g. a parameter where you think that exploitation might be possible.

Different types of server-side request forgery!

Generally speaking, we have to differentiate between two types of SSRF vulnerabilities:

Basic SSRF
Blind SSRF

The first one (Basic SSRF) describes a vulnerable endpoint where an attacker receives immediate feedback if the manipulated URL was doing the malicious job it was supposed to do. The example in the beginning of this page can be considered a basic or regular SSRF vulnerability.

Blind SSRF vulnerabilities on the other hand are a little more tricky to exploit. Here, we do mean that an attacker is not receiving any feedback by the application if the changed URL was accepted or not.

Feedback could be:

Display of HTTP response (best case)
Custom messaging about the state of the request
HTTP status code

In order to detect blind SSRF vulnerabilities, an attacker would usually use tools such as Burp Collaborator or DNSBin. They both offer you the possibility to create URLs to be used as your “payload”. If you do see a request showing up in those tools coming from the target application, you know that it is potentially vulnerable.

Check out the video below for an example of how a blind SSRF could lead to RCE!

How to test if the application is vulnerable?

Once you have an indicator that an application might be vulnerable to SSRF, you have to weaponize your payloads. We have already seen an example in the first paragraph of this page. Let’s have a look at some more:

In a first attempt, we could try to reach internal network addresses. Try inserting private IP addresses and see if you get a response (e.g. 192.168.0.137). If you try out every possible IP address in an automated fashion, you can run a full fledged port scan of the target network.

Next up, you could try to query a metadata API of a cloud provider (e.g. http://169.254.169.254/latest/user-data/iam/security-credentials/%5BROLE NAME]). Have a look at this Github repo for more endpoints.

We can also try to turn an SSRF vulnerability into cross-site scripting by loading a file that contains an XSS payload (e.g. http://yourdomain.com/xss_poc.svg).

What you can do for all of the above is to try various URL schemes such as file://, dict://, sftp://, ldap://, tftp://, gopher://.

Also make sure to try out the Intigriti SSRF payload generator at https://tools.intigriti.io/redirector/.

How to prevent server-side request forgery?

As SSRF is a vulnerability that comes in various different shapes, preventive measures also look different from case to case. However, there are a number of best practices:

Whitelist all IP / services to which the application needs access
Disable URL schemes that are not needed (e.g. “file://”, “gopher://”, “ldap://”)
Enable mandatory authentication on all reachable services (e.g. databases)
Implement monitoring with anomaly detection on all outgoing http traffic

Additional resources:

Let’s have a look at a video example of an SSRF vulnerability:

In this video, we will have a look at how we can prevent basic SSRF protection controls:

Following links are valuable to learn more about SSRF:

Follow us on twitter for more #BugBountyTips and don’t forget to subscribe to our weekly Bug Bytes, a newsletter curated by Pentester Land & powered by intigriti containing more write-ups and helpful resources.