OWASP, API Security OWASP, API Security

A10:2021 OWASP – Server Side Request Forgery

A10:2021 OWASP – Server Side Request Forgery

Introduction

Professionals, dealing with API security, keep an eye on the  OWASP Top 10 List as the list provides detailed insides of cyber threats/issues/vulnerabilities that could be proved fatal if ignored for long. As the recent list is released, everyone from the AppSec domain is curious to know about the vulnerabilities mentioned. 

In past posts, we have explained the top 10 OWASP picks already. The left one is the SSRF vulnerability which has secured 10th place. After all, one can’t afford to take the issue lightly. Its dangers are damage-causing. 

Let’s talk about it in detail today.

Learning Objectives

What is Server Side Request Forgery?

OWASP SSRF when abbreviated, it is a variety of cyber-attack wherein the skilled hacker takes the advantage of the pre-existed vulnerability, present on a server, and uses it against the server. Depending upon the intent of the hacker, an attacker uses SSRF to temper mission-critical server data (stored or passing by) by inserting a corrupted code/link.

The Impact of SSRF

If ignored for a long time, the SSRF attack can cause hassles beyond once it and expectations. The key impacts are as follows:

  • Attackers can use a compromised server as an IP scanner or port to gather the information from front and back-end systems
  • If internal protocols like Gopher are enabled on targeted servers then hackers can easily make a path for further reconnaissance possibilities  
  • A successful SSRF cyber-attack permits threat actors to find out the hidden IP addresses that are running at the back of reverse proxy
  • By creating a possibility for XCE, SSRF creates a base for multiple cyber troubles as malware, viruses, ransomware, and other sorts of ill-intended components can be introduced.

All in all, SSRF can cause big troubles for the victim. 

SSRF and OWASP Top 10 2021

When successful, this vulnerability can cause a wide array of hassles that includes exploitation of servers and related systems, bypassing host-based authentication and IP whitelisting, accessing files stored on the server, exporting the user data, authorized interaction, or access to server-side APIs, and so on.

Seeing this, it’s not shocking to learn why SSRF is included in Top 10s of OWASP. From the very first list released to the newest one, SSRF has always been defined as a potential security threat. However, it got its separate category this time only.

Depending upon the total CVEs reported, SSRF secured 10th place in the OWASP list. Wallarm - a top cybersecurity organization - had already predicted the same in OWASP Top 10 2021 predictions. Based on a huge database and detailed analysis, this prediction emphasizes more on taking SSRF vulnerability seriously. 

Wondering what would be the OWASP Top 10 2022 predictions? Here is what you need.

SSRF in action

The best way to understand how SSRF works and impacts is to get familiar with the Server Side Request Forgery examples. See a few of them here:

Example #1 - Unsegmented network architecture is an opportunity for attackers as they can use them to figure out whether or not the internal server ports are open. If ports are open, they can easily carry an SSRF connection.

Example #2 - Using the URLs like http://localhost:28017/ and file:///etc/passwd</span>, attackers can get into internal services or local files, stealing sensitive data thereafter.

Example #3 - Cloud solutions having stored metadata as http://169.254.169.254/. are easily accessible to the attacker and they can use it to access crucial information.

Example #4 - By modifying the response, an attacker can create a scope for DoS and RCE.

Server Side Request Forgery in action

Main types of SSRF vulnerabilities

For any server-side ecosystem, there are two sides, the server and its internal components and the server with the back-end system. Based on the side impacted by this vulnerability, it has got 2 classifications:

Against the server

This is also known as basic SSRF and refers to the direct display of the outcome of the attack to the hacker. To make this happen, the server accesses the attacker-fetched URL, gathers the information/data/response and shares it with the hacker.

Mostly, the hacker swaps the actual URL with ‘localhost’ or IP 127.0.0.1. Doing so will help the hacker to find out the path that will directly lead to crucial data. This type of SSRF attack is common and can lead to hacker identification if the right kind of investigation is carried out.

Against back-end systems

Here, the threat actor doesn’t directly reach the server or communicate with it. Rather, it involves taking any server back–end system under control and using it to access severe responses or information. So, it is known as blind SSRF too.

When the server transmits data to that compromised back-end system, the hacker will access it and use it as per the will.  As most of the back-end systems feature weak security, hackers don’t have to do much hard work to process it. 

What kind of damage can SSRF do?

Honestly speaking, the damage extent is hard to predict as the outcomes depend on the system configuration, API security practices adopted, and the severity of the attack. However, certain standard dangers follow for sure if an SSRF against you in successful. here are a few examples of what may happen:

It is a potential danger of a successful SSRF attack. Most modern applications use ample HTTP requests and their improper control or management grants an opportunity for attackers for RCE. Mostly, RCE targets the core server like Redis because it could fetch hackers more info that is precious to the victim.

  • Port Scans or Cross Site Port Attack (XSPA)

It’s not necessary that an SSRF-related attack will have to bring the response data to the hacker. To avoid missing any response, an attacker can take the help of an open port. Using an open port, it’s easy to carry out a quick network scan of the application server. This is known as XSPA.

