Server-side Request Forgery

Introduction:

Server-side Request Forgery (a.k.a SSRF) occurs when a malicious user initiates an outbound request to another server from the vulnerable server. This is a server-side attack that arises due to a lack of sanitization wherein a target server gets affected (this is not a client-side attack). 

Here, I am describing a basic SSRF attack followed by how to identify and remediate them.

Attack Scenario:

• The attacker looks for the endpoints within the application which fetches external or internal resources as part of the application functionality. Endpoints can be either in the form of GET or POST requests. 

For the sake of example, I have hidden the actual name of the site which displays the contact details of the consumer. This is an intended functionality of the application.

https://subdomain.main.com/plugins/servlet/oauth/users/icon-uri?consumerUri=contacts

• Then he/she tries to fetch another content that is not intended as per business functionality and if he/she gets the response then this confirms the application is prone to SSRF.

To check if the above application is prone to SSRF, I changed the value of the “consumerUri” to “https://google.com” which is as per the functionality not intended.

https://subdomain.main.com/plugins/servlet/oauth/users/icon-uri?consumerUri=https://google.com

I was lucky enough; I got the response as shown below. This confirmed that it is SSRF.

Figure 1: A response from google.com

• He/she then sends a malicious payload by modifying the original request to non-HTTP Protocols like File, SFTP, LDAP, GOPHER, etc. to see if he/she can read the Internal files which are not publicly accessible. It is also possible to scan the Internal network and ports which are behind the Firewall.

Since the site was running on the AWS EC2 instance, I used a query that fetched instance metadata. It got succeeded and got below response:

Figure 2: A Response from AWS EC2 instance about the metadata

You can also use the “file” protocol to fetch the internal files from the file system.

Potential Impact:

1. Extract server-internal files such as password file, config file, etc.
2. Scan Internal Ports which are not publicly accessible 
3. Sometimes leads to Reflected Cross-Site Scripting
4. Also, possible to obtain meta-data of the host for cloud instances

How vulnerable server handle requests will determine what you can do with SSRF.

Remediation:

Always follow a whitelist approach. Only allow domains and protocols that you need and trust.  An additional layer of defense is to sanitize the backend response received from the remote server before sending it back to the end-users and disable the unused protocols.

How to Identify:

Look for functionality within the application that allows the end-users to submit URL or IP address as part of the user Input and see if you can take due advantage of this security vulnerability to render the content other than intended.

Tool:

A Web Application Proxy such as Burp Suite.

Figure 3: A typical SSRF flow for an outbound request

A Bounty Tip: Open Redirect sometimes leads to an SSRF attack. So, before reporting an Open Redirect issue alone, see if you can chain it into SSRF as this increases the overall Impact and Severity level.  You will also be eligible to receive a high bounty amount.

AUTHOR: Vinayak Sakhare