What is Business Logic Vulnerabilities?
Business logic vulnerabilities are flaws in the design and implementation of an application that allow an attacker to bring out unintended behavior. This potentially enables attackers to manipulate legitimate functionality to achieve a malicious goal. Most security problems are weaknesses in an application that result from a broken or missing security control (authentication, access control, input validation, etc…). By contrast, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization.
The term “business logic” simply refers to the set of rules that define how the application operates . As these rules aren’t always directly related to a business, the associated vulnerabilities are also known as “application logic vulnerabilities” or simply “logic flaws”.
The business rules dictate how the application should react when a given scenario occurs. This includes preventing users from doing things that will have a negative impact on the business or that simply don’t make sense.
In most applications, business logic is implemented with defined rules, constraints, and user workflows. These rules and flows are defined either at the design stage or easier, when defining business requirements. Developers build these constraints into applications, defining how the application will behave. However, a weak point is the implementation of appropriate access rights at each point of the user flow. Depending on how user inputs are handled and parameters passed to functions and APIs, business logic vulnerabilities can occur.
How Do Business Logic Vulnerabilities Arises?
These flaws often arise because of the loophole in the design and development process. The wrong assumption of how end-user will interact with the application can lead to an inadequate validation of user input. For instance, if the developer is completely relying on the fact that the user will only pass data via the web browser, then it will result in the weak-client side control to validate input, and which can be easily bypassed by using a web proxy (such as Burpsuite).
So in general we can say that when an attacker deviates from the expected user behavior, the application fails to take appropriate steps to prevent this and, subsequently, fails to handle the situation safely.
Logic flaws are particularly common in overly complicated systems that even the development team themselves do not fully understand. To avoid logic flaws, developers need to understand the application as a whole. Developers working on large code bases may not have an intimate understanding of how all areas of the application work. Someone working on one component could make flawed assumptions about how another component works and, as a result, inadvertently introduce serious logic flaws. If the developers do not explicitly document any assumptions that are being made, it is easy for these kinds of vulnerabilities to creep into an application.
Impact of Business Logic Vulnerabilities
The impact of any logic flaw depends on what functionality it is related to. If the flaw is in the authentication mechanism, for example, this could have a serious impact on your overall security. Attackers could potentially exploit this for privilege escalation, or to bypass authentication entirely, gaining access to sensitive data and functionality. This also exposes an increased attack surface for other exploits.
Example of Business Logic Vulnerabilities
EXCESSIVE TRUST IN CLIENT-SIDE CONTROLS
A fundamentally flawed assumption is that users will only interact with the application via the provided web interface. This is especially dangerous because it leads to the further assumption that client-side validation will prevent users from supplying malicious input.
However, an attacker can simply use proxy tools such as Burp Proxy or ZAP to tamper with the data after it has been sent by the browser but before it is passed into the server-side logic. This effectively renders the client-side controls useless.
Accepting data at face value, without performing proper integrity checks and server-side validation, can allow an attacker to do all kinds of damage with relatively minimal effort. Exactly what they are able to achieve is dependent on the functionality and what it is doing with the controllable data. In the right context, this kind of flaw can have devastating consequences for both business-related functionality and the security of the website itself.
MAKING FLAWED ASSUMPTIONS ABOUT USER BEHAVIOR
One of the most common root causes of business logic bugs is wrong assumptions about user behavior. Commonly, developers don’t consider potentially dangerous scenarios that violate these assumptions.
For example, applications can appear secure because they implement a robust way to enforce business rules. However, some developers don’t realize that users and data within the application cannot be trusted indefinitely after passing these strict controls. By applying constraints only at the beginning of the interaction, and failing to verify them later, these applications can allow privilege escalation.
In general, if business rules and security measures are not applied consistently across applications and throughout user interactions, they can create potentially dangerous vulnerabilities that attackers can exploit.
Many logical flaws are related to the specific business domain or the subject matter of a specific application. An example is a discount feature in an eCommerce website. This is a significant attack surface, because it allows attackers to explore underlying logical flaws in the way discounts are applied.
In general, any application function that makes it possible to adjust prices, make payments, or modify any sensitive data value based on user interaction, must be carefully considered. It is important to understand the algorithms the application uses to make these adjustments and in which circumstances they occur. A good way to test this is to manipulate these types of functions, attempting user inputs that will lead to unexpected results.
For more example with practical labs
How to prevent business logic vulnerabilities
Avoid making assumptions about user behavior or the behavior of other parts of the application
Developer should identify what assumptions he have made about the server-side state and implement the necessary logic to verify that these assumptions are met.
It is also important to make sure that both developers and testers are able to fully understand these assumptions and how the application is supposed to react in different scenarios. This can help the team to spot logic flaws as early as possible. To facilitate this, the development team should adhere to the following best practices wherever possible:
Maintain clear design documents and data flows for all transactions and workflows, noting any assumptions that are made at each stage.
Write code as clearly as possible. If it’s difficult to understand what is supposed to happen, it will be difficult to spot any logic flaws. Ideally, well-written code shouldn’t need documentation to understand it. In unavoidably complex cases, producing clear documentation is crucial to ensure that other developers and testers know what assumptions are being made and exactly what the expected behavior is.
Note any references to other code that uses each component. Think about any side-effects of these dependencies if a malicious party were to manipulate them in an unusual way.
Due to the relatively unique nature of many logic flaws, it is easy to brush them off as a one-time mistake due to human error and move on