At the end of the first quarter, Salt Labs of Salt Security released a report addressing the state of Application Programming Interfaces (API) security. Over the past 12 months, 95% of organizations running production APIs have experienced an API security incident and API attacks have more than doubled for 2022. The report also showed that malicious API traffic increased by 681% and overall API traffic increased by 321%.
Traditional security measures fail to protect organizations from API attacks and most organizations aren’t prepared to handle the challenges that come with the attacks – having no real API security strategy. API use is growing at an astounding rate and 26% of organizations use twice as many APIs today than they did in 2021.
Everyday threat actors are realizing how lucrative it can be to target APIs. That fact coupled with the failing of traditional security measures is the prime reason why APIs are a favored attack vector for threat actors. To keep your organization from becoming a victim of an API attack, you’ll need to implement a security strategy that was built specifically for API attacks. Let’s take a look at how API attacks are different from other attack vectors and how your organization’s cyber environment can remain secure.
Understanding what Application Programming Interfaces are, is crucial in order to know how to keep API vulnerabilities at bay. An API is a software and allows two applications to communicate with each other. If you’ve checked the weather on your mobile phone, used a social media app, or sent an instant message, then you’ve used an API.'
When you use an app on your mobile phone, the app connects to the internet – sending data to a server. After the data is sent, the server retrieves the data and interprets it before sending it back to your phone. Once the application interprets the data, it then presents you with the information you wanted in a readable way.
Although it may appear as such, your phone’s data is not completely exposed to the server and the server is never completely exposed to your phone. Both your phone and the server communicate with small packets of data, and they only share what’s necessary.
In the past, APIs were described in generic terms as a connectivity interface to an application. However, today’s APIs are more complex and have characteristics that make them far more valuable than previous years. Today’s APIs adhere to HTTP and REST standards and are developer friendly. They are also designed for consumption for particular audiences and are documented for consumption and versioning.
Because APIs are a preferred attack vector for threat actors, it’s important to make sure your organization is vigilant regarding API security. The API attack surface is growing at a rapid rate and the average number of APIs per company has increased 221% in just 12 months. Because threat actors know how valuable and lucrative it is to attack APIs, the number of attacks has increased.
Unfortunately, existing security measures don’t work for APIs and those measures are not stopping threat actors from stealing sensitive data and causing damage to an organization’s API. A lot of times, organizations will implement API gateways, API management tools, firewalls, and IAM tools to prevent API attacks. However, the truth is that those tools were not designed to prevent API attacks and securing APIs comes with its own set of challenges. Those challenges include:
According to Salt Lab’s API report, 40% of the respondents surveyed were concerned about their organization’s API programs. Also, lack of expertise/resources (35%), as well as budget constraints were the biggest roadblocks to API security. Some organizations (34%) didn’t even have an API security strategy, while 27% had a basic strategy. Only 27% of the organizations surveyed had a robust API security strategy – including API testing and protection. For organizations that don’t have a more advanced API strategy and the proper resources in place, it will be almost impossible for them to stop API attacks.
When it comes to API security, there seems to be confusion regarding who should be held accountable for and shoulder the responsibility for API security. Salt Lab’s API report indicated that most of the respondents believed the responsibility should rest with the developers, DevOps, or DevSecOps, while the rest believed that AppSec or InfoSec teams should be responsible.
To overcome this, organizations are starting to share the responsibility between application security and DevOps teams. Thirty-four percent of the respondents in the report stated that security teams collaborate more with DevOps to address API security, while another 30% said DevOps receives input from security teams to help structure API guidelines. Twenty-five percent of the organizations placed security engineers within their DevOps teams to address the challenge.
In April 2022, a flaw was found in the API of a large U.S. based Fintech company. FinTech platforms provide a digital transformation service for banks, which allows them to change many of their banking services to online services. The API vulnerability was a server-side request forgery (SSRF) flaw and could have allowed threat actors to compromise millions of bank customers. They could have defrauded clients by controlling their bank accounts and funds.
According to Threat Post, Salt Labs identified the flaw in the API through a web page that was supporting the FinTech platform’s fund transfer functionality. The functionality is used to transfer client’s money from their accounts on the FinTech platform and into their own bank accounts.
FinTech is integrated into many banking systems and is used daily by millions of people. If threat actors successfully exploited an API flaw in one of the platforms, they would have been able to leak users’ personal data, transfer funds into their own bank accounts, and gain administrative access to the banking system. Salt Labs stated that API vulnerabilities are appealing for threat actors for two reasons:
According to Salt Lab, the FinTech vulnerability was found in the request parameters that send data for the transfer of funds. The parameter is called “InstitutionURL”. In this particular case, the API endpoint recognized a JWT administrative token which contained no group restrictions and returned a list of every user and its details across the platform. These kinds of flaws make financial institutions especially vulnerable to API attacks.
In November 2018, 60 million U.S Postal Service (USPS) user had their data exposed because of broken API for the postal service’s InformedDelivery. InformedDelivery allows users who signed up for the service to look at their incoming mail, set delivery instructions, manage deliveries, track packages, etc. The vulnerability was discovered in 2017, but there were no actions taken to fix the issue until the week of November 26, 2018. As a result, 60 million USPS users had their information leaked.
The breach included mailing campaign data, phone numbers, and email addresses. The breach also allowed the attackers to see and search other users on the site, allowing for the attackers to see when mail was arriving at someone’s home
In February 2018, Facebook was breached, compromising about 50 million users. The breach was the result of an API attack and was the largest cyber attack in Facebook’s history. The threat actors behind the breach stole access tokens, which is a security key that allows users to stay logged into their Facebook account without having to re-enter their password every time they log in. If an attacker has one of these tokens, they can take full control of an account – including third-party applications that use Facebook Login. Stealing access tokens is the easiest way to access an API.
The above attacks are excellent examples of what is known as BOLA (Broken Object Level Authorization). According to API Security, BOLA happens when an attacker substitutes the ID of their own resource in the API with an ID of a resource belonging to another user. This allows attackers to access the specified resource if there aren’t proper authorization checks. These kinds of attacks are common with APIs in general and are not unique to FinTech APIs. Organizations can help prevent these attacks by doing the following:
As we stated earlier, traditional security measures simply don’t work for APIs. Traditional security measures fail to protect API management platforms against attacks that target the unique business logic of APIs, which in turn keeps organizations at risk. Organizations relying on gateway alerts, web application firewalls, and log file analysis are sure to experience attacks, as these tools have failed to detect API attacks – giving organizations are false sense of security.
If an organization relies solely on log file analysis, they only ensure that threat actors have already accessed the data, it does nothing to detect the actual attack. Let’s take a look at some other reasons why traditional security measures are not ideal for API platforms:
Now that you know why traditional security doesn’t work for API platforms, you’re probably wondering what you can do to address the security issues and protect your organization. There are seven kinds of API attacks:
The best ways to secure your APIs are as follows:
API security means shifting your organizations focus from traditional security measures and implementing API specific best practices. Developing a sound API security strategy is the first step to protecting your organization and Avertium can help take things a step further by providing you with the following services:
This document and its contents do not constitute, and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.
Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of Client's compliance with any law, regulation or standard.
COPYRIGHT: Copyright © Avertium, LLC and/or Avertium Tennessee, Inc. | All rights reserved.