API Business Logic: What & Why they exist & how to protect
APIs have taken over, and that is not an exaggeration. The proof lies in the pudding (numbers):
- 83% of all online traffic involves API-based services.
- 2 Million + API Repositories exist on GitHub alone.
- 56% Of developers state that APIs help them create superior products.
Thanks to their ability to interconnect various apps, devices, and platforms, APIs have transformed product features, business offerings, and strategies (both technical and business-end). It is not a stretch to say that APIs are crucial in any industry that seeks a digital presence, be it on the public internet or their own isolated networks. However, as with other technologies, APIs add vulnerabilities like all other software components in existence. Untested or inadequately tested APIs present another point of attack for hackers and malicious individuals. API security disclosures are almost guaranteed to invite infiltration attempts and can harm an organization’s products, internal tech stack, communications, or network efficiency. By connecting applications, APIs can alter how they function. This may create specific vulnerabilities that API-focused hackers know of and invite them to attack said APIs to access their support data and functions. The OWASP API Top 10 List states that insufficient authentication or missing authorization checks in API endpoints can allow malicious individuals to access sensitive data they are not authorized to. Further, by invoking APIs in a distinct order than built, they may be able to access functionality unintended for them, i.e., gain control of the application business logic – a hacker’s dream.
What are the Application’s business logic attacks?
Since every proprietary API is unique, so are its vulnerabilities. Protecting its business logic adds a layer of difficulty for security mechanisms when it comes to defending against them. Let’s understand this with a simple example. Below is an example of a BOLA attack scenario against a famous social network in 2019:
As you see from this example, a group of two APIs and two objects (highlighted) were involved in the breach. The two APIs were chained/connected. Individually each of the API calls is benign. However, the change of object value while calling the second API in the malicious scenario results in the attack. If the second API implementation doesn’t do sufficient security checks, it will result in unauthorized access, breaching the logic built across the two APIs. Current generation products can’t protect against such an attack due to a variety of reasons. First, their architecture limits them to look at every single network session in silos. They don’t understand application behavior or context. Second, they are mostly based on signature while one cannot write a signature to protect the above attempt. Third and a very important point, these attacks are extremely easy to carry out and don’t require deep knowledge of computer systems or network stacks, thereby attracting newbies into attacking APIs. Finding and blocking such API attacks require building a deep understanding of the application behavior and user context that current generation security products lack.
Why API Business Logic exists aplenty?
While shift-left testing has gained wide acceptance in companies, API security is yet to become a fixture in all testing pipelines. Even when it is performed, security test cases are minimal, and the focus is on functional aspects. A few reasons for this disparity are:
- Most generic testing tools aim to detect and resolve traditional exposures, cursory security gaps, and basic vulnerabilities in web apps. They are not designed to examine the business-logic complications of APIs.
- Websites, web apps, and mobile apps have UIs that allow for easier testing of each. However, since APIs do not require UIs, the need to test them often slips.
- If a team has to deal with hundreds (in some cases, thousands) of APIs, testing them manually is a Herculean task that often is not completed for every release major or minor.
- API testing requires a unique set of skills that may not always be available among testers.
- In the case of legacy APIs, testers may not be aware of already implemented APIs or have access to documentation.
Another reason for such issues to exist aplenty is thelimitations of API testing tools for shift-left: Commonly, modern application security testing comprises two major approaches: static security testing and dynamic security testing. Static security testing (SAST) uses the white-box tactic by looking into code for misconfigurations, hard-coding of keys or tokens, common vulnerabilities, etc. This entails examining design, code, and architecture as well as data paths. Dynamic security testing (DAST) leveraged black box testing principles, with test cases built to monitor applications in various real-world user scenarios. It does not require knowledge of an app’s internal mechanisms. Keeping in mind, API exploits are complex business logic exploits, in the case of APIs, there’s a strong debate as to which approach works best to test APIs. To prevent business logic exploits, a tool needs to build a complete understanding of the application behavior and user context. However current generation SAST & DAST tools don’t have the necessary architecture to baseline application behavior and build the required context. Hence benefits of both static and dynamic testing are minuscule for APIs. API testing needs to be approached by first building an understanding of the Application business logic. Leaving API testing, especially security testing out of the shift-left picture leads to major gaps in the security coverage of APIs. The rapid adoption and implementation of APIs also mean that there will be more security gaps and vulnerabilities and organizations will seldom have the bandwidth to address issues in code already built.
How to Protect APIs?
A business logic-first security approach to APIs is needed that introduces greater maturity into the organization’s API ecosystem and enhances the overall potency of its defensive processes and apparatus.
