Discovering Business Logic Flaws in Your API Applications

27% of the API attacks in 2023 were business logic attacks, according to “The State of API Security in 2024” by Imperva. For comparison, only a year before, logic attacks made up 17% of the cyberattacks targeting APIs. That’s a significant increase, and there are not many good reasons to think it’ll dwindle.

Business logic vulnerabilities have already found their place among the OWASP Top 10 API Security Risks. They’re also among the Hacker One Top Ten Vulnerabilities based on bug bounty reports between June 2022 and June 2023.

Clearly, business logic vulnerabilities are a force to reckon with, but not in the good sense. And the best way to tackle this security risk is to discover it in your APIs before threat actors find it. This article shows how to achieve this feat. But not before it shows you how terrible a business logic vulnerability involving an API can be.

An Example of a Business Logic Vulnerability in the Wild: Log4Shell

One of the most devastating vulnerabilities ever, Log4Shell, is an example of a business logic vulnerability involving an API.

As a reminder, Log4j is a popular open-source library used in the products and services of tech colossi like Amazon, Apple, Cisco, Cloudflare, Microsoft, and Twitter. Its purpose is to enable:

• Log management
• Communication between different services

What made it vulnerable was the way its two features, JNDI (Java Naming and Directory Interface) lookups and message lookup substitutions, worked together.

JNDI is an API that allows Java software to communicate with and retrieve assets from external servers. JNDI lookups instruct a Java app to reach out to a server and download data or code needed by the app. Applications with vulnerable versions of Log4J run the downloaded code automatically.

Message lookup substitutions, on the other hand, output log data based on user-provided input. For instance, if you input the string ${java:version}, the log records will show which version of Java your software runs.

This capability implies that the message lookup substitutions work not as plain text but as commands. The unanticipated corollary is that someone can use this feature to run arbitrary instructions, including malicious code.

Threat actors can use the JNDI lookup and message lookup substitutions together to:

• Input malicious JNDI lookups that instruct an application to reach out to an external LDAP server and retrieve a malicious payload.
• Download the malicious payload.
• Run it on a Java application’s server automatically.

The consequence is unauthorized full access to your system, allowing threat actors to:

• Shut down the system.
• Start remote shells.
• Perform cryptojacking.
• Exfiltrate data.
• Install ransomware.
• Turn devices into bots.

What makes Log4Shell a business logic vulnerability is the following:

• Log4j is a simple software component whose main function is to record information and events, such as error messages and user inputs, and connect different services through its API.
• The API performed the normal function of connecting services.
• The message lookup substitutions performed the normal function of logging user inputs.
• However, the logic that connected these two aspects didn’t take into account the possible abuse, which is why there were no suitable security mechanisms in place.
• Consequently, the same main function that made Log4j a popular logger turned on its head, allowing hackers to manipulate its logic and cause devastating harm.

How to Discover API-Related Business Logic Vulnerabilities

Log4Shell reminds us how the contemporary complex information environment—comprising disparate components like APIs, open-source dependencies, and web applications—can be disrupted in the worst possible ways by a business logic vulnerability.

More specifically, by flawed logic that rests on the misplaced assumptions that a user:

• Interacts with software in line with how it’s expected to work
• Doesn’t look beyond the front end to find gaps in the software’s logic implementation

The problem with the Log4j API wasn’t technical. It was doing what it was supposed to be doing: connecting an app with an external entity, in this case, servers. That was all intended and expected.

What was not expected was that someone would look behind the UI, find the API, figure out its function, and use it (in conjunction with another functionality) for what it was not intended to do.

When looking at business logic vulnerabilities from this standpoint, you can’t unsee that they call for a completely different approach to security than technical vulnerabilities.

Handling API-related business logic vulnerabilities starts with discovery—knowing that they’re there in the first place. So, the burning question is: How do you find them, taking into account their uniquely elusive nature?

Human thinking and expertise used to be necessary in this process. However, let’s not forget that cybersecurity suffers from a terrible workforce shortage, currently being estimated to amount to 2.8M professionals globally.

Considering what we see currently in the cybersecurity labor market, as well as the fact that API security is a relatively newer discipline, it’s safe to assume that the shortage of API security professionals is among the worst in the industry.

We cannot create these experts ex nihilo.

Moreover, it’s utterly unrealistic to think that manual vulnerability management can follow up with the current threat landscape, its growth rate, the API sprawl, and the API attack surface. As security experts have said themselves so many times, cybersecurity is no longer a human-scale problem.

So, what can we do?

The answer is the following:

• Use a purpose-built API security solution that makes the most of innovative technologies, such as artificial intelligence and machine learning. These can be extremely efficient in dealing with countless scenarios, gazillions of API sequences, and petabytes of data, which are all critical for discovering business logic vulnerabilities.
• Make sure that this solution covers at least the OWASP Top 10 API Security Risks, as they make up the foundation for building your API vulnerability management program and include logic-related security vulnerabilities.
• At the same time, ensure that its vulnerability discovery capabilities go beyond the OWASP API Security Top 10 since these vulnerabilities do not constitute a complete framework, especially in light of all the possible variations of scenarios of logic flaw abuse.

Equixly: Not Your Average API Security Tool

Equixly ticks all the boxes above.

It’s an automated API security solution built with business logic vulnerability management in mind.

What’s more, Equixly was developed by API security specialists; hence, it has embedded human expertise in it. Knowing the pitfalls of misplaced API application logic themselves, Equixly’s creators made sure that the discovery of business logic vulnerabilities is a trademark of this API security platform.

Unlike traditional DAST-based solutions, Equixly is capable of understanding API context and logic. It can generate and test a myriad of API sequences for in-depth testing, looking for as many combinations as necessary to discover flaws in the implemented logic.

Also, due to its proprietary AI engine and applied automation, Equixly drastically decreases the time necessary to complete vulnerability discovery.

Finally, Equixly’s price is a fraction of the costs of manual API security testing.

Have questions? Talk to us—we’re listening.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.