Business Logic Exploits

Executive Summary

Business logic exploits are sophisticated attacks that manipulate an application’s intended functions, bypassing traditional security measures. These exploits often target APIs, which expose core business processes, making them particularly vulnerable. Business logic vulnerabilities arise because of oversights in the application design or implementation. Unlike usual attacks, where attackers break into the system, business logic exploits happen within legitimate use of the application, making such type of attack difficult to detect. Traditional security tools, such as WAFs, are ineffective against these threats. Codesealer offers a robust solution by encrypting API communications and securing the application’s integrity, preventing attackers from exploiting vulnerabilities. Implementing Codesealer could have prevented major breaches, like those experienced by Coinbase and Venmo.

What are Business Logic Exploits?

Business logic exploits are attacks that target weaknesses in the functionality and design of an application rather than its technical vulnerabilities. These attacks manipulate the normal flow of business operations to get unintended outcomes, often without triggering traditional security alarms, leaving this type of abuse difficult to detect. The attacker uses the system’s legitimate features in a way that the developers did not expect. For example, an e-commerce site might offer discounts or coupons, and an attacker might find a way to apply the same discount multiple times or even skip certain validation steps, resulting in unauthorized discounts or fraudulent transactions.

APIs Expose Business Logic Directly

Business logic exploits and APIs are closely related because APIs often serve as the primary interface through which an application’s business logic is exposed to external users, including both legitimate users and potential attackers. Keeping in mind that for many applications, APIs have become the central channel where sensitive business data flows from the backend to the user interface, and that 71% of Internet traffic in 2024 was related to APIs, brings us to the conclusion that API attacks are one of the most interesting attack vectors.

With the API attacks, the classic kill chain is significantly shorter. A classic attack flow consists of six steps: reconnaissance, weaponization, infiltration, lateral movement, privilege escalation, and the breach itself. However, attacks targeting APIs often require only two steps: find a vulnerability and exploit it. This shorter kill chain means attackers need less time to execute their malicious actions, giving security teams even less time to detect and respond. Moreover, traditional security tools, like penetration tests against general attack scenarios, such as SQL injection or code execution are not effective against business logic vulnerabilities that are seen as a legitimate use of the application.How do Business Logic Attacks Happen?

Attacks against APIs logic occur when the design or implementation of an API allows users to perform actions that bypass or manipulate the intended business processes. These attacks are made possible by logic vulnerabilities coming from flawed assumptions about how users will interact with the application. Here are some of the examples of different types of business logic exploits and how they can happen.

Parameter Tampering

APIs accept parameters that dictate the behavior of the application, for instance, if you requested to get all flights from Amsterdam to New York on the 16th of October 2024, then APIs will take departure and arrival cities, and date of trip as the main parameters for the search. If these parameters are not properly validated, attackers can manipulate them to alter the business logic.

Imagine an API that allows users to book flights by sending a request with parameters such as origin, destination, departure_date, ticket_class, and price. If the API fails to validate the price on the server side and relies solely on the client’s input, an attacker could manipulate the price parameter to purchase a flight ticket at a much lower cost.

Legitimate request:

POST /book_flight
{
  "origin": "AMS",
  "destination": "JFK",
  "departure_date": "2024-10-16",
  "ticket_class": "economy",
  "price": 500.00
}

In this case, the user is booking an economy class ticket from Amsterdam (AMS) to New York (JFK) on October 16, 2024, at the standard price of $500.00.

Tampered request:

POST /book_flight
{
  "origin": "AMS",
  "destination": "JFK",
  "departure_date": "2024-10-16",
  "ticket_class": "economy",
  "price": 50.00
}

In this tampered request, the attacker has altered the price parameter to $50.00. If the server does not verify the price against a trusted source, such as a database or an internal pricing engine, it might accept this manipulated value, allowing the attacker to purchase the ticket for just $50.00 instead of the intended $500.00.

Inventory Manipulation:

Imagine an online store that reduces inventory only after a purchase is confirmed. At the same time, the API might decrement the inventory count after processing the payment. An attacker discovers that they can make multiple purchase requests for an item without completing the payment step, thereby reserving inventory without actually paying. By doing this rapidly, they might deplete inventory for legitimate customers or artificially inflate demand.

The attacker sends rapid successive API requests but never follow through with the purchase:

POST /reserve_inventory
{
  "item_id": "ITEM123",
  "quantity": 10
}

