What Are Business Logic Vulnerabilities#
Business logic vulnerabilities are flaws in the design or implementation of an application that let attackers produce unintended behavior.
This can potentially enable attackers to manipulate some other part of a web application for malicious purposes.
These logic flaws aren’t typically found under normal circumstances, and usually only reveal themselves when attackers try to coax them out.
Business logic rules are designed to enforce rules defined during the creation of the application. This includes preventing users from doing things that will have a negative impact on the business or that simply don’t make sense.
Given the definition of these vulnerabilities, they can take many shapes and sizes. This could mean deviating from an intended purchase workflow on an online store to produce some unexpected result - or it could mean skipping a step in the checkout process.
How Do These Vulnerabilities Arise?#
These often arise because of assumptions developers make about how users will interact with the application, which can lead to inadequate validation of user input. For example, if the developers assume that users will pass data exclusively via a web browser, the application may rely entirely on weak client-side controls to validate input.
These vulnerabilities are more common in over-complicated systems that lead developers to have trouble understanding the entire application. Someone working on one component could make flawed assumptions about how another component works and, as a result, inadvertently introduce serious logic flaws.
What is the Impact?#
This can at times be trivial and at other times be serious. The impact relates to what function is being manipulated and what the outcome of that malicious manipulation is.
If attackers are able to exploit the application in ways that let them gain access to special data, escalate privileges, or bypass authentication it could be a real issue.
Keep in mind that even though logic flaws may not allow an attacker to benefit directly, they could still allow a malicious party to damage the business in some way.
With all that being said, lets go over some examples.
Excessive Trust in Client-Side Controls#
You shouldn’t assume that the users will only interact with a web application through the provided web interface. For example, an attacker could use a proxy to tamper with data as it is sent to circumvent client-side controls.
If you accept data at face value without performing proper integrity checks or validation, attackers can do all sorts of damage.
Failing to Handle Unconventional Inputs#
Ideally, you can restrict user input to adhere to the business rules put in place. While the design may accept arbitrary values of certain data types, the logic also needs to follow the same principles.
For example, if you are buying something from an online store where you can set the item quantity you want to buy - any integer may be a valid input, but it still needs to be checked against a business rule that should only let you but items if they are in stock.
To implement effective rules, developers need to consider these scenarios and incorporate ways to handle them in the application logic.
Another example of this would be if you could add a negative amount of items to your cart in an online store, where you could essentially cancel out the cost of another item in the cart.
When testing, try to answer these questions:
- Are there limits being imposed on the data I am submitting?
- What happens when these limits are reached?
- Is there transformation being performed on the inputs?
These could help you find weak input validation on an application.
Unexpected User-Behavior#
One of the root causes for these vulnerabilities is making flawed assumptions about user behavior. Try to keep in mind these three things:
- Trusted users won’t always be trustworthy
- Users won’t always supply mandatory inputs
- Users won’t always follow intended sequence
Trusting Users Too Much#
If you assume that any authenticated user is to be trusted, you might over-provision permissions or make weak policies.
For example, if a application restricts roles based on a username or email format, allowing a user to to change their username or email could open a door for privilege escalation.
Mandatory Inputs#
Browsers can stop users from submitting a form without filling required fields, but this can be bypassed with a proxy.
Sometimes, the application will validate this with a server side script, but if you remove the parameters from the request the script might not throw an error.
When looking for logic flaws, you should try removing each parameter and observing the response. Make sure to:
- Remove one parameter at a time
- Try deleting the parameter name and the value
- Follow the multi-stage process through completion, trying to understand the information being exchanged
This testing applies to both URL and POST parameters. This simple process can reveal some bizarre application behavior that may be exploitable.
Users Won’t Always Follow Intended Sequence#
Many transactions rely on predefined workflows consisting of a sequence of steps. The web interface will typically guide users through this process, taking them to the next step of the workflow each time they complete the current one.
Attackers won’t always follow this intended sequence which can lead to dangerous flaws that may be relatively simple to exploit.
For example, lots of websites have you log in before moving you to the 2FA verification screen, but if you skip past the 2FA it might not force you to complete the check.
To find these, you should try to force certain browsing requests to deviate from the intended sequence.
Domain-Specific Flaws#
In many cases, you will encounter logic flaws that are specific to the business domain or the purpose of the site.
For example, think of a website that gives you a discount if you spend over a certain amount. If the application doesn’t check the balance at the very end of the checkout sequence and instead verifies earlier, then you might be able to just remove the items and get the discount anyways.
To identify these vulnerabilities, you need to think carefully about what objectives an attacker might have and try to find different ways of achieving this using the provided functionality. This may require a certain level of domain-specific knowledge in order to understand what might be advantageous in a given context.
Dangerous Encryption#
Dangerous scenarios can occur when user-controllable input is encrypted and the resulting ciphertext is then made available to the user in some way. This kind of input is sometimes known as an “encryption oracle”. An attacker can use this input to encrypt arbitrary data using the correct algorithm and asymmetric key.
When the application expects certain encrypted data that the user can produce on their own, you might be able to pass values that are interpreted as if they are legitimate.
This issue can be compounded if there is another user-controllable input on the site that provides the reverse function. This would enable the attacker to decrypt other data to identify the expected structure.
Quiz 1 - HTB Academy#
This showcases excessive trust in client-side controls by allowing us to set our role while registering an account.
We run a port scan and find academy.htb as a domain name to use. Once we edit our /etc/hosts file we can do some directory enumeration to find a /register/php page. We also see these endpoints:
---SNIP---
[21:16:46] 200 - 3KB - /admin.php
[21:16:53] 200 - 0B - /config.php
[21:16:58] 200 - 2KB - /index.php
[21:16:58] 200 - 2KB - /index.php/login/
[21:17:00] 200 - 3KB - /login.php
[21:17:06] 200 - 3KB - /register.php
---SNIP---
When we register an account on the site, we are usually just able to set the username, password and repeated password fields. But if we capture the request in Burp Suite we see the following:
Weird - given the web application’s input form, we are not expected to be able to edit this field.
If we submit a registration request with the roleid parameter set to 1, we are able to access the admin.php endpoint after logging in.
This vulnerability is present because the developers probably didn’t consider the possibility that a user could manipulate the roleid parameter and assumed that user input from the registration page was adequately restricted.
Prevention#
- Make sure that developers and testers understand the domain the application is meant to serve
- Avoid making assumptions about user behavior and behavior about other parts of the application
- Maintain clear design documents and data flows for all transactions and workflows
- Write clear code that is easy to read to avoid logic flaws
- Note references to other code that uses other components of the project, think about side effects that the dependencies might cause.