Salt Labs Launched To Heighten API Security Threat Awareness

Anyone with a stake in keeping ahead of cybersecurity assaults and enterprise network intrusions through an application programming interface (API) vulnerabilities can now tap into expert advisories and security reports.

Salt Security, on July 14, announced the launch of Salt Labs, a now-public forum for publishing research on API vulnerabilities. Through its vulnerability and threat research as well as industry reports, Salt Labs will be a resource for enterprises looking to harden infrastructure against API risk.

The company aims to fill a void in available information on API risk and vulnerability research highlights. Salt Labs was created as a resource for Salt Security customers, as well as the wider industry, to increase public awareness of API security threats, harden infrastructure against API risk, and accelerate business innovation by making APIs attack-proof and resilient.

API security concerns have become a significant inhibitor of business innovation, according to Salt.

Salt also released its first research report detailing four recently discovered API vulnerabilities impacting financial services businesses. This first threat research report, “Detailed Financial Records Exposed on Financial Services Platform,” serves as a glaring example of such an outlet.

The team discovered multiple API vulnerabilities that could enable attackers to view customer financial records, delete customer accounts, perform account takeover (ATO), or create a denial of service condition that would render entire applications unavailable.

APIs are software codes that allow computer applications to access data and interact with external software components, operating systems, or microservices. The process delivers user responses to a system and sends the system’s response back to a user.

“With the growth of APIs and the central role they play in today’s application environments, the need for unbiased, relevant, and reliable research has prompted us to share the groundbreaking API security research that our team has been conducting for years,” said Roey Eliyahu, co-founder and CEO of Salt Security.

A Case in Point

According to the Salt Security State of API Security Report, 66 percent of organizations have delayed the deployment of a new application because of API security concerns. To counter these concerns, Salt Labs’ research and reports will enable organizations to improve their API security posture and mitigate threats impacting API-centric businesses.

Utilizing a deep technical understanding of API threats, security gaps, and misconfigurations, Salt Labs focuses on three objectives. It aims to deliver high-impact threat research, uncover the latest API attack vectors, and provide remediation best practices to make API security programs increasingly agile and actionable.

Salt Labs researchers investigated a large financial institution’s online platform that provides API services to thousands of partner banks and financial advisors. As a result of multiple API vulnerabilities, researchers found attackers were able to launch attacks where:

• Any user could read the financial records of any customer.
• Any user could delete any customer’s accounts in the system.
• Any user could take over any account.
• Any user could create a denial-of-service condition that would render entire applications unavailable.

Salt’s researchers exploited these high-severity API security vulnerabilities in the financial services platform:

• Broken Object Level Authorization (BOLA)
• Broken Function Level Authorization (BFLA)
• Susceptibility to parameter tampering
• Improper input validation

Reporting Strategies

Researchers anonymized any technical details of the vulnerability that could identify the organization so as not to expose the financial entity to any additional risk. Salt Lab officials reviewed these findings with the organization and shared the information publicly to improve awareness around API security by detailing relevant attack patterns, technical details, and mitigation techniques for each vulnerability.

Many API issues only exhibit themselves as APIs are running within a completely integrated application, system, and architecture, according to Michael Isbitski, technical evangelist at Salt Security. Code analysis alone will not cover you, and it also is not feasible in cases of third-party-owned code or external service integration.

“Testing APIs thoroughly in runtime without the aid of machines is a complex and time-consuming endeavor. It is difficult to find relevant subject matter expertise to run all the necessary tooling and understand results of what is being uncovered since API issues cross a number of technology and security domains,” he told TechNewsWorld.

Hidden Cybersecurity Concern

APIs are not always called out by name as a facet of cybersecurity. But APIs underpin most modern system designs and software supply chains.

“Many incidents we are seeing in the industry, including supply chain attacks, occur because of APIs being left unsecured or APIs were used as a critical step of an attack chain,” said Isbitski.

Realistically, organizations concerned about API security risks should be looking for purpose-built API security offerings that are designed as platforms, he added. Such solutions provide a range of capabilities to secure APIs throughout the lifecycle.

Divergent Trajectories

API proliferation and API security, unfortunately, are on divergent trajectories, according to Setu Kulkarni, vice president of strategy at NTT Application Security. APIs are proliferating exponentially faster than the security testing of these very APIs. Meanwhile, creating and deploying APIs is easier than ever.

“Examining metadata and live traffic analysis is becoming a better way to discover APIs than just merely enlisting them based on developer feedback,” he told TechNewsWorld.

API security testing follows the pattern of API functional testing. That is, using the base framework provided by functional testing tools to orchestrate the API call sequence to ensure that security tests are exercised in those call sequences, Kulkarni explained.

“Dynamic testing is turning out to be the most sure shot way of examining APIs for security. Dynamic testing is being adapted to developer usage,” he added.

Common Business Models

APIs are fast becoming the technical basis for B2B and B2C business models. As such, when APIs are developed and deployed, there is really no way to estimate all the possible places the APIs are going to get used, according to Kulkarni.

“APIs are silently but rapidly becoming one of the most critical pieces of the software supply chain. Organizations are now one vulnerable API call away from a potential major breach,” he warned.

An underlying challenge that gets obfuscated is the fact that APIs today are facades to legacy systems that were never designed to be online or used in an integrated B2B or B2C setting, observed Kulkarni.

“By creating an API layer, these legacy transactional systems are enabled to participate in digital transformation initiatives,” he said.

This pattern of API enablement of legacy systems creates security issues. They otherwise would not have been issues in the controlled trusted zones the legacy systems were designed to operate in.

Fixing API Security

When it comes to API-first and microservices-based applications, there is not adequate attention paid to security — which often is not a documented or measured requirement.

“Moreover, even if security were a requirement, development teams do not know what good secure APIs look like,” Kulkarni noted.

He offered these strategies to overcome these challenges:

• Always ask for what security measures have been taken to secure the APIs you are planning to use from a partner or third party (internal or external). If you ask, you will know. Otherwise, you will just assume.
• Test your APIs in production — whether they are wrapper APIs for legacy systems or new API-first applications. There is no substitute for testing in production.
• Ensure your product management team is documenting security-related abuse cases as requirements during development. Make security an exit criterion.

The security team should include asking developer teams about API security measures as a checklist item in their acceptance criteria, Kulkarni suggested.

Also, focused developer training is needed to ensure just enough training is available to developers to make them effective and not overburden them, he added.