API Attacks & Best Practices

Executive Summary

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.

what is an api

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.'

How Does an API Work?

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.

The importance of api security + why api security is different

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:

• The API landscape is constantly changing and its nearly impossible to keep up with changed or new APIs. Documentation is of little use since its almost always out of date or incomplete.
  
  
• While other kinds of attacks such as SQL injection attacks are quick and follow the protocols for leveraging known vulnerabilities, API attacks do not. The attacks are slow and because every API is unique, so are the attacks. Threat actors often probe the APIs for business logic gaps they can exploit.
  
  
• Finally, although pre-production testing is able to find gaps in API security best practices, they don’t uncover vulnerabilities within API business logic gaps – developers don’t write fully secure code all the time.

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.

who is to blame?

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.

fintech and other api attacks

Fintech

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:

1. Their API landscape is rich and complex, which makes room for errors and overlooking details in development.
2. If a threat actor can abuse the API platform, the profits are massive because it could allow them to control millions of bank accounts and funds.

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.

United States Postal Service

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

Facebook

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.

BOLA

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:

• Use random IDs
  
  
• Don’t rely on client IDs, use IDs stored in the session object
  
  
• Authorization checks should be implemented with user policies and hierarchy
  
  
• Each client request should be checked for authorization in order to access the database

why traditional security does not work

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:

• Your organization’s developers may have limited exposure to APIs. While implementing them doesn’t require an expert, developers could misconfigure APIs if they aren’t familiar with them. Due to human error, threat actors wouldn’t even need to put much effort into stealing an organization’s data. If you don’t have a well-versed team who is familiar with API best practices, then there is no way for the team to see the vulnerabilities and address them before deploying the APIs into production. Make sure developers are up to speed on all things API.
  
  
• Your organization’s team has a lack of visibility. Sometimes, an organization will develop APIs and then cast them from their memory. This means that there is barely any inventory of the APIs involved in a workload. While it may be inconvenient for a team to focus on the tedious task of inventory, it’s better than having a huge portion of APIs slipping through the cracks. Validating APIs and their behaviors is difficult for a lot of organizations – they simply aren’t sure how to find out which API isn’t working the way it should be and which one is misconfigured.
  
  
• The volume of API attacks is growing and it’s becoming harder to implement security. The rate that APIs are developing exceeds the rate at which organizations can secure their APIs. DevSecOps teams try to make sure that API builds are functional, as well as secure, but sometimes it can be impossible for those teams to be on top of security.
  
  
• Traditional security practices are not effective. Organizations tend to rely on Web Application Firewalls or API gateways, but those tools work best with other modern tools that can scan your APIs for misconfigurations or give insight into your workloads. A WAF may be able to see that an API request was successful, but it will not see that the token was reused against an endpoint it should not have access to.
  
• Organizations have improper security ownership structure. If an organization does not have a clear security ownership structure, misconfigured APIs will definitely find their way to production. Having a proper ownership hierarchy in place before you start working on an application, could prevent confusion.
  
  
• Rushing to push new API releases to the market can lead to teams cutting corners in security implementation. In a cloud era, it’s not possible to have a totally secure application. Because of this, teams are less willing to put security first. Developers should reconsider pushing releases before they are ready because delivering an application that could be vulnerable to attacks is worse than missing a set deadline.

How Your Organization Can Remain Safe with API Best Practices

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:

• Man in the Middle – this attack happens when a threat actor sneakily alters or intercepts messages and requests between two parties to glean sensitive information.
  
  
• Data Exposure – credit card information, passwords, session tokens, and more is frequently processed and transferred by sensitive data. If an application doesn’t encrypt the data in transit or at rest, it could be compromised.
  
  
• DDoS Attack – this happens when a threat actor disrupts the traffic of a network or server by overwhelming the surrounding infrastructure of a website through internet traffic. It creates unusual traffic and jams up your site, making legitimate traffic unable to reach your website.
  
  
• Injection Attack – this attack method inserts SQL queries into input fields through the SQL database underlying the system.
  
  
• Parameter Tampering – threat actors may manipulate the parameters exchanged between a client and a server, allowing the modification of application data like permissions or user credentials.
  
  
• Authentication Hijacking – a threat actor could try to bypass or break authentication methods the API is using.
  
  
• Unencrypted Communications – Transport Layer Security (TLS) should be used to encrypt the data exchanged between clients and servers, thus avoiding the man in the middle attack. This is the final step to securing your API.

The best ways to secure your APIs are as follows:

• The first thing you need to do is take inventory of all the APIs in your workloads. It’s tedious but it can be done with the help of automated tools that can identify known, as well as unknown APIs. They can also provide insight and information about APIs that could be important to securing your environment.
   
  • The automated tools that use machine learning to identify the nature of your APIs and their normal behavior, are available. Using these tools will help you to differentiate between anomalies and malicious behavior. To ensure that threat actors don’t exploit APIs that fall through the cracks, implement mature tools to scan APIs at runtime.
    
    