Flawed Authentication and Authorization

APIs often require authentication and authorization to ensure that users can only perform actions they are allowed to. If these mechanisms are flawed, attackers might gain access to functionality or data they shouldn’t have access to. For example, an API allows users to change their password by sending their user ID and a new password. If the API does not validate that the user is authenticated or authorized to change the password, an attacker could change another user’s password by modifying the user_id in the request.

POST /change_password
{
  "user_id": "12345",
  "new_password": "newpassword123"
}

Tampered request:

POST /change_password
{
  "user_id": "67890",
  "new_password": "hackedpassword"
}

Insecure Direct Object References (IDOR)

IDOR occurs when an API exposes internal implementation objects, such as database keys, as parameters. Attackers can manipulate these references to access or modify unauthorized data. An API allows users to view their order details by specifying an order ID in the request. If the API does not check whether the user is authorized to view the specified order, an attacker could modify the order_id to access someone else’s order.

Request:

GET /orders/12345

Tampered request:

GET /orders/67890

Missing or Insufficient Input Validation

APIs may not sufficiently validate inputs, allowing attackers to send unexpected or malicious data that disrupts the business logic or causes unintended behavior. Let’s consider an API that allows users to upload files as part of a form submission. If the API does not validate the file type or content, an attacker could upload a script or binary file instead of a document, potentially leading to code execution or other attacks.

Expected input:

POST /upload
{
  "file": "document.pdf"
}

Tampered input:

POST /upload
{
  "file": "script.sh"
}

Real world attacks

Coinbase

One of the most famous example of exploits that occurred because of business logic vulnerability happened with Coinbase. In 2022, a white-hat security researcher discovered a critical vulnerability in the Coinbase API. By scraping API calls from the web UI, the researcher found a flaw in the new Advanced Trading feature that would have allowed him to sell BTC or other cryptocurrencies without owning them. The root cause of the bug was a missing logic validation check, leading to an OWASP API#1 Broken Object Level Authorization (BOLA) risk. The Coinbase bug cost the company six hours of closed market and damaged its reputation. The consequences could have been much worse, potentially leading to a full business disruption and loss of clients’ money.

Venmo

This data leak happened several years ago but still remains an illustrative example of what not to do. 200 Million of payments with massive amounts of sensitive data related to Venmo were accessed publicly. The attacker managed to find a publicly accessible developer API with default settings that allowed anyone to view transaction details and harvest as much data as possible. This API was used to show feed with live transactions happening in the app. The filtering of the data was happening in the UI and all private data was flowing there from the backend. With these admin access rights to that API, the attacker scraped all publicly available data during the period of six months, including the entire user’s public transaction history, who they shared money with, when, and in some cases for what reason.

How to prevent this type of attack

Traditional security tools like API Gateways and Web Application Firewalls (WAF) do not fully protect against business logic flaws and API exploits. While WAFs play an important role in blocking malicious requests using defined rules and signatures, they cannot detect hacking behavior within legitimate use of the application.

Knowing that most attacks target API traffic, investing solely in WAF solutions is insufficient. Continuous automated testing against vulnerabilities is essential to ensure new features or app changes do not expose new vulnerabilities. However, APIs have historically been under-tested, and covering all possible business-logic flows is nearly impossible without blocking the development pipeline for extended periods.

To close potential security gaps in your application, Codesealer offers a solution that prevents reconnaissance of the attack surface. By encrypting all APIs, Codesealer prevents manipulation of API payloads. It hides potentially valuable information from attackers, preventing them from accessing the APIs directly and seeing payload structures and responses. By securing the communication channel from the browser to the backend, we protect the integrity and confidentiality of the data throughout its journey.

Codesealer’s solution involves multiple layers of security. Our client-side Bootloader verifies the integrity of the application code before it is executed, ensuring that no unauthorized modifications have been made. Once the application is running, it establishes a secure E2E tunnel that encrypts all data, making it inaccessible to attackers. This approach not only protects against API attacks but also enhances overall security by ensuring that the application code and data remain secure.

With Codesealer in place, the Coinbase bug caused by a missing logic validation check would not have been exploited because the APIs would be encrypted and thus not valuable to attackers. Venmo’s attacker would not be able to see the developer API endpoint and exploit it. Imagine how many more attacks could be prevented with Codesealer in place.

Check our product video to see how Codesealer encrypts APIs and removes attack surface in one click.