Business Logic Vulnerabilities (BLVs) are a cause of a lot of headaches in the cybersecurity sphere. And why is that? The primary reason is that, unlike most other vulnerabilities, business logic exploits are heavily contextualized and very difficult to detect automatically, leaving room for different interpretations of the application’s logic, which could go unnoticed by the developers.
“Business Logic Vulnerabilities are the ones where we use the application’s own logic against it”
Table of Content
- What is the Difference Between Regular Vulnerability and Business Logic Vulnerability?
- Busting the Myth: BLVs Cannot Be Automated
- Examples of Business Logic Vulnerability
- Mitigating Business Logic Vulnerabilities
What is the Difference Between Regular Vulnerability and Business Logic Vulnerability?
Regular vulnerability usually occurs when the application has a technical flaw, meaning that a developer made a mistake that best coding practices could’ve prevented. This would include invalid data sanitization, pushing everything directly to the database, etc.
SQL injection is a good example of a technical vulnerability – you inject something into the database that allows you to exit the data context and enter the command context, leaving you with a world of possibilities to harm the application and cause mayhem.
On the other hand, all BLVs do is recognize logical flaws within the application itself, even though from the outside, nothing looks inherently wrong. This is why they’re so revered as the most dangerous and difficult vulnerabilities to recognize and mitigate.
Busting the Myth: BLVs Cannot Be Automated
Back in 1989, when the legendary chess grandmaster Gary Kasparov was asked about machines playing chess, his answer was resolute – he proclaimed that a machine’ll never beat him. Only seven years later, this proclamation would come back to haunt him as he lost to Deep Blue, IBM’s state-of-the-art computer. For as brilliant as he was, even someone like Kasparov was stunned by the rapid development of machines to the point where humans didn’t stand a chance against machines in chess matches since the end of the 20th century.
Well, similar to Kasparov’s theory, there’s a certain sentiments around BLVs that says that, due to complexity and specificity of each use case, business logic vulnerabilities cannot be automated and that they require a human pentester in order to be properly tested.
Regardless of application-specific workflow, we can still identify recurring patterns and find common denominators to create an automatic process that finds the vulnerabilities in the app. Some of those would include:
- Broken access control
- Race conditions
- ID enumerations
- Cart manipulation
- Password resets
- Discount abuse
Examples of Business Logic Vulnerability
Say that we have an e-commerce website in a traditional sense where you have a list of products that you can put in a cart, a checkout page, and ultimately, the payment. In the API checkout call below, we have an example of what that call would look like:
{
"status": "success",
"message": "Thank you for your purchase",
"orderDetails": {
"orderId": 451350,
"orderDate": "2024-12-03T14:25:30Z",
"totalAmount": 366.0,
"items": [
{"itemId": 312, "name": "Wireless Keyboard", "price": 87.0},
{"itemId": 872, "name": "Monitor", "price": 223.0},
{"itemId": 15, "name": "Wireless Mouse", "price": 56.0}
]
}
}
Now, if the totalAmount calculation was put on a frontend, we would be able to change it to any sum we want. So, in a modified version of the call, we would get this:
{
"status": "success",
"message": "Thank you for your purchase",
"orderDetails": {
"orderId": 451350,
"orderDate": "2024-12-03T14:25:30Z",
"totalAmount": 1.0,
"items": [
{"itemId": 312, "name": "Wireless Keyboard", "price": 87.0},
{"itemId": 872, "name": "Monitor", "price": 223.0},
{"itemId": 15, "name": "Wireless Mouse", "price": 56.0}
]
}
}
This wasn’t any traditional vulnerability, it was only using app’s logic against itself in a practical way. This is why moving the logic to the backend and validating every request is so important. Move as many modules as you can away from the user.
Mitigating Business Logic Vulnerabilities
The obvious answer to the question of how to protect against BLVs seems to be quality assurance. A thorough QA process is important, but unfortunately, it’s simply not enough. If you’re doing development at scale & speed, it’s impossible for human QA to test every single scenario with every single endpoint.
The faster you want to release, the more problems you’ll run into, and the whole thing can get messy real fast.
You’ll often see WAF (Web Application Firewall) as an alternative, but it’s far from an ideal solution. That’s because WAF won’t even understand there’s anything wrong with having a BLV due to the fact it’s not set up to recognize contextualized exploits that occur in these scenarios. With business logic vulnerabilities, the attacker is simply using the application within the rulebooks, easily bypassing WAF.
So, what’s the answer to this dilemma?
Continuous testing and automation is what you’re looking for. Say that you have a CI/CD process – simply run the automated tests before pushing them into the QA cycle. Doing that on each iteration is the only way to ensure maximum security in defending against BLVs, at least at a high level.