• Implement authentication and authorization. Before a request is processed, an API performs authentication to verify the identity of a user or program that sent the request. APIs authenticate via a password, authentication token, or muti-factor authentication. The OAuth protocol is the accepted standard for API user authentication. Authorization is implemented after verifying the identity of the user sending the request
   
  • REST APIs especially must authenticate and authorize each request made to the server, even if several come from the same user. You can govern authorization by user roles, giving each role different permissions. Adhere to the principle of least privilege and only grant users access to resources necessary for their role.
    
    
• All requests need to be validated. Sometimes, requests can come from valid sources, but could actually be a hacking attempt. This is why APIs need rules to govern if a request is friendly, friendly but invalid, or harmful. The request should not reach the application data layer without passing a thorough validation check.
  
  
• All requests and responses should be encrypted – making any intercepted requests or responses useless to threat actors without the right decryption method. Using Transport Layer Security (TLS) will successfully encrypt REST APIs.
  
  
• Only necessary information should be included in responses. An API response could expose information that threat actors can take advantage of if you are not careful. Responses that are sent to the end-user should only contain information to communicate the success or failure of the request or the resource requested.
  
  
• To prevent brute force attacks, throttle API requests and establish quotas. Quotas limit the number of requests a user’s is allowed over a span of time. Throttling will slow the users’ connection but will still allow them to use the API.
  
  
• You must log API activity. If an attacker breaches the above protections, you’ll be able to see how they did it. You’ll also be able to use the attack to harden your API and prevent attacks from happening in the future.
  
  
• Instead of waiting until you are attacked to see how your safeguards hold up, conduct security tests by intentionally hacking into your API. Security tests ensure that you expose vulnerabilities.
  
  

MITRE MAP

How Avertium is Protecting Our CUSTOMERS 

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:

• To identify the source of your breach and the scope that it reached; you’ll want to include Avertium’s DFIR services in your protection plan. We offer DFIR (Digital Forensics and Incident Response) to mitigate damage from a successful breach.
• Avertium offers VMaaS to provide a deeper understanding and control over organizational information security risks. If your enterprise is facing challenges with the scope, resources, or skills required to implement a vulnerability management program with your team, outsourced solutions can help you bridge the gap.
• Avertium offers Zero Trust Network as a Service (ZTNaaS) for any organization that wants to control their attack surface. The zero-trust security model delivers exactly what the name promises: it's an IT security concept that specifies no access is allowed until the successful completion of authentication and authorization processes.
• Avertium has virtual CISOs who can provide a high level of service by helping you develop a plan to conduct a physical hardware inventory assessment. This service includes a visibility study to help discover what devices are on your network. This can be done remotely or in person.

Avertium’s Recommendations 

• Make sure only authenticated users can access your endpoints.
• Only grant the necessary endpoints to users based on their roles.
• The correct information should be returned in the responses for each potential request (take a lesson from FinTech’s API vulnerability).
• Reject benign but invalid requests.
• All data transfers should be encrypted.
• Run a parameter tampering test to see if your API responds with the correct error codes.
• Inject NoSQL, LDAP, OS, SQL and other commands in API inputs to test if your API is vulnerable to injections.
• Conduct a Fuzz test by pushing your API to its limits in order to discover any security issues that have not been revealed. This requires sending a large number of randomized requests (SQL queries, system commands, arbitrary numbers, etc.) to see if your API responds with any errors or if it processes any of the inputs incorrectly. This kind of test mimics Overflow and DDoS attacks.

SUPPORTING DOCUMENTATION

API Security Trends (salt.security)

API Attacks Increased by 681%, Affecting 95% Of Organizations, Salt Labs State of API Security Report 2022 Says - CPO Magazine

https://oauth.net/

Salt Labs API Threat Research

API1:2019 — Broken object level authorization (apisecurity.io)

Scorched Earth: Hacking Banks and Cryptocurrency Exchanges Through Their APIs (nonamesecurity.com)

How to prevent API Security Attacks (l7defense.com)

Scorched Earth: Hacking Banks and Cryptocurrency Exchanges Through Their APIs (nonamesecurity.com)

API Security 101 - Security Boulevard                

USPS Data Breach Exposed Information of 60 Million People (secureforensics.com)

8 API Security Best Practices to Protect Sensitive Data (hubspot.com)

SSRF Flaw in Fintech Platform Allowed for Compromise of Bank Accounts | Threatpost

7 Reasons Your API Security Strategy is Failing & how to fix it - Amazic

What is an API? (Application Programming Interface) | MuleSoft

Facebook says nearly 50m users compromised in huge security breach | Facebook | The Guardian

What is an API Attack - Reblaze

Salt Security Discovers Critical API Security Vulnerability That Would Have Enabled Administrative Account Takeover on FinTech Platform Serving Hundreds of Banks (prnewswire.com)

Top 3 Attack Trends in API Security – Podcast | Threatpost

APPENDIX II: Disclaimer

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.