Also, it’s worth noting that network connection timeout maintains the original value and is not bothered about the status of the port/host. A seasoned attacker can use this feature to carry out an SSRF attack by using an acceptable request and using it to define the future network connection timelines.  

Once the request is accepted, attackers are able to record the service existence details on the targeted network and perform the protocol smuggling assaults.

  • Data Exposure

If successful, SSRF vulnerability grants hackers admin-like access to the data stored on the server and its back-end system. The world has already witnessed it when Amazon EC2 became a victim of this vulnerability. A variety of Amazon EC2 instance credentials were compromised. 

Now, if you’re wondering how much data can be exposed or compromised then it’s crucial to understand that it depends on the permissions given to IAM roles. If too many permissions are allowed then entire customer account details can be compromised.

  • Reconnaissance

Enterprises adopt the practice of limiting the usage of servers involved in public dealing. This is done to narrow down the scope of outsiders’ threats. SSRF can use the reserved servers and make them work to gather the data/information/response shared or stored via an internal network and use these details to monitor other servers. This is known as reconnaissance and is a potential danger as one successful attempt can put all your internal servers at risk.

  • Denial of Service (DoS)

As we all know, DoS refers to preventing authorized or permitted users to access a particular resource. When SSRF is considered, the resource here is the server. Because of receiving a higher number of requests, internal servers are designed to handle reduced bandwidth.

However, skilled threat actors can overflow the internal servers with huge traffic. This leads to a DoS attack.

How to identify SSRF vulnerability? 

Early detection is the first toward a successful SSRF mitigation approach. Gladly, it’s not hard to spot the problem if you’re attentive. Here are a few good practices to adopt:

  • Look at partial URLs in the request

It’s very common practice for an application/program to keep a part of the URL or host details while forwarding a request. Such requests, on their receipt in server, are incorporated as a full URL. You have to closely look for the presence of GET-type form inputs or URLs to look for the easy clues of SSRF cyber-attack, for which, the input can reveal the obvious.

  • Pay attention to the data formats

In general, applications, transmitting the data in rich formats, permits the presence of the URL needed for the parsing of data in a preferred manner. For instance, XML often carries the structured data to and fro. So, it makes a path for XXE injections and SSRF. So, if you’re using a data format within an URL, stay alert and adopt adequate SSRF prevention measures.

  • Presence of Referer header

If you’re using server-side analytics software to keep tabs on server visitors then it’s obvious that the software will record the Referer header in requests. This is important for effective tracking of received links.

There is also a possibility that this server analytics software is visiting a third-party URL and it’s appeared in the Referer header. This kind of Referer Header shows a positive environment for SSRF like intrusions.

Mitigating and preventing attacks

SSRF can be proved fatal, if not handled carefully. Hence, it’s important to learn about the best SSRF mitigation techniques. While you’re doing so, make sure that your preventive measures are updated, potential, and capable of making the SSRF attack ineffective. Here are the top four ways using which an organization can reduce the likelihood of such attacks.

  • Response handling

To make sure the server-side or client-side response, against a request, isn’t approachable by any unauthorized user, request-response handling measures should be adopted. For instance, under no circumstances, an unfamiliar response or a raw response body should be processed further.

  • Whitelists and DNS resolution

A better alternative to blacklisting, IP and DNS name whitelist works well as an SSRF preventive solution as it makes the application-accessible IP address/DNS names inaccessible. Also, it’s crucial to perform user input authentication wisely. Actions like not giving access to a private IP address, as it is non-routable, must be taken.

  • Disable unused URL schemas

Always follow the HTTPS or HTTP URL schemas for request initiation and dispose of all the other redundant URL schemas and reduce the scope of SSRF attacks. The more URL schemas you follow or store, the higher the opportunities for the hacker to carry out an attack.

  • Keeping proper access-restrictions for internal services

In case you’re using services like MongoDB, Memcached, Redis, and MongoDB, it’s essential to enforce solid authentication. As these services lack default authentication, hackers can use them as a means to conduct the SSRF attack. When strong authentication measures are implemented on such internal services, they become safe to use.

Wallarm will protect against SSRF vulnerability

Even though SSRF has the potential to create a great ruckus, the right kind of assistance and timely actions can lead to early SSR mitigation. Wallarm, a renowned AppSec platform, offers a wide range of security tools that can help you prevent the SSRF.

Capable of protecting resources like APIs, serverless workloads, and applications stored on servers, this cloud WAF requires only a minor DNS change to work. Its automatic tuning and nearly zero false-positive results ensure that you always get accurate protection against SSRF-related dangers. This is the first even cloud WAF offering the assistance of automated incident analysis. Hence, it is a hard pass.

With Wallarm’s API Threat Prevention, it’s easy to keep your server-side APIs protected from SSRF. The solution works on all the leading APIs and is compatible with all sorts of ecosystems, including IBM Cloud, AWS, and Service Mesh.

Along with SSRF, many other cyber-vulnerabilities (including OWASP Top 10) can be stopped in their infancy stage.

Subscribe for the latest news