Parameter Logic Bugs  

Types of Logic Bugs

By now, we should have a fundamental understanding of logic bugs. This section will discuss how we can categorize different logic bugs, discuss our methodology for identifying them, and set up a local environment to follow along with the module.

It is important to note that logic bugs are not as thoroughly researched and studied as other types of web vulnerabilities, such as injections or authentication flaws. So, when writing this module, we needed to come up with new categorization and identification methodology for logic bugs, which required studying and reviewing a great number of logic bug reports, research papers, as well as our own experiences. We hope that such efforts drive the industry forward into advancing the research in logic bugs, and that the categorization and methodologies we created here will help in doing so.

Having a clear definition of what a logic bug is and its different types is crucial for this module, as it allows us to clearly define what qualifies as one. So, let's start by discussing the different causes of logic bugs, and then categorize each into its own type of bugs.

Causes of Logic Bugs

From what we have seen so far, we know that logic bugs are not only found in web apps, but in any application that follows any form of logic, which means that they can basically be found in any type of applications.

We can also understand why automated tools provide little to no value in identifying logic bugs, as they are caused by a flaw in the logic design, and tools would need to fully comprehend the application's logic and design to identify such an issue. For the same reason, tools like Web Application Firewalls (WAF) and Anti-Virus software usually cannot protect against such vulnerabilities, as malicious behaviour to exploit logic bugs usually looks like normal application usage.

So, what exactly causes logic bugs? As you may be able to tell, there isn't a single cause for all logic bugs, but certain common bad coding practices often cause them.

Perhaps the single most important cause for logic bugs is having a weak application logic design. However, designing a sound application logic is much easier said than done, as it requires a firm understanding of the whole application's flow and process to do so. Throughout the module, we will provide different tips and methods for avoiding logic bugs, which should help build a more robust logic design.

A weak logic design can mean that our application does not know how to handle certain kinds of 'unexpected' inputs or conditions, and may default to the wrong action/function that leads to a logic bug. Many developers make the mistake of only designing the application logic to handle the intended use, and do not consider what users may actually do, or other unlikely outcomes of user actions.

A weak logic design can also be due to lack of proper testing of every possible scenario and type of input, or not programming the application to have a default way to handle any other type of input or any unexpected conditions. For example, a developer may use a switch statement for a specific type of input, but they do not default to a specific case. Or a developer may use an if and an else if statements, but not have a general else statement. This can be found in many other areas of coding, like catching specific types of errors but not having a general catch statement, and so on.

In addition to weak logic design, other factors can lead to logic bugs. One example is not having parity between the front-end and back-end logic in web applications, which may cause logic bugs even if the logic is well-designed. There are many other causes for logic bugs, and we'll discuss some of them throughout the module.

Logic Bugs Types

To categorize logic bugs into different types, we need to consider the above-mentioned causes. Many online resources and research papers consider all types of web vulnerabilities (e.g. injections, file uploads, IDORs, LFI, etc) also to be logic bugs. While this is fundamentally true, as even a file upload vulnerability can be considered a logic bug (since the upload logic does not prevent certain file types), we will not be taking this route. Such vulnerabilities are usually caused by weak filtering, like injections, or weak configurations, like weak user access control. So, we will not consider such vulnerabilities to be logic bugs under our own definition.

Instead, we will be mainly focusing on vulnerabilities caused by a weak logic design. Furthermore, we will split this into two types of Logic Bugs: parameter manipulation and flow bypasses. In this module, we will focus on Parameter Manipulation logic bugs only, which has the following types:

Type Description
Parameter Manipulation An application's logic cannot properly handle a specific type of parameters
Validation Logic Disparity Where validation logic varies between front-end and back-end.
Unexpected Input Where bugs are caused by different types of input the application cannot handle.
Null Safety Where bugs are caused by not properly handling null parameters.

As a forward look into flow logic bugs, here are the different types of bugs that fall under it:

Type Description
Flow Bypass An application's flow can be broken due to certain flaws in its design
Repeating One-off Actions Where we are able to repeatedly use actions that should only be carried once.
Out of Order Steps Where we break a multi-step process by doing steps out of order.
Unexpected Behavior Covers all other flow logic bugs, usually caused by a user behavior the application isn't designed to handle.

This categorization should cover the majority of logic bugs. We went through various logic bugs reports, and we found that most would always fall under one of the above categories. In the next section, we will go through the methodology and scenario that we will be following throughout this module.

Previous

+10 Streak pts

Next