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 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.
Leave a Reply